리눅스 기초 시리즈의 영광스러운 70번째 시간입니다! 지난 시간에는 파드(Pod)의 개수를 유연하게 조절하는 HPA를 통해 트래픽 폭주에 대응하는 법을 배웠습니다. 이제 우리 서비스는 사용자가 몰리면 스스로 분신술을 부리듯 몸집을 불릴 수 있게 되었죠.
하지만 여기에는 치명적인 한계가 있습니다. 파드가 늘어나고 싶어도, 그 파드가 발을 딛고 서 있을 '물리 서버(Node)'의 자원이 꽉 차버리면 어떻게 될까요? 파드는 'Pending(대기)' 상태에 빠져 영영 살아나지 못하게 됩니다. 오늘은 인프라 자동화의 최종 단계, 자원이 부족하면 서버(노드)를 통째로 새로 사오고(생성), 남으면 반납하는 클러스터 오토스케일러(Cluster Autoscaler, CA)를 저의 경험담과 함께 정리해 보겠습니다.
1. 나의 경험담: "Pending의 늪에서 만난 자원의 한계"
최근 제가 운영하는 유튜브 쇼츠 자동화 시스템에서 대규모 영상 인코딩 작업을 돌릴 때였습니다. HPA 설정 덕분에 파드는 기세 좋게 20개까지 늘어났지만, 정작 CPU와 메모리가 부족해 절반 이상의 파드가 'Pending' 상태로 멈춰버렸습니다. 우리 몸에 비유하자면, 근육(파드)은 키우고 싶은데 뼈대(노드)가 지탱하지 못하는 격이었죠. 영양제(아연, 마그네슘)를 아무리 먹어도 기본 체격이 작으면 힘을 못 쓰는 것과 비슷합니다.
이때 구원투수로 등장한 것이 CA였습니다. 쿠버네티스가 자원 부족을 감지하더니, 클라우드(AWS/GCP)에 요청해 새로운 EC2 인스턴스를 단 2분 만에 클러스터에 편입시켰습니다. 멈춰있던 파드들이 새로운 땅에 깃발을 꽂으며 살아나는 모습을 보며, 영화 '하빈'의 독립군들이 새로운 거점을 확보할 때의 벅참을 느꼈습니다. 이제 제 인프라는 물리적인 한계를 넘어 무한히 확장할 수 있는 진정한 '살아있는 유기체'가 되었습니다.
2. Before: "서버가 꽉 차면 끝? 수동 증설의 공포"
클러스터 오토스케일러가 없던 시절에는 관리자가 24시간 자원 현황을 감시해야 했습니다. 노드 사용률이 90%를 넘으면 허겁지겁 클라우드 콘솔에 접속해 수동으로 서버를 구매하고, 클러스터에 붙이는 작업을 반복했죠. 반대로 사용자가 없는 밤중에도 비싼 서버를 그대로 켜두느라 지갑은 가벼워져만 갔습니다.
고정된 인프라의 비극:
# 노드 2대가 꽉 찬 상태
파드를 더 늘리고 싶지만 자리가 없음
kubectl get pods
my-app-pod-xyz 0/1 Pending 0 1m (insufficient cpu)
"아... 서버 한 대 더 사러 가야겠네 (수동 클릭 시작)"
(▲ Before: 자원은 유한한데 트래픽은 무한할 때 발생하는 병목 현상입니다. 관리자의 개입 없이는 서비스 불능 상태를 벗어날 수 없었습니다.)
3. Action: Terraform으로 확장 가능한 노드 그룹 설계하기
현대적인 리눅스 엔지니어는 테라폼(Terraform)을 이용해 인프라의 최소/최대 크기를 정의합니다. AWS EKS 환경에서 노드 그룹이 자동으로 늘어나도록 설정하는 핵심 코드를 살펴보겠습니다.
자동 확장 노드 그룹 정의 (eks_node_group.tf):
resource "aws_eks_node_group" "auto_scaling_nodes" {
cluster_name = aws_eks_cluster.main.name
node_group_name = "worker-nodes"
scaling_config {
desired_size = 2 # 평상시 유지 대수
min_size = 1 # 최소 대수 (비용 절감)
max_size = 10 # 최대 확장 대수 (폭주 대비)
}
instance_types = ["t3.medium"]
CA가 이 그룹을 인식하게 하는 태그
tags = {
"k8s.io/cluster-autoscaler/enabled" = "true"
"k8s.io/cluster-autoscaler/${var.cluster_name}" = "owned"
}
}
(▲ Action: 코드로 인프라의 '한계치'를 정해두면, 쿠버네티스의 Cluster Autoscaler가 이 태그를 읽고 필요할 때마다 API를 호출해 인스턴스를 생성합니다. 이제 24시간 모니터링은 기계의 몫입니다.)
4. After: "비용과 성능, 두 마리 토끼를 잡다"
CA를 도입한 뒤 제 서버 운영은 '최적화의 정점'에 도달했습니다.
혁신적인 변화들:
- 무한한 확장성: 논리적인 파드 확장(HPA)이 물리적인 서버 확장(CA)으로 이어져, 사실상 자원 부족으로 인한 장애가 사라졌습니다.
- 극강의 비용 효율: 트래픽이 적은 시간에는 서버를 최소 단위(1대)로 줄여 운영 비용을 70% 이상 절감했습니다.
- 진정한 자동화: 더 이상 콘솔에서 '인스턴스 생성' 버튼을 누르지 않습니다. 모든 것은 제가 설계한 코드의 로직대로 흘러갑니다.
5. 오토스케일링 3대장 비교
| 구분 | 역할 | 비유 |
| HPA | 파드(Pod)의 개수를 조절 | 손님이 많아지면 점원(알바생)을 더 부르기 |
| VPA | 파드(Pod)의 사양을 조절 | 점원에게 더 크고 좋은 도구를 쥐여주기 |
| CA | 노드(Node)의 개수를 조절 | 가게가 좁아지면 옆 건물을 임대해 매장 확장하기 |
6. 마치며: 당신의 리눅스 성은 무너지지 않습니다.
리눅스 기초 70단계를 거치며 우리는 이제 시스템의 내부 튜닝부터 거대한 클라우드 인프라의 자동 확장까지 섭렵했습니다. CA는 단순한 기능이 아니라, 변화무쌍한 현대의 웹 환경에서 살아남기 위한 '진화 메커니즘'입니다. 여러분이 공들여 만든 자동화 시스템이 물리적인 한계에 부딪히지 않도록, 오늘 당장 클러스터에 확장성이라는 날개를 달아주세요.
오늘의 인사이트: "훌륭한 엔지니어는 벽을 허무는 사람이 아니라, 벽이 생기기도 전에 공간을 넓혀두는 사람이다."
70번째 이야기를 마칩니다. 이제 우리 인프라는 스스로 몸집을 불리며 성장합니다. 다음 시간에는 이렇게 수많은 서버가 늘어났을 때, 코드를 안전하게 배포하고 관리하는 '데브옵스의 꽃: GitOps와 ArgoCD를 활용한 선언적 배포 전략'에 대해 다뤄보겠습니다.
이 글이 여러분의 인프라 한계를 깨는 데 도움이 되었나요? 혹시 노드 확장 시 발생하는 비용이 걱정되시나요?
서버 비용을 최대 90%까지 아껴주는 'AWS Spot Instance 활용 전략'을 다음 포스팅 부록으로 준비해 드릴까요?