[Docker] Docker Swarm Cluster 생성

Docker Swarm을 사용하는 이유

일반적인 도커 사용법은 대부분 하나의 호스트를 기준으로 한다. 예를 들어 docker ps 명령어는 하나의 도커 엔진에 존재하는 컨테이너의 목록을 출력하며 create, run 명령어 또한 하나의 도커 엔진에 컨테이너를 생성한다. 그러나 실제 도커를 서비스 환경에 적용한다면 문제가 생길 수 있다.

만약 하나의 호스트 머신에서 도커 엔진을 구동하다가 CPU나 메모리, 디스크 용량과 같은 자원이 부족하면 어떻게 해결할까?

가장 간단한 해결 방법은 '성능이 좋은 서버를 새로 구매'하는 방법일 것이다. 하지만, 자원의 확장성 측면이나 비용 측면에서도 이는 좋은 해답이 아니다. 자원이 부족할 때마다 성능이 좋은 서버를 구매할 수 없을 뿐만 아니라 높은 가격의 서버를 사고 유지하는 비용 또한 무시할 수 없다. 이를 해결하기 위해 여러 가지 방법이 제안되었지만, 가장 많이 사용하는 방법은 여러 대의 서버를 클러스터로 만들어 자원을 병렬로 확장하는 것이다.

예를 들어 8GB의 메모리가 탑재된 서버 3대에 도커 엔진을 설치해 실제 운영 환경에 사용한다고 가정해 보자. 
이 3대의 서버에 컨테이너가 너무 많이 생성되어 있어 더이상 컨테이너를 사용할 수 없다면 8GB의 메모리가 탑재된 새로운 서버를 추가해 자원을 늘리는 것이다. 이렇게 추가된 서버의 자원만큼 클러스터 내의 가용 자원은 늘어나므로 총 사용 가능한 자원은 32GB가 된다. 따라서 필요한 만큼 많은 서버를 병렬로 확장해 나가면 적당한 성능의 서버 여러대를 하나의 자원 풀로 만들어 사용할 수 있고, 성능이 좋은 비싼 서버를 구매하지 않아도 된다.

그러나 여러 대의 서버를 하나의 자원 풀로 만드는 것은 쉬운 작업이 아니다.

새로운 서버나 컨테이너가 추가되었을때 이를 Service Discovery 하는 작업부터 어떤 서버에 컨테이너를 할당할 것인가에 대한 스케줄러와 로드밸런서 문제, 클러스터 내의 서버가 다운되었을 때 HA을 어떻게 보장할지 등은  추가적인 문제이다. 

다행히도 이러한 문제를 해결하는 여러 솔루션을 오픈소스로 해결할 수 있다. 이 가운데 대표적인 것이 바로 도커에서 공식적으로 제공하는 '도커 스웜'과 '스웜 모드'이다.

스웜 클래식과 도커 스웜 모드

'스웜 클래식'과 '스웜 모드'는 여러대의 도커 서버를 하나의 클러스터로 만들어 컨테이너를 생성하는 여러 기능을 제공한다. 다양한 전략을 세워 컨테이너를 특정 도커 서버에 할당할 수 있고 유동적으로 서버를 확장할 수도 있다. 그뿐만 아니라 스웜 클러스터에 등록된 서버의 컨테이너를 쉽게 관리할 수 있다. 따라서 PaaS와 같은 용도로 도커 서버 클러스터링을 고려한다면 가장 먼저 스웜을 사용해보는 것이 권장된다.

비록 도커 스웜 모드가 실제 운영 환경에서 많이 쓰이는 것은 아니지만, 서버 클러스터에서 컨테이너를 어떻게 다루는지에 대한 기초적인 지식을 쌓기 적합하기 때문이다. 

도커 스웜에는 두 가지 종류가 존재한다. 첫 번째는 도커 1.6 버전 이후부터 사용할 수 있는 컨테이너로서의 스웜이고, 두 번째는 도커 버전 1.12 이후부터 사용할 수 있는 도커 스웜 모드이다. 앞으로 두 가지 종류의 스웜을 구분하기 위해 첫 번째를 '스웜 클래식', 두 번째를 '스웜 모드'라고 부르겠다.

스웜 클래식과 스웜 모드의 가장 큰 차이점은 바로 그 목적에 있다.
스웜 클래식은 여러 대의 도커 서버를 하나의 지점에서 사용하도록 단일 접근점을 제공한다면, 스웜 모드는 MSA의 컨테이너를 다루기 위한 클러스터링 기능에 초점을 맞추고 있다. 

스웜 클래식은 docker run, docker ps 등 일반적인 도커 명령어와 도커 API로 클러스터의 서버를 제어하고 관리할 수 있는 기능을 제공한다. 반면 스웜 모드는 같은 컨테이너를 동시에 여러 개 생성해 필요에 따라 유동적으로 컨테이너의 수를 조절할 수 있으며 컨테이너로의 연결을 분산하는 로드밸런싱 기능을 지원한다. 개발하는 애플리케이션의 특성에 따라 적절한 것을 선택해 사용하면 되지만, 스웜 모드가 서비스의 확장성과 안정성 등 여러 측면에서 스웜 클래식보다 뛰어나기 때문에 일반적으로 많이 사용된다.

스웜 클래식과 스웜 모드의 또 다른 차이점은 '분산 코디네이터 (Distributed Coordinator)', '에이전트'와 같은 클러스터 툴이 별도로 구동되느냐이다. 여러개의 도커 서버를 하나의 클러스터로 구성하려면 각종 정보를 저장하고 동기화하는 분산 코디네이터, 클러스터 내의 서버를 관리하고 제어하는 매니저, 각 서버를 제어하는 에이전트가 반드시 존재해야 한다. 

스웜 클래식은 분산 코디네이터, 에이전트 등이 별도로 실행되어야 하지만, 스웜 모드는 클러스터링을 위한 모든 도구가 도커 엔진 자체에 내장되어 있기 때문에 더욱 쉽게 서버 클러스터를 구축할 수 있다. 따라서 대규모 클러스터에서 서비스를 운영하고자 한다면, 스웜 클래식보다는 스웜 모드를 사용하는 것이 좋다. 스웜 모드는 MSA 애플리케이션을 컨테이너로 구축할 수 있도록 도와줄 뿐만 아니라, 서비스 장애에 대비한 고가용성과 부하 분산을 위한 로드밸런싱 기능 또한 제공하기 때문이다. 

스웜 모드를 사용하려면 적어도 3대 이상의 도커 서버를 사용해야만 기능을 제대로 테스트할 수 있으므로 앞으로 3대의 도커 서버를 기준으로 살펴볼 것이다. 

Docker Swarm Mode Architecture

앞서 언급했듯이, 스웜 모드는 별도의 설치 과정이 필요하지 않으며 도커 엔진 자체에 내장되어 있다. docker info 명령어를 통해 도커 엔진의 스웜 모드 클러스터 정보를 확인해보자.

docker info | grep Swram

별도의 설정을 하지 않았기 때문에 현재 스웜 모드의 상태는 inactive(비활성)으로 설정되어 있다.

스웜 모드는 위의 그림과 같은 구조로 구성되어 있다. 워커 노드는 실제로 컨테이너가 생성되고 관리되는 도커 서버이고, 매니저 노드는 워커 노드를 관리하기 위한 도커 서버이다. 주의할 점은 매니저 노드에도 컨테이너가 생성될 수 있다는 점이다. 즉, 매니저 노드는 기본적으로 워커 노드의 역할을 포함하고 있다.

도커 스웜에서 매니저 노드는 무조건 1개 이상이 있어야 하지만, 워커 노드는 없을 수도 있다. 이는 매니저 노드가 워커 노드의 역할도 포함하고 있어 매니저 노드만으로 스웜 클러스터를 구축할 수 있기 때문이다. 그렇지만 일반적으로는 워커 노드와 매니저 노드를 구분해서 사용한다.

Docker Swarm Mode Cluster 구축

Docker Swarm Mode Cluster를 구축하기 위해 사용할 서버의 IP와 호스트 이름은 아래와 같다.

manager 192.168.56.103
worker1 192.168.56.101
worker2 192.168.56.102

먼저 아래의 docker swarm init 명령어를 입력해 매니저 역할을 할 서버에서 스웜 클러스터를 시작하자.

docker swarm init --advertise-addr 192.168.56.103

--advertise-addr에는 다른 도커 서버가 매니저 노드에 접근하기 위한 IP 주소를 입력하면 된다.

출력 결과를 보면, docker swarm join을 볼 수 있는데, 이 명령어는 새로운 워커 노드를 스웜 클러스터에 추가할 때 사용된다. --token 옵션에 사용된 토큰 값은 새로운 노드를 해당 스웜 클러스터에 추가하기 위한 비밀키이다.

이제 워커 노드로 사용할 각 서버에서 아래와 같은 명령어를 입력하자.

특정 도커 서버가 정상적으로 스웜 클러스터에 추가되었는지 확인하려면 매니저 노드에서 docker node ls 명령어를 입력하면 된다.

위의 출력 결과 중 ID 옆에 ( * )가 붙어있는 노드가 현재 서버를 나타낸다. 다른 2개의 워커 노드가 정상적으로 스웜 클러스터에 추가되었고, 사용 가능한 상태(Active) 임을 볼 수 있다. 

Ref : 시작하세요! 도커/쿠버네티스