87. 디플로이먼트 (Deployment) - 롤링 업데이트와 롤백

⚠️ 이 문서는 쿠버네티스(Kubernetes) 환경에서 단순히 파드(Pod)의 숫자를 유지해 주는 레플리카셋(ReplicaSet)의 기능을 넘어, v1 버전의 앱을 v2로 업데이트할 때 서비스 중단 없이 순차적으로 배포(Rolling Update)하고, 치명적인 버그가 터졌을 때 단 1초 만에 이전 버전으로 되돌리는(Rollback) 실질적인 '웹 서비스 배포 사령관'인 디플로이먼트 객체를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 쿠버네티스에서 무상태(Stateless) 웹 애플리케이션을 배포할 때 사용하는 가장 흔하고 강력한 워크로드(Workload) 단위다. 사용자가 Deployment를 만들면, 내부적으로 ReplicaSet을 생성하고 그 ReplicaSet이 다시 Pod를 생성하는 3단계 계층 구조의 꼭대기다.
  2. 가치: "새벽 3시에 서버 내리고 점검창 띄워서 업데이트" 하던 과거의 낡은 방식을 완전히 종식시켰다. 고객이 앱을 쓰고 있는 대낮에도 아무런 끊김 현상(Downtime) 없이 우아하게 새 버전으로 코드를 덮어치게 해 준다.
  3. 기술 체계: 구버전 파드와 신버전 파드의 숫자를 동시에 서서히 조절하는 **롤링 업데이트(Rolling Update)**가 기본 무기이며, 배포 이력(Revision History)을 암기하고 있어 장애 발생 시 undo 명령어 한 줄로 즉각 타임머신을 탈 수 있다.

Ⅰ. 레플리카셋의 한계와 디플로이먼트의 계층 구조

알바생(ReplicaSet)은 개수만 맞출 줄 알지 머리를 쓸 줄 모른다.

  1. 버전 업데이트의 딜레마:
    • nginx:v1 이미지로 파드를 3개 돌리는 레플리카셋이 있다. 개발팀이 v2로 업데이트해 달라고 요청했다.
    • 레플리카셋 자체에는 '업데이트'라는 개념이 없다. 관리자가 수동으로 v1 파드 3개를 도끼로 쳐 죽인 다음, v2 설정으로 바꾼 파드 3개를 새로 띄워야 한다. 파드가 죽고 다시 뜰 때까지 고객은 수 분 동안 '접속 불량(에러)' 화면을 봐야 한다.
  2. 사령관의 등장 (Deployment $\rightarrow$ ReplicaSet $\rightarrow$ Pod):
    • 디플로이먼트는 이 과정을 자동화하기 위해 등장한 매니저의 매니저다.
    • 사용자는 디플로이먼트의 설정 파일(yaml)에 image: nginx:v2라고 한 줄만 고치고(선언적 업데이트) 쿠버네티스에 던져주면 끝이다.
    • 디플로이먼트는 내부적으로 새로운 'v2용 레플리카셋'을 몰래 하나 더 창조하여 두 개의 알바생(v1, v2)을 동시에 조종(Orchestration)하기 시작한다.

📢 섹션 요약 비유: 군대에서 소대장(레플리카셋)은 오직 "초소에 3명의 병사를 무조건 세워놔라"라는 단순 명령만 따릅니다. 만약 병사의 군복(버전)을 구형에서 신형으로 갈아입혀야 한다면, 중대장(디플로이먼트)이 등장해 "구형 군복 입은 애 1명 빼고, 신형 입은 애 1명 채워 넣어"라는 식으로 두 명의 소대장을 교묘하게 조종하며 초소가 한순간도 비지 않게 교대 근무를 지시하는 상위 지휘관입니다.

Ⅱ. 롤링 업데이트 (Rolling Update)의 마법

서비스를 살려둔 채 달리는 기차의 바퀴를 갈아 끼운다.

  1. 무중단 교대 근무의 원리:
    • 디플로이먼트가 v2 업데이트 명령을 받으면, v2 레플리카셋에게 파드 1개를 새로 만들라고 지시한다.
    • 새 v2 파드가 정상적으로 켜져서 "나 이제 트래픽 받을 준비 됐어(Readiness Probe 통과)!"라고 외치면, 그제야 v1 레플리카셋에게 구형 파드 1개를 죽이라고 지시한다. (총파드 수: 구형 2, 신형 1)
    • 이 과정을 파드 개수만큼 반복하여 최종적으로 구형은 0개, 신형은 3개가 되면 우아하게 배포가 종료된다.
  2. 배포 속도 튜닝 (Surge & Unavailable):
    • maxSurge (여분 한도): 배포 중에 원래 목표 개수(3개)보다 얼마나 더 많은 파드를 임시로 띄워도 되는지 허용치. (예: 1로 주면 배포 중 최대 4개까지 띄움)
    • maxUnavailable (결원 한도): 배포 중에 파드가 최소 몇 개는 무조건 살아있어야 하는지 방어선. (예: 1로 주면 배포 중에도 최소 2개는 무조건 응답을 받음)
    • 이 두 숫자를 튜닝해 "안전하게 한 땀 한 땀 교체할지, 서버 자원을 펑펑 쓰며 한 번에 싹 바꿀지" 속도를 조절한다.

📢 섹션 요약 비유: 3개의 계산대를 운영하는 마트입니다. 구형 계산대 직원 3명을 신형 로봇 계산대로 바꿀 때, 마트 문을 닫지 않습니다. 먼저 로봇 1대를 옆에 켜서 정상 작동하는지 확인한 뒤에야 기존 직원 1명을 퇴근시킵니다. 이 과정을 3번 반복하면 손님들은 마트가 리모델링되는지도 모르게 어느 순간 전부 로봇 계산대로 계산하고 있게 됩니다.

Ⅲ. 치명적 버그 터졌을 때: 롤백 (Rollback)의 기적

신형 로봇이 미쳐 날뛰면, 퇴근한 직원을 1초 만에 멱살 잡아 끌고 와야 한다.

  1. 리비전 히스토리 (Revision History) 암기:
    • 디플로이먼트는 롤링 업데이트를 끝낸 뒤에도, 파드가 0개가 된 옛날 v1 레플리카셋을 삭제하지 않고 백업용으로 휴지통(기본 10개까지)에 고이 보관해 둔다.
    • 이것을 '리비전(버전)'이라고 부른다 (Revision 1 = v1, Revision 2 = v2).
  2. Undo 명령어 한 줄의 위력:
    • v2를 배포했는데 결제가 안 되는 치명적 버그가 터졌다.
    • 관리자는 콘솔에 kubectl rollout undo deployment/web 명령어를 다급하게 엔터 친다.
    • 디플로이먼트는 즉시 v2 파드들을 싹 다 쳐내고, 휴지통에 보관해 뒀던 v1 레플리카셋의 목표 개수를 다시 3으로 올려 구형 파드 3개를 빛의 속도로 되살려내어 시스템을 사고 발생 전 시간으로 돌려놓는다. (타임머신 탑재)

📢 섹션 요약 비유: 마트 점장은 새로 도입한 로봇 계산대가 돈을 엉망으로 거슬러주는 버그를 발견했습니다. 점장은 당황하지 않고 비상 스위치(Undo)를 누릅니다. 그러자 아까 퇴근시켜서 대기실에 쉬고 있던 구형 계산대 직원들(v1 레플리카셋)이 1초 만에 뛰쳐나와 다시 계산대에 앉고, 고장 난 로봇들을 창고로 치워버리는 완벽한 비상 롤백(Rollback) 시스템입니다.