SageMaker HyperPod Inference Operator, 1클릭 설치부터 Terraform까지 완벽 정리

들어가며: Inference Operator 설치, 왜 이렇게 어려웠나?

Amazon SageMaker HyperPod는 대규모 AI 모델의 학습과 추론을 위한 엔드투엔드 플랫폼입니다. 하지만 기존에는 Helm 차트, IAM 역할 구성, 의존성 관리 등 복잡한 수동 작업이 필요해 첫 모델을 서빙하기까지 몇 시간이 걸리기도 했죠.

이제 SageMaker HyperPod Inference Operator가 EKS add-on으로 제공되면서 상황이 완전히 달라졌습니다. SageMaker 콘솔에서 한 번의 클릭으로 설치하고, 업그레이드도 자동으로 관리할 수 있습니다. 이 글에서는 실제 운영 환경에서 바로 적용할 수 있는 세 가지 설치 방법과 핵심 기능을 실습해보겠습니다.

근거자료: AWS Architecture Blog 원문

설치 방법 1: SageMaker UI (추천) — 1클릭 설치

가장 간단한 방법입니다. 신규 클러스터 생성 시 Quick Setup을 선택하면 Inference Operator가 자동으로 설치되며, 기존 클러스터도 Inference 탭에서 Quick Install 버튼 한 번으로 끝납니다.

Quick Install vs Custom Install

| 옵션 | 설명 | 적합한 상황 ||------|------|------------|| Quick Install | IAM 역할, S3 버킷, VPC 엔드포인트 등 모든 리소스를 최적 기본값으로 자동 생성 | 처음 시작하는 팀, 빠른 PoC || Custom Install | 기존 IAM 역할이나 S3 버킷을 재사용하고 세부 설정을 커스터마이즈 | 엄격한 보안/규정 준수가 필요한 조직

설치 단계

1. SageMaker 콘솔 → HyperPod Clusters → Cluster Management 진입
2. 대상 클러스터 선택 → Inference 탭 → Quick Install 또는 Custom Install 선택
3. 설치 완료 후 다음 명령어로 확인

# 파드 상태 확인
kubectl get pods -n hyperpod-inference-system

# EKS add-on 상태 확인
aws eks describe-addon --cluster-name CLUSTER-NAME --addon-name amazon-sagemaker-hyperpod-inference --region REGION

설치 방법 2: EKS CLI — IaC 파이프라인 연동

코드 기반 인프라를 선호하는 팀을 위한 방법입니다. 단, IAM 역할, S3 버킷, VPC 엔드포인트 등 모든 사전 조건을 수동으로 생성해야 합니다.

aws eks create-addon \
  --cluster-name my-hyperpod-cluster \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --addon-version v1.0.0-eksbuild.1 \
  --configuration-values '{
    "executionRoleArn": "arn:aws:iam::ACCOUNT-ID:role/SageMakerHyperPodInference-inference-role",
    "tlsCertificateS3Bucket": "hyperpod-tls-certificate-bucket",
    "hyperpodClusterArn": "arn:aws:sagemaker:REGION:ACCOUNT-ID:cluster/CLUSTER-ID",
    "alb": {
      "serviceAccount": {
        "create": true,
        "roleArn": "arn:aws:iam::ACCOUNT-ID:role/alb-controller-role"
      }
    },
    "keda": {
      "auth": {
        "aws": {
          "irsa": {
            "roleArn": "arn:aws:iam::ACCOUNT-ID:role/keda-operator-role"
          }
        }
      }
    }
  }' \
  --region us-west-2

설치 방법 3: Terraform — 완전 자동화

awesome-distributed-training GitHub 리포지토리의 Terraform 모듈을 사용하면 HyperPod 클러스터와 Inference Operator를 한 번에 프로비저닝할 수 있습니다.

# custom.tfvars 예시
kubernetes_version = "1.33"
eks_cluster_name = "tf-eks-cluster"
hyperpod_cluster_name = "tf-hp-cluster"
resource_name_prefix = "tf-eks-test"
aws_region = "us-east-1"

instance_groups = [
  {
    name = "accelerated-instance-group-1"
    instance_type = "ml.g5.8xlarge"
    instance_count = 2
    availability_zone_id = "use1-az2"
    ebs_volume_size_in_gb = 100
    threads_per_core = 1
    enable_stress_check = false
    enable_connectivity_check = false
    lifecycle_script = "on_create.sh"
  }
]

# Inference Operator 활성화
create_hyperpod_inference_operator_module = true

참고: Terraform 모듈은 Inference Operator 외에도 task governance, training operator, observability add-on도 함께 지원합니다.

핵심 기능 3가지: 실무에서 바로 활용하기

1. 멀티 인스턴스 타입 배포 (Multi-Instance Type Deployment)

우선순위 기반으로 인스턴스 타입을 지정하면, 선호 타입에 용량이 부족할 때 자동으로 다음 타입으로 폴백(fallback)됩니다. Kubernetes node affinity를 활용합니다.

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: lmcache-test-1
  namespace: default
spec:
  replicas: 13
  modelName: Llama-3.1-8B-Instruct
  instanceTypes: ["ml.p4d.24xlarge","ml.g5.24xlarge","ml.g5.8xlarge"]

2. Node Affinity를 통한 세밀한 스케줄링 제어

스팟 인스턴스 제외, 특정 가용 영역 선호, 커스텀 레이블 기반 타겟팅이 필요할 때 nodeAffinity를 직접 설정할 수 있습니다.

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: lmcache-test-1
  namespace: default
spec:
  replicas: 15
  modelName: Llama-3.1-8B-Instruct
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: node.kubernetes.io/instanceType
          operator: In
          values: ["ml.g5.4xlarge"]
  worker:
    resources:
      limits:
        nvidia.com/gpu: "1"
      requests:
        cpu: "6"
        memory: 30Gi
        nvidia.com/gpu: "1"

3. 기존 Helm 사용자를 위한 마이그레이션 스크립트

AWS가 공개한 helm_to_addon.sh 스크립트를 사용하면 기존 Helm 배포를 EKS add-on으로 자동 전환할 수 있습니다. 실패 시 롤백도 지원합니다.

# 대화형 마이그레이션
./helm_to_addon.sh --cluster-name my-cluster --region us-east-1

# 자동 승인 모드
./helm_to_addon.sh --cluster-name my-cluster --region us-east-1 --auto-approve

# 종속성 마이그레이션 건너뛰기
./helm_to_addon.sh --cluster-name my-cluster --region us-east-1 --skip-dependencies-migration

⚠️ 주의사항: 마이그레이션 스크립트는 /tmp/hyperpod-migration-backup-*에 백업 파일을 생성하므로, 롤백이 필요할 경우 이 디렉터리를 확인하세요.

실무 적용 팁과 한계점

한국 개발 생태계에서의 적용 맥락

국내에서는 NCP(Naver Cloud Platform)나 KT Cloud 등 AWS 외 클라우드를 사용하는 기업도 많습니다. 하지만 SageMaker HyperPod는 AWS EKS 전용이므로, 멀티 클라우드 전략을 고려 중이라면 Kubernetes 네이티브 추론 솔루션(Kserve, Seldon 등)과 함께 평가해보는 것이 좋습니다.

또한, 국내 SI/금융권에서는 보안 규정으로 인해 VPC 엔드포인트 구성이 까다로울 수 있습니다. Quick Install이 자동 생성하는 리소스(IAM 역할, S3 버킷 등)가 내부 보안 정책에 부합하는지 사전에 확인하세요.

이 기술의 한계

• EKS 클러스터 필수: HyperPod는 EKS 오케스트레이션을 전제로 하므로, EKS가 없는 환경에서는 사용할 수 없습니다.
• 사전 조건 리소스: EKS CLI나 Terraform 방식에서는 IAM 역할, S3 버킷, VPC 엔드포인트 등을 수동으로 생성해야 합니다. 실수로 누락되면 add-on 설치가 실패합니다.
• 지원 리전: 현재 일부 리전에서만 정식 지원됩니다. AWS 공식 문서에서 지원 리전을 반드시 확인하세요.

다음 단계 학습 방향

1. 실전 배포: 위 예제 코드를 사용해 실제 Llama 또는 DeepSeek 모델을 배포해보세요.
2. 관측 가능성: HyperPod Observability와 Amazon Managed Grafana를 연동하여 지연 시간, GPU 사용률 등을 모니터링하는 방법을 익혀보세요.
3. 비용 최적화: 멀티 인스턴스 타입 배포와 스팟 인스턴스 활용 전략을 조합하여 추론 비용을 절감하는 방법을 연구해보세요.

함께 보면 좋은 글

• 암 진단을 혁신하는 AI, Artera의 AWS 기반 확장 가능한 아키텍처 설계
• NVIDIA Blackwell Ultra, AI 추론의 숨은 병목 소프트맥스를 해결하다