Day 3 - 운영 모니터링: CloudWatch 지표·알람, 엔드포인트 지연·오류, 로깅

요청 한 건이 지나가는 길

지연을 진단하려면 요청이 어디를 거치는지부터 그려야 한다. CloudWatch 지표는 이 경로의 각 구간에 대응한다.

 [클라이언트]
      │  ①  네트워크 · 앞단(API Gateway / Lambda)   ← CloudWatch로는 안 보임 → X-Ray
      ▼
 ┌───────────────────────────────────────────┐
 │  SageMaker 엔드포인트                        │
 │  ┌─────────────┐        ┌───────────────┐ │
 │  │ 요청 수신·라우팅 │  ──▶   │ 모델 컨테이너 추론 │ │
 │  └─────────────┘        └───────────────┘ │
 │      ② OverheadLatency      ③ ModelLatency │
 │  자원 상태: CPUUtilization / MemoryUtilization / GPUUtilization
 │  호출 결과: Invocations / Invocation4XXErrors / Invocation5XXErrors
 └───────────────────────────────────────────┘
      │
      ▼  CloudWatch Metrics ──▶ Alarm ──▶ SNS · Application Auto Scaling · Lambda
         CloudWatch Logs   ──▶ Logs Insights (원인 상세)

• 전체 응답이 느린데 ③이 정상이면 ①이나 ②를 의심한다 — 모델이 아니라 앞단·페이로드 문제다.
• ③만 튀면 모델·인스턴스 문제다 — 인스턴스 타입·배치 크기·인스턴스 수를 본다.

SageMaker 엔드포인트가 내보내는 핵심 지표

SageMaker는 엔드포인트 호출과 인스턴스 상태를 자동으로 CloudWatch에 보낸다. 시험에서 다루는 지표들이다.

전체 응답 지연은 대략 ModelLatency + OverheadLatency다. 지연이 갑자기 늘면 ModelLatency(모델·인스턴스 부하 문제)인지 OverheadLatency(요청 처리·페이로드 문제)인지를 나눠 봐야 원인이 잡힌다.

같은 지표라도 "튀었을 때 무엇을 의심하고 무엇부터 손대는가"가 다르다.

💡 관련 이론: 4XX와 5XX 오류는 책임 소재가 다르다. 4XX(클라이언트 오류)는 호출 측의 잘못된 입력·잘못된 형식·인증 문제로, 페이로드 검증이나 클라이언트 수정으로 해결한다. 5XX(서버 오류)는 모델 컨테이너 충돌·타임아웃·자원 부족 등 서버 측 문제다. 5XX가 급증하면 인스턴스 증설·헬스 체크·컨테이너 디버깅이 필요하다. 시험에서 "오류율 급증의 원인을 좁히려면"이라고 물으면 4XX/5XX 구분이 첫 단계다.

CloudWatch 알람으로 자동 대응

지표를 보기만 해서는 의미가 없다. 임계치를 넘으면 자동으로 알리거나 행동해야 한다. CloudWatch Alarm은 지표가 조건을 만족하면 상태를 ALARM으로 바꾸고 SNS 알림, Auto Scaling, Lambda 트리거 등을 실행한다.

import boto3
cw = boto3.client("cloudwatch")
 
cw.put_metric_alarm(
    AlarmName="HighModelLatency",
    Namespace="AWS/SageMaker",
    MetricName="ModelLatency",
    Dimensions=[{"Name": "EndpointName", "Value": "my-endpoint"},
                {"Name": "VariantName", "Value": "AllTraffic"}],
    Statistic="Average",
    Period=60,                       # 60초 단위 평가
    EvaluationPeriods=3,             # 3번 연속 위반 시 ALARM
    Threshold=200000,                # 200,000 마이크로초 = 200ms
    ComparisonOperator="GreaterThanThreshold",
    AlarmActions=["arn:aws:sns:us-east-1:123456789012:ops-alerts"],
    TreatMissingData="notBreaching", # 데이터 없음(트래픽 0)을 위반으로 보지 않음
)

핵심 파라미터는 Period(평가 간격), EvaluationPeriods(몇 번 연속 위반해야 ALARM), Threshold(임계치), ComparisonOperator다. EvaluationPeriods를 늘리면 일시적 스파이크에 의한 오탐을 줄인다.

지연은 평균보다 꼬리(p90·p99)가 사용자 체감에 가깝다. 평균 80ms인데 p99가 3초라면 100명 중 1명은 사실상 실패로 느낀다. 평균 알람 하나만 걸어두고 "지연은 정상"이라고 판단하는 것이 운영에서 가장 흔한 착시다.

⚠️ 함정: 트래픽 급증으로 지연이 늘 때, "알람만 보내고 끝"이 아니라 Auto Scaling으로 인스턴스를 자동 증설하는 것이 정석이다. SageMaker 엔드포인트의 Auto Scaling은 보통 SageMakerVariantInvocationsPerInstance(인스턴스당 호출 수) 같은 지표를 타겟으로 정책을 건다. 시험에서 "트래픽 변동에 자동 대응"이면 단순 알람이 아니라 Application Auto Scaling 정책을 떠올려야 한다.

aas = boto3.client("application-autoscaling")
 
# ① 스케일 대상 등록 — 배리언트의 인스턴스 수를 1~8 사이에서 조절
aas.register_scalable_target(
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/my-endpoint/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    MinCapacity=1, MaxCapacity=8,
)
 
# ② 타겟 추적 정책 — 인스턴스당 호출 수를 목표치 근처로 유지
aas.put_scaling_policy(
    PolicyName="invocations-target-tracking",
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/my-endpoint/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    PolicyType="TargetTrackingScaling",
    TargetTrackingScalingPolicyConfiguration={
        "TargetValue": 1000.0,
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"},
        "ScaleInCooldown": 300, "ScaleOutCooldown": 60,
    },
)

• ScaleOut 쿨다운은 짧게, ScaleIn 쿨다운은 길게 — 늘릴 땐 빠르게, 줄일 땐 신중하게가 기본 감각이다.
• 인스턴스 추가에는 프로비저닝 시간이 걸린다. 스케일아웃이 즉발이 아니라는 점을 감안해 임계치를 여유 있게 잡는다.

로깅 — CloudWatch Logs

엔드포인트 컨테이너의 stdout/stderr는 자동으로 CloudWatch Logs로 흘러간다. 로그 그룹은 보통 /aws/sagemaker/Endpoints/{endpoint-name} 형태다. 모델 로딩 실패, 예외 스택트레이스, 추론 중 경고 등을 여기서 본다.

logs = boto3.client("logs")
# 특정 로그 그룹에서 최근 에러를 필터링
response = logs.filter_log_events(
    logGroupName="/aws/sagemaker/Endpoints/my-endpoint",
    filterPattern="ERROR",          # ERROR 포함 로그만
    limit=50,
)

대량 로그를 SQL 비슷한 문법으로 조회·집계하려면 CloudWatch Logs Insights를 쓴다. "최근 1시간 5xx 오류 상위 원인" 같은 분석에 유용하다.

fields @timestamp, @message
| filter @message like /ERROR|Exception|Timeout/
| stats count() as hits by bin(5m)
| sort @timestamp desc

X-Ray로 분산 추적

엔드포인트가 다른 서비스(전처리 Lambda, 외부 API, 데이터베이스)와 엮이면, 어느 구간에서 지연이 나는지 한눈에 보기 어렵다. AWS X-Ray는 요청이 거쳐가는 각 구간(segment)의 소요 시간을 추적해 병목을 시각화한다. "전체 응답은 느린데 ModelLatency는 정상이다 → 앞단 Lambda나 네트워크가 병목"을 X-Ray 트레이스로 확인할 수 있다.

운영 모니터링은 "관측성(observability)의 세 기둥"으로 정리된다. 메트릭(무엇이 얼마나 — 지연·오류율·사용률), 로그(무슨 일이 — 이벤트·예외 상세), 트레이스(어디서 — 요청 흐름과 구간별 지연). CloudWatch Metrics·Logs와 X-Ray가 이 세 기둥에 정확히 대응한다. 문제 해결 순서도 보통 "메트릭으로 이상 감지 → 로그로 원인 상세 확인 → 트레이스로 어느 구간인지 특정"으로 흐른다.

비용·사용량도 모니터링 대상

운영 모니터링에는 비용도 포함된다. 항상 켜진 실시간 엔드포인트는 유휴 시간에도 비용이 나가므로, Invocations가 장기간 0에 가깝다면 서버리스나 비동기로 전환을 검토한다. CloudWatch 대시보드로 지연·오류·사용률·호출량을 한 화면에 모아 운영 상태를 한눈에 본다.

운영이 꼬일 때: 증상 → 원인 → 조치

다음 글에서는 모니터링이 드리프트나 성능 저하를 감지했을 때 이어지는 대응 — 자동 재학습 파이프라인과 A/B·섀도 테스트를 본다.

📖 용어

• 관측성의 세 기둥 : 메트릭(수치 시계열)·로그(이벤트 상세)·트레이스(구간별 흐름). CloudWatch Metrics·Logs와 X-Ray가 각각 대응한다.
• ModelLatency : 모델 컨테이너가 추론에 쓴 시간. 여기가 튀면 모델·인스턴스 쪽 문제다.
• OverheadLatency : 요청 수신·라우팅 등 SageMaker 측 부가 시간. 페이로드가 크거나 형식이 무거우면 늘어난다.
• Invocation4XXErrors / 5XXErrors : 클라이언트 잘못으로 실패한 호출 수 / 서버 측 문제로 실패한 호출 수.
• CloudWatch Alarm : 지표가 조건을 만족하면 ALARM 상태로 전환해 SNS·Auto Scaling·Lambda를 발동하는 감시 규칙.
• EvaluationPeriods : 몇 주기 연속 위반해야 알람을 울릴지. 늘리면 순간 스파이크 오탐이 줄어든다.
• TreatMissingData : 지표 데이터가 없는 구간을 위반으로 볼지 정하는 옵션. 트래픽 0 시간대 헛알람을 막는 데 쓴다.
• Application Auto Scaling : 엔드포인트 배리언트의 인스턴스 수를 지표 기준으로 자동 증감하는 서비스. 대표 타겟 지표는 인스턴스당 호출 수(SageMakerVariantInvocationsPerInstance)다.
• CloudWatch Logs Insights : 대량 로그를 쿼리 문법으로 필터·집계·정렬하는 분석 도구.
• AWS X-Ray : 요청이 거치는 각 구간의 소요 시간을 추적해 어디서 느려지는지 시각화하는 분산 추적 서비스.