84. 블루/그린 배포 (Blue/Green Deployment) - 광속 스위칭과 무중단 아키텍처

⚠️ 이 문서는 서버 업데이트 도중 신버전(v2.0)과 구버전(v1.0) 화면이 짬뽕으로 섞여 고객을 멘붕에 빠뜨리는 '롤링 배포'의 지저분한 한계를 완벽하게 박살 내기 위해, **돈을 아끼지 않고 클라우드 허공에 100% 똑같은 거울 세계 쌍둥이 서버(Green)를 통째로 띄워놓은 뒤, 문지기(로드밸런서)의 방향을 단 0.1초 만에 확 꺾어버려 수만 명의 고객을 한 방에 미래(v2.0)로 텔레포트시키는 갑부들의 궁극적 무중단 배포 전술인 '블루/그린 배포'**를 다룹니다.

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

  1. 본질: 두 개의 완벽히 격리된 환경(Blue, Green)을 활용한다. 현재 장사 중인 서버(Blue)는 건드리지 않고, 텅 빈 옆 건물(Green)에 새 코드를 다 깔고 요리 준비를 마친 뒤, 손님들이 들어오는 정문 간판(라우팅)만 옆 건물로 1초 만에 스위칭(전환)해버리는 공간 마법이다.
  2. 가치: 배포 중간에 버전이 뒤섞이는 일(Inconsistency)이 절대 없다(0%). 또한 치명적 버그가 터졌을 때 서버를 다시 끄고 켤 필요 없이 간판만 다시 구형 건물(Blue)로 1초 만에 꺾으면 되므로 **'초광속 무피해 롤백(Rollback)'**을 보장하는 우주 최강의 방패막이다.
  3. 기술 체계 (치명적 한계): 배포하는 그 10분 남짓한 시간 동안 서버 자원(클라우드 인스턴스 비용)이 **정확히 2배로 폭발적 소모(100대 $\rightarrow$ 200대)**되므로 자금력이 뒷받침되어야 하며, 두 건물이 동시에 하나의 데이터베이스(DB)를 바라볼 때 발생하는 DB 스키마 하위 호환성 및 트랜잭션 유실 문제를 극복하는 것이 가장 뼈아픈 숙제다.

Ⅰ. 롤링 배포의 딜레마와 블루/그린의 도래

찔끔찔끔 바꾸지 마라. 새로운 세상(Green)을 완벽히 창조한 뒤 문을 열어라.

  1. 버전 혼재의 악몽 (롤링의 한계):
    • 롤링 배포(Rolling)는 바퀴를 하나씩 갈아 끼운다. 100대 중 50대가 교체된 시점, 고객이 장바구니에 물건을 담을 땐 v2.0 서버를 타고, 결제 버튼을 누르는 순간 재수 없게 뒷단의 v1.0 서버로 라우팅 되면?
    • 코드가 안 맞아서 장바구니 데이터가 허공에 증발하고 고객은 쌍욕을 박으며 500 에러 창을 본다. 프론트엔드/백엔드 덩어리 앱(Monolithic)일수록 이 혼재 현상은 치명적 독이 된다.
  2. 블루(Blue)와 그린(Green)의 2개 우주 창조:
    • Blue 환경: 현재 1만 명의 고객이 접속해서 결제 중인 v1.0 서버 100대 묶음이다. (절대 건드리지 않고 신성불가침 영역으로 둔다.)
    • Green 환경: 클라우드 허공에 AWS EC2(또는 K8s 파드) 100대를 새로 결제해서 펑 띄운다. 여기에 v2.0 새 코드를 쫙 배포한다. 고객 트래픽은 0(Zero)이다.
  3. 격리된 QA (사전 내부 테스트):
    • Green 서버가 100% 떴다. 하지만 손님은 아직 한 명도 없다.
    • 이때 사내 개발팀과 QA 테스트 로봇들만 'Green 전용 비밀 뒷문(Test URL)'으로 슬쩍 들어간다. 결제도 해보고 장바구니도 담아본다. 고객은 전혀 모른 채 운영망과 완벽히 동일한 인프라에서 최후의 실전 테스트를 1시간 동안 안전하게 수행한다.

📢 섹션 요약 비유: 맥도날드(Blue)가 장사 중입니다. 롤링 배포는 손님들이 햄버거를 먹고 있는데 주방 아줌마 한 명씩 불러내어 유니폼을 갈아입히는 산만한 짓입니다. 블루/그린 배포는 돈을 쳐발라서 아예 옆 공터에 맥도날드 2호점(Green) 건물을 똑같이 지어버립니다. 2호점 주방에 빨간 유니폼 입은 알바들을 세팅하고, 사장님이 들어가서 햄버거(QA 테스트)를 먹어봅니다. 완벽하다 싶으면, 바깥 도로의 네비게이션 표지판(로드밸런서) 방향을 1초 만에 2호점 쪽으로 휙 꺾어버려서, 뒤따라오던 차들이 아무 혼란 없이 스무스하게 2호점으로 빨려 들어가 햄버거를 사게 만드는 위대한 공간 분리 건축술입니다.

Ⅱ. 트래픽 스위칭과 빛의 롤백 (Rollback) 마법

배포가 망했을 때 소스코드를 컴파일하느라 땀 빼는 자는 3류다.

  1. 대망의 스위칭 (Traffic Routing):
    • 사내 QA팀의 "OK!" 사인이 떨어졌다.
    • 데브옵스 엔지니어는 앞단에 있는 로드밸런서(AWS ALB, Route 53 DNS, 또는 K8s Service)의 설정 창을 연다.
    • 타겟 그룹(Target Group)의 포인터를 Blue(10.0.0.1)에서 Green(10.0.0.2)으로 변경하고 [Apply] 버튼을 꽝 누른다.
    • 단 0.1초 만에 밀려들던 트래픽의 물줄기가 꺾이며, 모든 고객은 새로고침 한 번에 화면이 v2.0으로 싹 바뀐다. 구형 화면과 신형 화면이 뒤섞이는 기분 나쁜 골짜기(버전 혼재)는 단 1초도 존재하지 않는다.
  2. 초광속 생존술 (무피해 롤백):
    • 트래픽을 Green으로 넘긴 지 5분 뒤, 사내 테스트 때 못 잡았던 "결제 시 100원이 덜 깎이는 치명적 버그"가 현장에서 터져 난리가 났다.
    • 롤링 배포였다면? 소스코드를 v1.0으로 git revert 치고 도커 이미지를 구워서 다시 1대씩 서버를 내리고 올리느라 30분 동안 회사는 수십억의 손해를 본다.
    • 블루/그린은 다르다. 아까 버려진 파란색(Blue) 서버 100대 묶음의 전원을 아직 안 끄고 살려뒀다(Wait).
    • 엔지니어가 1초 만에 로드밸런서의 포인터를 다시 Green $\rightarrow$ Blue 로 휙 꺾어버린다. 끝이다. 고객은 1초 전 버그를 봤다가 F5를 누르니 멀쩡했던 어제 화면(v1.0)으로 완벽하게 되돌아오는 시간 여행(광속 롤백)을 경험하며 회사 생명이 유지된다.

📢 섹션 요약 비유: 기차 선로 전환기입니다. 기차(트래픽)가 구형 선로(Blue)로 달리고 있습니다. 신형 선로(Green)를 다 깔아놨습니다. 기관사가 레버를 탁! 당기는 1초의 찰나에 기차는 매끄럽게 신형 선로로 방향을 틀어 질주합니다. 그런데 신형 선로 앞에 바위(치명적 버그)가 굴러떨어진 걸 발견했습니다! 기관사는 식은땀을 흘리며 소스코드(선로)를 곡괭이로 파내서 고칠 시간이 없습니다. 1초 만에 레버를 팍! 반대로 당겨 다시 방금 전 구형 선로(Blue)로 기차를 되돌려 넣어 10만 명 승객의 목숨(매출)을 지체 없이 살려내는 궁극의 보험(롤백) 스위치입니다.

Ⅲ. 치명적 맹점 2가지 (돈과 DB 트랜잭션의 늪)

빛이 강할수록 그림자도 짙다. 갑부의 전술엔 막대한 세금이 따른다.

  1. 클라우드 요금 폭탄 (2x Resource Cost):
    • 블루/그린의 가장 크고 명확한 단점이다. 스위칭을 앞둔 배포 기간(약 1시간~하루) 동안, 클러스터 허공에는 Blue 100대 + Green 100대 = 총 200대의 서버가 징징거리며 돌아간다.
    • 만약 10,000대의 서버를 돌리는 넷플릭스라면, 이 한 번의 꿀 같은 배포를 위해 허공에 10,000대의 서버 월세를 순식간에 2배로 태워야 하는 무지막지한 클라우드 요금 폭탄(비용 2배)을 맞게 된다. (돈 없는 스타트업이 침만 흘리다 롤링 배포를 돌리는 이유다.)
  2. 최악의 적: 데이터베이스 (Stateful) 동기화의 딜레마:
    • 웹 서버(Stateless) 100대는 휙 꺾으면 그만이지만, 뒷단에 무거운 데이터베이스(DB)는 Blue와 Green 두 군데로 복사해 둘 수 없다. (두 집 살림하면 회원가입 데이터가 반으로 갈라져 망함.)
    • 결국 Blue(v1.0) 웹 서버와 Green(v2.0) 웹 서버가 똑같은 하나의 중앙 DB의 빨대를 동시에 꽂고 바라봐야 한다.
    • 대참사 시나리오: 트래픽을 Blue에서 Green으로 꺾는 0.1초의 찰나에, 어떤 고객 A가 Blue 쪽에 '장바구니 담기(INSERT)'를 누르고 로딩이 도는 상태였다. 그런데 트래픽 밸브가 Green으로 팍 잠겨버려서, A의 장바구니 DB 트랜잭션이 허공에 붕 뜨고 짤려버려 돈만 빠져나가고 물건은 없는 결제 사고가 터진다.
    • 해결책 (Connection Draining): 스위치를 팍 꺾을 때, Blue 쪽 밸브를 아주 서서히 잠근다. "새 손님은 Green으로 가고, 이미 Blue에 들어와 결제 중이던 손님은 결제(세션) 끝날 때까지 3분 정도 기다려 주마!"라는 우아한 종료(Graceful Shutdown) 세팅을 거쳐야만 무결점의 블루/그린이 완성된다.

📢 섹션 요약 비유: 맥도날드 2호점(Green) 꼼수는 완벽해 보이지만 2가지 출혈이 있습니다. 첫째, 1호점과 2호점을 며칠 동안 동시에 임대하느라 월세(클라우드 비용)가 두 배로 깨집니다. 둘째, 손님 방향을 2호점으로 확 꺾으라며 1호점 문을 쾅 잠가버리면, 1호점에서 햄버거 한 입 베어 물고(DB 트랜잭션 도중) 서 있던 불쌍한 손님이 문에 갇혀 질식사(데이터 유실)합니다. 진정한 매니저는 1호점 정문 셔터는 내리되(신규 유입 차단), 이미 들어와 씹고 있는 손님들이 햄버거를 다 삼키고 뒷문으로 빠져나갈 3분의 시간(Graceful Shutdown)을 자비롭게 허락한 뒤에야 1호점 불을 끄는 세심한 지능범이어야 합니다.