과대광고를 넘어서: Docker Swarm 실전 운영 플레이북

출처: Dev.to

컨테이너 오케스트레이션 이야기가 나오면 대화는 거의 즉시 쿠버네티스로 넘어갑니다.
그리고 왜 그런지 이해합니다.

쿠버네티스는 강력합니다. 방대한 생태계, 견고한 추상화, 커스텀 리소스, 오퍼레이터, 서비스 메시, 어드미션 컨트롤러, 그리고 거의 무한에 가까운 확장성을 가지고 있죠. 복잡한 멀티테넌트 플랫폼을 운영하는 대규모 조직에게는 쿠버네티스가 종종 최선의 선택이 됩니다.

하지만 수년간 리눅스 인프라, 백엔드 시스템, 프라이빗·퍼블릭 클라우드 환경, CI/CD 파이프라인, 모니터링 스택, 그리고 프로덕션 배포를 다루면서 제가 배운 한 가지를 쉽게 잊어버리곤 합니다.

가장 좋은 인프라가 항상 가장 강력한 인프라인 것은 아닙니다. 팀이 압박 속에서도 안전하게 운영할 수 있는 것이 바로 최선입니다.

여기서 Docker Swarm이 아직도 존중받아야 할 이유가 있습니다.

Docker Swarm을 장난감, 구시대의 백업, 혹은 작은 데모에만 적합한 것으로 보지는 않습니다. 오케스트레이터 자체를 메인 프로젝트로 만들지 않고도 프로덕션 급 컨테이너 배포를 원하는 팀을 위한 실용적인 오케스트레이션 레이어라고 생각합니다.

이 글에서는 Docker Swarm을 초보자 튜토리얼이 아니라, 아키텍처, 보안, 배포, 모니터링, 실제 프로덕션 트레이드오프를 다루는 실전 플레이북으로 바라보는 시각을 공유하고자 합니다.

헬로월드 예제는 없습니다.

Docker Swarm의 가장 큰 장점은 쿠버네티스보다 기능이 많다는 것이 아닙니다.
그렇지 않죠.

장점은 훨씬 적은 운영 복잡성으로 충분한 오케스트레이션을 제공한다는 점입니다.

팀이 이미 Docker와 docker‑compose를 이해하고 있다면 Swarm은 자연스럽게 느껴집니다. 단일 머신 Compose 설정에서 멀티 노드 클러스터로 전환해도 사고 모델을 완전히 바꿀 필요가 없으니까요.

그것이 중요합니다.

프로덕션에서는 인지 부하가 실제 비용이 됩니다. 도입하는 모든 추상화는 학습, 문서화, 모니터링, 업그레이드, 보안, 디버깅을 필요로 합니다. 팀이 자신 있게 운영할 수 없는 강력한 플랫폼은 금방 부채가 됩니다.

많은 실제 백엔드 시스템에서 요구사항은 매우 명확합니다.

• API의 여러 복제본 실행
• 다운타임 없이 배포
• 실패 시 자동 롤백
• 내부 서비스와 퍼블릭 트래픽 격리
• 이미지와 환경 파일에 비밀 정보가 포함되지 않도록 관리
• 노드와 컨테이너 상태 모니터링
• 필요 시 수평 확장
• 아키텍처 가독성 유지

Docker Swarm은 이러한 요구를 충분히 만족시킵니다.

핵심 포인트는 이것입니다. Swarm이 모든 상황에서 쿠버네티스를 대체하는 것은 아니지만, 단순함, 속도, 운영 명료성이 무한한 확장성보다 더 중요한 경우 더 나은 엔지니어링 선택이 될 수 있습니다.

저는 종교적인 기술 논쟁을 좋아하지 않습니다. 대부분의 도구는 상황에 따라 좋기도 하고 나쁘기도 합니다.

그래서 “어떤 것이 더 좋다”는 질문 대신에 이렇게 묻습니다.

내가 감수하는 운영 비용은 무엇이며, 그 대가로 얻는 비즈니스·기술적 역량은 무엇인가?

아래는 제가 보통 Docker Swarm과 쿠버네티스를 비교하는 방식입니다.

예를 들어, 커스텀 오퍼레이터, 고급 자동 스케일링, 복잡한 RBAC 정책, 어드미션 컨트롤러, 멀티테넌트 플랫폼 엔지니어링, 서비스 메시 통합이 필요하다면 쿠버네티스가 보통 더 강력한 선택입니다.

하지만 목표가 백엔드 서비스, 워커, 리버스 프록시, 큐, 내부 API, 스케줄링 워크로드를 소규모·중간 규모 클러스터에 배포하는 것이라면 Swarm이 운영상의 놀라움을 최소화하면서 더 깔끔한 경로를 제공할 수 있습니다.

제 경험상, 많은 팀이 오케스트레이터의 기능 부족 때문에 실패하는 것이 아니라, 인프라가 팀이 운영하기엔 너무 복잡해졌기 때문에 실패합니다.

Swarm 모델 이해하기

프로덕션 아키텍처 이야기를 하기 전에 Swarm 모델을 먼저 이해해야 합니다.

Swarm 클러스터에는 두 가지 주요 노드 역할이 있습니다.

• 매니저 노드: 클러스터 상태를 유지하고 스케줄링 결정을 내립니다.
• 워커 노드: 실제 컨테이너를 실행합니다.

Swarm에서는 개별 컨테이너를 직접 다루기보다는 서비스 단위로 생각합니다. 서비스는 원하는 상태를 정의합니다.

• 어떤 이미지를 실행할지
• 몇 개의 복제본이 필요할지
• 어떤 네트워크에 연결할지
• 어떤 비밀 정보를 사용할지
• 배치 제약조건은 무엇인지
• 업데이트와 롤백은 어떻게 할지

Swarm은 이 원하는 상태를 만족시키기 위해 태스크를 생성합니다. 태스크는 기본적으로 서비스의 실행 인스턴스 하나입니다.

이 desired‑state 모델은 오케스트레이션에서 가장 중요한 개념 중 하나입니다. 이제 “여기 컨테이너를 실행해라”가 아니라 “이 서비스의 복제본 5개를 만들고, 아래 규칙을 따르게 해라”라고 선언합니다. 오케스트레이터는 지속적으로 실제 상태가 원하는 상태와 일치하도록 조정합니다.

간단해 보이지만 배포 설계 방식을 크게 바꿉니다.

매니저 노드와 Raft

Docker Swarm의 매니저 노드는 Raft 합의 알고리즘을 사용해 클러스터 상태를 유지합니다. 이는 프로덕션에서 가장 중요한 세부 사항 중 하나입니다.

Raft는 쿼럼이 필요합니다. 쉽게 말해, 클러스터는 의사결정을 내리기 위해 과반수 이상의 매니저가 살아 있어야 합니다.

쿼럼 = (매니저 수 / 2) + 1

이 때문에 실용적인 규칙이 하나 생깁니다.

매니