여기어때에서 Observability Right-Sizing 기준을 세우는 법

여기어때컴퍼니는 self-hosted Observability 스택을 OpenTelemetry와 Grafana LGTM으로 운영하면서, Pod 리소스를 다시 맞추기 위한 Right-Sizing 기준을 새로 세웠다. 노드가 가득 차 보이는 상황이 실제 사용량과 다를 수 있고, 반대로 requests가 낮으면 OOMKill이나 CPU Throttling으로 이어질 수 있었다.

기준은 평균이나 최대값이 아니라 P95였다. 3개월 데이터는 최근 변화를 희석하고 2주 데이터는 이벤트 영향을 과대반영해, 1주일을 기본 측정 기간으로 두고 5분 샘플링을 사용했다. 필요할 때는 1개월 데이터와 교차 검토해 이상치를 걸렀다.

메모리는 container_memory_working_set_bytes와 kube_pod_container_resource_requests를 비교했고, CPU는 container_cpu_usage_seconds_total과 CFS throttling 지표를 함께 봤다. 계산식은 적정 Request = P95 사용량 / 목표 사용률로 정리했고, P95 메모리가 250Mi면 80% 기준 적정 Request는 약 312Mi가 된다.

컴포넌트는 동작 방식에 따라 다르게 분류했다.

• Stateless: Distributor, Query-frontend처럼 낮은 버퍼로도 안정적인 컴포넌트
• Stateful 읽기: Store-gateway, Querier처럼 지연 영향은 있지만 유실 위험이 낮은 컴포넌트
• Stateful 쓰기: Ingester처럼 flush 전 OOM이 곧 데이터 유실로 이어져 가장 큰 버퍼가 필요한 컴포넌트
• 버스트 패턴: Compactor처럼 평소엔 대기하다가 작업 시 대용량 메모리를 쓰는 컴포넌트

이 분류에 맞춰 Ingester에는 +50% 버퍼에 준하는 높은 여유를 뒀고, Stateless에는 더 낮은 버퍼를 적용했다. Grafana의 Mimir sizing 권장, AWS Compute Optimizer의 Balanced 프로필, GKE VPA의 보수적 버퍼링도 참고했지만, 최종 기준은 각 컴포넌트의 피크 패턴과 장애 영향도를 기준으로 차등화했다.

적용은 Stateless부터 시작해 각 단계마다 3~7일 검증하며 진행했다. 결과적으로 Observability 인프라 리소스를 줄이면서도 OOMKill이나 Throttling 증가는 없었고, 이후에는 분기별 정기 점검 항목으로 편입했다.