쇼핑몰 사례로 알아보는 Docker Swarm 과 Compose 의 차이점
도커 Swarm 과 Compose 의 차이점
안녕하세요 코마입니다. 오늘은 Docker 에서 Compose 와 Swarm 의 차이점에 대해 알아보겠습니다. 😺
개요
도커는 가장 인기있는 컨테이너링 기술입니다. 그러나 오픈소스 기술이다보니 여러가지 개념들이 혼재되어 있는 경우가 있습니다. 그러나 지향하는 바는 분명하죠 그러한 차원에서 각 기술들을 조명할 필요가 있다고 생각했습니다. 이에, Swarm 과 Compose 의 차이를 쇼핑몰의 사례를 통해 소개해 드리도록 하겠습니다.
쇼핑몰 사례
만약에 여러분이 쇼핑몰을 운영하고 있고 하루에 100명의 사용자가 하루에 접속한다고 가정해봅시다. 그런데 어느 날 사업부의 엄청한 기획력으로 대박 이벤트가 줄줄이 쏟아진다고 가졍해보죠. 갑작스럽게 하루 1만명의 접속량을 유지해야 하는 서비스가 되었습니다.
그 동안 우리는 한 대의 서버에 하나의 웹 서비스를 구성하여 유지해 왔습니다. 지금까지는 3대의 서버면 충분했죠. 그러나 이제는 10대 이상의 서버가 갑작스럽게 필요할 것입니다.
그렇다면 분할해서 생각해 볼까요?
문제 분할
쇼핑몰 사례를 분할해서 생각해 보겠습니다.
- 10 개의 머신(=서버)를 가져야합니다.
- 웹, 앱, 그리고 DB 서비스를 구성해야 합니다.
- 이 서비스들이 서로 통신할 수 있어야 합니다.
이 세 가지를 한번에 충족하는데 Docker 를 사용해 보겠습니다.
도커 스웜(Swarm)
우선, 도커 Swarm 에 대해서 알아보겠습니다. Swarm 은 무리라는 뜻입니다. 그리고 클러스터링과 오케스트레이션 도구입니다.
도커 Swarm 은 1번 항목을 기본적으로 충족합니다. 아래의 요건을 충족하면 가능합니다.
- 서버들을 하나의 클러스터에 묶습니다.
- “docker run” 명령어를 클러스터에 실행합니다.
- Swarm 은 스케쥴링을 통해 컨테이너를 10 대의 서버 중 하나에 할당합니다.
마치 VMWare 의 vSphere 와 유사합니다.
Docker Compose
이제, Docker Compose 를 알아보겠습니다. 앞에서 여러분들이 여러 어플리케이션 스택을 구동하는 케이스에 대해서 티어라는 표현을 사용하였습니다. 다시 용어를 치환하여 여러 컴포넌트들을 가진 어플리케이션 스택이라고 말씀드리겠습니다. 만약 여러분들이 일일이 컴포넌트들을 “docker run”을 통해서 구동하는 것은 조금 비효율적일 수 있을 것입니다.
이때 우리는 docker compose 를 이용해서 spec 파일을 이용한 구동을 고려해 보아야 합니다. 즉, spec 파일은 각각의 컴포넌트들을 위해 어떻게 컨테이너가 빌드될지를 정의하는 파일입니다.
이제, db, app, web 티어에 대한 컴포넌트들을 정의할 때 고민되는 요소가 어떻게 이들이 서로와 통신하는지를 정의하는 것입니다. 컨테이너를 잘 올렸다고 해서 끝나는 것이 아닌 서로 통신이 잘되도록 구성하는 것이죠.
또 다른 쉽게 생각하는 방법은 Dockerfile 의 multi-container 버전이라고 spec 파일을 간주하는 것입니다.
Docker Compose 는 우선 클라이언트 기반의 툴입니다. 그리고 Swarm 은 서버 측 기능이죠. 그렇기 때문에 아래의 문서를 한번 읽어서 그 경계를 명확히 인지하는 것도 실무에 도움이 될 것입니다.
다음 시간에는 도커 아키텍처에 대해서 완벽하게 정리해보도록 하겠습니다.
- 도커 아키텍처 그림
Docker Network
마지막으로 3) 이 서비스들이 서로 통신할 수 있어야 합니다.
를 만족시키기 위해서 필요한 것은 Docker Network 입니다. Network 는 각각의 컨테이너가 서로 통신할 수 있도록 하는 것입니다. 그리고 외부 네트워크와도 마찮가지 입니다.
도커는 Default 네트워크 드라이버를 이미 가지고 있습니다. 이것은 대부분의 작업에는 매우 좋은 기능입니다. 그러나 응용 작업을 한다거나 production 에 deploy 할때는 네트워크를 다루는 것이 필요합니다. 아래의 경우를 생각해 볼까요?
- 컨테이너나 어플케이션 스택을 isolation(고립, 다른 컨테이너에 노출하지 않음)
- 호스트에서 여러분의 포트를 노출하는 경우
위의 내용들은 보안을 위해서도 충분히 시간을 들여서 투자해야합니다. 오랜 시간 공을 들인 프로덕트가 단 하나의 실수로 초라해지는 것은 매우 슬픈일입니다.
도커 네트워크는 서버 사이드 기능이므로 Swarm 에도 적용이 가능합니다. 그러나 이 네트워크에도 종류가 있는데요. 아래와 같습니다.
- bridge
- 기본 네트워크 드라이버입니다. 만약에 아무런 드라이버를 지정하지 않은 경우 이 드라이버가 지정됩니다.
- Bridge Network 는 Standalone 컨테이너가 통신을 하기 위해서 설정하는 케이스입니다.
- host
- 마찬가지로 standalone 방식의 컨테이너를 위한 네트워크 드라이버입니다. 도커 호스트(여러분의 PC)와 컨테이너간의 네트워크 독립(isolation)을 해제해주는 역할을 합니다. 즉, bridge 는 고립, host 는 개방이라고 생각하면 간단합니다.
- 호스트와 독립하지 않는 관계로 호스트의 네트워크를 직접 사용하게됩니다.
- 호스트 네트워크는 Docker 17.06 이상에서 동작하는 Swarm 에서만 사용가능한 점을 유의해 주세요
- overlay
- 다수의 도커 데모늘 연결해주는 것이 Overlay 네트워크 입니다. 또한, Swarm 서비스들이 서로 통신하는 것을 가능하게 합니다.
- standalone 방식의 컨테이너와 swarm 서비스를 통신하게 하는데에도 overlay 를 사용할 수 있습니다.
- 즉, 이 전략은 OS 레벨에서 컨테이너간 라우팅을 설정을 할 필요가 없도록 해줍니다.
- macvlan
- Macvlan 은 각 컨테이너에 MAC 주소를 부여합니다. 따라서 네트워크 상에서 물리적인 기기로 보입니다.
- Docker 데몬은 트래픽을 MAC 주소에 기반하여 라우팅해줍니다.
- 만약, 여러분이 물리 네트워크로 접속해야하는 legacy 어플리케이션을 다룰 때 이 전략은 유효합니다.
- none
- 모든 네트워크를 비활성화 합니다. 이 전략은 Custom 네트워크 드라이버와 결합해서 사용할 때 쓰입니다.
- 그러나 Swarm 에서는 none 을 사용할 수 없습니다.
우리는 컨테이너간의 통신을 원하므로 overlay 또는 host 전략을 사용하여 적절하게 구성하는 계획을 수립할 수 있습니다.
차이점
지금까지 쇼핑몰 케이스를 분할하여 Docker 로 각각의 이슈를 정복하는 관점에 대해서 알아보았습니다. compose 는 어플리케이션 스택을 정의하는데 유용하다고 볼 수 있습니다. 그리고 swarm 은 클러스터링과 auto scaling 에 적절합니다.
또한, 두 가지 도구는 각각 클라이언트 사이드 도구, 서버 사이드 도구 입니다. 이 차이점을 분명하게 인지하시면 좋을 것 같습니다. 또한, docker 는 compose 를 지원하므로 이점 또한 잘 활용할 경우 적절하게 스택을 관리할 수 있습니다.
마무리
지금까지 docker swarm 과 compose 의 차이점을 쇼핑몰의 사례를 통해서 알아보았습니다. 다음 장에는 Windows 10 테스트 환경에서 vagrant 를 통해 docker 환경을 가상으로 설정하는 방법을 알아보도록 하겠습니다. 지금까지 코마 였습니다.
구독해주셔서 감사합니다. 더욱 좋은 내용으로 찾아뵙도록 하겠습니다. 감사합니다
링크 정리
이번 시간에 참조한 링크는 아래와 같습니다. 잘 정리하셔서 필요할 때 사용하시길 바랍니다.
- Whats-the-difference-between-Docker-Swarm-Docker-Compose-and-Docker-Network
- Deploy a stack to a swarm