Day 2 - 실시간 엔드포인트: 구성, 오토스케일링, 인스턴스 선택

3계층 구조: Model, EndpointConfig, Endpoint

사용자가 결과를 기다리는 온라인 서비스는 거의 다 실시간 엔드포인트로 배포된다. 이 엔드포인트는 다음 3개 리소스로 만들어진다.

• Model: S3의 모델 아티팩트(model.tar.gz)와 추론 코드가 담긴 컨테이너 이미지를 묶은 정의.
• EndpointConfig: 어떤 Model을, 어떤 인스턴스 타입으로, 몇 대(initial instance count) 띄울지, 트래픽 분배 가중치는 어떻게 둘지 정의.
• Endpoint: EndpointConfig를 실제로 프로비저닝해 HTTPS로 호출 가능하게 만든 실체.

S3 model.tar.gz ─┐
                 ├─▶ [ Model ] ─▶ [ EndpointConfig ] ─▶ [ Endpoint ]
컨테이너 이미지  ─┘   아티팩트+코드   인스턴스 타입/수      HTTPS 주소
                                    ProductionVariant     (호출자가 보는 것)
 
핵심: 셋은 별개 리소스다. Endpoint 주소는 그대로 둔 채
      EndpointConfig만 갈아 끼우면 호출자는 아무것도 바꾸지 않아도 된다.

import boto3
sm = boto3.client("sagemaker")
 
# 1) Model: 아티팩트 + 컨테이너
sm.create_model(
    ModelName="churn-model",
    PrimaryContainer={"Image": image_uri, "ModelDataUrl": "s3://bkt/model.tar.gz"},
    ExecutionRoleArn=role,
)
# 2) EndpointConfig: 인스턴스 타입/수
sm.create_endpoint_config(
    EndpointConfigName="churn-config",
    ProductionVariants=[{
        "VariantName": "AllTraffic",
        "ModelName": "churn-model",
        "InstanceType": "ml.m5.xlarge",
        "InitialInstanceCount": 2,
    }],
)
# 3) Endpoint: 실제 배포
sm.create_endpoint(EndpointName="churn-endpoint", EndpointConfigName="churn-config")

이 3계층 분리의 진짜 가치는 무중단 업데이트에 있다. 새 모델을 배포할 때 새 EndpointConfig를 만들고 update_endpoint를 호출하면, SageMaker가 새 인스턴스를 먼저 띄워 헬스 체크를 통과시킨 뒤 트래픽을 옮기고 옛 인스턴스를 내린다(Blue/Green). 엔드포인트는 그대로 살아 있어 호출자는 다운타임을 겪지 않는다. ProductionVariant의 가중치를 조절하면 같은 엔드포인트에서 두 모델로 트래픽을 나누는 A/B 테스트나 카나리 배포도 가능하다.

무중단 배포 — Blue/Green 전환 흐름

새 모델을 올릴 때 엔드포인트를 지웠다 다시 만들면 주소가 끊긴다. 올바른 절차는 새 EndpointConfig 생성 → update_endpoint다.

[업데이트 전]  Endpoint(churn-endpoint) ──▶ Config v1 ──▶ 인스턴스 2대 (구모델)
 
update_endpoint(EndpointConfigName="config-v2")
        │
        ├─ 1) 새 인스턴스(green) 프로비저닝 + 모델 로드
        ├─ 2) 헬스 체크 통과 대기
        ├─ 3) 트래픽을 green으로 전환(전량/카나리/선형)
        ├─ 4) 알람 감시 구간(baking) — 실패 시 자동 롤백
        └─ 5) 구 인스턴스(blue) 종료
 
[업데이트 후]  Endpoint(churn-endpoint) ──▶ Config v2 ──▶ 인스턴스 2대 (신모델)
                 ↑ 주소는 그대로. 호출자는 아무것도 안 바꾼다

# 새 설정으로 교체 — 엔드포인트 이름은 그대로 둔다
sm.update_endpoint(
    EndpointName="churn-endpoint",
    EndpointConfigName="churn-config-v2",
)
# 전환 상태 확인: Updating → InService
status = sm.describe_endpoint(EndpointName="churn-endpoint")["EndpointStatus"]

트래픽 전환 방식(deployment guardrails)은 성격이 다르다.

⚠️ 함정: "다운타임 없이 새 모델 배포"의 정답은 항상 새 EndpointConfig + update_endpoint다. ① 엔드포인트 삭제 후 재생성은 주소가 끊겨 다운타임이 생기고, ② Model 리소스만 새로 만들어도 기존 엔드포인트에 자동 반영되지 않으며, ③ 관리형 인스턴스에 직접 접속해 파일을 바꾸는 것은 애초에 불가능한 안티패턴이다. 이 세 개가 오답 보기로 반복 출제된다.

ProductionVariant와 A/B 테스트

EndpointConfig 안에는 여러 ProductionVariant를 둘 수 있다.

• 각 variant에 InitialVariantWeight를 주면 트래픽이 가중치 비율로 분배된다.
• 신모델 10% / 구모델 90%로 시작해 비중을 올리는 카나리 배포가 가능하다.
• variant마다 인스턴스 타입·개수를 다르게 둘 수 있다(신모델만 작게 띄우기).

ProductionVariants=[
    {"VariantName": "ModelA", "ModelName": "model-a",
     "InstanceType": "ml.m5.xlarge", "InitialInstanceCount": 2,
     "InitialVariantWeight": 9},   # 90% 트래픽
    {"VariantName": "ModelB", "ModelName": "model-b",
     "InstanceType": "ml.m5.xlarge", "InitialInstanceCount": 1,
     "InitialVariantWeight": 1},   # 10% 트래픽
]

A/B 테스트와 shadow testing은 사용자가 신모델 응답을 받느냐로 갈린다.

[A/B 테스트]  요청 ──┬─ 90% ─▶ ModelA ─▶ 응답을 사용자에게 반환
                     └─ 10% ─▶ ModelB ─▶ 응답을 사용자에게 반환  ← 일부 사용자가 영향받음
 
[Shadow]      요청 ────────▶ ModelA ─▶ 응답을 사용자에게 반환
                  └(사본)──▶ ModelB ─▶ 응답 폐기, 지표만 기록     ← 사용자 영향 0

SageMaker는 InvokeEndpoint 호출 시 TargetVariant 파라미터로 특정 variant를 강제 지정할 수도 있다. 이는 가중치와 무관하게 특정 모델만 테스트하고 싶을 때 쓴다. 또 Shadow testing(섀도 변형) 기능을 쓰면 프로덕션 트래픽 사본을 신모델에 보내되 응답은 버려서, 실사용자에게 영향 없이 신모델 성능을 검증할 수 있다. A/B(가중치 분배)와 shadow(응답 폐기)의 차이로 구분한다.

Auto Scaling — 트래픽에 맞춰 인스턴스 수 조절

실시간 엔드포인트는 Application Auto Scaling을 붙여 트래픽에 따라 인스턴스 수를 자동 조절한다. 가장 흔한 정책은 타깃 추적(target tracking)으로, 특정 지표를 목표값에 맞추도록 인스턴스를 늘리고 줄인다.

대표 지표는 SageMakerVariantInvocationsPerInstance(인스턴스당 초당 호출 수)다. "인스턴스 하나가 초당 1,000건을 처리하길 원한다"고 목표를 정하면, 트래픽이 늘어 이 값을 넘으면 스케일 아웃하고 줄면 스케일 인한다.

aas = boto3.client("application-autoscaling")
resource_id = "endpoint/churn-endpoint/variant/AllTraffic"
 
aas.register_scalable_target(
    ServiceNamespace="sagemaker",
    ResourceId=resource_id,
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    MinCapacity=2, MaxCapacity=10,
)
aas.put_scaling_policy(
    PolicyName="invocations-tracking",
    ServiceNamespace="sagemaker", ResourceId=resource_id,
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    PolicyType="TargetTrackingScaling",
    TargetTrackingScalingPolicyConfiguration={
        "TargetValue": 1000.0,
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
        },
        "ScaleInCooldown": 300, "ScaleOutCooldown": 60,
    },
)

• MinCapacity를 1 이상으로 둬야 하므로 실시간 엔드포인트는 0으로 줄지 않는다(0이 필요하면 서버리스/비동기).
• 쿨다운(cooldown)은 스케일 동작 후 다음 동작까지의 대기 시간이다.
  • ScaleOutCooldown은 짧게 → 부하 증가에 빠르게 반응
  • ScaleInCooldown은 길게 → 트래픽이 다시 튈 때 성급히 줄여 놓고 후회하지 않도록

스케일링 정책 유형은 목적에 따라 갈린다.

⚠️ 함정: Auto Scaling은 만능이 아니다. 새 인스턴스를 띄우고 모델을 로드해 헬스 체크를 통과하기까지 몇 분이 걸리므로, 갑작스러운 트래픽 스파이크에는 즉각 대응하지 못한다. 블랙프라이데이처럼 예측 가능한 급증에는 예약 스케일링(scheduled scaling)으로 미리 용량을 늘려두거나 충분한 MinCapacity를 확보해야 한다. "Auto Scaling을 켰는데도 스파이크 때 지연이 튀었다"는 시나리오의 답은 보통 예약 스케일링 또는 더 높은 최소 용량이다.

엔드포인트 모니터링 지표

무엇을 보고 스케일·튜닝을 판단하는지 알아야 한다. 엔드포인트 지표는 CloudWatch로 나간다.

지연 문제를 볼 때는 ModelLatency와 OverheadLatency를 분리해서 봐야 한다. ModelLatency가 높으면 모델 자체가 무겁거나 인스턴스가 부족한 것이라 인스턴스 상향·스케일 아웃·모델 최적화가 답이다. 반면 OverheadLatency가 높으면 큰 페이로드 직렬화나 네트워크 구간이 원인일 가능성이 크다. 두 값을 뭉뚱그려 "느리다"로 보면 엉뚱한 조치를 하게 된다.

인스턴스 선택 — CPU vs GPU vs 가속기

인스턴스 패밀리 선택은 모델 종류와 지연 요구에 따라 갈린다.

추론 인스턴스 선택은 "지연 목표 × 처리량 × 비용"의 균형이다. 전통 ML(XGBoost)은 CPU로 충분하고 GPU를 붙여도 효과가 미미하다. 반면 트랜스포머·CNN 같은 딥러닝은 GPU나 Inferentia에서 지연이 극적으로 줄어든다. 시험에서 "딥러닝 모델인데 GPU 비용이 부담"이라는 조건이 나오면 Inferentia(inf1/inf2)가 정답 신호다. 반대로 "XGBoost인데 GPU를 써서 비용을 낮추자"는 잘못된 선택지로 쓰이기 쉽다.

Inference Recommender — 어떤 인스턴스가 최적인가

인스턴스 타입과 개수를 직접 고르기 어렵다면 SageMaker Inference Recommender가 부하 테스트를 자동 수행해 비용·지연·처리량 기준으로 최적 구성을 추천한다. 여러 인스턴스 타입에 모델을 배포해 트래픽을 흘려보고 결과를 비교해준다.

sm.create_inference_recommendations_job(
    JobName="rec-job-1",
    JobType="Default",
    RoleArn=role,
    InputConfig={"ModelPackageVersionArn": model_package_arn},
)

Inference Recommender는 두 모드가 있다. Default(기본) 잡은 여러 인스턴스 타입에 빠르게 배포해 광범위하게 비교하고, Advanced(커스텀) 잡은 원하는 트래픽 패턴(초당 요청 수, 지연 SLA)을 직접 정의해 정밀 부하 테스트를 한다. "인스턴스 타입을 어떻게 정할지 모르겠다, 데이터로 결정하고 싶다"는 시나리오의 답이 Inference Recommender다.

증상 → 원인 → 조치

다음 글에서는 한 엔드포인트에 여러 모델을 얹어 비용을 줄이는 멀티모델/멀티컨테이너와 추론 파이프라인, 그리고 Inferentia/Elastic Inference를 깊이 본다.

📖 용어

• 모델 아티팩트 : 학습이 끝난 모델의 가중치·구조를 담아 S3에 올려 둔 압축 파일(model.tar.gz).
• EndpointConfig : 어떤 모델을 어떤 인스턴스로 몇 대 띄울지 적어 둔 설계도. 엔드포인트와 별개 리소스다.
• ProductionVariant : 한 엔드포인트 안에서 트래픽을 나눠 받는 모델 묶음 하나. 가중치를 줄 수 있다.
• Blue/Green 배포 : 새 버전을 따로 띄워 정상 확인 후 트래픽을 옮기고 옛 버전을 내리는 무중단 교체 방식.
• 카나리(Canary) 배포 : 아주 적은 비율의 트래픽만 신버전에 먼저 보내 보고 이상 없으면 넓히는 방식.
• Shadow testing : 실제 요청의 사본을 신모델에 보내되 응답은 버려서, 사용자 영향 없이 성능만 재는 검증.
• 타깃 추적(Target tracking) : 지표를 목표값에 맞추도록 인스턴스 수를 자동으로 늘리고 줄이는 정책.
• 쿨다운(Cooldown) : 한 번 스케일한 뒤 다음 스케일까지 기다리는 시간. 너무 짧으면 증감이 요동친다.
• ModelLatency : 모델 컨테이너가 요청을 처리해 응답하기까지 걸린 시간.
• Inference Recommender : 여러 인스턴스 타입에 실제로 부하를 걸어 최적 구성을 데이터로 골라 주는 기능.