무중단 배포의 원리: 롤링 업데이트(Rolling Update)

배포의 공포와 다운타임

과거의 개발자들에게 배포일은 곧 야근을 의미했습니다. 기존 서버를 내리고, 새로운 코드를 올린 뒤 다시 서버를 켜는 동안 사용자들은 '점검 중'이라는 화면을 봐야 했으니까요.

이러한 서비스 중단 시간을 다운타임(Downtime)이라고 합니다. 바이브코딩 시대에 다운타임이 긴 서비스는 경쟁력을 잃습니다. 우리가 원하는 것은 사용자가 전혀 눈치채지 못하는 사이에 시스템이 자연스럽게 최신 버전으로 교체되는 것입니다.

블루-그린 배포와 롤링 업데이트

다운타임을 없애기 위한 가장 고전적인 방법은 블루-그린(Blue-Green) 배포입니다. 완전히 똑같은 서버 환경을 두 세트(블루, 그린) 준비한 뒤, 사용자가 블루를 보고 있을 때 그린에 새 버전을 배포합니다. 배포가 완료되면 스위치를 딸깍 눌러 트래픽을 한 번에 그린으로 돌리는 방식입니다. 안정적이지만 비용이 두 배로 든다는 치명적인 단점이 있습니다.

쿠버네티스는 비용 효율적이면서도 안전한 롤링 업데이트(Rolling Update)를 기본적으로 제공합니다.

롤링 업데이트의 작동 원리

롤링 업데이트는 마치 톱니바퀴가 굴러가듯, 기존의 낡은 파드(Pod)를 하나씩 부수고 새로운 파드를 하나씩 채워 넣는 방식입니다. 전체 클러스터의 트래픽을 한 번에 전환하지 않고, 순차적으로 파드를 교체하기 때문에 추가적인 서버 리소스를 크게 요구하지 않습니다.

쿠버네티스 디플로이먼트의 활약

이 마법을 지휘하는 것이 바로 Part 2에서 배운 디플로이먼트(Deployment)입니다. 디플로이먼트는 단순히 파드가 죽었을 때 살려내는 역할만 하는 것이 아닙니다. 새로운 버전의 이미지가 배포되면 디플로이먼트는 다음과 같이 행동합니다.

무중단 배포를 위한 안전장치

만약 새로 배포한 버전에 치명적인 버그가 있어 파드가 제대로 실행되지 않는다면 어떻게 될까요? 쿠버네티스는 무작정 모든 파드를 교체하지 않습니다.

새로운 파드가 트래픽을 받을 준비가 되었는지 끊임없이 확인하며, 만약 실패한다면 기존 파드의 교체를 즉시 중단합니다. 이렇게 하면 서비스 전체가 다운되는 끔찍한 사고를 막을 수 있습니다.

# 이미지 업데이트 명령
kubectl set image deployment/my-app my-app=my-app:v2

# 롤링 업데이트 상태 확인
kubectl rollout status deployment/my-app
# 출력 예시:
# Waiting for deployment "my-app" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "my-app" rollout to finish: 2 out of 3 new replicas have been updated...
# deployment "my-app" successfully rolled out

롤아웃과 롤백: 실수해도 괜찮은 세상

아무리 테스트를 완벽하게 했다고 해도, 실무에서는 배포 직후에야 발견되는 버그들이 존재합니다. 이럴 때는 최대한 빨리 이전 버전으로 되돌려야 합니다. 이 과정을 롤백(Rollback)이라고 부릅니다.

디플로이먼트는 이전의 배포 기록(Revision)을 모두 기억하고 있습니다. 터미널에서 명령어 한 줄만 입력하면, 쿠버네티스는 마치 타임머신을 타듯 안전했던 이전 상태로 파드들을 다시 교체합니다. 이는 개발자에게 엄청난 심리적 안정감을 제공합니다. 배포가 두렵지 않은 조직만이 빠른 속도로 성장할 수 있기 때문입니다.