96. VPA (Vertical Pod Autoscaler) - 파드 수직 자동 스케일러

⚠️ 이 문서는 쿠버네티스 클러스터에서 파드(Pod)의 '개수'를 여러 개로 늘려서 부하를 분산하는 HPA(수평 스케일러)와 달리, 데이터베이스나 캐시 서버처럼 개수를 쪼갤 수 없거나 분산 처리가 불가능한 애플리케이션이 메모리 초과로 뻗는 것을 막기 위해, **컨테이너 자체의 체력(CPU와 메모리의 Request/Limit 값)을 밑바닥부터 헐크처럼 통째로 키워버리거나 깎아내어 자원 할당량을 수직 상향/하향 조정해 주는 'VPA (수직 파드 오토스케일러)'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "알바생을 더 뽑아라(HPA)"가 아니라, "지금 일하고 있는 1명의 주방장에게 근력 강화 주사를 놔서 덩치(CPU/RAM)를 강제로 키워라(VPA)"라는 개념의 스케일업(Scale-up) 기술이다.
  2. 가치: 개발자가 처음에 파드의 CPU를 100m, RAM을 256Mi로 대충 때려 맞춰 적어두었다가 런타임에 메모리 부족(OOM)으로 파드가 터지는 삽질을 없애준다. 기계가 며칠간 파드의 섭취량을 감시하다가 "얘는 램 512Mi가 적당하네"라며 설정값(yaml) 자체를 인공지능처럼 알아서 최적화해 고쳐버린다.
  3. 기술 체계: HPA와 동시에 같은 CPU/RAM 메트릭을 바라보게 세팅하면 둘이 멱살을 잡고 싸우게 되므로 절대 같이 쓰면 안 되며(예외 있음), VPA가 자원 크기를 바꿀 때는 어쩔 수 없이 기존 파드를 한 번 죽이고(Evict) 더 큰 덩치로 새로 띄워야 하는 파괴적 재시작(Downtime)이 동반된다.

Ⅰ. 수동 리소스 할당의 찍기(Guesswork) 고통

개발자는 자기 앱이 램을 얼마나 퍼먹는지 정확히 모른다.

  1. Requests와 Limits의 딜레마:
    • 쿠버네티스 파드를 배포할 때, 착한 개발자는 항상 resources.requests(최소 요구량)와 limits(최대 제한량)를 적는다.
    • 하지만 이 값은 100% 감(Guess)으로 찍은 숫자다. "램 512MB면 넉넉하겠지?" 하고 배포했는데 새벽에 트래픽이 터져 512MB를 넘자, 쿠버네티스 OOM Killer가 냅다 파드의 목을 날려버려 서비스가 장애 난다.
  2. 오버 프로비저닝 (Over-provisioning)의 낭비:
    • 놀란 개발자는 다음 배포 때 무서워서 파드의 램 리미트를 4GB로 엄청나게 크게 잡아버린다.
    • 실제로 이 파드는 1GB밖에 안 쓰는데, 쿠버네티스는 이 파드를 위해 4GB의 공간을 영원히 예약(Block)해둔다. 결국 비싼 AWS 노드 서버(EC2) 공간이 텅텅 비었는데도 다른 파드가 못 들어가는 막대한 돈 낭비(자원 누수)가 발생한다.

📢 섹션 요약 비유: 엄마(개발자)가 고등학생 아들(파드)에게 매달 용돈(자원)을 5만 원 줍니다. 아들이 문제집 살 돈이 모자라 굶어 쓰러집니다(OOM 에러). 놀란 엄마가 다음 달부터 용돈을 50만 원 쏴줍니다. 아들은 10만 원만 쓰고 40만 원은 지갑에 썩혀둡니다(오버 프로비저닝). 엄마의 한 달 생활비(클라우드 요금)만 거덜 나는 눈물 나는 헛발질의 연속입니다.

Ⅱ. VPA의 기적: 며칠 지켜보고 체질을 바꿔버린다

찍지 마라. 기계가 학습해서 완벽한 맞춤형 옷을 재단해 준다.

  1. Recommender (감시와 추천):
    • VPA 엔진을 켜두면, 이 똑똑한 봇이 며칠 동안 클러스터 구석에 숨어서 내 파드가 CPU와 램을 얼마나 쓰는지 그래프 패턴을 조용히 관찰(History)한다.
    • "흠, 개발자가 처음에 램 256MB로 적어놨는데, 지켜보니 어젯밤에 피크 칠 때 400MB까지 쓰네? 이 파드는 512MB로 세팅하는 게 제일 예쁘고 안전하겠어."라고 완벽한 최적의 권장 값(Recommendation)을 산출한다.
  2. Updater 와 Auto 모드의 파괴적 갱신:
    • VPA를 updateMode: Auto 로 세팅해 두었다 치자.
    • VPA가 "너 덩치 키워야 해!"라고 결심한 순간, 런타임에 고무줄처럼 램 크기를 쓱 늘릴 수는 없다 (리눅스 컨테이너의 한계).
    • VPA는 미련 없이 **현재 돌아가는 파드를 즉시 암살(Evict/Kill)해 버리고, 0.1초 뒤 자신이 계산한 거대한 CPU/RAM 세팅값(512MB)이 적힌 새로운 파드로 바꿔치기해서 부활(Restart)**시켜 버린다. (이 과정에서 아주 잠깐의 서비스 끊김이 발생할 수 있다.)
  3. Off 모드 (권고만 받기):
    • 운영 서버 한복판에 파드가 강제로 껐다 켜지는 게 무서운 DBA나 엔지니어는 updateMode: Off 로 둔다.
    • 이렇게 하면 VPA는 파드를 안 죽이고 "내가 관찰해 보니 512MB가 딱이야"라고 귓속말로 조언(로그 기록)만 해준다. 개발자는 다음 배포 때 그 조언을 참고해서 yaml 파일의 숫자를 고치면 된다.

📢 섹션 요약 비유: 아들의 용돈을 얼마 줘야 할지 모르는 엄마를 위해, 가계부 AI 비서(VPA)가 아들의 한 달 치 카드 내역(메트릭)을 완벽히 분석합니다. 그리고 엄마에게 "아들은 매달 딱 12만 5천 원을 쓰네요. 앞으로 용돈을 13만 원으로 자동 변경(Auto)해 드릴까요, 아니면 참고만 하시겠어요(Off)?"라고 완벽한 컨설팅 리포트를 들이미는 맞춤형 자산 관리 시스템입니다.

Ⅲ. HPA vs VPA: 멱살잡이와 아키텍처의 분리

두 마리의 호랑이를 같은 산(CPU 메트릭)에 두면 산이 무너진다.

  1. 동시 적용의 치명적 오류 (Race Condition):
    • 어떤 멍청한 개발자가 "오! 그럼 HPA로 개수도 늘리고, VPA로 덩치도 키우면 무적의 서버가 되겠네?" 하고 두 개를 똑같이 CPU 기준으로 켜버렸다.
    • 트래픽이 몰려 CPU가 80%를 찍었다.
    • HPA 봇: "앗 CPU가 높네? 파드 개수를 2개에서 4개로 늘려!"
    • VPA 봇: "앗 CPU가 높네? 현재 파드를 죽이고 CPU 덩치를 2배 큰 놈으로 새로 띄워!"
    • 둘이 동시에 발작하면서 파드가 4개로 늘어남과 동시에 기존 파드들이 죽어 나가고 재부팅되는 대혼란(플래핑)이 터져 시스템이 지옥에 빠진다.
  2. 절대적 원칙 (지표의 분리):
    • 쿠버네티스의 철칙: "절대로 HPA와 VPA를 'CPU/메모리'라는 똑같은 조건(Metric)으로 동시에 엮지 마라."
    • 굳이 같이 써야 한다면? **HPA는 [카프카 큐에 쌓인 메시지 수(Custom Metric)]**를 보고 개수를 늘리게 하고, **VPA는 [CPU/RAM(Resource Metric)]**을 보고 덩치를 키우게 역할을 완벽하게 찢어놓아야만 두 로봇이 평화롭게 공존할 수 있다.

📢 섹션 요약 비유: 불이 난 현장(CPU 100%)에 소방관 두 명이 도착했습니다. 한 명(HPA)은 "빨리 동료 소방관 5명을 더 데려와!(개수 증가)"라고 무전을 치고, 다른 한 명(VPA)은 "야, 너 입고 있는 방화복 작으니까 잠깐 벗고 이 2배 두꺼운 헐크 방화복으로 갈아입어!(덩치 키우기)"라며 불 속에서 동료의 옷을 강제로 벗기고 있습니다. 두 지시가 동시에 떨어지면 소방관은 불타 죽습니다. 지휘 체계는 무조건 하나로 통일해야 합니다.