🚀 알아두면 쓸모있는 쿠버네티스 배포 전략: 롤링, 블루/그린, 카나리 완벽 정복!

안녕하세요! 개발자 여러분, 열심히 개발한 애플리케이션의 새 버전을 사용자에게 선보일 시간입니다! 🎉 하지만 '배포' 버튼을 누르기 전에 항상 드는 걱정이 있죠. '서비스가 중단되면 어떡하지?', '새 버전에 문제가 생기면 빠르게 되돌릴 수 있을까?' 하는 고민들 말이에요.

 

이런 고민을 해결하기 위해 쿠버네티스는 다양한 배포 전략을 제공합니다. 오늘은 그중에서도 가장 기본적이고 필수적인 세 가지 전략, 롤링 업데이트(Rolling Update), 블루/그린(Blue/Green), 카나리(Canary)에 대해 쉽고 상세하게 알아보겠습니다!

 

---

1. 롤링 업데이트 (Rolling Update) 🔄

롤링 업데이트는 쿠버네티스의 가장 기본적인 배포 전략이며, Deployment 오브젝트의 기본 배포 방식입니다. 이름처럼 파도처럼 점진적으로 새 버전을 배포하는 방식이죠.

🤔 개념

롤링 업데이트는 구버전의 파드(Pod)를 하나씩 종료하면서, 동시에 신규 버전의 파드를 하나씩 생성하여 교체하는 방식입니다. 마치 움직이는 자동차의 바퀴를 하나씩 차례대로 교체하는 것과 같아요. 전체 서비스가 중단되지 않고 자연스럽게 업데이트가 진행됩니다.

⚙️ 동작 방식

쿠버네티스 Deployment에서는 두 가지 중요한 옵션으로 롤링 업데이트를 제어합니다.

• maxSurge: 업데이트 중 기본 replicas 수보다 얼마나 더 많은 파드를 생성할 수 있는지 지정합니다. (e.g., replicas가 10개이고 maxSurge가 20%이면, 최대 12개의 파드가 동시에 존재할 수 있습니다.)
• maxUnavailable: 업데이트 중 사용 불가능한 상태가 되어도 되는 파드의 최대 개수를 지정합니다. (e.g., replicas가 10개이고 maxUnavailable이 20%이면, 최소 8개의 파드는 항상 운영되어야 합니다.)

이 두 옵션 덕분에 쿠버네티스는 (1) 새 버전 파드를 띄우고 → (2) 새 파드가 준비되면 트래픽을 연결하고 → (3) 구버전 파드를 종료하는 과정을 점진적으로 반복하며 무중단 배포를 실현합니다.

👍 장점

• 간단함: 쿠버네티스의 기본 전략이라 별도의 복잡한 설정 없이 바로 사용할 수 있습니다.
• 자원 효율적: 추가적인 인프라 자원을 거의 필요로 하지 않습니다.
• 무중단 배포: 점진적으로 교체되므로 서비스 중단 시간이 없습니다.

👎 단점

• 느린 배포/롤백: 파드를 하나씩 교체하므로 전체 클러스터에 배포되기까지 시간이 오래 걸릴 수 있습니다. 롤백도 마찬가지입니다.
• 버전 호환성 문제: 배포가 진행되는 동안 구버전과 신버전이 공존하게 됩니다. 두 버전 간에 호환성(e.g., API, 데이터베이스 스키마) 문제가 있다면 예기치 못한 오류가 발생할 수 있습니다.

🤔 언제 사용할까요?

버전 간 호환성이 보장되고, 약간의 배포 시간이 소요되어도 괜찮은 일반적인 애플리케이션에 가장 적합합니다.

---

2. 블루/그린 배포 (Blue/Green Deployment) 🔵🟢

블루/그린 배포는 '제로 리스크' 배포를 목표로 하는 전략입니다. 현재 운영 중인 환경(블루)과 똑같은 신규 버전 환경(그린)을 미리 준비해두고, 준비가 완료되면 트래픽을 한 번에 전환하는 방식입니다.

🤔 개념

마치 두 개의 똑같은 무대(블루, 그린)를 준비하는 것과 같습니다. 관객들(사용자)은 블루 무대에서 공연을 보고 있습니다. 우리는 보이지 않는 그린 무대에서 다음 공연을 완벽하게 준비합니다. 모든 준비가 끝나면, 조명을 '탁' 하고 그린 무대로 한 번에 전환하는 것이죠.

⚙️ 동작 방식

기본 쿠버네티스 환경에서는 Service의 selector를 이용하여 구현합니다.

1. 블루 환경 운영: 현재 version: blue 레이블을 가진 파드들이 운영되고 있고, Service는 이 selector를 통해 트래픽을 보내고 있습니다.
2. 그린 환경 배포: version: green 레이블을 가진 신규 버전의 Deployment를 블루 환경과 동일한 규모로 배포합니다. 이 시점까지 그린 환경에는 사용자 트래픽이 들어오지 않습니다.
3. 그린 환경 테스트: 내부적으로 그린 환경에 접근하여 모든 기능이 정상적으로 동작하는지 완벽하게 테스트합니다.
4. 트래픽 전환: 모든 테스트가 완료되면, Service의 selector를 version: green으로 변경합니다. 이 한 번의 변경으로 모든 사용자 트래픽이 블루에서 그린으로 즉시 전환됩니다.
5. 블루 환경 대기/제거: 그린 환경이 안정적으로 운영되는 것을 확인한 후, 문제가 생겼을 때 빠른 롤백을 위해 블루 환경을 잠시 대기시키거나, 자원 효율을 위해 삭제합니다.

👍 장점

• 즉각적인 롤백: 문제가 발생하면 Service의 selector를 다시 version: blue로 돌리기만 하면 되므로, 거의 즉시 롤백이 가능합니다.
• 안정성: 신규 버전에 대한 충분한 테스트 시간을 가질 수 있고, 배포 중 버전 충돌 문제가 없습니다.
• 빠른 배포: 트래픽 전환은 한 번에 일어나므로 사용자는 업데이트를 거의 인지하지 못합니다.

👎 단점

• 높은 자원 비용: 동일한 환경을 2개 유지해야 하므로 인프라 자원(컴퓨팅, 메모리 등)이 2배로 필요합니다.
• 상태 관리의 복잡성: 데이터베이스 스키마 변경 등 상태를 가진 애플리케이션의 경우, 블루와 그린 환경의 데이터 동기화가 매우 까다로울 수 있습니다.

🤔 언제 사용할까요?

서비스 중단이 치명적인 미션 크리티컬(Mission-Critical) 애플리케이션이나, 즉각적인 롤백 기능이 반드시 필요한 서비스에 적합합니다.

---

3. 카나리 배포 (Canary Deployment) 🐦

카나리 배포는 과거 광부들이 유독가스를 감지하기 위해 카나리아 새를 데리고 탄광에 들어갔던 것에서 유래했습니다. 신규 버전을 전체가 아닌, 아주 일부 사용자에게만 먼저 공개하여 위험을 감지하는 점진적인 배포 전략입니다.

🤔 개념

새로운 기능을 전체 사용자에게 한 번에 공개하는 것은 위험 부담이 큽니다. 카나리 배포는 신규 버전(카나리)을 1%, 5%, 10% 등 소수의 사용자에게만 먼저 노출시키고, 이들의 반응과 시스템 메트릭(에러율, 응답 시간 등)을 면밀히 관찰합니다. 문제가 없다고 판단되면 점차적으로 배포를 확대해 나가는 방식입니다.

⚙️ 동작 방식

기본 쿠버네티스에서는 롤링 업데이트나 블루/그린처럼 명확하게 지원하는 기능은 없으며, 여러 개의 Deployment를 조합하여 구현해야 합니다.

1. 안정 버전(Stable) 운영: 현재 대부분의 사용자는 안정 버전의 Deployment를 사용하고 있습니다.
2. 카나리 버전 배포: 신규 버전의 Deployment를 아주 적은 수의 파드(e.g., 1개)로 배포합니다.
3. 트래픽 분산: Service는 안정 버전과 카나리 버전의 파드를 모두 selector로 지정합니다. 이렇게 하면 Service는 라운드 로빈 방식으로 두 버전 모두에게 트래픽을 보냅니다. 예를 들어 안정 버전 파드가 9개, 카나리 버전 파드가 1개라면, 전체 트래픽의 약 10%가 카나리 버전으로 향하게 됩니다.
4. 모니터링 및 점진적 확대: 카나리 버전을 사용하는 소수 그룹의 데이터를 분석하여 안정성을 검증합니다. 문제가 없다면 카나리 버전의 파드 수를 점차 늘리고, 안정 버전의 파드 수를 줄여나갑니다.
5. 전체 배포 완료: 최종적으로 모든 트래픽이 카나리 버전으로 향하게 되면 배포가 완료되고, 구버전의 Deployment는 삭제합니다.

참고: 사실 이 방식은 트래픽을 정교하게 제어하기 어렵기 때문에, 실제 현업에서는 Istio, Linkerd와 같은 서비스 메시(Service Mesh) 도구를 사용하여 weight 기반으로 "2%의 트래픽은 카나리로, 98%는 안정 버전으로" 와 같이 훨씬 정교하게 제어합니다.

👍 장점

• 최소화된 위험: 실제 운영 환경에서 소수의 사용자를 대상으로 테스트하므로, 문제가 발생해도 전체 서비스에 미치는 영향이 매우 적습니다.
• 실사용자 기반 테스트 (A/B 테스트): 특정 기능에 대한 실제 사용자의 반응을 보고 데이터를 수집하는 A/B 테스트 목적으로 활용할 수 있습니다.
• 유연한 배포: 문제 발생 시 카나리 버전의 파드만 제거하면 되므로 빠르고 안전하게 대응할 수 있습니다.

👎 단점

• 관리의 복잡성: 배포 과정이 길고, 여러 버전을 동시에 관리해야 하며, 정교한 모니터링 시스템이 반드시 필요합니다.
• 사용자 경험 불일치: 일부 사용자는 신기능을, 다른 사용자는 구기능을 사용하게 되어 혼란을 줄 수 있습니다.

🤔 언제 사용할까요?

대규모 사용자를 보유한 서비스에서 신규 기능의 안정성을 검증하며 점진적으로 배포하고 싶을 때, 또는 A/B 테스트가 필요할 때 가장 이상적인 전략입니다.

---

✨ 한눈에 보는 배포 전략 비교

구분	롤링 업데이트 (Rolling Update)	블루/그린 (Blue/Green)	카나리 (Canary)
핵심 아이디어	점진적으로 구버전을 신버전으로 교체	신버전 환경을 미리 준비 후 트래픽을 한번에 전환	일부 사용자에게만 먼저 신버전을 공개 후 점차 확대
배포 속도	느림	매우 빠름	매우 느림
롤백 속도	느림	매우 빠름	매우 빠름
자원 사용량	효율적 (소량의 추가 자원)	비효율적 (2배의 자원)	중간 (소량의 추가 자원)
복잡도	낮음	중간	높음
위험도	중간	낮음	매우 낮음

 

결론

지금까지 쿠버네티스의 대표적인 배포 전략 세 가지에 대해 알아보았습니다. 어떤 전략이 무조건 좋다고 말할 수는 없습니다. 우리의 서비스의 특성, 중요도, 팀의 기술 성숙도, 그리고 자원 상황을 종합적으로 고려하여 가장 적합한 전략을 선택하는 것이 중요합니다.

 

이 글을 통해 여러분의 다음 배포가 조금 더 안정적이고 자신감 넘치게 되기를 바랍니다! 😊

---

태그: Kubernetes, 쿠버네티스, 배포 전략, 롤링 업데이트, 블루그린, 카나리, 무중단 배포, DevOps, CI/CD