82. 무중단 배포 (Zero Downtime Deployment) 전략 3가지

⚠️ 이 문서는 웹 서비스의 버전이 v1.0에서 v2.0으로 업데이트될 때, 과거처럼 새벽 2시에 "시스템 점검 중입니다"라는 끔찍한 에러 화면을 띄워 고객의 결제를 끊어버리는 아마추어 같은 짓을 막고, **대낮에 수만 명의 고객이 물건을 사고 있는 와중에도 서버 100대가 물 흐르듯 조용히 새 버전으로 갈아입어 고객이 단 1초의 멈춤(Downtime)도 느끼지 못하게 만드는 클라우드 아키텍처의 마법, 무중단 배포 3대 전술(롤링, 블루-그린, 카나리)**을 다룹니다.

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

  1. 본질: 서버를 끄고 새 코드를 밀어 넣는 방식이 아니라, "새 버전의 서버(컨테이너)를 띄워두고, 로드밸런서(문지기)의 방향을 구버전에서 신버전으로 절묘하게 꺾어치기" 하는 네트워크 라우팅 예술이다.
  2. 가치: 1년 365일 24시간 장사를 멈추지 않는 아마존, 넷플릭스가 하루에도 수천 번씩 배포를 쏘아댈 수 있는 비결이다. 배포의 두려움을 0%로 만들어 개발자들이 하루에도 10번씩 코드를 고치고 릴리스(Agile)하게 만든다.
  3. 기술 체계: 도미노처럼 1대씩 끄고 켜는 가장 저렴한 롤링(Rolling), 쌍둥이 서버를 똑같이 띄워두고 0.1초 만에 스위치를 확 꺾어버리는 갑부들의 방식 블루-그린(Blue/Green), 그리고 1%의 고객만 새 서버에 슬쩍 밀어 넣어 독가스를 테스트하는 극한의 안전망 **카나리(Canary)**로 나뉜다.

Ⅰ. 롤링 배포 (Rolling Update): 점진적 도미노 교체

가장 싸고 기본적이지만, 중간에 과거와 미래가 뒤섞이는 혼돈이 발생한다.

  1. 작동 원리 (순차적 끄고 켜기):
    • 10대의 서버가 v1.0으로 돌고 있다.
    • 로드밸런서가 1번 서버로 가는 트래픽의 입구를 꽉 닫는다. (손님은 나머지 9대 서버로만 감)
    • 1번 서버의 v1.0을 내리고, v2.0(새 코드)을 띄운다. 서버가 완전히 켜지면(Health Check OK), 로드밸런서가 1번 서버의 문을 다시 열어준다.
    • 이제 2번 서버의 문을 닫고 v2.0으로 바꾼다. 이 짓을 10번 반복하여 도미노처럼 차례대로 모두 교체한다. 쿠버네티스(Deployment)의 기본 탑재(Default) 배포 방식이다.
  2. 장점과 딜레마 (호환성의 저주):
    • 장점: 10대의 서버 기계(리소스)만 있으면 추가 돈 한 푼 안 들고 무중단이 가능하다 (가성비 끝판왕).
    • 단점 1 (버전의 혼재): 배포가 50% 진행된 10분 동안, 어떤 고객은 1번 서버(v2.0) 화면을 보고, 새로고침한 어떤 고객은 10번 서버(v1.0) 화면을 보는 기괴한 시간 여행(불일치)을 겪는다.
    • 단점 2 (DB 하위 호환성): v1.0 코드와 v2.0 코드가 완전히 똑같은 하나의 데이터베이스(DB) 스키마를 바라보고 있어야 하므로, DB 컬럼을 함부로 지우거나 이름을 바꾸면 절반의 서버가 에러를 뿜으며 대형 사고가 난다.

📢 섹션 요약 비유: 달리는 기차(서비스)의 바퀴 10개를 교체해야 합니다. 롤링 배포는 기차를 세우지 않고, 한 번에 바퀴 1개씩만 공중으로 살짝 들어 올려 헌 바퀴(v1.0)를 빼고 새 바퀴(v2.0)를 끼우는 묘기입니다. 기차는 남은 9개의 바퀴로 힘겹게 계속 달리므로 멈추진 않지만(무중단), 교체 도중에는 구형 바퀴와 신형 바퀴가 섞여서 달리는 약간의 덜컹거림(버전 혼재)을 감수해야 하는 짠돌이 공법입니다.

Ⅱ. 블루/그린 배포 (Blue/Green Deployment): 광속 스위칭

돈으로 허공에 쌍둥이 별을 지어놓고 0.1초 만에 텔레포트 시킨다.

  1. 작동 원리 (거울 세계의 창조):
    • 현재 손님들이 바글거리는 파란색 서버(Blue, v1.0) 10대를 절대 건드리지 않는다.
    • AWS 허공(클라우드)에 완벽히 똑같은 덩치의 녹색 서버(Green, v2.0) 10대를 통째로 새로 띄운다. (이 순간 서버 20대 분량의 월세가 팍팍 나간다.)
    • 개발팀만 몰래 녹색 서버의 뒷구멍 주소로 들어가 결제 버튼이 잘 눌리는지 1시간 동안 완벽히 내부 테스트(QA)를 한다.
    • 확신이 서면, 앞단의 로드밸런서 스위치(Route 53 DNS 등)를 잡고, 파란색 서버로 가던 1만 명의 손님 트래픽을 '단 0.1초 만에' 녹색 서버 쪽으로 콱! 꺾어버린다.
  2. 장점과 롤백(Rollback)의 예술:
    • 장점: 손님들은 새로고침 하는 0.1초 찰나에 전원이 동시에 v2.0 화면으로 넘어간다(버전 혼재 완전 차단).
    • 롤백의 기적: 만약 녹색 서버(v2.0)로 손님이 넘어갔는데 심각한 버그로 서버가 터져나간다. 개발팀은 소스코드를 다시 짤 필요가 없다. 아직 허공에 안 끄고 놔뒀던 파란색 서버(v1.0)로 로드밸런서 스위치를 다시 0.1초 만에 꺾어버리면 끝이다. 1초 만에 어제 상태로 완벽히 시간 여행(초광속 롤백)을 하는 기적의 방어막이다.

📢 섹션 요약 비유: 달리는 기차의 바퀴를 바꾸는 게 위험하다고요? 갑부(블루그린)는 옆 선로에 완벽하게 세팅된 최신형 기차(Green)를 한 대 똑같이 달리게 띄워놓습니다. 그리고 구형 기차(Blue)와 신형 기차 사이에 구름다리를 놓고, 기관사가 "지금!" 하고 소리치면 1만 명의 승객이 1초 만에 신형 기차로 싹 다 건너뛰는(스위치 라우팅) 미친 짓입니다. 신형 기차가 덜컹거리면(버그)? 승객들은 1초 만에 다시 옆에서 같이 달리던 구형 기차로 쏙 건너뛰어 목숨을 구하는 100% 안전 보장 공법입니다. (대신 기차 2대 값이 듭니다.)

Ⅲ. 카나리 배포 (Canary Release): 독가스 감별사

겁쟁이들을 위한 궁극의 방패. 1%만 밀어 넣어 보고 간을 본다.

  1. 카나리아 새의 전설:
    • 옛날 광부들은 탄광 깊은 곳에 유독 가스가 있는지 알기 위해, 사람보다 가스에 10배 예민한 '카나리아' 새를 새장에 넣어 먼저 들여보냈다. 새가 죽으면 광부들은 도망쳐 목숨을 구했다.
  2. 작동 원리 (극단적인 점진적 유입):
    • 10대의 v1.0 서버 틈새에, 딱 1대의 v2.0(새 버전) 서버를 슬쩍 띄워 끼워 넣는다.
    • 로드밸런서(Ingress 등)에 무시무시한 라우팅 가중치(Weight) 룰을 건다. "지금 들어오는 1만 명 중 99%는 옛날 서버로 보내고, 무작위로 뽑힌 불쌍한 1%의 손님(카나리아)만 v2.0 서버로 밀어 넣어라!"
  3. 관망과 점진적 스케일 업:
    • 데브옵스 팀은 모니터(Datadog, 엑스레이)를 켜고 이 1%의 고객들이 결제하다가 500 에러를 맞고 죽는지(새가 죽는지) 3시간 동안 팝콘을 먹으며 지켜본다.
    • 새가 안 죽고 잘 돌아가면 밸브를 열어 트래픽을 5% $\rightarrow$ 10% $\rightarrow$ 50% $\rightarrow$ 100%로 서서히 늘리며, 옛날 서버 10대는 천천히 폐기해 버린다.
    • 전 세계 수십억 명을 상대하는 구글, 페이스북 같은 빅테크 기업들이 어떤 끔찍한 버그에도 전면 장애를 맞지 않는 궁극적이고도 가장 느리면서 안전한 배포 방식이다.

📢 섹션 요약 비유: 새로운 김치찌개 레시피(v2.0)를 개발했습니다. 식당의 100개 테이블 손님에게 이 찌개를 몽땅 뿌려버리는 것(일반 배포)은 미친 짓입니다(다 환불해 달라고 난리 남). 사장님은 구석에 앉은 딱 1팀의 테이블(1% 트래픽)에만 새 레시피의 찌개를 몰래 내어줍니다(카나리 배포). 사장님은 멀리서 그 테이블 손님 표정이 일그러지는지 관찰합니다. 손님이 "오 맛있네!"라고 하면, 그때부터 5개, 10개 테이블로 새 찌개 배급을 늘려가는 절대 망하지 않는 식당 운영 철칙입니다.