AWS Graviton 으로 EKS 비용 최적화 하기

AWS Graviton ARM64 프로세서를 EKS 노드에 도입해 x86 대비 최대 40% 가격 대비 성능 향상과 60% 전력 절감을 달성하는 마이그레이션 전략을 다룬다. 멀티 아키텍처 이미지 빌드 방식 3가지(에뮬레이션, 네이티브, 크로스 컴파일)와 카나리 배포 기반의 점진적 전환 방법을 설명한다.

핵심 포인트

Graviton은 1 vCPU = 1 물리 코어(x86의 하이퍼스레딩과 달리 공유 없음), Graviton5는 DDR5-8800 메모리로 높은 대역폭 확보.
EKS 비용의 대부분은 컴퓨팅으로, 컨트롤 플레인은 월 73달러 고정이므로 데이터 플레인 최적화가 핵심.
멀티 아키텍처 이미지는 에뮬레이션(QEMU+buildx), 네이티브(ARM 인프라 직접 빌드), 크로스 컴파일(Go/Rust 효율적) 3가지 전략 중 선택.
신규 Graviton 노드그룹을 기존 x86과 병렬 운영하며 Service 레플리카 비율을 단계적으로 이동하는 카나리 패턴을 권장.
국내 실증: 하이퍼커넥트 300개 서비스 마이그레이션, 카카오페이손해보험 약 20% 절감, 삼성전자 약 15% 절감 + 응답 시간 개선.

상세 정리

Graviton 아키텍처 특성: ARM64 기반, 클라우드 워크로드 전용 설계. x86 하이퍼스레딩(2 vCPU = 1 물리 코어)과 달리 1 vCPU가 1 물리 코어에 직접 대응해 컨텍스트 스위칭 오버헤드 없음.
성능 수치: 동급 x86 대비 최대 40% 가격 대비 성능 향상, 최대 60% 전력 절감(Graviton5 기준).
EKS 비용 구조: 컨트롤 플레인 월 73달러 고정, 컴퓨팅(EC2)이 대부분 — 데이터 플레인 인스턴스 타입이 비용의 핵심 레버.
멀티 아키텍처 이미지 전략 1 — 에뮬레이션: QEMU와 Docker buildx 조합. 추가 ARM 인프라 불필요하지만 빌드 속도 저하가 단점.
멀티 아키텍처 이미지 전략 2 — 네이티브 빌드: Graviton EC2에서 직접 빌드. 가장 안정적이나 ARM 빌드 인프라 필요.
멀티 아키텍처 이미지 전략 3 — 크로스 컴파일: Go/Rust 등 언어 수준에서 타겟 아키텍처 지정. 빌드 환경과 실행 환경이 일치하지 않아도 됨.
점진적 전환 패턴: 기존 x86 노드그룹 유지 + 신규 Graviton 노드그룹 병렬 추가 → 동일 Service 아래 레플리카 비율을 단계적으로 ARM 쪽으로 이동(카나리 방식). 이 방식으로 롤백 리스크 최소화.
국내 사례 — 하이퍼커넥트: 300개 마이크로서비스 Graviton3 마이그레이션 완료.
국내 사례 — 카카오페이손해보험: 약 20% 비용 절감.
국내 사례 — 삼성전자: 약 15% 비용 절감 + 응답 시간 개선.