EKS Auto Mode
24년 12월 1일, AWS에서 EKS Auto Mode를 정식 출시를 알렸습니다.
요약하면, Amazon EKS Auto Mode는 클러스터 관리 작업을 AWS로 offload함으로써(넘김으로써) Kubernetes 실행을 간소화하고, 애플리케이션의 성능 및 보안을 강화하며, 컴퓨팅 비용을 최적화하는 데 도움이 된다고 합니다.
추가로 지난 24년 12월 5일, AWS re:Invent의 The future of Kubernetes on AWS (KUB201) 세션에서 EKS Auto Mode 에 대한 내용도 있었습니다.
전반적으로 살펴보았을 때 EKS Auto Mode 는 EKS 관리에서 장점이 있긴하나, 쿠버네티스 및 기타 기술에 대해 어려움이 없다면 굳이 더 많은 비용을 지불하며 사용할 필요는 없어보입니다.
그러나 쿠버네티스 및 관련 기술에 대한 기반이 없는 경우 EKS Auto Mode 는 쿠버네티스에 대한 진입 장벽을 굉장히 낮춰줄 수 있을 것으로 생각합니다.
EKS Auto Mode 등장의 배경
AWS re:Invent 2024 - The future of Kubernetes on AWS (KUB201) 의 내용을 참고했습니다.
AWS EKS를 사용하는데는 크게 두가지 형태의 고객(회사)이 존재합니다.
•
분산 시스템, 머신 러닝등에서 어려운 소프트웨어 기술적 문제를 해결하는 고객 (기술 기업)
•
기술적 문제가 아닌 다른 문제를 해결하는 고객
두 고객의 주요 차이 중 하나는 집중하는 분야가 기술(Kubernetes)인지 아닌지 입니다.
기술 기업의 경우는 쿠버네티스를 포함해 전문적인 엔지니어링 팀을 구성하고 운영하는게 일반적이지만, 나머지는 보통 그렇지 않습니다. 기술 외에도 투자하고 신경 써야할 것들이 너무 많기 때문이죠.
우리는 개발자/엔지니어이기에 기술 기업을 주로 알고 있지만, 현실의 세계 대부분 기업은 보통 소프트웨어 기술 기업이 아닙니다.
그리고 기술 기업이 아니더라도 최근 다양한 기술을 활용하려는 노력이 계속되고 있습니다.
이런 배경에서 EKS Auto Mode는 “EKS를 기술 기업이 아닌 곳에서도 어떻게 쉽게 사용할 수 있도록 만들까?” 에 대한 대답을 하고 있습니다.
즉, 모든 사용자가 EKS를 조금 더 쉽게 활용할 수 있도록 하는 것이 EKS Auto Mode 라고 할 수 있겠습니다.
EKS Auto Mode 아키텍처 비교
지금까지 사용해오던 EKS는 기본적으로 다음과 같은 관리 영역을 가졌습니다.
EKS Auto Mode에서는 아래와 같이 AWS에게 더 많은 부분을 관리하도록 맡깁니다.
개인적으로 가장 먼저 Add-Ons의 대부분을 관리하지 않는다는 점이 눈에 들어옵니다.
보통 EKS를 구성하면 Add On들을 선택하여 설치하는데, 여기에는 필수적인 요소들이 꽤나 많이 포함되어있습니다.
EBS Controller, CoreDNS, kube-proxy, CNI 등 별도로 구성하지 않는다면 필수적인 것들이 있는데, 모두 자동 관리하는 영역으로 넘어간 것을 알 수 있습니다.
그 외에도 Managed NodeGroup 대신 Karpenter를 자동으로 구성해주는 것을 보면 확실히 사용자가 몰라도 잘 쓸 수 있도록 되어있는 것으로 보입니다.
그 외에도 각종 보안 관리와 최적화, 특히 쿠버네티스 버전 관리 및 노드 AMI 버전도 자동 관리된다는 점도 눈에 띕니다.
EKS 포함 쿠버네티스 클러스터를 운영해보셨다면 다들 한 번쯤 겪을 문제인데, 이 버전 관리가 운영에 있어 상당히 많은 어려움을 줍니다.
대략적으로 살펴보니 제가 초기에 쿠버네티스 클러스터를 구성하고 운영하면서 공부했던 것들, 어려웠던 것들을 모두 자동으로 구성하고 관리해준다니, 확실히 기술에 투자할 수 없는 환경에서는 아주 큰 도움이 될 것 같습니다.
그러나, 정말 장점뿐일까요? 잘 아시겠지만, 자동(Automation)과 관리 책임을 위임하는 것에는 분명히 단점도 존재하기 마련입니다.
EKS Auto Mode의 단점
비용
자동으로 EKS를 관리해주는데 공짜로 해줄리가 만무하겠죠? 당연히 추가 비용이 있습니다.
추가 비용은 EC2의 인스턴스 타입과 사용하는 기간에 따라 Auto Mode에 대해 발생합니다. 아래 EKS Pricing 페이지를 참고하면 각 EC2에 대한 추가 비용을 확인할 수 있습니다.
현재 제가 운영하고 있는 EKS에서 가장 많이 쓰는 워커노드 EC2 인스턴스 타입 2가지는 c7g.2xlarge c7g.4xlarge 입니다.
각각 EC2 비용은 시간당 0.3264 달러, 0.6528 달러입니다.
EKS Auto Mode를 사용한다면 위 EC2 타입에 대해서 각각 시간당 0.03917 달러, 0.07834 달러가 추가됩니다.
얼마안되는 것 같아보이지만 한 달 기준으로 c7g.2xlarge 한 대 당 약 28달러, 현재 한화로 약 4만원이 추가되고, c7g.4xlarge 의 경우 한 대 당 약 56달러, 한화로 약 8만원이 추가됩니다.
운영 중인 하나의 EKS 클러스터 하나에 대해서 한 달 전체 추가비용을 계산해보면 다음과 같습니다.
인스턴스 타입 | 시간당 EC2 요금 | 한 달 EC2 요금 | 시간당 EKS Auto Mode 추가 요금 | 한 달 추가 요금 | 전체 한 달 요금 | 증가율 |
c7g.2xlarge | $0.3264 | 약 $235 | $0.03917 | 약 $28 | 약 $263 (39만원) | +12% |
c7g.4xlarge | $0.6528 | 약 $470 | $0.07834 | 약 $56 | 약 $526 (77만원) | +12% |
위 2가지 타입의 EC2를 각각 70대, 10대씩 운영중인 제 클러스터 하나의 경우, 대략 한 달에 360만원 가량이 추가됩니다. 절대 무시할 수 없는 금액이죠.
자동 관리, 양날의 검
첫번째로 Karpenter를 통한 관리에 대한 걱정입니다.
물론 EKS Auto Mode가 구성하는 Karpenter를 경험하지는 않았지만, Auto Mode가 장점으로 내세우는 것 중에 다음과 같은 문구가 있습니다.
optimal compute instances, dynamically scaling resources, continuously optimizing costs
EKS Auto Mode는 기본적으로 Karpenter를 사용하기 때문에 최적화를 위해 Consolidation 등을 활용하는 것으로 추정할 수 있는데, 해당 기능은 서비스 중 노드의 중단과 재시작을 수반합니다.
만약 쿠버네티스의 Pod 라이프사이클을 잘 이해하고 Deployment를 구성하지 않았거나, PDB 등의 설정이 없다면 운영 중인 서비스의 중단을 야기할 수 있습니다.
두번째로 쿠버네티스 버전 업그레이드와 AMI 업그레이드 관리에 대해서 입니다.
Eliminate the burden of versioning, upgrades, and security patches while maintaining Kubernetes conformance.
앞 단락에서 말했듯이, 쿠버네티스 버전 업그레이드 및 기타 버전 관련 작업은 꽤 위험합니다.
쿠버네티스 버전 변경 같은 경우는 API의 변경이 있다면 매우 치명적이며, 게다가 관련된 모든 작업은 노드의 중단과 재시작을 가져오기 때문에 운영 서비스에서 쉽게 수행하기 어려운 일들 입니다.
물론 자동으로 관리한다고해서 냅다 버전을 변경해버릴 것이라고는 생각하지는 않지만, 과연 EKS Auto Mode가 쿠버네티스 클러스터에서 구동 중인 Pod / 애플리케이션까지 고려해줄까요?
글쎄요, 저는 믿을 수 없습니다.
마치며
이번 포스트에서는 2024년 12월에 공개된 EKS Auto Mode에 대해서 살펴봤습니다.
기존 EKS 클러스터를 EKS Auto Mode로 마이그레이션할 이유는 딱히 없어보이고,
현재 Kubernetes를 전문적으로 다루는 조직이 없거나, 소규모로 서비스를 시작해보려는 상황에서 EKS Auto Mode는 꽤 좋은 선택지가 될 수도 있을 것 같습니다.
다만 자동 관리라는 것이 100% 자동은 아니며, 마냥 믿을 수도 없어보입니다.
어쨌든 쿠버네티스에서 서비스한다면 결국엔 관련 지식이 언젠가는 필요합니다.
쿠버네티스 위에서 서비스를 지속할 수록, 그리고 서비스의 규모가 커질 수록 쿠버네티스에 대한 지식 없이는 힘든 것이 아직까지는 현실이니까요.
