도커 스웜 (Docker Swarm) 정리 및 실습

쿠버네티스 (Kubernetes) 시스템을 자세히 다루기에 앞서, 도커에서 공식적으로 지원하는 오케스트레이션 도구인 도커 스웜 (Docker Swarm) 에 대해 내용을 정리하고, 직접 간단한 시스템을 구성해 본다.

Docker Swarm 이란?

컨테이너 시스템을 구성하다 보면 자원 요구사항에 따라 더 많은 컨테이너가 필요해질 수도 있고, 혹은 MSA (Micro Service Architecture) 서비스를 구성하는 경우에는 수많은 작은 시스템들이 모여서 하나의 서비스를 이루게 될 것이다.

한 서비스 내의 많은 작은 모듈들을 하나의 자원 풀로 만드는 작업은 쉽지 않은 일이며, 이를 위한 많은 오케스트레이션 도구들이 존재한다. 대표적으로는 최근 주목받고 많이 이용되는 쿠버네티스가 있지만, 본 포스트에서는 이를 다루기에 앞서 도커에서 공식적으로 제공하는 솔루션인 도커 스웜에 대해서 조금 더 자세히 살펴보고자 한다.

도커 스웜의 경우 두 종류가 존재하는데, 각각 스웜 클래식 (Swarm Classic) 과 스웜 모드 (Swarm Mode) 이다. 두 종류에 대해 간단히 정리하자면 다음과 같다.

• 스웜 클래식 : 여러 대의 도커 서버를 하나의 지점에서 이용할 수 있도록 하는 접근점을 제공
• 스웜 모드 : 같은 컨테이너를 여러 개 생성해서 유동적으로 컨테이너 수를 조절할 수 있는 로드 밸런싱 기능 제공

특히 각종 정보를 저장하고 동기화하는 분산 코디네이터 (Distributed Coordinator) 와 서버를 제어하는 에이전트 와 같은 툴이 필요한데, 스웜 모드는 이러한 툴이 모두 도커 엔진 자체에 내장되어 있기 때문에 이용하기에 더 편리하고 확장성이 뛰어나다는 장점을 가진다.

이 때 도커 스웜의 기능을 정상적으로 이용하기 위해서는 도커 엔진 1.12 버전 이상이 설치되어 있어야 한다.

Swarm Mode

스웜 모드는 크게 Manager Node 와 Worker Node 로 구성된다.

• Manager Node : Worker Node를 관리하기 위한 도커 서버
• Worker Node : 실제로 컨테이너가 관리, 생성되며 운영되는 도커 서버

매니저 노드의 경우에도 워커 노드의 역할을 수행할 수 있다. 따라서 스웜 모드에서 매니저 노드는 반드시 1개 이상 있어야 하지만, 워커 노드는 없을 수도 있다.

매니저 노드가 많다고 해서 클러스터의 성능이 좋아지는 것은 아니지만, 실제 시스템을 구성하는 경우 시스템의 안정성을 고려해서 매니저 노드를 다중화하는 것이 권장된다.

이제 스웜 모드를 이용한 시스템을 직접 구성해보자. 이 때 사전 준비사항이 필요하다. 도커 엔진이 설치되어 있어야 하는 것은 기본이며, 다음 포트들이 이용되므로 Host PC에서 해당 포트가 이용 가능한 상태여야 한다.

• 2377/tcp : Swarm Manager
• 7947/tcp, 7947/udp : Node 간 통신
• 4789/tcp : Ingress Overlay 네트워크

실습

앞서 설명한 것과 같이 도커 엔진이 설치되어 있으면 스웜 모드를 이용할 수 있으므로, Host PC를 매니저 노드로 구성할 수도 있다. 하지만 본 실습에서는 매니저 노드 또한 별도의 컨테이너를 생성하여 워커 노드를 연결해보도록 한다.

이 때 각 컨테이너에도 도커 엔진이 설치되어 있어야 도커 스웜을 이용할 수 있기 때문에, 허브에서 DinD (Docker in Docker) 이미지를 받아서 총 3개의 컨테이너를 아래와 같이 구성하였다.

컨테이너 생성에 이용한 명령어는 다음과 같다.

$ docker run --privileged --name manager1 -p 4101:80 -d docker:20.10.5-dind

manager1 컨테이너를 매니저 노드로, worker1 과 worker2 컨테이너를 워커 노드로 이용할 것이다.

이제 먼저 매니저 노드에 쉘을 열어, 스웜 클러스터를 생성한다.

$ docker exec -it [container_name] /bin/sh
/# docker swarm init --advertise-addr [ip_addr]

Swarm Init을 통해 워커 노드의 추가에 필요한 토큰을 얻을 수 있다. 혹은 추후에 다시 해당 토큰 값을 받고자 한다면, docker swarm join-token [type] 명령어를 통해 획득할 수 있다. type 에는 manager 혹은 worker 를 입력하여 어떤 형태로 추가할 지 선택할 수 있다.

이제 워커 노드에 접속하여, 스웜 클러스터에 추가하도록 한다.

/# docker swarm join --token [token] [ip_addr]:[port]

클러스터에 추가한 결과를 매니저 노드에서 확인할 수 있다.

이제 스웜 클러스터를 구성 완료하였으므로, 간단히 테스트를 위해 nginx 이미지를 이용하여 웹 서버를 구동해보고자 한다.

매니저 노드에서 다음과 같이 서비스를 생성하였다. 컨테이너가 자동으로 생성되는 것을 확인하기 위해 Replica 수를 우선 3개로 지정하였다.

실행 결과, 우선 매니저 노드를 포함하여 워커 노드까지 총 3개의 노드에 각각 1개의 컨테이너가 생성되었다. 이제 레플리카 수를 4개로 변경하여, 스웜에 의해 노드에 컨테이너가 자동 생성되는 것을 확인한다.

레플리카 수를 변경한 결과, 워커 노드 2에 새로운 컨테이너가 추가되었다. 최종 상태는 아래의 그림과 같이 구성되었다.

최초에 매니저 노드를 생성할 당시 Host PC의 4101 번 포트를 컨테이너 내부 80 번 포트와 연결하도록 했기 때문에, Host PC의 웹 브라우저에서 127.0.0.1:4101 에 접속했을 때 아래와 같이 웹 서버가 정상 동작하는 것을 확인할 수 있다.

만약 서비스를 정식으로 구성하고 사용자 요청이 들어오는 경우, 스웜 모드는 각 레플리카에 Round Robin 방식으로 트래픽을 분산시킬 것이다.

결론

스웜 모드를 이용하여 간단하게 클러스터를 구축해 보았다. 물론 본 포스트에서 다룬 내용보다 스웜 모드가 지원하는 기능은 정말 많다. 특히 롤링 업데이트 기능을 제공하고 로드 밸런싱 을 제공한다는 점에서 스웜 모드는 실제 서비스에서도 충분히 이용할 수 있다.

또한 본 포스트에서는 스웜 모드의 기본 인그레스 네트워크만을 이용하였으나, 별도의 인그레스 네트워크 드라이브를 생성하여 이용할 수도 있으며, Volume을 생성하여 다룰 수도 있다는 점에서 스웜 모드는 꽤나 유용한 오케스트레이션 툴이다.

물론 쿠버네티스는 비교적 복잡하지만 더 다양하고 강력한 기능을 제공한다는 점에서 대부분의 대규모 MSA 서비스에서는 쿠버네티스를 기본으로 사용하고 있다. 추후 쿠버네티스에 대한 포스트를 다루며, 조금 더 복잡한 서비스를 구축해 보고 도커 스웜과 비교해 보았을 때의 장단점에 대해서 조금 더 자세히 정리해 보고자 한다.