[리눅스 기초 #69] 폭주하는 트래픽도 두렵지 않다: 쿠버네티스 HPA로 구현하는 마법 같은 자동 확장(Autoscaling)

리눅스 기초 시리즈의 69번째 시간입니다! 지난 시간에는 파이썬을 활용한 지능형 로그 분석을 통해 서버가 내뱉는 수많은 데이터 속에서 유의미한 패턴을 찾아내는 법을 배웠습니다. 이제 우리는 서버가 언제 아픈지, 왜 아픈지 데이터로 증명할 수 있는 능력을 갖췄습니다.

하지만 데이터를 아는 것과 실제로 대응하는 것은 별개의 문제입니다. 새벽 3시에 갑자기 트래픽이 몰려 CPU 점유율이 90%를 찍고 있다는 알람을 받았을 때, 다시 졸린 눈을 비비며 kubectl scale 명령어를 직접 치실 건가요? 오늘은 리눅스 서버 운영의 '진정한 자율 주행'이라 불리는 HPA(Horizontal Pod Autoscaler)를 통해, 서버가 스스로 몸집을 불리고 줄이는 마법 같은 기술을 저의 경험담과 함께 정리해 보겠습니다.

---

1. 나의 경험담: "알고리즘의 선택을 받은 날, 서버는 비명을 질렀다"

최근 제가 운영하는 유튜브 쇼츠 자동화 채널 중 하나가 소위 말하는 '떡상'을 한 적이 있습니다. 평소보다 100배가 넘는 시청자가 블로그 sunyjini.com으로 유입되었죠. 당시 저는 건강 관리를 위해 고함량 마그네슘을 챙겨 먹고 깊은 잠에 빠져있었습니다. 만약 예전 같았으면 다음 날 아침, 터져버린 서버와 '접속 불가' 메시지만 남은 게시판을 보며 영화 '하빈'의 비극적인 장면처럼 좌절했을 겁니다.

하지만 제 서버에는 HPA라는 든든한 파수꾼이 있었습니다. 트래픽이 몰리자 쿠버네티스는 0.1초 단위로 CPU 사용량을 감시하더니, 제가 설정해둔 임계치를 넘자마자 파드(Pod)를 2개에서 10개로 순식간에 확장했습니다. 트래픽이 잠잠해진 새벽녘에는 다시 2개로 줄여 클라우드 비용까지 아껴주었죠. 잠에서 깨어 대시보드를 확인했을 때, 물결치듯 유연하게 변한 리소스 그래프를 보며 '인프라 자동화'의 위력을 다시 한번 실감했습니다.

---

2. Before: "예측할 수 없는 미래와 낭비되는 비용"

오토스케일링이 없던 시절에는 두 가지 선택지뿐이었습니다. 트래픽 폭주를 대비해 미리 고사양 서버를 비싸게 유지하거나, 평소에 저사양으로 쓰다가 장애가 나면 수동으로 서버를 늘리는 것이었죠. 전자는 돈이 아깝고, 후자는 사용자를 잃게 만듭니다.

수동 확장의 한계:

Bash Terminal

 

# 사람이 직접 서버가 느린 걸 인지한 후...
kubectl scale deployment my-web --replicas=10

이미 사용자는 다 떠나간 뒤일 확률이 높습니다.
"아... 미리 늘려놓을걸" (후회와 비용의 반복)

(▲ Before: 리소스는 고정되어 있고 트래픽은 변덕스럽습니다. 이 간극을 메우는 것은 오직 관리자의 '희생'뿐이었습니다.)

---

3. Action: HPA로 '생각하는 인프라' 만들기

HPA를 구현하려면 먼저 클러스터의 메트릭을 수집하는 Metrics Server가 설치되어 있어야 합니다. 그 후, "CPU 사용량이 50%를 넘으면 파드를 늘려라"라는 규칙을 담은 YAML 파일을 적용하면 됩니다.

자동 확장 설정 코드 (hpa.yaml):

YAML Manifest

 

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-web # 확장할 대상 서비스 이름
minReplicas: 2  # 최소 유지 개수
maxReplicas: 10 # 최대 확장 개수
metrics:

type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50 # CPU 50% 사용 시 자동 확장!

적용 및 상태 확인:

Terminal

 

# HPA 규칙 적용
kubectl apply -f hpa.yaml

실시간 확장 상태 모니터링
kubectl get hpa -w

(▲ Action: 이제 쿠버네티스는 여러분의 명령 없이도 15초마다 메트릭을 체크합니다. 조건이 맞으면 즉시 Replicas 숫자를 조절하며 서버의 체급을 바꿉니다.)

---

4. After: "평화로운 새벽, 스마트한 비용 관리"

HPA를 도입한 뒤, 제 개발 라이프는 한 단계 더 높은 차원의 '여유'를 얻었습니다.

혁신적인 변화들:

• 무결점 가용성: 어떤 돌발적인 트래픽 폭주에도 서비스가 죽지 않고 유연하게 대응합니다.
• 지갑을 지키는 인프라: 사용자가 없는 시간대에는 리소스를 최소한으로 줄여 클라우드 과금 폭탄을 방지합니다.
• 진정한 데브옵스: 운영에 쏟던 에러 대응 시간을 이제 새로운 자동화 스크립트 설계나 콘텐츠 기획에 온전히 쏟을 수 있게 되었습니다.

---

5. 실험 요약 및 팁

용어	역할	비유
HPA	부하에 따라 파드(Pod) 개수를 조절	손님이 많아지면 점원을 늘리기
VPA	부하에 따라 개별 파드의 사양을 조절	점원에게 더 성능 좋은 도구 쥐여주기
Metrics Server	리소스 사용량 데이터를 수집/제공	현장을 감시하는 CCTV
Cooldown	잦은 확장/축소를 방지하는 대기 시간	점원이 들어오고 나갈 때의 교대 시간

---

6. 마치며: 당신의 서버에 '근육'을 달아주세요.

리눅스 기초 69단계를 거치며 우리는 이제 시스템을 만들고, 감시하고, 이제는 스스로 변신하게 만드는 단계에 도달했습니다. 엔진(커널)과 보안이 튼튼해졌으니, 이제 그 위에서 돌아가는 서비스들이 어떤 풍파에도 흔들리지 않도록 유연함을 더해주어야 합니다. 오토스케일링은 단순한 기능이 아니라, 사용자와의 약속을 지키는 '엔지니어의 신뢰'입니다.

오늘의 인사이트: "최고의 관리는 관리할 필요가 없게 만드는 시스템을 구축하는 것이다."

---

69번째 이야기를 마칩니다. 이제 우리 서버는 스스로 숨 쉬며 성장합니다. 다음 시간에는 이렇게 수많은 파드가 늘어났을 때, 실제 물리 서버(Node)까지 자동으로 추가하고 줄이는 끝판왕 기술, '클라우드의 정점: Cluster Autoscaler(CA)와 비용 최적화 전략'에 대해 다뤄보겠습니다.

이 글이 여러분의 트래픽 공포증을 해소하는 데 도움이 되었나요? 혹시 HPA를 설정했는데도 파드가 늘어나지 않아 당황하고 계신가요?

HPA 작동의 필수 전제 조건인 'Resources Requests/Limits' 설정법을 다음 포스팅 부록으로 준비해 드릴까요?