이 글에서 얻는 것

  • 배포를 “코드 올리기”가 아니라 변경을 안전하게 적용하는 절차로 설계할 수 있습니다.
  • 롤링/블루그린/카나리 같은 전략을 “언제 무엇을 쓰는지” 기준으로 선택할 수 있습니다.
  • DB 마이그레이션이 포함된 배포에서 호환성(확장/수축, expand/contract) 원칙을 적용할 수 있습니다.
  • 장애 조짐이 보일 때 “배포 중단/완화/롤백”을 어떤 순서로 판단해야 하는지 런북 감각이 생깁니다.

0) 배포는 ‘변경 관리’다

안전한 배포는 한 문장으로 요약하면 이렇습니다.

  • 변경 범위를 작게 나누고(Blast radius),
  • 빨리 감지하고(Detect),
  • 빨리 복구한다(Recover).

그래서 런북에는 “명령”만이 아니라, **판단 기준(어떤 지표가 얼마면 중단/롤백할지)**가 들어가야 합니다.

1) 배포 전략 4가지(운영 감각)

  • Rolling: 인스턴스를 순차 교체(단순). 호환성(구버전/신버전 공존)이 중요.
  • Blue/Green: 두 환경을 유지하고 트래픽을 전환(롤백 빠름). 비용이 더 듦.
  • Canary: 일부 트래픽만 신버전에 보내며 검증(안전). 관측/분리 설계가 필요.
  • Shadow: 트래픽을 복제해 실제 응답은 버리고 영향만 관측(위험 낮음). 구현 비용이 큼.

2) 배포 전에 ‘반드시’ 결정할 3가지

  1. 검증 기준: 무엇을 보면 성공/실패인지(예: 5xx, p99, 핵심 플로우 성공률)
  2. 완화 수단: 피처 플래그/트래픽 스위치/레이트리밋 등 “즉시 영향 줄이는 버튼”
  3. 되돌리기 방법: 코드 롤백만 가능한지, 데이터/스키마까지 손댈지(가장 중요)

이 3개가 없으면 배포 중 이상이 생겼을 때 “우왕좌왕”하게 됩니다.

3) DB 마이그레이션이 있는 배포: expand/contract 원칙

가장 안전한 방식은 “한 번의 배포로 스키마를 완전히 바꾸지 않는 것”입니다.

예시(감각):

  1. 스키마 확장(expand): 컬럼/테이블 추가(기존 코드가 깨지지 않게)
  2. 애플리케이션 배포: 신/구버전이 공존해도 동작하도록 읽기/쓰기 호환
  3. 데이터 이행(backfill): 배치로 데이터 채우기
  4. 스키마 수축(contract): 제약 강화/컬럼 삭제 같은 파괴적 변경은 “마지막”에

핵심은 “롤백 가능성”입니다. 파괴적 변경(컬럼 삭제/타입 변경/NOT NULL 강제 등)은 롤백을 거의 불가능하게 만들 수 있습니다.

4) 배포 런북 템플릿(복사해서 쓰는 형태)

4-1) 사전 확인(배포 시작 전)

  • 변경 범위: 어떤 기능/엔드포인트/배치가 영향을 받는지
  • 의존성: DB/캐시/메시지/외부 API 상태(최근 장애/지연)
  • 관측 준비: 대시보드/알람/로그 조회 링크(배포 중 클릭 한 번에 보이게)
  • 완화 수단: 피처 플래그 기본값/레이트리밋/트래픽 스위치 준비

4-2) 배포 실행(롤링/카나리/블루그린)

  • 롤링: 배치 단위(몇 개씩)와 관찰 시간(몇 분)을 정한다
  • 카나리: 트래픽 비율(예: 1%→5%→25%→100%)과 각 단계 검증 지표를 정한다
  • 블루그린: 컷오버 시점과 “롤백은 라우팅만 되돌리면 되는지”를 확인한다

배포 중 반드시 보는 것:

  • 에러율(5xx/의미 있는 실패)
  • 레이턴시(p95/p99)
  • 포화(CPU/메모리/스레드/커넥션 풀/큐)
  • 의존성 상태(DB slow/lock, Kafka lag 등)

4-3) 배포 후 검증(스모크 테스트)

  • 핵심 플로우 3~5개(로그인/조회/생성/결제 같은 것)만 고정해서 빠르게 확인
  • “정상 트래픽”뿐 아니라, 실패 케이스(권한 없음/잘못된 입력)도 한두 개 확인
  • 에러 로그가 급증하지 않는지(특정 예외/특정 엔드포인트) 확인

4-4) 이상 발생 시 대응(중단 → 완화 → 롤백)

  1. 배포 중단: 더 퍼지지 않게 롤아웃을 멈춘다
  2. 완화: 피처 플래그 off / 레이트리밋 / 트래픽 우회 등 즉시 조치
  3. 롤백: 문제 원인이 “새 버전”이 확실하고, 데이터 리스크가 낮으면 빠르게 롤백

롤백은 2종류로 나눠서 생각하면 좋습니다.

  • 트래픽 롤백: 라우팅/서비스 셀렉터를 이전으로(블루그린/카나리에서 강력)
  • 코드 롤백: 이전 이미지/릴리즈로 되돌리기(롤링에서는 이게 핵심)

데이터/스키마 문제가 섞이면 “롤백”이 아니라 “서비스 보호(쓰기 차단/기능 off) + 복구(runbook)”로 접근해야 합니다.

5) 배포가 끝난 뒤(운영 루프)

  • “배포 중 어떤 지표가 흔들렸는지”를 짧게 기록(다음 배포의 기준이 됨)
  • 장애가 있었다면 원인/대응/재발 방지를 런북에 반영(런북은 계속 진화해야 합니다)

연습(추천)

  • 내 서비스의 배포 런북을 1페이지로 써보기(검증 지표 3개 + 중단/롤백 기준 3개)
  • DB 스키마 변경이 포함된 배포를 하나 골라 expand/contract로 분해해보기
  • “피처 플래그 off”로 즉시 완화되는 시나리오를 만들어보고, 배포 중 실제로 써보기