26Y06m3

Young-Kyoo Kim·2026년 7월 6일

1,000개 노드 규모의 에어갭(Air-gapped) 온프레미스 환경에서 엔터프라이즈급 데이터 레이크하우스와 대규모 분산 워크로드를 운영할 때, HPA, VPA, KEDA를 조합하여 오토스케일링 아키텍처를 설계하는 것은 자원 효율성과 클러스터 안정성을 동시에 확보하기 위한 가장 중요한 이정표입니다.

최신 쿠버네티스(v1.34+)의 성숙된 기능(특히 In-place Pod Resizing)과 대규모 환경의 제약 조건을 고려하여, 세 가지 도구를 상호 충돌 없이 최적의 시너지를 내도록 배치하는 인프라 아키텍처 가이드라인 및 베스트 프랙티스를 제안합니다.

1. HPA vs VPA 공존 전략 및 최신 v1.34+ 활용

전통적으로 HPA(수평 확장)와 VPA(수직 확장)는 동일한 메트릭(예: CPU/Memory)을 기준으로 동시에 가동할 수 없습니다. 두 컨트롤러가 서로 반대 방향으로 자원을 조정하려는 핑퐁 현상(Race Condition)이 발생하기 때문입니다. 따라서 워크로드의 특성에 따라 대상을 명확히 분격해야 합니다.

① VPA 지정 대상: 대형 상태풀(Stateful) 및 데이터 엔진 워크로드

대상: StarRocks BE/FE, Spark Driver, AI/ML 모델 서빙 프레임워크, 로컬 컨트롤러 파드.
이유: 이들은 수평 확장(Scale-out) 시 데이터 재분산(Resharding) 비용이 너무 크거나, 단일 프로세스가 대용량 힙 메모리를 점유해야 하는 특성을 가집니다.
💡 최신 v1.34+ 핵심 튜닝 (In-place Pod Resizing 활용):
과거 VPA의 최대 약점은 자원을 변경할 때 파드를 무조건 재시작(Restart)해야 한다는 점이었습니다. 하지만 v1.34 환경에서는 파드의 재시작 없이 실행 중인 컨테이너의 CPU/Memory 할당량을 실시간으로 변경하는 'In-place Pod Vertical Scaling'이 안정적으로 작동합니다.
VPA 매니페스트 설정 시 updateMode: "Auto"를 주입하더라도, 파드 명세의 resizePolicy를 조율하면 대규모 ETL 배치나 쿼리가 도는 도중에 다운타임 없이 자원 가드레일이 유동적으로 확장됩니다.

② HPA 지정 대상: 무상태(Stateless) 애플리케이션 및 데이터 웹 포탈

대상: 현업 사용자용 웹 워크벤치 포탈, API 게이트웨이, 마이크로서비스 앱.
이유: 트래픽 증가에 따라 즉각적인 팟 개수 확장으로 대응하기 가장 유리한 구조입니다.
v1.34+ 튜닝 가이드: 대규모 환경에서는 파드가 뜰 때의 이미지 다운로드 및 가동 레이턴시가 존재하므로, HPA 매니페스트 내부의 behavior 구역을 정밀 제어해야 합니다. 급격한 축소로 인한 캐시 스파이크를 막기 위해 scaleDown 안정화 윈도우(stabilizationWindowSeconds)를 기본 300초에서 600초 이상으로 보수적 정렬하는 것을 권장합니다.

2. KEDA(Event-driven) 중심의 데이터 레이크 파이프라인 고도화

표준 HPA는 프로메테우스의 사후 메트릭(과거 1~5분간의 평균 CPU 사용량)을 보고 움직이기 때문에, 대규모 데이터 스트리밍이나 일시적 배치 작업이 몰릴 때 예측 대응(Scale-up 레이턴시)에 실패합니다. 이때 KEDA(Kubernetes Event-driven Autoscaling)를 전면 배치해야 합니다.

KEDA는 내부적으로 HPA의 External Metrics Provider 아키텍처를 활용하므로 HPA와 충돌하지 않으며, 오히려 HPA를 완벽하게 지배하는 상위 오케스트레이터 역할을 수행합니다.

🚀 데이터 인프라 전용 KEDA Scaler 활용 시나리오

Kafka Lag Scaler (실시간 데이터 싱크 워커):

프로메테우스 메트릭 대신 사내 Kafka 토픽의 컨슈머 그룹 랙(Lag) 개수를 직접 감시합니다.
대량의 원천Parquet 파일이 스트리밍 버킷으로 쏟아져 들어오기 직전, 랙이 쌓이는 속도를 감지하여 파이프라인 워커 파드를 선제적으로 수백 개까지 수평 확장합니다.

MinIO (AIStor) Bucket Scaler / Prometheus Scaler:

AIStor 버킷 내부의 특정 이벤트 큐나 원천 메트릭 오브젝트 개수를 추적하여 데이터 가공(Step 1, 2 계열) 파드를 동적으로 핸들링합니다.

Cron Scaler (예측형 시간제 배치):

매일 새벽 3시 전사 결산 배치처럼 주기가 명확한 작업의 경우, KEDA Cron Scaler를 심어둡니다. 3시 정각에 CPU가 치솟은 뒤 파드를 늘리는 것이 아니라, 새벽 2시 55분에 미리 최적의 컨테이너 볼륨을 100% 확보(Warm-up)해 두는 전략입니다.

3. 1,000노드급 폐쇄망(Air-gapped) 환경 최적화 제언 (SRE 가이드라인)

대규모 노드 클러스터와 높은 파드 생성/소멸(High Pod Churn Rate)이 발생하는 환경에서 오토스케일링을 무작정 켜두면 마스터 노드의 커널 제어부와 네트워킹 레이어가 붕괴할 수 있습니다. 플랫폼 SRE 관점에서 다음 3대 코어 하이퍼 파라미터를 반드시 보정해야 합니다.

① 쿠버네티스 API 서버 부하 제어

쿠버네티스 컨트롤러 매니저의 기본 설정은 15초마다 클러스터 전체의 HPA 수식을 계산(--horizontal-pod-autoscaler-sync-period=15s)합니다. 1,000노드 시스템에서 모든 파드의 HPA를 15초마다 쿼리하면 API 서버가 메트릭 동기화 병목으로 마비될 수 있습니다.

조치: 마스터 제어부 아규먼트에서 이 동기화 주기를 30초 ~ 45초 수준으로 완화하십시오. KEDA의 내부 감시 주기(checkInterval) 역시 기본 30초 이상으로 느긋하게 정렬하여 API 서버로의 대량 쿼리를 분산시켜야 합니다.

② Cilium CNI 네트워킹 시너지 튜닝

KEDA나 HPA에 의해 수백 개의 파드가 동시 생성/소멸되면, 기존 CNI 구조에서는 IP 할당 및 라우팅 테이블 동기화 지연으로 인해 파드는 떴으나 네트워크가 통하지 않는 ContainerCreating 병목이 발생합니다.

조치: 사용 중이신 Cilium CNI의 CRD 기반 IPAM 모드를 최적화해야 합니다. 노드마다 예비로 들고 있는 IP 풀의 마진(cilium-operator-risk-margin)을 넉넉하게 선점해 두어, 파드가 버스트 스케일링을 치더라도 노드 가상 이더넷 인터페이스와 BGP/ECMP 경로가 커널 가속(eBPF) 레이어 위에서 즉시 바인딩되도록 통로를 넓혀두어야 합니다.

③ 에어갭 내부 Metrics 배포 규격

KEDA와 VPA 모두 폐쇄망 내부의 마스터 시크릿 보관소(HashiCorp Vault 등) 및 전사 Keycloak 계정계와 유기적으로 엮여야 합니다. KEDA 설치 시 TriggerAuthentication 오브젝트를 전사 표준 규격으로 선언하여, 외부 메트릭 소스(Kafka, StarRocks 등)를 찌를 때 사용하는 인증 토큰이 안전하게 순환(Rotation)되도록 아키텍처 보안 가드레일을 쳐두십시오.

4. 최종 컴포넌트별 배치 매트릭스 (Blueprint)

워크로드 분류	추천 오토스케일러	핵심 튜닝 지표 (Trigger / Metric)	v1.34+ SRE 아키텍처 구성 지침
stateless 웹 / API 게이트웨이	HPA	CPU / Memory Utilization (Target: 70%)	`scaleDown` 안정화 윈도우를 600초로 길게 가져가 고가용성 유지
실시간 데이터 스트리밍 / 큐 파이프라인	KEDA	Kafka Consumer Lag / MinIO Event Queue	사후 메트릭을 배제하고 이벤트 건수 기반 선제적 대량 수평 확장
정기 대규모 배치 / 마감 정산 엔진	KEDA	Cron Scaler (Time-based scheduling)	배치 시작 5분 전 대용량 풀 사전 가동 후 마감 시 `minReplicaCount: 0`으로 완전 자원 회수
대형 분산 DB 및 쿼리 엔진 (StarRocks 등)	VPA	Long-term Profile History (CPU/Mem P95)	In-place Pod Resizing 활성화로 쿼리 중단 없는 무중단 실시간 수직 자원 부스팅