Day 5 - Week 6 종합: 추론 배포 복습

Week 6 전체 지도

이번 주는 학습된 모델을 실제로 서빙하는 추론 배포를 다뤘다. Day1~4를 하나의 의사결정 흐름으로 엮어 시험장에서 바로 꺼낼 수 있게 정리한다.

                       [ 학습이 끝난 모델 ]
                                │
                    ① 어떻게 요청이 들어오는가?   ← Day1
        ┌───────────────┬───────┴───────┬───────────────┐
        ▼               ▼               ▼               ▼
     실시간          서버리스         비동기          배치 변환
   (꾸준·저지연)    (간헐·0스케일)  (큰 페이로드)   (대량 일괄)
        │
        │  ② 엔드포인트를 어떻게 운영하는가?      ← Day2
        ├─ Model → EndpointConfig → Endpoint
        ├─ 오토스케일링(InvocationsPerInstance, 최소 1대)
        ├─ 무중단 배포(update_endpoint, blue/green)
        └─ A/B(가중치) · Shadow(응답 폐기)
        │
        │  ③ 비용·복잡도를 어떻게 줄이는가?       ← Day3
        ├─ MME(같은 컨테이너 + 수백~수천 모델)
        ├─ MCE(다른 프레임워크 컨테이너 ≤15)
        ├─ 추론 파이프라인(전처리→추론→후처리)
        └─ Inferentia(딥러닝 추론 단가↓, Neuron 컴파일)
        │
        │  ④ 대량·간헐은 어떻게 튜닝하는가?       ← Day4
        ├─ 배치: InstanceCount · SplitType · BatchStrategy
        └─ 서버리스: MemorySize · MaxConcurrency · Provisioned Concurrency

4가지 추론 옵션 총정리

Day1의 핵심 표를 다시 머릿속에 새기자.

선택 결정 트리
즉시 응답 필요?
 ├─ 아니오 → 전체 데이터셋 일괄? → 예: 배치 변환 / 아니오(개별·큰 페이로드·긴 처리): 비동기
 └─ 예 → 트래픽 꾸준? → 예: 실시간 / 아니오(간헐·콜드스타트 허용): 서버리스
추가 제약: 페이로드>6MB 또는 처리>60초 → 실시간/서버리스 탈락, 비동기/배치로

💡 관련 이론: 4옵션의 근본은 "always-on 비용 vs 지연 vs 처리량" 삼각 트레이드오프다. 실시간은 지연 최소·비용 상시, 서버리스는 비용 0~·콜드 스타트 지연, 비동기는 큰 작업·큐 지연, 배치는 처리량 최대·즉시성 0. 시험은 이 셋 중 무엇을 우선하라고 시나리오에 숨겨둔다. "50ms 이내"는 지연 우선(실시간), "유휴가 많아 비용 아까움"은 비용 우선(서버리스), "100만 건 야간 처리"는 처리량 우선(배치)이다.

실시간 엔드포인트 복습

• 3계층 구조: Model(아티팩트 + 컨테이너) → EndpointConfig(인스턴스 타입·수, ProductionVariant 가중치) → Endpoint(HTTPS 실체). 이 분리가 무중단 Blue/Green 배포, A/B 테스트(가중치 분배), shadow testing(응답 폐기 검증)을 가능케 한다.
• Auto Scaling: SageMakerVariantInvocationsPerInstance 타깃 추적이 표준, 최소 1대 유지(0 불가). 갑작스러운 스파이크는 Auto Scaling이 못 따라가니 예약 스케일링이나 높은 MinCapacity로 대비한다.
• 인스턴스 선택: 전통 ML(XGBoost)=CPU(m5/c5), 딥러닝=GPU(g4dn/g5), 딥러닝 비용 절감=Inferentia(inf1/inf2). 결정이 어려우면 Inference Recommender가 부하 테스트로 최적 구성을 추천한다.

배포부터 스케일링, 교체까지의 흐름을 코드 한 덩어리로 압축하면 다음과 같다.

import boto3
sm = boto3.client("sagemaker")
aas = boto3.client("application-autoscaling")
 
# 1) Config → Endpoint 생성
sm.create_endpoint_config(EndpointConfigName="cfg-v1", ProductionVariants=[{
    "VariantName": "AllTraffic", "ModelName": "churn-model",
    "InstanceType": "ml.m5.xlarge", "InitialInstanceCount": 2}])
sm.create_endpoint(EndpointName="churn-ep", EndpointConfigName="cfg-v1")
 
# 2) 오토스케일링 등록 (최소 1대, 0 불가)
aas.register_scalable_target(
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/churn-ep/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    MinCapacity=2, MaxCapacity=10)
 
# 3) 새 모델로 무중단 교체 — 엔드포인트 이름은 그대로
sm.update_endpoint(EndpointName="churn-ep", EndpointConfigName="cfg-v2")

⚠️ 함정: 오답으로 쓰이기 쉬운 경우가 둘 있다. ① XGBoost에 GPU를 붙이는 것 — 트리 모델은 GPU 이득이 미미하므로 CPU가 정답. ② 실시간 엔드포인트를 0으로 스케일하려는 것 — 실시간은 최소 1대 유지가 강제이므로 0이 필요하면 서버리스/비동기로 가야 한다.

고급 추론 복습 — 무엇을 한 엔드포인트에 묶는가

Day3의 네 패턴을 한 줄씩 구분하면 다음과 같다.

• MME(멀티모델 엔드포인트): 같은 컨테이너 + 수백~수천 모델, TargetModel 지정, S3 동적 로드. "같은 종류 모델이 매우 많아 엔드포인트 비용을 줄이고 싶다."
• MCE(멀티컨테이너 엔드포인트): 서로 다른 프레임워크 컨테이너 최대 15개, TargetContainerHostname 지정. "TensorFlow와 PyTorch를 한 엔드포인트에."
• 추론 파이프라인: 전처리→추론→후처리 선형 컨테이너 체인(2~15개), 한 호출로 처리. "학습/서빙 일관성(skew 방지)."
• Inferentia(inf1/inf2): 딥러닝 추론 비용·지연 절감, Neuron 컴파일 필요. Elastic Inference는 레거시(분수 GPU)로 Inferentia가 대체.

MME vs MCE는 시험에서 헷갈리기 쉬운 짝이다. 결정 키워드는 "프레임워크가 같은가/다른가"와 "모델이 수백 개인가/소수인가"다. 같은 컨테이너 + 다수 = MME, 다른 컨테이너 + 소수 = MCE. 추론 파이프라인은 "선택 호출"이 아니라 "순차 실행"이라는 점에서 둘과 다르다. 입력이 한 컨테이너를 거쳐 다음으로 흘러간다.

호출 파라미터 이름만 봐도 어떤 패턴인지 즉시 구분된다.

배치·서버리스 심화 복습

• 배치 변환 — 대량 일괄의 최저 비용 옵션.
  • 처리량 튜닝: InstanceCount(병렬), SplitType=Line(레코드 분할), BatchStrategy=MultiRecord/MaxPayloadInMB/MaxConcurrentTransforms.
  • 입력은 여러 파일로 샤딩하거나 분할 가능하게 둬야 분산이 먹힌다.
  • 예측을 원본 ID와 매칭하려면 input_filter/output_filter/join_source를 쓴다.
• 서버리스 — MemorySize(1~6GB) + MaxConcurrency만 지정하면 0까지 스케일된다.
  • 콜드 스타트가 문제면 Provisioned Concurrency로 미리 워밍(상시 비용 발생).
  • 비용 이점은 "유휴가 많을 때"만 유효하고, 꾸준히 높은 트래픽이면 실시간이 더 싸다.
  • 인스턴스 타입을 고르지 않으므로 GPU가 필요한 모델은 배포할 수 없다.

비용 최적화의 큰 그림은 "유휴 비용을 없애는 것"이다. 트래픽이 0으로 떨어지는 구간이 있으면 서버리스·비동기·배치로 그 구간 비용을 0에 가깝게 만들 수 있다. 반대로 트래픽이 항상 차 있으면 실시간 + Auto Scaling + (다수 모델이면)MME + (딥러닝이면)Inferentia로 단위 비용을 낮춘다. 추론 비용 시나리오는 거의 다 이 두 갈래로 환원된다.

통합 시나리오 매핑

시험 키워드 → 정답을 직접 매핑해 둔다.

• "구매 순간 수십 ms 판정, 꾸준한 트래픽" → 실시간
• "사내 도구, 가끔 호출, 유휴 많음, 첫 지연 허용" → 서버리스
• "200MB 이미지, 5분 처리, 개별 요청, 결과 나중에" → 비동기
• "매일 밤 1,000만 건 점수화, 즉시성 불필요" → 배치 변환
• "매장 1,500개에 같은 종류 모델, 가끔 호출" → MME
• "TensorFlow + PyTorch를 한 엔드포인트에" → MCE
• "전처리를 추론에 동일하게, skew 방지" → 추론 파이프라인
• "딥러닝 추론인데 GPU 비용 부담" → Inferentia
• "인스턴스 타입을 데이터로 결정" → Inference Recommender
• "무중단으로 신모델 배포" → 새 EndpointConfig + update_endpoint(Blue/Green)

오답 유발 함정 총정리

시험에서 반복적으로 등장하는 잘못된 선택지들이다.

증상 → 원인 → 조치 종합

한 문장 체크리스트

• 4옵션의 페이로드·처리시간 한계(6MB·4MB·1GB / 60초·60초·60분)를 말할 수 있는가
• "실시간은 0으로 못 줄인다"를 근거와 함께 설명할 수 있는가
• 무중단 배포 절차(새 Config → update_endpoint)를 순서대로 말할 수 있는가
• A/B와 shadow의 차이를 "사용자에게 응답이 가는가"로 구분할 수 있는가
• MME·MCE·파이프라인을 호출 파라미터 이름으로 구분할 수 있는가
• 배치가 느릴 때 가장 먼저 볼 것이 "입력이 분할 가능한가"임을 기억하는가

다음 주에는 배포한 모델을 운영하는 단계 — 오케스트레이션과 모니터링으로 넘어간다.

📖 용어

• 요청 패턴 : 트래픽이 얼마나 자주·어떤 크기로 들어오는지의 성격. 추론 옵션 선택의 첫 번째 기준이다.
• always-on 비용 : 요청이 없어도 인스턴스가 켜져 있어 계속 나가는 고정 비용.
• 0 스케일(Scale to zero) : 요청이 없을 때 인스턴스를 아예 0대로 줄여 비용을 없애는 동작.
• Blue/Green 배포 : 새 버전을 따로 띄워 정상 확인 후 트래픽을 옮기고 옛 버전을 내리는 무중단 교체.
• 카나리 배포 : 아주 적은 트래픽만 신버전에 먼저 흘려 보고 문제없으면 넓히는 방식.
• Shadow testing : 실제 요청의 사본을 신모델에 보내되 응답은 버려서 사용자 영향 없이 검증하는 방법.
• MME / MCE : 각각 "같은 컨테이너 + 다수 모델", "다른 컨테이너 + 소수 모델"을 한 엔드포인트에 두는 방식.
• 추론 파이프라인 : 전처리→추론→후처리 컨테이너를 순서대로 이어 한 번의 호출로 처리하는 구조.
• training-serving skew : 학습 때와 추론 때 전처리가 달라 성능이 조용히 떨어지는 문제.
• 예약 스케일링(Scheduled scaling) : 정해진 시각에 용량을 미리 늘려 두는 스케일링. 예측 가능한 급증에 쓴다.