MLA-C01 문제은행에서 엔드포인트 Auto Scaling과 컨테이너 기반 추론의 확장을 묻는 문제는 약 30문항으로, 단일 주제로는 가장 큰 묶음 중 하나입니다. 시험 안내서도 과제 3.2에서 "수요와 시간에 따른 SageMaker 엔드포인트 Auto Scaling 정책"과 "Auto Scaling 지표 고르기(모델 지연 시간, CPU 사용률, 인스턴스당 호출 수)"를, 과제 3.1에서 "SageMaker 엔드포인트, Kubernetes, ECS, EKS, Lambda 중 배포 대상 고르기"를 명시합니다. 정책 이름을 아는 것만으로는 부족하고, 상황에 맞는 정책과 지표를 조합할 수 있어야 합니다.
이 글은 Auto Scaling의 동작 원리에서 시작해 정책 3종과 조합, 지표 선택, 쿨다운과 용량 한도, 0으로 줄일 수 있는 엔드포인트, 인스턴스 유형 고르기, 그리고 SageMaker 밖의 배포 대상(EKS, ECS, Lambda)까지 정리합니다. 실시간·서버리스·비동기·배치 추론 4종의 기본 차이는 배포 인프라와 스케일링 전략에서 먼저 다뤘습니다.
---
Auto Scaling은 어떻게 동작하나
식당 매니저는 손님이 몰리면 직원을 더 부르고, 한산해지면 일찍 퇴근시킵니다. 다만 너무 자주 부르고 보내면 오히려 혼란스러우니 한 번 조정한 뒤에는 잠시 지켜봅니다. SageMaker 엔드포인트의 Auto Scaling도 같은 구조입니다.
| 구성 요소 | 역할 | |------|------| | CloudWatch 지표 | 엔드포인트의 부하를 숫자로 보여 줌 (예: 인스턴스당 호출 수) | | CloudWatch 경보 | 지표가 기준을 넘었는지 판단 | | Application Auto Scaling | 정책에 따라 인스턴스 수를 계산하고 조정 | | 확장 대상 | 프로덕션 변형(variant)의 인스턴스 수, 최소·최대 용량 범위 안에서 조정 |
설정 순서는 확장 대상 등록(최소·최대 용량 지정) → 정책 정의 → 정책 적용입니다. 엔드포인트 이름과 변형 이름을 함께 지정해야 하고, 필요한 권한은 Application Auto Scaling용 서비스 연결 역할이 처리합니다.
!CloudWatch 지표와 경보가 Application Auto Scaling 정책을 거쳐 엔드포인트 인스턴스 수를 최소·최대 범위 안에서 조정하는 순환 구조
---
정책 3종과 조합
| 정책 | 동작 | 적합한 상황 | |------|------|------| | 대상 추적(권장) | 지표를 목표값 근처로 유지, 경보는 자동 생성 | 대부분의 경우, 설정이 가장 간단 | | 단계 | 경보를 넘은 정도에 따라 추가할 인스턴스 수를 다르게 지정 | 세밀한 제어, 0에서 확장할 때는 필수 | | 예약 | 정한 시각에 최소·최대 용량을 바꿈, 한 번 또는 반복 | 매일 오전 9시 같은 예측 가능한 피크 |
AWS는 대부분의 경우 대상 추적 정책을 권장합니다. 예를 들어 인스턴스당 호출 수의 목표를 70으로 두면, 값이 70을 넘을 때 인스턴스를 더하고 내려가면 줄입니다. 예약 확장은 콘솔에서는 설정할 수 없고 AWS CLI나 Application Auto Scaling API로만 만듭니다.
시험에서 자주 나오는 정답은 정책의 조합입니다. 출근 시간처럼 예측 가능한 피크는 예약 확장으로 미리 인스턴스를 늘려 두고, 예상하지 못한 변동은 대상 추적이 따라가게 합니다. 예약 작업이 실행된 뒤에도 대상 추적 정책은 계속 동작합니다. 같은 대상에 여러 정책이 걸려 충돌하면 더 많은 용량을 만드는 쪽이 선택됩니다.
시험 팁: "매주 월요일 아침 트래픽 급증을 미리 대비하고, 그 밖의 변동에도 자동 대응"은 예약 확장 + 대상 추적입니다. "가장 적은 운영 노력으로 자동 확장"은 대상 추적 하나입니다.
---
어떤 지표로 확장할까
대상 추적에 쓰는 지표는 인스턴스를 늘리면 값이 비례해서 내려가는 지표여야 합니다. 그래야 "인스턴스를 더하면 목표값으로 돌아간다"는 계산이 맞습니다.
| 지표 | 종류 | 언제 쓰나 | |------|------|------| | InvocationsPerInstance | 미리 정의된 지표, 1분 단위 | 일반적인 실시간 엔드포인트의 기본값 | | ConcurrentRequestsPerModel · ConcurrentRequestsPerCopy | 미리 정의된 고해상도 지표, 10초 단위 | 트래픽이 갑자기 몰리는 경우, 응답을 토큰 스트림으로 보내는 LLM | | CPUUtilization · GPUUtilization · MemoryUtilization | 사용자 지정 지표 | 계산량이 많아 CPU나 GPU가 먼저 한계에 닿는 모델 | | ModelLatency | 사용자 지정 지표 | 응답 지연 시간 목표(SLA)를 직접 관리할 때 | | ApproximateBacklogSizePerInstance | 사용자 지정 지표 | 비동기 엔드포인트의 대기열 길이 |
고해상도 지표는 10초마다 값을 내보내 트래픽이 늘 때 훨씬 빨리 확장합니다. 다만 축소 속도는 일반 지표와 같습니다. CPUUtilization은 인스턴스의 vCPU 수만큼 100%를 넘을 수 있어서(4 vCPU면 최대 400%) 목표값을 정할 때 주의해야 합니다.
시험 팁: "갑작스러운 동시 요청 증가에 확장이 늦어 지연이 생긴다"는 고해상도 동시 요청 지표입니다. "모델이 GPU를 다 써서 느려진다"는 GPUUtilization 기반 사용자 지정 지표입니다.
---
쿨다운, 용량 한도, 부하 테스트
쿨다운: 너무 자주 흔들리지 않게
쿨다운은 한 번 조정한 뒤 다음 조정을 늦추는 대기 시간입니다. 지정하지 않으면 확장과 축소 모두 기본값 300초가 적용됩니다.
인스턴스가 너무 자주 늘었다 줄었다 한다: 쿨다운을 늘림 트래픽 증가에 비해 인스턴스가 늦게 붙는다: 확장 쿨다운을 줄임 축소는 천천히, 확장은 빠르게: 축소 쿨다운을 확장 쿨다운보다 길게 (예: 600초와 300초)
최소·최대 용량
일반 실시간 엔드포인트의 최소 용량은 1 이상이어야 하고, 트래픽이 0이 되면 최소값까지 줄어듭니다. 최대값은 SageMaker가 따로 제한하지 않지만 계정의 인스턴스 할당량을 넘을 수 없습니다. 급하게 직접 늘리고 싶다면 최소값을 올리고, 줄이고 싶다면 최대값을 내리면 됩니다.
목표값은 부하 테스트로 정한다
AWS가 권장하는 방법은 인스턴스 하나가 지연 시간 목표 안에서 처리할 수 있는 최대 초당 요청 수(MAX_RPS)를 부하 테스트로 찾은 뒤, 안전 계수를 곱해 목표값을 정하는 것입니다.
목표 InvocationsPerInstance = MAX_RPS × 안전 계수 × 60 안전 계수는 0.5에서 시작해 테스트하며 조정
시험 팁: "확장이 너무 잦아 인스턴스가 계속 늘었다 줄었다 한다"는 쿨다운을 늘리는 것이 정답입니다.
---
0으로 줄일 수 있는 엔드포인트
밤새 요청이 없는 모델에 인스턴스를 계속 띄워 두면 비용이 낭비됩니다. 0까지 줄일 수 있는지는 엔드포인트 유형에 따라 다릅니다.
| 유형 | 0으로 축소 | 방법과 주의할 점 | |------|------|------| | 실시간 엔드포인트 (일반) | 불가 | 최소 용량 1 이상 | | 실시간 + 추론 구성 요소 | 가능 | 최소 인스턴스 수를 0으로, 0에서 다시 늘릴 때는 단계 정책과 경보 필요, 프로비저닝되는 몇 분 동안 요청은 오류 | | 비동기 엔드포인트 | 가능 | 최소 용량 0, 요청은 대기열에서 기다림, HasBacklogWithoutCapacity 단계 정책을 더하면 첫 요청에 바로 확장 | | 서버리스 엔드포인트 | 자동 | 유휴 시 자동으로 0, 첫 요청에 콜드 스타트 발생 |
서버리스 추론의 콜드 스타트는 프로비저닝된 동시성으로 줄입니다. 지정한 동시성만큼은 미리 준비된 상태로 유지되고, 이 값은 Application Auto Scaling으로 대상 지표나 일정에 맞춰 조정할 수 있습니다. 서버리스 엔드포인트는 메모리 1~6GB, 엔드포인트당 최대 동시성 200이며 GPU, VPC 구성, 멀티 모델 엔드포인트, 데이터 캡처, Model Monitor를 지원하지 않습니다.
시험 팁: "요청이 드물고 몇 분을 기다려도 되며 페이로드가 큼"은 비동기 엔드포인트 + 0으로 축소, "간헐적인 짧은 요청인데 첫 응답 지연을 줄이고 싶다"는 서버리스 + 프로비저닝된 동시성입니다.
---
인스턴스 유형 고르기: Inference Recommender
Auto Scaling이 "몇 대"를 정한다면, 그 전에 "어떤 인스턴스"를 쓸지 정해야 합니다. SageMaker Inference Recommender는 모델을 여러 인스턴스 유형에 실제로 배포해 부하 테스트를 하고, 성능과 비용을 비교한 추천을 줍니다.
| 작업 유형 | 하는 일 | 소요 시간 | |------|------|------| | 기본(Inference recommendations) | 추천 후보 인스턴스에서 자동 부하 테스트 | 보통 45분 이내 | | 고급(Endpoint recommendations) | 인스턴스, 트래픽 패턴, 지연 시간 목표를 직접 지정한 맞춤 부하 테스트 | 평균 2시간 안팎 |
실시간과 서버리스 엔드포인트 모두 대상으로 하고, 작업이 도는 동안의 인스턴스 비용만 냅니다. EC2, Lambda, Fargate 기반 ECS처럼 SageMaker 밖에서 돌리는 추론 리소스의 크기 조정은 AWS Compute Optimizer가 최근 사용률 기록을 바탕으로 권장합니다.
하드웨어 선택의 기본 감각도 알아 두세요. 정형 데이터 모델처럼 가벼운 추론은 CPU 인스턴스로 충분하고, 딥러닝 추론은 GPU 인스턴스나 AWS Inferentia 기반 인스턴스(ml.inf2)가 적합합니다. Inferentia는 추론 전용 칩이라 같은 처리량을 더 낮은 비용으로 얻는 선택지입니다.
---
배포 대상 고르기: SageMaker, EKS, ECS, Lambda
모든 모델이 SageMaker 엔드포인트에 올라가야 하는 것은 아닙니다. 회사가 이미 쓰는 플랫폼이 있다면 그 위에 올리는 것이 정답일 때가 많습니다.
| 배포 대상 | 강점 | 확장 방법 | 문제 속 단서 | |------|------|------|------| | SageMaker AI 엔드포인트 | 완전 관리, Model Monitor·배포 가드레일·멀티 모델 같은 ML 전용 기능 | Application Auto Scaling | "운영 부담 최소", "모델 모니터링과 함께" | | Amazon EKS | Kubernetes 표준, 다른 환경과 같은 방식으로 운영 | 파드는 HPA, 노드는 Karpenter나 Cluster Autoscaler | "이미 Kubernetes로 모든 서비스를 운영" | | Amazon ECS (Fargate 포함) | Kubernetes 없이 간단한 컨테이너 운영 | ECS 서비스 Auto Scaling (CPU, 메모리, ALB 요청 수) | "컨테이너로 운영하지만 클러스터 관리는 싫다" | | AWS Lambda | 요청당 과금, 이벤트 기반, 서버 관리 없음 | 요청에 따라 자동, 필요하면 프로비저닝된 동시성 | "작은 모델, 간헐적 호출" |
Lambda는 최대 15분 실행, 메모리 최대 10,240MB, 컨테이너 이미지 최대 10GB이고 GPU를 쓸 수 없어서 작은 모델에만 맞습니다. 외부에 공개하는 추론 API는 API Gateway → Lambda → SageMaker 엔드포인트 호출 구조가 흔합니다. Lambda에서 입력 검증과 전처리를 하고, 모델은 SageMaker가 맡는 방식입니다.
Kubernetes 확장은 두 층으로 생각한다
EKS에서는 파드와 노드를 따로 늘려야 합니다. HPA(Horizontal Pod Autoscaler)가 CPU나 사용자 지정 지표로 파드 수를 늘려도, 파드를 올릴 노드가 없으면 파드는 대기(Pending) 상태에 머뭅니다. 이때 Karpenter가 대기 중인 파드에 맞는 인스턴스 유형(스팟 포함)을 골라 노드를 바로 추가합니다.
시험 팁: "HPA로 파드는 늘었지만 노드가 부족해 Pending 상태"는 Karpenter(또는 Cluster Autoscaler)를 추가하는 것이 정답입니다.
---