소프트웨어 개발의 최신 경향을 쫓다 보면, 분명 두 가지 용어를 만나고 또 만날 것이다. 바로 도커(Docker)와 쿠버네티스(Kubernetes) 인데, 본질적으로는 컨테이너와 오케스트레이션을 가리키는 말이다.
도커 컨테이너는 애플리케이션을 개발과 테스트를 거쳐 프로덕션으로 이전하는 과정을 최적화해 주며, 도커와 쿠버네티스 둘은 애플리케이션을 구축하고 배치하는 방식을 재창조해 획일적인 단일체 소프트웨어 스택이 아니라 마이크로서비스의 모음으로 바꿔준다.
도커와 쿠버네티스가 왜 중요하며, 이 둘이 소프트웨어 개발을 어떻게 바꾸고 있으며, 이 과정에서 각각이 맡은 역할이 무엇인지 살펴보자.
도커와 컨테이너
리눅스와 윈도우, 그리고 기타 현대적인 운영체제가 지원하는 컨테이너는 소프트웨어가 자체 보유한 작은 환경에서 실행될 수 있도록 해 준다. 이 환경은 시스템의 나머지 부분과 격리된다. 컨테이너는 가상머신과 비슷하지만, 가상머신이 아니다. 컨테이너는 가상머신보다 더 날렵하며 기동과 정지도 더 빠르고 유연성과 이동성도 더 뛰어나다. 컨테이너는 단 몇 초 만에 확장하고 축소할 수 있으며, 클라우드와 같은 탄력적인 환경에서 애플리케이션을 더 쉽게 구동할 수 있다.
리눅스와 기타 운영체제가 컨테이너화된 애플리케이션을 지원하는 것은 오래 된 일이다. 하지만 컨테이너를 사용하는 것은 그리 사용자 친화적이지 않았다. 오픈소스이기도 하고 상용 소프트웨어이기도 한 도커는 기존의 컨테이너를 사용자 친화적이고 개발자 친화적인 환경으로 만든 주역이다. 도커는 컨테이너를 위한 공통 툴 세트를 제공해 애플리케이션을 컨테이너 이미지로 패키징해 기업 내에는 물론 다른 곳에도 쉽게 배치하고 재사용할 수 있다.
쉽게 말해 도커는 컨테이너 이미지를 생성하고 관리하고 공유하고 여러 곳으로 옮기고 도커 호환 호스트에 배치해 컨테이너를 구동하는 작업을 똑딱이 단추를 풀고 잠그는 것만큼 간단한 것으로 만들어 버린다.
도커와 컨테이너를 사용해야 할 때
도커와 컨테이너는 다음과 같은 속성을 가진 워크로드를 다룰 때 안성맞춤이다,
- 탄력적인 확장성. 수요를 맞추려면 얼마나 많은 앱 인스턴스를 실행해야 할지 모를 때가 있다. 이 때 컨테이너화된 앱과 서비스는 컨테이너 인스턴스 몇 개를 더 적게 혹은 더 많이 배치하는 것으로 수요에 맞춰 확장하고 축소할 수 있다.
- 격리. 다른 앱과 섞이지 않는 앱이 필요할 때가 있다. 서로 다른 버전의 API 여럿을 만족하기 위해 여러 버전의 앱을 나란히 나란히 구동해야 할 수도 있고, 아니면 기반 시스템을 깨끗하게 유지하기 위해 새로 배치한 앱이 아무런 영향을 미치지 않도록 해야 할 수도 있다. 기반 시스템을 깨끗하게 유지하는 것은 언제나 좋은 생각이다.
- 이식성. 하나의 앱을 여러 환경에서 구동해야 하고, 각각의 구성을 복제해야 할 때가 있다. 컨테이너는 애플리케이션의 전체 런타임 환경을 패키징해 도커 호환 호스트가 있다면 어디에나 쉽게 배치할 수 있다. 개발자 데스크톱부터 QA팀의 테스트 시스템, 로컬 장비, 원격 클라우드 등 가리지 않는다.
쿠버네티스와 컨테이너 오케스트레이션
컨테이너는 원래 프로세스나 애플리케이션을 서로서로 그리고 기반 시스템으로부터 격리하기 위해 만들어졌다. 그래서 개별 컨테이너를 생성하고 배치하기는 쉽다. 하지만 여러 컨테이너, 그러니까 데이터베이스와 웹 프론트엔드, 연상을 위한 백엔드 등 여러 컨테이너를 모아 하나의 단위로 관리할 수 있는 커다란 애플리케이션으로 만들고자 한다면 문제가 달라진다. 더구나 이들 컨테이너 각각을 독립적으로 배치하고 연결하고 관리하고 확장할 수 있어야 한다면? 이 모든 구성요소를 전체로 기능하도록 조직할 방법이 필요하다.
이 작업이 바로 쿠버네티스가 도전하는 영역이다. 만약 컨테이너가 크루즈선의 승객이라면, 쿠버네티스는 크루즈선의 선장이다.
구글이 시작한 프로젝트를 기반으로 하는 쿠버네티스는 여러 컨테이너 애플리케이션을 여러 대의 호스트에 배치하고 관리하는 작업을 자동화하는 방법을 제공한다. 각각의 컨테이너를 직접 하나씩 관리하지 않아도 된다. 개발자는 여러 컨테이너에 걸친 애플리케이션의 배치도를 작성하는데, 여기에는 각 컨테이너가 네트워킹과 스토리지를 사용하는 방식 등의 세부 정보가 담겨 있다. 쿠버네티스는 런타임에서 나머지 부분을 처리한다. 또한 기밀이나 앱 환경 구성 같은 성가신 세부 관리도 맡는다.
쿠버네티스를 잘 사용하기 위해서는 상당한 전문지식이 필요하다. 물론 턴키 솔루션으로 사용되는 경우가 많다. 쿠버네티스의 사용 편의성이 개선된 데는 일반적인 애플리케이션용으로 언제나 사용할 수 있는 레시피(헬름 차트)가 한몫했다. 레드햇이나 캐노니컬, 도커 같은 이름있는 업체들도 쿠버네티스 배포판을 인기 있는 애플리케이션 스택과 개발 프레임워크에서 사용할 수 있는 쿠버네티스 배포판을 만들면서 여기에 일조했다.
쿠버네티스 컨테이너 오케스트레이션을 사용해야 할 때
소수의 사용자를 위한 비교적 단순한 컨테이너 앱은 보통 오케스트레이션이 필요없다. 쿠버네티스까지 건드릴 필요가 없다. 하지만 만약 앱의 기능과 사용자 수가 사소한 수준 이상이라면, 오케스트레이션 시스템을 사용하지 않고 직접 해결하기 어려워진다. 다음과 같은 경우에는 오케스트레이션을 반드시 사용해야 한다.
- 복잡한 앱. 두 개 이상의 컨테이너가 관련되는 앱이라면 오케스트레이션을 사용하는 것이 좋을 것이다. 하지만 사용자 수가 많지 않고 크기도 보통인 앱이라면 쿠버네티스보다는 도커 스웜(Docker Swarm) 모드 같은 좀 더 최소화된 솔루션을 사용하는 것이 좋다.
- 확장성과 복구성이 중요한 앱. 쿠버네티스를 비롯한 오케스트레이션 툴은 조건이 바뀔 때마다 코딩으로 대응하지 않고, 원하는 시스템 상태를 서술하는 방식으로 워크로드와 컨테이너 간의 균형을 맞출 수 있다.
- 현대적인 CI/CD 기법을 적용하고 싶을 때. 오케스트레이션 시스템은 블루/그린 배치나 롤링 업그레이드를 사용하는 앱을 위한 배치 패턴을 지원한다.
도커와 쿠버네티스가 좀 더 사용자 친화적인 추상화 기술에 밀려나고 좀 더 우아하게 컨테이너를 생성하고 관리하는 방법이 등장할 날이 올지도 모른다. 하지만 현재 컨테이너와 오케스트레이션을 이용하기 위해서는 도커와 쿠버네티스를 알아야 한다.
