블루 그린 및 카나리아 릴리스

(섹션: 아키텍처 및 프로토콜)

1) 왜 "안전한 롤아웃" 이 필요합니까?

최신 시스템에서 릴리스는 코드 전달뿐만 아니라 판매 통제 실험이기도합니다. 동시에 위험을 최소화하고 (사용자를 파괴하지 마십시오) 피드백 시간을 줄입니다 (효과를 신속하게 참조). Blue-Green과 Canary의 두 가지 고전적인 전략은 다른 방식으로이 문제를 해결하지만 공통 목표는 제로 다운 타임, 빠른 롤백, SLO의 관찰 가능성입니다.

2) 기본 정의

청록색

우리는 두 가지 본격적인 생산 환경 사본을 유지합니다. 액티브 (블루) 는 트래픽을 제공하고 패시브 (그린) 는 새 버전을 준비하고 있습니다. 스위칭은 밸런서/라우터 레벨에서 원자 (스위치/플립) 입니다. 더 나빠지면 즉시 블루로 돌아갑니다.

카나리아

먼저 트래픽의 작은% (예: 1-5%) 로 배포하고 메트릭/SLO를 관찰 한 다음 단계별로 점유율을 높입니다 (10% → 25% → 50% → 100%). 분해 중-이전 안정적인 단계에서 롤백 또는 정지

3) 어떤 접근 방식이 가장 좋은시기

Blue-Green-다음을 선택하십시오

복잡한 기동없이 즉시 롤백이 필요합니다.
아키텍처/예산은 이중 인프라 복제를 허용합니다.
대규모 마이그레이션 또는 플랫폼 업데이트 (OS/JDK/런타임) 를 단독으로 수행하려고합니다.
응용/연결 풀은 점진적인 "혼합" 상태에 민감합니다.

카나리아-다음을 선택하십시오

폭발 반경을 최소화하고 사용자 공유의 동작을 확인해야합니다.
높은 출시율, 정상적인 점진적 전달.
성숙한 관찰 성과 자동 게이트 (오류 예산, 대기 시간, 변환) 가 있습니다.
제품 팀은 변환, 보존, LTV 등에 미치는 영향과 같은 가설을 테스트하려고합니다.

4) 성공적인 릴리스를위한 일반적인 원칙

Idempotent 빌드 아티팩트: 모든 단계에서 동일한 이미지/패키지.
결정 론적 구성: 코드로 설정, 환경의 비교 가능성.
설계 별 관찰 가능성: 로그, 메트릭, 추적, 경고; 사전에 SLI/SLO.
빠른 자동 롤백: 롤백 버튼/명령은 수동 마법이 아닌 파이프 라인의 일부입니다.
호환 가능한 스키마 변경: 확장 마이그레이션 계약 전략 (§ 10 참조).
L7 라우팅 (바람직한): API 헤더/쿠키/경로/버전의 유연성.

5) 청록색: 건축 및 프로세스

5. 1 토폴로지

두 개의 prod 스택: 파란색 (활성) 과 녹색 (후보).
일반적인 외부 종속성: CNC, 외부 API, 대기열; DB는 특별한 경우입니다 (§ 10 참조).
스위치 포인트: 밸런서/침입/게이트웨이.

5. 2 단계별 흐름

1. 새로운 아티팩트 (vNext) 하에서 Green을 올리고 스모크 테스트를 수행합니다.
2. Green (e2e, 계약, 회귀) 에 대한 자동 실행.
3. 캐시/세션을 예열하고 (해당되는 경우) 배경 bs/큐를 동기화하십시오.
4. 트래픽을 그린으로 전환: 원자 플립 (DNA TTL 낮음, Route/Listener 교환, Ingress weight = 100%).
5. 처음 몇 분/시간에 SLO를 관찰합니다 (황금 신호: 대기 시간, 오류, 채도 + 비즈니스 지표).
6. 문제가있는 경우-즉시 파란색으로 돌아갑니다 (뒤로).

5. 3 개의 단점

장점: 인스턴트 롤백, 간단한 정신 모델, 순수한 격리.
단점: 인프라의 두 배, 고정 구성 요소의 어려움 및 데이터 마이그레이션.

6) 카나리아 건축 및 프로세스

6. 1 토폴로지

단일 생산 클러스터; 단일 전선 뒤에 여러 버전의 서비스 (안정 및 카나리아).
트래픽은 가중치 (1-5-10-25-50-100%) 또는 대상 (헤더/쿠키/ID) 으로 나뉩니다.

6. 2 단계별 흐름

1. 카나리아 버전을 동일한 클러스터/ASG/NSG에 배포합니다.
2. 일부 트래픽 (예: 1-5%) 을 카나리아로 라우팅하십시오.
3. SLI/SLO 및 비즈니스 지표의 자동 점검; CI/CD의 게이트 (오류율, p95 대기 시간, CPU/RES, 변환, 거부/반환).
4. 게이트를 통과 할 때 트래픽 점유율이 단계별로 증가합니다.
5. 100% 로의 전체 출시 및 이전 버전의 비활성화; 열화의 경우-자동 롤백.

6. 3 개의 단점

장점: 데이터 중심 솔루션 인 대부분의 사용자에게 최소한의 위험.
단점: 성숙한 관찰 가능성, 유능한 라우팅, 인스턴스 간의 "버전 왜곡" 위험이 필요합니다.

7) 트래픽 라우팅

레이어 L4: IP/포트 별 균형; 간단하지만 유연성은 거의 없습니다.
레벨 L7: 경로, 호스트, 헤더, 쿠키, 사용자 에이전트, GeoIP, SNI에서 HTT/S 규칙.

• 가중 라우팅 (가중치 1-100%).
• 헤더 기반/쿠키 기반.
• 세션 끈적 끈적함 (고정/캐시 된 스크립트에 중요).
• 섀도우/트래픽 미러링 (새 버전에 대한 미러 요청 "조용히").

8) 도구 및 구현 (예)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
차이나: AWS ALB/ELB, Route 53 가중 레코드, ECS/EKS; GCP 부하 밸런싱 + NEG; Azure Front Door/App 게이트웨이.
CD 플랫폼: Spinnaker, Argo CD, GitHub Actions + Progressive Delivery 플러그인, GitLab/CD.

9) 관찰 가능성, SLI/SLO 및 게이트

황금 신호: 대기 시간 (p95/p99), 오류율 (5xx/4xx

비즈니스 지표: 전환, 승인, 지불/성공, 평균 점검, 깔때기 단계 거부.

• 오류 임계 값 (예: 오류율 카나리아 기준 + X%).
• p95 대기 시간은 기준선보다 더 나쁘지 않습니다.
• 비즈니스 임계 값 (예: 변환 감소
• SLO 오류 예산이 더 빨리 연소되지 않아야합니다.

단계 지속 시간: 통계적 유의성에 충분한 최소 시간 (트래픽에 따라 다름).

10) 데이터베이스 마이그레이션 및 스키마 호환성

주요 규칙: 앞뒤로 버전이 호환되는 경우 릴리스가 안전합니다.

1. 확장: 이전 버전을 깨지 않고 새 열/색인/테이블을 추가하십시오.

2. 앱 vNext를 배포합니다 (새 체계를 읽거나 쓰지만 이전 체계와 작업하는 방법을 알고 있음).

3. 마이그레이트 데이터 (배경/배치, demotent, 체크 포인트 포인트 포함).

4. 계약: 안정화 후 이전 필드/기능을 삭제하십시오.

반 패턴: Blue-Green 스위치 지점에서 독점적 인 차단이 필요한 마이그레이션; 체계를 다운 그레이드 할 수 없음; 중복없이 "이중 쓰기".

11) 롤백 및 비상 계획

청록색: 청색에 즉시 뒤집기; 녹색 배경 작업의 꼬리를 모니터링하십시오

카나리아: 무게 롤백 (예: 25% 에서 5% 또는 0%); 경고시 자동 중단.
데이터: 반복/보상에 대한 잘 알려진 정책 (idempotency 키, "받은 편지함/아웃 박스" 패턴, 메시지 중복 제거).
Ficheflags: 부분적으로 출시 된 기회를 종료하기위한 빠른 킬 스위치.

12) 주 및 세션과 협력

카나리아를위한 끈적 끈적한 세션 또는 버전을 상호 교환 할 수 있도록 외부 세션 (Redis/Memcashed) 을 저장합니다.
미리 예열하고 (녹색 예열) 뒤집을 때 무효화를 고려하십시오.
배경 작업자: 버전별로 대기열 분리 또는 "리더십" 버전간에 "인종" 을 허용하지 않습니다.

13) 안전 및 준수

Zero Trust의 Green/Canary 액세스: 서비스 계정, 최소 필수 역할.
비밀 및 키-KMS/비밀 관리자를 통한; 회전을 켜십시오.
트래픽 - TLS 만; 엔드 포인트 버전이 명확하게 표시됩니다. 감사 라우팅 및 해제 활동.

14) 비용과 성능

Blue-Green은 출시 당시 또는 지속적으로 예산을 두 배로 늘 렸습니다.
카나리아는보다 경제적이지만 자동화하려면 관찰 가능한 도구와 엔지니어링 시간이 필요합니다.
최적화: 오토 스케일, 임시 환경, 버전의 병렬 존재 창 단축.

15) 점검표

출시 전

• 단일 소스에서 홍보 된 이미지/빌드, 서명 확인.
• 테스트 계획, 경고 및 SLO 게이트가 구성됩니다.
• 데이터베이스 마이그레이션-확장 모드에서는 다운 그레이드 계획을 사용할 수 있습니다.
• 롤백 계획-준비/생산과 유사한 점검.

출시 당시

• 메트릭 및 로그는 기준선과 비교됩니다.
• 카나리아의 경우 단계와 임계 값이 수정됩니다. Blue-Green-플립 백 준비.
• 통화 중 명령은 알고 있으며 피드백 창이 있습니다.

출시 후

• SLO가 가라 앉지 않았고 오류 예산은 정상입니다.
• 출시 후 마이그레이션/정리가 완료되었습니다.
• 회고 및 플레이 북 업데이트.

16) 빈번한 오류 및 패턴 방지

메트릭이없는 롤아웃: 데이터 없음-관리 솔루션 없음.
호환되지 않는 데이터베이스 체계, 다운 그레이드 전략 부족.
무작위 트래픽 믹싱: 끈적 거리지 않고 사용자가 버전간에 "점프" 합니다.
숨겨진 안정적인 종속성 (로컬 디스크, 메모리 내 캐시).
Long DNA-TTL은 빠른 플립 (Blue-Green) 을 방해합니다.
자동 게이트 부족: 수동 "눈 별" 솔루션이 느려지고 위험이 증가합니다.

17) 결합 된 접근 방식

Blue-Green + Canary: 먼저 Green을 출시 한 다음 Green 내부에서 개별 서비스를 위해 Canary를 출시하십시오.
그림자/마이그레이션 트래픽: 카나리아 이전에는 새 버전으로 미러 트래픽을 실행합니다.
기능 플래그 (프로그레시브 전달): 기능은 세그먼트별로 "어두운" 플래그로 안정적인 버전 위에 포함됩니다.

18) 샘플 시나리오 (스케치)

1. 새로운 청취자/침입을 위해 녹색 (v2) 을 배포하십시오.

2. 캐시를 데우고 재확인 검사를 수행하고 담배를 피우십시오.

3. 무게를 Green = 100% 로 전환합니다.

4. SLO를 30-60 분 동안 관찰하십시오. 모든 것이 괜찮다면-파란색을 끄십시오.

1. 카나리아 vNext 배포 (복제 5%).

2. 내부 계정/테스트 세그먼트의 트래픽 5% 가 포함됩니다.

3. 자동 게이트: 오류율은 기준선 + 0입니다. 3%, p95 λ+ 20ms.

4. 게이트를 통과 할 때 N 분마다 10% → 25% → 50% 증가합니다.

5. 모든 세그먼트에 대해 ficheflag를 100% 번역합니다. 이전 버전을 삭제합니다.

19) 다른 아키텍처의 변형

Monolith: Blue-Green은 더 간단하고 Canary는 기능의 불가분화로 인해 더 어렵습니다. ficheflags를 사용하십시오.

마이크로 서비스: 카나리아는 자연 스럽습니다. 소비자 중심 계약을 모니터링하십시오

안정적인 서비스: 신중하게 제작 된 마이그레이션과 끈적 끈적함이있는 Blue-Green을 선호하십시오.

20) 간단한 비교 (요약)

롤백 속도: Blue-Green = 순간; 카나리아 = 빠르지 만 무게가 줄어 듭니다.

인프라 비용: Blue-Green JA; 카나리아 리더

사용자 위험: 카나리아가 낮습니다 (우리는 점유율을 제어합니다).
구현 난이도: Blue-Green은 시작하기가 더 쉽습니다. 카나리아는 강력한 관찰 성과 자동화가 필요합니다.
데이터/회로 호환성: 둘 다에 중요한; 확장 마이그레이션 계약 계획.

21) 결론

Blue-Green과 Canary는 상호 배타적 인 전략이 아니라 점진적인 전달 요소입니다. 선택은 비용 제약, 관찰 성숙도 및 변경 특성에 따라 다릅니다. 접근 방식에 관계없이 지속 가능한 릴리스는 자동화, 관찰 가능성, 이전 버전과의 호환성 및 빠른 롤백의 네 가지 기둥에 있습니다.