MyAI(마이아이)개발 · 제품 · 운영 학습 노트

Release 전략: Rolling · Blue-Green · Canary · Feature Flag · Rollback

배포(Deploy)와 출시(Release)는 다르다. Deploy는 코드를 환경에 올리는 것, Release는 사용자가 그 변경을 경험하게 하는 것이다. 둘을 분리할수록 위험이 작아진다.

전략 한눈에 보기

전략 방식 장점 비용 / 주의
Recreate 기존 버전을 내리고 새 버전을 올림 단순 중단 시간 발생
Rolling Instance를 조금씩 교체 추가 자원이 적음 두 버전이 잠시 공존
Blue-Green 동일한 환경을 하나 더 만들고 Routing 전환 전환·복귀가 빠름 일시적으로 자원 2배
Canary 일부 Traffic만 새 버전으로 보내고 비교 영향 범위 최소화 지표와 비교 기준 필요
Feature Flag 코드는 배포하고 기능 노출만 설정으로 제어 Deploy와 Release 분리 Flag 부채 관리 필요

Rolling Update

Kubernetes Deployment의 기본 전략이다. maxUnavailable과 maxSurge의 기본값은 모두 **25%**다.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

Blue-Green

flowchart LR
    U[사용자] --> R[Router / Load Balancer]
    R -->|현재| B[Blue: v1]
    R -.->|전환 후| G[Green: v2]

새 버전(Green)을 Production과 같은 환경에 올려 검증한 뒤 Router만 바꾼다. 문제가 생기면 Router를 다시 Blue로 돌린다. Database Schema가 두 버전 모두와 호환되어야 이 복귀가 실제로 가능하다.

Canary

Google SRE Workbook은 Canary를 변경을 일부에, 일정 시간 동안 배포하고 평가하는 것으로 정의한다. 작은 Production 구간(Canary)과 나머지(Control)를 비교해 진행 여부를 결정한다.

flowchart LR
    D[새 버전 배포] --> C1[1% Traffic]
    C1 --> E1{Error / Latency 비교}
    E1 -->|정상| C2[10% Traffic]
    C2 --> E2{다시 비교}
    E2 -->|정상| C3[100% Traffic]
    E1 -->|이상| RB[Rollback]
    E2 -->|이상| RB

비교 지표 예: Error Rate, p95 Latency, Crash Rate, 핵심 전환율. 자동화할 때는 통과 기준을 배포 전에 정해 둔다.

Traffic을 나누는 방법은 Platform마다 다르다.

Feature Flag

martinfowler.com에 실린 Pete Hodgson의 글 "Feature Toggles"는 Release Toggle을 "기능 Release와 코드 Deployment를 분리"하는 가장 흔한 방법으로 설명한다.

Flag 종류 수명 예
Release Toggle 짧음 미완성 기능 숨기기
Experiment Toggle 실험 기간 A/B Test
Ops Toggle 운영 중 장애 시 무거운 기능 끄기 (Kill Switch)
Permissioning Toggle 김 유료·Beta 사용자에게만 노출

Rollback과 Roll Forward

Rollback      이전 Artifact로 되돌린다. 빠르고 예측 가능하다.
Roll Forward  수정 버전을 새로 배포한다. Data 변경이 되돌릴 수 없을 때 선택한다.
Flag Off      코드는 두고 기능만 끈다. 가장 빠르다.

되돌리기를 어렵게 만드는 가장 흔한 원인은 Database Migration이다. Parallel Change(Expand → Migrate → Contract) 패턴으로 나눈다.

  1. Expand: 새 Column을 추가하고 구·신 코드 모두 동작하게 한다.
  2. Migrate: Data를 옮기고 새 코드로 전환한다.
  3. Contract: 더 이상 쓰지 않는 Column을 제거한다(충분히 안정된 뒤).

나쁜 예 / 좋은 예

나쁜 예: Column 이름 변경과 코드 배포를 한 번에 한다. 배포 실패 시 이전 코드가 새 Schema에서 깨진다.
좋은 예: Column 추가 → 양쪽 쓰기 → 읽기 전환 → 구 Column 제거를 여러 Release로 나눈다.

모바일은 어떻게 다른가

모바일 앱은 이미 설치된 Binary를 되돌릴 수 없다. 그래서 Store의 단계적 출시(Apple Phased Release, Google Play Staged Rollout)와 Server 측 Feature Flag가 더 중요하다. 자세한 내용은 05 문서에서 다룬다. 이미 기기에 깔린 문제 Build를 퇴출하는 유일한 방법은 Server가 확인하는 최소 지원 버전과 강제 Update 화면이며, 출시 전에 만들어 시험해 두어야 한다(05 문서의 Staged Rollout 운영).

참고 자료