100만 TPS 로그 시스템에 KEDA 오토스케일링 적용

이 게시물은 우아한형제들의 대규모 로그 시스템(Grafana Loki)에 KEDA를 도입해 비용과 안정성을 함께 개선한 과정을 설명합니다.

로그 시스템 구성과 병목 지점

• Fluentd가 로그를 수집·버퍼링한 뒤 Loki의 Distributor/Ingester를 거쳐 S3에 저장됩니다.
• Write Path에서 특히 Ingester가 메모리 의존도가 높고 기동 시간이 길어 오토스케일링 난이도가 높습니다.
• 컴포넌트 중 하나라도 리소스가 부족하면 Fluentd 버퍼가 차며 로그 유실로 이어질 수 있습니다.

기존 HPA의 한계

• Pod 간 리소스 사용률이 균일하지 않은 Stateful 특성으로 평균 기반 스케일링이 위험해질 수 있습니다.
• OOM Kill 후 재기동 Pod가 평균을 낮춰 스케일아웃이 지연되는 문제가 발생했습니다.

KEDA(ScaledObject)로의 전환과 설정 포인트

• KEDA는 ScaledObject로 Prometheus/CPU/메모리 등 외부·리소스 메트릭을 트리거로 사용하며, 내부적으로 HPA를 생성해 제어합니다.
• Fluentd 버퍼 사용률(Prometheus 쿼리)과 CPU/메모리를 함께 트리거로 두고, metricType 미지정 시 AverageValue로 동작해 스케일링이 꼬일 수 있음을 정리합니다.
• 버퍼 기반 트리거에서 OverProvisioning을 막기 위해 HPA behavior(예: 300초에 2개 Pod까지만 scale-up)를 적용했습니다.

결과

KEDA 도입 후 지연 없이 안정적으로 운행되었고, 임계치를 더 공격적으로 조정했으며, Pod 요청량 감소에 맞춰(별도 주제로) Karpenter 기반 클러스터 오토스케일링도 강화했다고 설명합니다.