도커 스웜을 사용하는 이유
docker ps 명령어는 하나의 도커 엔진에 존재하는 컨테이너 목록을 출력하며 create, run 명령어 또한 하나의 도커 엔진에 컨테이너를 생성하는 명령어입니다. 그러나 실제로 도커를 운영 환경에 적용한다면 실전에서는 일부 달라질 수 있습니다. 하나의 호스트 머신에서 도커 엔진을 구동하다가 CPU나 메모리, 디스크 용량과 같은 자원이 부족하다면 어떻게 처리해야 할까요? 가장 간단한 정답은 매우 성능이 좋은 서버로 구축한다는 것이 제일 좋은 명답이지만 비용적인 측면에서는 권장할 수 없겠죠? 자원이 부족할 대 마다 더 성능이 좋은 서버를 살 수는 없을뿐더러 높은 가격의 서버를 사고 유지하는 비용 또한 부담될 수밖에 없으므로 이를 해결하기 위한 여러 가지 방법이 제안됐었습니다. 그중 현재 가장 많이 사용하는 방법은 여러 대의 서버를 클러스터로 만들어서 자원을 병렬로 확장하는 방법이 가장 많이 사용되고 있습니다. 예를 들어 8GB 메모리가 탑재된 서버 3대에 도커 엔진을 설치해 실제 운영 환경에 사용한다고 가정하면 3대의 서버에 컨테이너가 너무 많이 생성돼 있어 더는 컨테이너를 사용할 수 없다고 판단되면 8GB의 메모리가 탑재된 새로운 서버를 추가해 자원을 늘리는 것입니다. 이렇게 추가된 서버의 자원만큼 클러스터 내의 가용 자원은 늘어나므로 총 사용 가능한 자원은 32GB가 됩니다. 따라서 필요한 만큼 많은 서버를 병렬로 확장해 나가면 적당한 성능의 여러 대를 하나로 만들어 사용할 수 있고 비싼 서버를 살 이유가 없어집니다. 하지만 여러 대의 서버를 하나의 자원 풀로 만드는 것 또한 쉽지 않겠죠? 새로운 서버나 컨테이너가 추가됐을 때 어떤 서버에 컨테이너를 할당할 것인가에 대한 스케줄러와 클러스터 내의 서버가 다운됐을 때 고가용성을 어떻게 보장할지 등이 문제로 남아 있을 수 있습니다. 하지만 다행히도 이러한 문제를 오픈 소스로 활용할 수 있습니다. 이 가운데 가장 대표적인 것이 바로 도커에서 공식적으로 제공하고 있는 도커 스웜과 스웜 모드입니다.
스웜 클래식과 도커 스웜 모드
스웜 클래식과 스웜 모드는 여러 대의 도커 서버를 하나의 클러스터로 만들어 컨테이너를 생성하는 여러 기능을 제공합니다. 다양한 전략을 세워 컨테이너를 특정 도커 서버에 할당할 수 있고 유동적으로 서버를 확장할 수도 있습니다. 그뿐만 아니라 스웜 클러스터에 등록된 서버의 컨테이너를 쉽게 관리할 수 도 있습니다. PaaS와 같은 용도로 도커 서버 클러스터링을 고려하고 있다면 가장 먼저 스웜을 사용해 보는 것을 권장합니다. 비록 도커 스웜 모드가 실제 운영 환경에서 많이 쓰이는 것은 아니지만 서버 클러스터에서 컨테이너를 어떻게 다루는지에 대한 기초적인 지식을 쌓기에 적합하기 때문입니다. 서버 클러스터에서의 컨테이너 관리에 익숙하지 않다면 한 번쯤은 경험해봐도 괜찮을 것 같습니다.
도커 스웜에는 두 가지 종류가 있습니다. 첫 번째는 도커 버전 1.6 후부터 사용할 수수 있는 컨테이너서의 스웜이고, 두 번째는 도커 버전 1.12 이후부터 사용할 수 있는 도커 스웜 모드입니다. 두 가지 종류의 스웜을 구분하기 위해 첫 번째를 '스웜 클래식'. '두 번째를' 스웜 모드라고 부르겠습니다. 스웜 클래식과 스웜 모드의 가장 큰 차이점은 바로 그 목적에 있습니다. 스웜 클래식은 여러 대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근 점을 제공하고 있다면 스웜 모드는 마이크로 서비스 아키텍처의 컨테이너를 위한 클러스 링 기능에 초점을 맞추고 있습니다. 스웜 클래식은 docker run, docker ps 등 일반적인 도커 명령어와 도커 API로 클러스터의 서버를 제어하고 관리할 수 있는 기능을 제공합니다. 이에 비해 스웜 모드는 같은 컨테이너를 동시에 여러 개 생성해 필요에 따라 유동적으로 컨테이너 의의 수를 조절할 수 있으며, 컨테이너로의 연결을 분산하는 로드밸런싱 기능을 자체적으로 지원합니다. 개발하는 애플리케이션의 특성에 따라 적절한 것을 선택해 사용하면 되지만, 스웜 모드가 서비스 확장성과 안정성 등 여러 측면에서 스웜 클래식보다 뛰어나기 때문에 일반적을으로 스웜 모드를 더 많이 사용합니다. 스웜 클래식과 스웜 모드의 다른 점은 분산 코디네이터 에이전트와 같은 클러스터 툴이 별도로 구동되느냐입니다. 여러 개의 도커 서버를 하나의 클러스터로 구성하려면 각종 정보를 저장하고 동기화하는 분산 코디네이터, 클러스터 내의 서버를 관리하고 제어하는 매니저, 각 서버를 제어하는 에이전트가 반드시 있어야 합니다. 스웜 클래식은 분산 코디네이터, 에이전트 등이 별도로 실행돼야 하지만, 스웜 모드는 클러스터링을 위한 모든 도구가 도커 엔진 자체에 내장돼있기 때문에 더욱 쉽게 서버 클러스터를 구축할 수 있습니다. 대규모 클러스터에서 서비스를 운영하는 것을 계획하고 있다면 스웜 클래식보다는 스웜 모드를 사용하는 것이 좋습니다. 스웜 모드는 마이크로 서비스 아키텍처 애플리케이션을 컨테이너로 구축할 수 있도록 도와줄 뿐만 아니라, 서비스 장에 대비한 고가용성과 부하 분산을 위한 로드밸런싱 기능 또한 제공하고 있기 때문입니다. 스웜 클래식을 사용해 도커 클러스터를 구축하는 것이 불가능한 것은 아니지만, 스웜 모드를 사용하면 더욱 많은 기능을 손 수 쉽게 사용할 수 있으므로 가능하다면 스웜 모드를 사용하는 것을 추천합니다.
스웜 모드 앞에서 설명한 것과 같이 스웜 모드는 별도의 설치 과정이 필요하지 않으며 도커 엔진 자체에 내장되어 있습니다. docker info 명령어를 통해 도커 엔진의 스웜 모드 클러스터 정보를 확인할 수 있습니다. 지금까지 도커 엔진을 사용해온 방법들은 전부 단일 도커에서 사용된 것이므로 현재 스웜 모드 상태는 비활성화로 되어 있습니다.
도커 스웜 모드의 구조
스웜 모드는 매니저와 노드와 워커 노드로 구성돼 있습니다. 워커 노드는 실제로 컨테이너가 생성되고 관리되는 도커 서버이고 매니저 노드는 워커 노드를 관리하기 위한 도커 서버입니다. 그렇지만 매니저 노드에도 컨테이너가 생성될 수 있습니다. 즉 매니저 노드는 기본적으로 워커 노드의 역할을 포함하고 있습니다. 매니저 노드는 1개 이상이 있어야 하지만 워커 노드는 없을 수도 있습니다. 이는 매니저 노드가 워커 노드의 역할도 포함하고 있어 매니저 노트만으로 스웜 클러스터를 구성할 수 있기 때문입니다. 그러나 일반적으로 워커 노드와 매니저 노드를 구분해서 사용하는 것을 권장합니다. 스웜 매니저는 가능한 홀수 개로 구성하는 것이 바람직합니다. 스웜 모드는 매니저 노드의 절반 이상에 장애가 생겨 정상적으로 작동하지 못하면 장애가 생긴 매니저 노드가 복구될 때까지 클러스터 운영을 중단합니다. 이때 매니저 노드의 개수를 홀수로 구성하면 짝수로 매니저 노드를 구성했을 때보다 매니저 노드의 장애를 더 허용할 수 있으며, 매니저 노드 사이의 데이터 일관성을 유지할 수 있습니다.
스웜 모드 서비스 개념
지금까지 계속 사용해온 도커 명령어의 제어 단위는 컨테이너입니다. docker run 명령어는 컨테이너를 생성하고, docker rm 명령어는 컨테이너를 삭제했던 것처럼 도커 클라이언트에서 사용하는 명령어가 제어하는 것은 컨테이너입니다. 그러나 스웜 모드에서 제어하는 단위는 컨테이너가 아닌 서비스입니다. 서비스는 같은 이미지에서 생성된 컨테이너의 집합이며, 서비스를 제어하면 해당 서비스 내의 컨테이너에 같은 명령이 수행됩니다. 서비스 내에 컨테이너는 1개 이상 존재할 수 있으며, 컨테이너들은 각 워커 노드와 매니저 노드에 할당됩니다. 이러한 컨테이너들을 태스크라고 부릅니다. 예를 들어 Ubuntu:14.04 이미지로 서비스를 생성하고 컨테이너 수를 3개로 설정했다고 가정해보면 스웜 스케쥴러는 서비스의 정의에 따라 컨테이너를 할당할 적합한 노드를 선정하고 해당 노드에 컨테이너를 분산해서 할당합니다. 이처럼 함께 생성된 컨테이너를 레플리카라고 하며, 서비스에 설정된 레플리카의 수만큼의 컨테이너가 스웜 클러스터 내에 존재해야 합니다. 스웜은 서비스의 컨테이너들에 대한 상태를 계속 확인하고 있다가 서비스 내에 정의된 레플리카의 수만큼 컨테이너가 스웜 클러스터에 존재하지 않으면 새로운 컨테이너 레플리카를 생성합니다.