Read Original
#DevOps

옵저버빌리티 Right-Sizing: 여기어때에서 기준을 만드는 법

옵저버빌리티 Right-Sizing: 여기어때에서 기준을 만드는 법
01

Summary

비용은 줄이고 성능은 지킨다! 여기어때의 K8s 리소스 다이어트 실전 전략

데이터가 증명하는 P95 기반 리소스 최적화로 클러스터 효율을 극대화하는 방법

쿠버네티스 환경에서 '적당한 리소스'라는 모호한 기준을 데이터 기반의 명확한 정책으로 전환한 사례를 소개합니다. 옵저버빌리티 시스템의 복잡한 컴포넌트들을 특성별로 분류하고, 각기 다른 안전 버퍼를 적용하여 가용성을 확보하면서도 비용 효율을 달성한 플랫폼 엔지니어의 통찰을 담고 있습니다.

  • 01단순 평균이 아닌 P95(95th Percentile) 지표를 활용한 실효성 있는 리소스 측정 기준 수립
  • 02Stateful vs Stateless 컴포넌트 특성에 따른 25~50%의 차등화된 안전 마진 전략
  • 03CPU 사용률과 Throttling 발생 비율을 결합한 다각도 성능 검증 방법론
  • 041주일 측정 및 5분 샘플링이라는 실무적인 데이터 분석 환경 설정 제안
  • 05장애 위험도에 따른 우선순위 기반 롤아웃 및 롤백 기준 수립

RECOMMENDATION

클러스터 비용 최적화가 시급하거나, 리소스 설정의 기준이 없어 막연하게 '넉넉히' 할당하고 있는 인프라 담당자에게 이 아티클의 정량적 접근법을 적극 권장합니다.

The Problem

쿠버네티스 환경에서 리소스 설정값(requests)이 실제 사용량보다 과도하게 높으면 노드 자원이 낭비되어 불필요한 비용이 발생하고, 반대로 너무 낮으면 OOMKill이나 CPU Throttling으로 인해 서비스 안정성이 저해되는 문제가 있었습니다. 특히 옵저버빌리티 스택(LGTM)은 컴포넌트별로 리소스 사용 패턴이 매우 상이하여 일괄적인 기준을 적용하기 어려운 배경이 있었습니다.

The Solution

정량적인 데이터 분석을 위해 1주일간의 데이터를 5분 단위로 샘플링하여 P95(95번째 백분위수) 사용량을 핵심 지표로 선정했습니다. 이를 바탕으로 '적정 Request = P95 사용량 / 목표 사용률' 공식을 도입하였으며, Ingester와 같은 Stateful 컴포넌트는 50%, Distributor와 같은 Stateless 컴포넌트는 25% 수준의 차등화된 안전 마진(Buffer)을 적용하여 리소스를 재산정했습니다.

The Result

옵저버빌리티 인프라 전반의 리소스를 유의미하게 절감하면서도 서비스 장애(OOMKill)나 성능 저하(Throttling) 없이 안정적인 운영 상태를 유지하게 되었습니다. 또한 이를 분기별 정기 점검 항목으로 정착시켜 트래픽 변화에 따라 유연하게 대응할 수 있는 데이터 기반의 의사결정 체계를 구축했습니다.

Trade-off

P95 지표는 대다수의 상황을 커버하지만 간헐적으로 발생하는 데이터 압축(Compaction)이나 플러시(Flush) 작업 시의 피크치를 과소평가할 위험이 있습니다. 따라서 이러한 버스트 패턴을 가진 컴포넌트는 Max 값을 보조 지표로 병행 검토해야 하며, 리소스 절감 시 갑작스러운 트래픽 급증에 대한 여유 용량이 줄어들 수 있다는 점을 고려해 단계적 적용이 필요합니다.

03

Key Concepts

Concept · 01

Right-Sizing

쿠버네티스 Pod의 리소스 예약(requests)과 제한(limits)을 실제 사용량에 가깝게 조정하여 자원 낭비를 줄이고 시스템 가동률을 최적화하는 프로세스입니다.

  • Over-provisioning에 의한 클러스터 비용 낭비 해결
  • Under-provisioning에 의한 서비스 중단 위험 방지
Concept · 02

P95 (95th Percentile)

수집된 데이터 중 상위 5%의 극단값을 제외한 95번째 위치의 값을 의미하며, 일시적 노이즈를 제거하면서도 대부분의 피크 부하를 수용할 수 있는 통계적 기준입니다.

  • JVM GC나 초기화 시 발생하는 일시적 스파이크에 의한 과다 할당 방지
  • quantile_over_time 쿼리를 통해 실제 운영 피크를 합리적으로 반영
Concept · 03

CPU Throttling

컨테이너가 할당된 CPU 쿼터를 모두 소모했을 때 커널이 CPU 사용을 강제로 제한하는 현상으로, 서비스의 응답 지연(Latency)을 유발합니다.

  • CPU 사용률이 낮더라도 Throttling이 빈번하면 리소스 상향이 필요함
  • CFS 스케줄링 주기를 기반으로 발생 비율을 측정하여 가용성 지표로 활용