배포 전략

구버전에서 신버전으로 트래픽을 옮기는 방식. 셋이 흔하다.

롤링 — 조금씩 바꿔 끼운다

인스턴스를 몇 개씩 새 버전으로 교체한다. 추가 자원이 필요 없어 기본값으로 많이 쓴다.

문제는 중간 상태가 길다는 것이다. 교체 중에는 구버전과 신버전이 동시에 떠 있으므로, 두 버전이 같은 DB·같은 API 와 공존할 수 있어야 한다. 응답 형식이 바뀌었다면 그 사이 요청이 어느 쪽으로 가느냐에 따라 결과가 달라진다.

블루-그린 — 통째로 세워 두고 바꾼다

사용자 → [라우터] ─ 현재 ─→ 블루(v1)
                  ─ 대기 ─→ 그린(v2)   ← 미리 다 띄워 검증
              스위치 전환 후 즉시 되돌릴 수 있다

되돌리기가 가장 빠르다 — 스위치만 되돌리면 되고, 구버전이 그대로 살아 있다. 대신 잠시 자원이 두 배로 든다.

주의할 것은 전환이 전부 아니면 전무라는 점이다. 검증에서 못 잡은 문제가 있으면 전환 순간 모든 사용자가 동시에 겪는다.

카나리 — 일부에게만 먼저

5% → 지표 확인 → 25% → 확인 → 50% → 100%
        ↓ 나빠지면
     그 자리에서 중단·회수

문제가 나도 5% 만 겪는다는 것이 핵심 값어치다. 다만 이 방식은 지표를 자동으로 보고 판단할 수 있을 때만 의미가 있다. 사람이 대시보드를 지켜보며 단계를 올린다면 자동 배포라 하기 어렵고, 5% 트래픽에서 유의미한 차이를 읽으려면 일정 규모도 필요하다.

세 전략 모두 전제로 하는 것

트래픽을 옮기려면 새 인스턴스가 받을 준비가 됐는지 알아야 한다. 프로세스가 떴다고 요청을 받을 수 있는 것은 아니다 — 커넥션 풀이 차고 캐시가 데워질 때까지 시간이 걸린다.

준비 상태 확인이 없으면 어느 전략을 쓰든 아직 준비 안 된 인스턴스로 트래픽이 가서 초기 요청이 실패한다. 배포 직후에만 오류가 튀는 증상이 이것이다.

반대쪽도 있다. 내리는 인스턴스는 처리 중인 요청을 끝낼 시간이 필요하다. 곧바로 죽이면 진행 중이던 요청이 잘린다. 트래픽을 먼저 끊고 잠시 기다린 뒤 종료하는 순서가 필요하다.

데이터베이스가 진짜 제약이다

애플리케이션은 두 벌 띄울 수 있지만 DB 는 보통 한 벌이다. 그래서 배포 전략이 무엇이든 두 버전이 같은 스키마를 동시에 다룰 수 있어야 한다. 블루-그린이 "완전히 분리" 처럼 보여도 DB 는 공유하므로, 스키마 변경은 여전히 단계적으로 해야 한다.

무엇을 고르나

• 트래픽이 작다 — 롤링으로 충분하다. 카나리는 표본이 안 나온다
• 되돌리는 속도가 절대적이다 — 블루-그린
• 규모가 크고 지표가 갖춰져 있다 — 카나리

어느 쪽이든 구버전과 신버전이 잠시 공존한다는 사실은 같다. API 하위 호환은 배포 전략과 무관하게 지켜야 한다.

면접 함정

• ❌ "블루-그린은 무중단이니 가장 좋다" → 자원이 두 배고, 전환 순간 전원이 동시에 영향을 받는다.
• ❌ "카나리는 안전하다" → 자동 판단 기준이 없으면 그냥 느린 배포다.
• ❌ "롤링은 중간 상태를 신경 안 써도 된다" → 두 버전이 공존하는 구간이 가장 길다.