Kubernetes v1.37, 네이티브 히스토그램 베타 전환 및 기본 활성화

무엇이 어떻게 달라졌는가

Kubernetes v1.37에서 네이티브 히스토그램 지원이 베타 단계로 전환되어 기본으로 활성화된다. 이 기능은 Kubernetes v1.36에서 KEP-5808을 통해 알파로 처음 도입되었으며, 고해상도와 저카디널리티 관측성을 제공한다.

Prometheus 네이티브 히스토그램을 채택함으로써 Kubernetes 컴포넌트는 지연 시간 및 기간 메트릭을 훨씬 더 높은 정확도로 노출한다. 동시에 텔레메트리 스토리지 및 스크래핑 오버헤드를 크게 줄이는 효과를 가져온다.

이 변화는 기존 클래식 히스토그램이 가지고 있던 정적 버킷 경계의 한계, 높은 카디널리티로 인한 스토리지 비용 문제, 그리고 분위수 계산 시 발생하는 보간 오류를 해결하는 데 중점을 둔다.

변화의 배경과 맥락

Kubernetes 관측성 초기부터 API 서버 요청 지연 시간이나 스케줄링 기간과 같은 지연 시간 및 기간 메트릭은 클래식 Prometheus 히스토그램에 의존해왔다. 이 방식은 메트릭 작성자가 0.005, 0.01과 같은 정적 누적 버킷 경계를 미리 정의해야 했다.

이러한 클래식 히스토그램 방식은 세 가지 주요 문제를 야기했다. 첫째, 워크로드의 지연 시간 프로필이 변화할 경우(예: 마이크로초 범위로 이동하거나 최고 버킷을 초과하는 긴 꼬리 지연 발생), 히스토그램은 가시성을 잃게 된다. 이는 관측 전에 분포를 알아야 버킷 경계를 지정할 수 있다는 한계가 있다.

둘째, 각 버킷 경계가 별도의 시계열로 내보내지므로(예: `_bucket{le="..."}`), 여러 레이블에 걸쳐 10개의 버킷을 가진 히스토그램은 시계열 수를 10배 증가시켜 Prometheus의 메모리 소비와 시계열 데이터베이스(TSDB) 스토리지 비용을 높인다. 셋째, `histogram_quantile()`을 사용한 백분위수 계산은 정적 버킷 경계 간의 선형 보간에 의존하는데, 버킷 간격이 넓으면 분위수 계산에 상당한 추정 오류가 발생할 수 있었다.

네이티브 히스토그램의 구체적 동작

Prometheus 네이티브 히스토그램은 정적 사용자 정의 버킷을 동적 지수 버킷으로 대체한다. 각 버킷 경계를 개별 시계열로 내보내는 대신, 네이티브 히스토그램은 양수 및 음수 스팬, 제로 임계값, 지수 스케일링 팩터 등 풍부한 스키마를 포함하는 단일 시계열로 저장된다.

이러한 방식은 나노초부터 시간 단위까지 모든 값 범위에 동적으로 조정되는 고해상도를 자동으로 제공하며, 미리 구성된 버킷 경계가 필요 없다. 버킷을 단일 시계열 내의 구조화된 스팬으로 통합함으로써 스크래핑 및 스토리지 오버헤드를 최대 90%까지 줄일 수 있다.

또한, 네이티브 히스토그램은 관측 스펙트럼 전반에 걸쳐 수학적으로 오차 범위가 제한된(기본 설정에서 최악의 경우 약 5% 상대 오차) 정확한 분위수 계산을 가능하게 한다.

Kubernetes 내 구현 및 지원 범위

Kubernetes에서 네이티브 히스토그램 지원은 공유 메트릭 서브시스템(`component-base/metrics`) 내에 직접 구현된다. `NativeHistograms` 기능 게이트가 활성화되면 Kubernetes 컴포넌트는 이중 노출(dual exposition) 방식을 사용한다. 이는 클래식 버킷(`h.Bucket`)과 네이티브 스팬(`h.Schema`, `h.PositiveSpan`)을 동시에 내보내어 기존 관측성 스택에 중단 없이 작동하도록 설계되었다.

네이티브 히스토그램이 활성화되면 `component-base/metrics` 패키지는 모든 히스토그램 메트릭에 표준화된 지수 옵션을 자동으로 적용한다. `BucketFactor`는 1.1로 설정되어 각 버킷이 이전 버킷보다 최대 10% 넓게 구성되며, 이는 작업 시간이 1밀리초든 10초든 관계없이 분위수 계산에 대해 최악의 경우 약 5%의 상대 오차를 보장한다.

`MaxBucketNumber`는 160으로 설정되어 히스토그램당 최대 버킷 수를 제한한다. 이는 OpenTelemetry SDK의 권장 사항을 따라 극단적인 이상치 분포에서도 컴포넌트의 메모리 사용량을 보호한다. 네이티브 히스토그램은 `component-base/metrics`에 통합되어 `kube-apiserver`, `kube-scheduler`, `kubelet`, `kube-controller-manager`, `kube-proxy` 등 모든 주요 Kubernetes 컨트롤 플레인 및 노드 컴포넌트가 자동으로 지원을 상속받는다.

개발자 및 사용자에게 미치는 영향

Kubernetes v1.37로 업그레이드하면 클러스터는 기본적으로 이중 노출 메트릭을 내보낸다. Prometheus 3.0 이상 버전에서는 `scrape_configs` 내에 `scrape_native_histograms: true` 및 `always_scrape_classic_histograms: true`를 명시적으로 설정하여 네이티브 히스토그램을 스크래핑할 수 있다. 전환 기간 동안 `always_scrape_classic_histograms: true` 설정은 기존 대시보드와 알림이 계속 작동하도록 보장한다.

Prometheus 2.40부터 2.x 버전에서는 Prometheus를 `--enable-feature=native-histograms` 기능 플래그와 함께 시작하여 네이티브 히스토그램을 전역적으로 활성화할 수 있다. 이 경우 모든 스크래핑 대상에 대해 일괄적으로 적용된다.

네이티브 히스토그램이 Prometheus에 수집되면 PromQL에서 `histogram_quantile()`과 같은 표준 히스토그램 함수를 사용하여 질의할 수 있다. 더 이상 정적 `le` 버킷 레이블이나 `_bucket` 접미사가 필요 없으며, 메트릭 이름에 직접 작동하여 정적 버킷 보간 오류 없이 높은 정확도의 분위수를 생성한다.

적용 조건과 한계 및 마이그레이션 전략

모니터링 인프라를 네이티브 히스토그램으로 안전하게 전환하기 위해 4단계 마이그레이션 워크플로우가 권장된다. 첫째, Prometheus 3.x 스크래핑 설정에서 `scrape_native_histograms: true`와 `always_scrape_classic_histograms: true`를 모두 설정하여 두 형식을 동시에 수집한다. 둘째, Grafana 대시보드와 Prometheus 알림 규칙의 쿼리를 클래식 쿼리(`histogram_quantile(..._bucket...)`)에서 네이티브 쿼리(`histogram_quantile(...)`)로 업데이트하고, `_count`, `_sum` 시리즈 참조를 `histogram_count(...)`, `histogram_sum(...)`으로 대체한다.

셋째, 스테이징 또는 프로덕션 환경에서 새로운 네이티브 히스토그램 쿼리를 사용하여 모든 대시보드와 SLO 알림이 올바르게 작동하는지 검증한다. 넷째, 마이그레이션이 완료되면 `always_scrape_classic_histograms: false`로 설정하여 Prometheus가 정적 `_bucket`, `_count`, `_sum` 시계열 수집을 중단하게 한다. 이를 통해 히스토그램 시계열 수를 최대 90%까지 줄여 스토리지 절감 효과를 얻을 수 있다.

네이티브 히스토그램은 이중 노출되므로, 수집기 관점에서는 전적으로 옵트인 방식이다. 네이티브 히스토그램 수집을 중단해야 할 경우, Prometheus 작업 구성에서 `scrape_native_histograms: false`로 설정하면 Kubernetes 재시작 없이 즉시 클래식 형식만 스크래핑하도록 롤백할 수 있다. 또한, 관리자는 Kubernetes 컴포넌트에서 `NativeHistograms` 기능 게이트를 비활성화하여 롤백할 수도 있다(컴포넌트 재시작 필요).

네이티브 히스토그램은 향후 Kubernetes 릴리스에서 일반 가용성(GA)으로 진행될 예정이며, SIG Instrumentation은 생태계 준비 상태, 성능 특성 및 장기 계획을 지속적으로 평가한다. 모니터링 커뮤니티 전반에 걸쳐 네이티브 히스토그램 채택이 보편화되면 정적 클래식 버킷은 점진적으로 사용 중단될 계획이다.