EKS와 ASG, 같은 듯 다른 이야기무엇이 다를까: 관점의 차이1. 격리의 가치: Gunicorn vs 파드(Pod)2. 2단계 확장 전략: 파드(Pod)와 노드(Node)비용 차이: 효율성이 결국 비용결론: 무엇을 관리하고 싶은가?
EKS와 ASG, 같은 듯 다른 이야기
AWS에서 서비스를 만들다 보면 ‘자동 확장’이나 ‘안정성’ 같은 키워드를 자주 마주하게 됩니다. 그러다 보면 자연스럽게 EKS와 ASG라는 두 가지 이름을 듣게 되죠. 저도 처음엔 이 둘이 결국 "서버 수를 자동으로 조절해서 서비스를 안정적으로 돌리는" 같은 목적을 가진 비슷한 기술이라고 생각했습니다. 하지만 계속 파고들수록, 둘이 세상을 바라보는 관점과 역할이 완전히 다르다는 걸 깨닫게 됐습니다.
무엇이 다를까: 관점의 차이
결론부터 말하면, 둘의 차이는 단순히 ‘어떻게 확장하는지’에 대한 정책 차이를 넘어섭니다. ASG가 서버, 즉 ‘인프라’의 관점에서 움직인다면, EKS는 그 위에서 돌아가는 ‘애플리케이션’의 관점에서 움직입니다. 어떻게 보면 EKS가 ASG를 자기 목적을 이루기 위한 도구로 활용하는, 더 큰 그림을 그리는 셈이죠.
1. 격리의 가치: Gunicorn vs 파드(Pod)
이 차이를 제대로 이해하려면, 먼저 ‘하나의 서버에서 여러 작업을 동시에 돌리는’ 두 가지 방식을 비교해볼 필요가 있습니다.
- ASG와 Gunicorn: 이 방식은 EC2 서버 하나에 Gunicorn 같은 툴로 여러 프로세스를 띄우는 겁니다. 마치 ‘개방된 사무실’ 같죠. 모든 프로세스가 같은 OS, 같은 라이브러리, 같은 자원을 공유합니다. 간단하고 빠르지만, 한 프로세스에 메모리 문제가 생기면 사무실 전체(서버)가 마비될 수 있습니다.
- EKS의 파드(Pod): EKS는 노드(서버) 하나에 여러 개의 파드를 띄웁니다. 이건 **‘독립된 사무 공간이 있는 건물’**과 비슷합니다. 각 파드는 컨테이너 기술로 자신만의 격리된 환경과 자원을 할당받습니다. 그래서 한 파드에 문제가 생겨도 그 파드만 딱 종료될 뿐, 다른 파드나 서버 전체에는 아무런 영향을 주지 않죠.
OOMKilled같은 이벤트가 바로 이런 격리를 통해 전체 시스템을 지키는 EKS의 스마트한 기능입니다.
2. 2단계 확장 전략: 파드(Pod)와 노드(Node)
ASG는 오직 서버, 즉 ‘노드’의 개수만 생각합니다. 하지만 EKS는 ‘파드’와 ‘노드’라는 2단계 확장 전략을 사용하죠.
- 1단계 (파드 확장): 트래픽이 늘면, EKS는 먼저 기존 서버의 남는 공간에 애플리케이션(파드)의 수를 순식간에 늘립니다. 이 과정은 몇 초면 끝나기 때문에, 갑작스러운 트래픽 증가에 정말 빠르게 대응할 수 있습니다.
- 2단계 (노드 확장): 파드를 계속 늘리다 보니 더 이상 기존 서버에 공간이 없을 때, 그때서야 Cluster Autoscaler가 ASG에게 "서버 한 대 더 필요해"라고 요청합니다. 즉, ASG는 EKS의 요청을 받아 서버를 늘리는 실행 도구일 뿐, 진짜 결정은 EKS가 내리는 거죠.
이처럼 EKS는 **실제 애플리케이션의 필요(자리가 없어 대기 중인 파드)**에 따라 서버를 늘리기 때문에, 단순히 서버의 CPU 사용률 같은 지표만 보고 판단하는 ASG보다 훨씬 더 정확하고 효율적입니다.
비용 차이: 효율성이 결국 비용
두 방식의 비용 차이는 결국 ‘리소스 효율성’에서 나옵니다.
- ASG 방식: 보통 최대 트래픽을 감당하기 위해 서버를 좀 넉넉하게 운영하는 경우가 많습니다. 그러다 보니 평소에는 쓰지 않는 유휴 자원에 대한 비용이 계속 발생할 수 있죠.
- EKS 방식: 하나의 서버(노드)에 여러 애플리케이션(파드)을 빈틈없이 채워 넣어 리소스 사용률을 최대한으로 끌어올립니다. 예를 들어, ASG로는 서버 3대가 필요했던 작업을 EKS에서는 2대로 처리할 수 있게 되는 거죠. 물론 EKS 자체의 컨트롤 플레인 비용이 있지만, 규모가 커질수록 리소스 효율을 통해 아끼는 비용이 훨씬 더 큽니다.
결론: 무엇을 관리하고 싶은가?
EKS와 ASG의 차이를 한 문장으로 정리하면 이렇습니다.
ASG는 서버(인프라)를 관리하는 도구이고, EKS는 그 위에서 돌아가는 애플리케이션(컨테이너)을 관리하는 플랫폼이다.
둘은 서로를 대체하는 경쟁 관계가 아닙니다. 오히려 EKS가 더 나은 애플리케이션 관리를 위해 ASG의 능력을 빌려 쓰는 협력 관계에 가깝죠.
만약 단순한 애플리케이션 하나를 안정적으로 운영하는 게 목표라면 전통적인 ALB + ASG 구성이 좋은 선택일 수 있습니다. 하지만 여러 개의 마이크로서비스로 이루어진 복잡한 시스템을 효율적이고 자동화된 방식으로 운영하고 싶다면, EKS는 거의 필수적인 선택지라고 생각합니다.
결국 어떤 기술을 선택할지는 "서버를 어떻게 관리할까?"라는 질문에서 "내 애플리케이션을 어떻게 배포하고 운영할까?"라는 질문으로 관점을 바꾸는 것에서부터 시작되는 것 같습니다.