기준: MLS-C01 시험 가이드오류 제보
새 모델이 실제 데이터 분포 변화, 지연 증가, 특정 세그먼트 실패로 무너지는 일은 흔하다. 그래서 배포는 "띄우거나 실패하거나"가 아니라 다중 Variant + 가중치라는 한 개의 레버 위에서 설계된다.
from sagemaker.session import production_variant
variant_a = production_variant("ModelA", "ml.m5.xlarge", initial_weight=90, initial_instance_count=2)
variant_b = production_variant("ModelB", "ml.m5.xlarge", initial_weight=10, initial_instance_count=1)
session.endpoint_from_production_variants("ab-endpoint", [variant_a, variant_b])TargetVariant 파라미터로 특정 호출을 원하는 Variant에 강제 지정할 수 있다(테스트·디버깅용).[ProductionVariant 가중치 이동]
A(구버전) B(신버전)
t0 ████████████████████ 100% ░ 0% ← 배포 직전
t1 ██████████████████ 90% ██ 10% ← 카나리 시작
t2 ██████████ 50% ██████████ 50% ← A/B 비교 구간
t3 ░ 0% ████████████████████ 100% ← 전면 전환
↑ 어느 시점에서든 가중치를 되돌리면 롤백배포 전략은 두 개의 레버로 정의된다. (1) 새 모델을 몇 %의 사용자에게 노출하는가, (2) 문제 시 얼마나 빨리 되돌리는가. A/B는 둘을 동시에 시험하고, 카나리는 노출을 점진적으로 키우며, 섀도는 노출을 0으로 고정한다. 전략들은 정확히 이 "노출 정도"에서만 갈린다.
두 모델을 동시에 운영하며 비즈니스 KPI(클릭률, 전환율, 리텐션)를 수집해 통계적으로 우열을 가린다.
ModelA (구버전) 50% ──┐
├─ 같은 엔드포인트, 가중치로 분할
ModelB (신버전) 50% ──┘
→ 양쪽에서 KPI 지표 수집 → 통계 검정| 항목 | 내용 |
|---|---|
| 목표 | ML 지표가 아니라 비즈니스 지표의 통계적 유의성 |
| Variant 지정 | TargetVariant로 특정 테스트를 한 모델에 고정 가능 |
| 기간 | 통계적 검정력을 확보할 만큼 충분히 길게 돌린다 |
| 노출 | 양쪽 모두 실제 사용자에게 응답을 반환한다 |
⚠️ 함정: A/B의 목적은 "안전한 전환"이 아니라 비교다. "어느 쪽이 더 나은지 실사용 지표로 판단하라"가 아니라 단순히 "안전하게 새 버전으로 넘어가라"는 지문이면 A/B가 아니라 카나리·Blue/Green이 답이다.
블루(현재 운영)와 그린(새 버전)을 나란히 띄운다. 그린을 완전히 검증한 뒤 트래픽을 한 번에 넘기고, 문제가 생기면 다시 블루로 되돌린다.
Blue(v1) 100% ──검증──> Green(v2) 100% (전면 전환)
문제 발생
Green(v2) ──롤백──> Blue(v1) 100%UpdateEndpoint는 일반적으로 Blue/Green 방식으로 새 플릿을 띄운 뒤 트래픽을 옮긴다.새 버전에 먼저 작은 비율(예: 5%)만 보내고, 건강하면 25% → 50% → 100%로 확대한다.
v2 5% → (지표 확인) → 25% → 50% → 100%
→ (지표 악화) → 즉시 0%로 롤백| 모드 | 트래픽 이동 방식 | 성격 |
|---|---|---|
All-at-once | 한 번에 전량 전환 | Blue/Green에 해당. 가장 빠르지만 노출 위험 최대 |
Canary | 소량 배치 먼저 → 건강하면 나머지 전량 | 초기 위험을 작게 제한 |
Linear | 일정 주기마다 고정 비율씩 증가 | 완만하고 예측 가능. 전체 전환 시간은 가장 길다 |
요청을 구버전과 신버전 양쪽에 보내되, 사용자에게 반환되는 응답은 구버전 것뿐이다. 신버전 출력은 로그에만 남는다.
요청 ──> 구버전 모델 ──> 이 응답만 사용자에게 반환
└─> 신버전 모델 ──> 로그로만 기록 (사용자는 보지 못함)
→ 응답 내용 / 지연 / 오류율 비교카나리(실제 사용자에게 점진 노출)와 섀도(노출 0, 로그만)의 차이는 누가 결과를 보는가에 있다. A/B는 비교를 위한 의도적 분할, 카나리는 위험의 단계적 확대, 섀도는 위험 자체를 없앤 검증이다. 감수할 수 있는 위험 수준으로 고르면 된다.
| 방식 | 동작 | 속도 |
|---|---|---|
| 수동 롤백 | 이전 EndpointConfig로 UpdateEndpoint 재호출 | 블루가 살아 있으면 즉시 |
| 자동 롤백 | CloudWatch 알람이 임계 초과 → 배포 가드레일이 전환을 중단하고 되돌림 | 알람 감지 즉시 |
| 베이크 타임 | 전환 후 다음 단계로 넘어가기 전 지표를 관찰하는 대기 구간 | 문제 조기 발견용 |
| CloudWatch 지표 | 악화 시 의미 | 배포 중 해석 |
|---|---|---|
Invocation5XX | 서버 오류 급증 | 신버전 컨테이너 자체가 깨졌다 → 즉시 롤백 |
Invocation4XX | 클라이언트 오류 급증 | 입출력 스키마·직렬화가 바뀌었다 → 계약 불일치 의심 |
ModelLatency | 모델 컨테이너 추론 시간 증가 | 신버전이 무거워졌다 → 인스턴스 상향 또는 롤백 |
OverheadLatency | SageMaker 처리 오버헤드 증가 | 페이로드·직렬화 문제 의심 |
CPU/Memory Utilization | 자원 포화 | 신버전이 더 많은 자원을 쓴다 → 용량 재산정 |
| 비즈니스 KPI(클릭·전환) | 하락 | 기술적으로는 정상이나 모델 품질이 나쁘다 → A/B로 판정 |
⚠️ 함정: 5XX·지연 같은 기술 지표만 정상이면 배포 성공이라고 착각하기 쉽다. 모델은 에러 없이 잘 응답하면서도 예측 품질이 나빠질 수 있다. 그래서 비즈니스 KPI 비교(A/B)와 기술 지표 기반 자동 롤백(카나리)은 서로를 대체하지 못한다.
[안전한 배포의 전제]
① 이전 EndpointConfig가 남아 있다 → 되돌릴 대상이 존재
② 롤백 판단 기준(알람)이 사전에 정의됐다 → 사람이 눈으로 볼 필요 없음
③ 전환이 단계적이다(또는 블루가 살아 있다) → 되돌릴 시간이 확보됨
④ 각 단계마다 베이크 타임이 있다 → 지연된 증상도 잡힌다
─────────────────────────────────────────
하나라도 빠지면 "롤백이 빠르다"는 말은 성립하지 않는다실전에서는 하나만 고르는 게 아니라 섀도 → 카나리 → 전면 전환 순으로 이어 붙이는 경우가 많다.
| 상황 | 적합한 전략 | 판단 근거 |
|---|---|---|
| 모델 구조가 크게 바뀌어 출력 스키마가 달라졌을 수 있다 | 섀도 | 사용자 노출 전에 응답 형식·지연을 실트래픽으로 대조 |
| 추천 알고리즘을 교체했고 클릭률로 판정해야 한다 | A/B | 기술 지표로는 우열이 안 나온다. KPI 표본이 필요 |
| 마이너 버전 업이며 회귀 위험만 관리하면 된다 | 카나리 | 소량 노출로 회귀를 조기 검출, 알람으로 자동 복귀 |
| 보안 패치라 즉시 전량 반영해야 한다 | Blue/Green | 점진 노출의 이점보다 전환 속도가 우선 |
| 트래픽이 적어 5%로는 표본이 안 모인다 | Blue/Green 또는 섀도 | 카나리의 소량 구간이 통계적으로 무의미해진다 |
| 전략 | 트래픽 이동 방식 | 사용자 노출 | 롤백 속도 | 리소스 비용 | 언제 쓰면 안 되나 |
|---|---|---|---|---|---|
| A/B 테스트 | 가중치로 고정 분할(예: 50/50) | 양쪽 모두 노출 | 가중치 조정으로 빠름 | 두 Variant 상시 운영 | 단순 버전 교체가 목적일 때, KPI 표본이 부족해 유의성을 못 낼 때 |
| Blue/Green | 한 번에 전량 전환 | 전환 후 100% | 가장 빠름(블루 유지) | 전환 구간 동안 2배 | 점진 노출로 위험을 제한해야 할 때, 여유 용량이 없을 때 |
| 카나리 | 소량 → 단계적 확대 | 초기에는 소수만 | 빠름(0%로 되돌림) | 전환 구간 동안 증가 | 즉시 전면 전환이 필요할 때, 소량 트래픽으로 문제가 드러나지 않는 유형일 때 |
| 섀도 | 요청 복제, 응답 미반환 | 0% | 롤백 개념 없음(끄면 끝) | 추론 2회분 | 실제 사용자 반응(KPI)을 봐야 할 때, 추론 비용 2배를 감당 못 할 때 |
새 모델을 프로덕션에 넣어야 한다
├─ 사용자에게 신버전 응답을 조금이라도 보여도 되나?
│ ├─ 아니오 → 섀도 배포 (요청 복제, 로그만 비교)
│ └─ 예 ↓
├─ 목적이 "둘 중 어느 쪽이 나은지 실지표로 판정"인가?
│ ├─ 예 → A/B 테스트 (가중치 분할 + 충분한 기간 + 통계 검정)
│ └─ 아니오(교체가 목적) ↓
├─ 단계적으로 위험을 제한하고 자동 복귀까지 원하나?
│ ├─ 예 → 카나리 / Linear (배포 가드레일 + CloudWatch 알람 자동 롤백)
│ └─ 아니오 ↓
└─ 즉시 전환하고 문제 시 즉시 되돌리면 되나?
└─ 예 → Blue/Green (All-at-once, 블루를 살려둔다)| 지문 단서 | 고를 답 | 이유 |
|---|---|---|
| "사용자에게 절대 노출하지 않고 실제 트래픽으로 검증" | 섀도 배포 | 응답을 반환하지 않고 로그만 비교한다 |
| "5%부터 시작해 단계적으로 확대, 오류율 급증 시 자동 복귀" | 배포 가드레일 Canary + CloudWatch 알람 자동 롤백 | 점진 확대 + 자동 롤백의 정의 |
| "일정 비율씩 주기적으로 트래픽을 옮긴다" | Linear 트래픽 시프팅 | 고정 비율 증분 방식 |
| "클릭률 등 비즈니스 KPI로 어느 모델이 나은지 판단" | A/B 테스트 | 실사용 지표 비교가 목적 |
| "한 번에 전환하되 문제 시 즉시 되돌려야 한다" | Blue/Green | 블루가 살아 있어 재전환이 즉시 |
| "가중치를 90/10에서 0/100으로 점진 조정" | 다중 ProductionVariant + 가중치 분할 | 모든 전략의 공통 기반 메커니즘 |
| "전환 직후 지표를 관찰할 시간을 둔다" | 베이크 타임 | 다음 단계 진행 전 관찰 구간 |
| "이전 버전 구성으로 되돌린다" | 이전 EndpointConfig로 UpdateEndpoint | 수동 롤백의 표준 절차 |
| "Batch Transform / MME로 안전 배포" | 오답 보기 | 둘 다 배포 전략이 아니라 추론·호스팅 방식이다 |
다음 글에서는 배포 이후의 세계 — 모니터링과 모델 드리프트 탐지를 다룬다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
새 추천 모델을 실제 사용자에게 전혀 노출하지 않은 채, 프로덕션 트래픽에 대해 응답과 지연을 운영 모델과 비교 검증하고 싶다. 가장 적합한 전략은?
문제 2
새 모델 버전을 처음에는 트래픽의 5%에만 보내고, CloudWatch 지표가 건강하면 25%, 50%, 100%로 단계 확대하며, 오류율이 급증하면 자동으로 되돌리고 싶다. 무엇을 사용해야 하는가?
문제 3
두 모델을 동일 엔드포인트에서 각각 50% 트래픽으로 동시에 운영하며, 클릭률 같은 비즈니스 KPI를 충분한 기간 수집해 어느 모델이 통계적으로 더 나은지 판단하려 한다. 이 방식은?
문제 4
블루/그린 배포의 주요 트레이드오프로 옳은 것은?
문제 5
SageMaker에서 ProductionVariant의 트래픽 가중치를 90/10에서 0/100으로 점진 조정하는 행위가 직접적으로 가능하게 하는 배포 전략들의 공통 기반은?