안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Under the hood: Architecting Amazon EKS for scale and performance]을 확인해보시기 바랍니다.

Under the hood: Architecting Amazon EKS for scale and performance

AI/ML 워크로드를 위한 Amazon EKS의 혁신적인 확장성 아키텍처를 소개합니다. 

1. Amazon EKS Ultra-Scale 클러스터

1-1. Ultra-Scale의 정의

• 단일 Kubernetes 클러스터에서 최대 100,000개 노드 지원
• 800,000개 Nvidia GPU 또는 1.6백만 AWS Trainium 칩 관리 가능
• 기존 아키텍처의 한계를 뛰어넘는 혁신적인 스케일링

1-2. 왜 Ultra-Scale이 필요한가?

• 대규모 AI 훈련: 수천 개의 GPU를 동기화하여 단일 모델 훈련
• 운영 오버헤드 감소: 여러 클러스터 대신 하나로 통합 관리
• 비용 효율성: 리소스 공유 및 활용률 향상
• 단일 관측성: 하나의 대시보드로 전체 워크로드 모니터링

2. etcd 아키텍처의 혁신적 재설계

2-1. 기존 etcd의 한계 

• Raft 합의 알고리즘이 데이터베이스에 긴밀히 통합되어 병목 발생
• 디스크 I/O가 대규모 읽기/쓰기 시 성능 저하
• 모놀리식 구조로 수평 확장 어려움

2-2. 새로운 아키텍처의 3가지 핵심 변경

• 합의 알고리즘 오프로드
  • Raft 합의를 AWS의 멀티-AZ 트랜잭션 저널로 이동
  • etcd가 자체 합의 관리에서 벗어나 처리량 대폭 향상
  • 3/5/7 노드 제약에서 자유로워져 수평 확장 가능
• 인메모리 데이터베이스 전환
  • BoltDB(디스크 기반)에서 **Redis(메모리 기반)**로 전환
  • 읽기/쓰기 처리량 10배 이상 향상
  • 데이터베이스 크기 최대 20GB 지원 (기존 8GB 대비 2.5배)
• 키 공간 파티셔닝
  • 트래픽이 많은 키(Nodes, Pods, Leases, Events)를 별도 etcd 인스턴스로 분리
  • 각 파티션이 독립적으로 확장 가능
  • 전체 읽기/쓰기 처리량 증가

2-3. 성능 지표

• 읽기 처리량: 초당 7,500 요청
• 쓰기 처리량: 초당 8,000-9,000 요청
• P99 레이턴시:
  • 읽기/쓰기/삭제: 100ms - 1초
  • List 요청: 5-20초 (업스트림 SLO 30초 이하)
• 최대 객체 수: 수천만 개 (800만 파드, 100,000 노드)

3. Provisioned Control Plane

3-1. 개요 

• 워크로드 수요에 따라 사전에 성능 티어를 선택하는 새로운 방식
• 기존 Standard(자동 스케일링) 외에 3개 티어 추가: XL, 2XL, 4XL
• 실시간으로 티어 업그레이드/다운그레이드 가능 (다운타임 없음)

3-2. 각 티어별 제공 용량 

3-3. 사용 시나리오 

• 제품 출시: 대규모 트래픽 예상 시 사전에 4XL로 업그레이드
• 대규모 배포: 수천 개의 파드를 빠르게 스케줄링해야 할 때
• AI 훈련/추론: 지속적으로 높은 API 요청이 필요한 워크로드
• 비용 최적화: 이벤트 후 다시 Standard로 다운그레이드

3-4. 모니터링 

• API Request Concurrency: 현재 처리 중인 동시 요청 수
• Pod Scheduling Rate: 초당 스케줄링되는 파드 수
• Database Size: etcd 사용량 (16GB 한도 모니터링)

4. AI/ML 워크로드 최적화 기능

4-1. 컨테이너 이미지 최적화 

• Soci (Seekable OCI) 병렬 풀링
  • 대용량 이미지(5GB+)를 병렬로 다운로드 및 언패킹
  • HTTP Range 요청으로 필요한 부분만 선택적 로딩
  • 이미지 로딩 시간 3배 단축

4-2. GPU 리소스 관리 

• Dynamic Resource Allocation (DRA): GPU를 여러 파드에 세밀하게 공유
• Capacity Block Reservations: 구매한 GPU 용량 예약 통합
• Accelerated AMI: GPU 드라이버 및 런타임 사전 설치로 설정 시간 단축

4-3. 스토리지 최적화 

• S3 Mountpoint CSI 드라이버 
  • S3를 로컬 파일 시스템처럼 마운트
  • 훈련 데이터 및 모델 아티팩트에 직접 액세스
  • 데이터 로딩 시간 대폭 감소

4-4. 네트워킹 최적화 

• 단일 파드가 모든 네트워크 카드 사용 가능
• 최대 100 Gbps 대역폭 활용
• S3 다운로드 등 대용량 데이터 전송 시 성능 향상

4-5. 노드 관리  

• 자동 헬스 체크 및 복구 
  • EC2 헬스 체크와 Kubernetes 노드 상태 통합 모니터링
  • 비정상 노드 자동 감지 및 교체
  • Graceful shutdown으로 파드 안전하게 재배치

4-6. Karpenter

• 차세대 오토스케일러 (4년 전 출시, CNCF 기부)
• 다양한 인스턴스 타입 선택 (On-Demand, Spot, GPU)
• 워크로드 재배치 및 bin-packing으로 비용 최적화
• 용량 예약(Capacity Reservations) 지원

5. Anthropic 사례 연구

5-1. Anthropic 소개

• Claude AI 개발사 (최근 Opus 4.5 출시)
• 99% 이상의 컴퓨팅이 EKS에서 실행
• 대부분 Trainium 기반 추론 워크로드

5-2. 왜 Ultra-Scale 클러스터를 선택했나? 

• 단일 애플리케이션 = 단일 클러스터 철학
  • 가장 큰 훈련 작업이 단일 StatefulSet에서 실행
  • 여러 클러스터에 분산하면 "Kubernetes 위에 또 다른 Kubernetes"를 만드는 격
  • 단일 관측성 창(Single Pane of Glass)으로 모든 것을 모니터링
•  효율적인 멀티테넌시
  • GPU 인스턴스는 매우 비쌈 → 유휴 시간 최소화가 핵심 KPI
  • 하나의 논리적 리소스 풀로 워크로드 간 효율적 공유
  • 스케일 업/다운 대기 시간 = 손실되는 비용

5-3. 기술적 최적화 

• 대용량 컨테이너 이미지 (35GB)
  • Soci 병렬 풀링으로 P50 시간 5분 단축
  • 노드 장애 시 복구 시간(MTTR) 개선
  • Prefetch로 이미지 미리 준비
• 커스텀 스케줄러 (Cgraph)
  • 워크로드 단위 스케줄링 (파드 단위 아님)
  • Rust 기반, Informer 패턴 사용
  • 전체 클러스터 상태를 보고 한 번에 수천 개 파드 바인딩
  • 토폴로지 인식: 네트워크 최적화를 위해 동일 스파인 내 배치
  • 성능 차이: 2-3배 향상 가능
  • 곧 업스트림 Kubernetes에 기여 예정
• DNS 스케일링
  • CoreDNS 수백 개 레플리카 → 멀티코어 수직 확장으로 전환
  • 레플리카 수 감소 → 캐시 히트율 증가 → 업스트림 부하 감소
  • 서비스 메시 없이 DNS로 서비스 디스커버리
• 스토리지 전략
  • 병렬 파일 시스템 없이 S3 직접 사용 
    • 오브젝트 스토어 + Prefetch 버퍼 + 큐
    • Job Leader가 S3에서 데이터 가져와 워커에 브로드캐스트
    • 5,000 GB/초 처리 (작년 800 GB/초에서 증가)
  • EFS: Jupyter 노트북 등 멀티팟 워크플로우에만 사용

5-4. 향후 계획

• Namespace별 컨트롤러 분리: 30개 컨트롤러를 샤딩하여 장애 도메인 격리
• 멀티-VPC 아키텍처: NAT 한계 극복
• Karpenter로 용량 예약 관리: GPU/Trainium 워크로드도 자동 스케일링
• IPv6 전환: 대규모 플랫 네트워크로 서비스 메시 없이 통신

6. 주요 통계 및 벤치마크

6-1. Ultra-Scale 클러스터 테스트 결과

• 사전 훈련 작업: 100,000 노드 전체에 StatefulSet 배포 성공
• 혼합 워크로드:
  • 각 10,000 노드를 사용하는 여러 파인튜닝 작업 병렬 실행
  • Llama 3.2 모델로 실시간 추론 (Leader-Worker Set 사용)
• 관리 객체 수:
  • 800만 개 파드
  • 100,000 개 노드
  • 600만 개 리스 객체
  • 수천만 개 이벤트

6-2. 컨트롤 플레인 확장 개선

• 확장 시간: 50분 → 10분 (5배 단축)
• 쿨다운 시간: 15분으로 단축
• 가용성: 99.95% SLA 유지

6-3. GPU 사용 증가

• EKS에서 실행되는 GPU 인스턴스: 수백만 개
• 전년 대비 2배 증가
• EKS가 AI/ML 워크로드의 사실상 표준이 됨

7. 아키텍처 원칙

7-1. 정적 안정성 (Static Stability)

• 장애 발생 시에도 기존 클러스터는 계속 실행
• 4가지 즉각 조치:
  • 모든 클러스터 업데이트 일시 중지 (용량 보존)
  • API 트래픽을 정상 AZ로 리디렉션
  • 리더 선출 컨트롤러를 정상 AZ로 재배치
  • etcd 리더십 이전으로 쿼럼 유지

7-2. 결정론적 복원력 (Deterministic Resiliency)

• 장애 중에도 예측 가능한 결과 보장
• 원활한 API 경험
• Kubernetes 컨트롤러 워크플로우 중단 없음
• API 레이턴시 유지

7-3. 철저한 장애 테스트

• 패킷 드롭 시나리오
• 헬스 체크 실패
• 의존 서비스 연결 끊김