문제는 분명한 운영상의 역설에서 시작된다. Adobe 환경에서는 GPU 사용 데이터가 중앙 Prometheus에 매초 수집되었지만, 해당 GPU 비용을 부담하는 팀은 메트릭을 직접 확인할 수 없었다. 엔지니어 Bingi Narasimha Karthik과 Ramkumar Nagaraj에 따르면, 이로 인해 할당되어 실행 중이었지만 담당 팀에는 보이지 않은 GPU가 11일 동안 사용률 0%로 유지된 사실이 발견되었다.
2026년 9월 9일 CNCF 블로그에 게시된 이 글은 새로운 상용 제품을 제시하는 것이 아니라, 멀티테넌트 Kubernetes 클러스터에서 메트릭에 안전하게 셀프서비스 방식으로 접근하는 실용적인 구축 패턴을 설명한다. 핵심 아이디어는 중앙 Prometheus 앞에 테넌트를 인식하는 중간 계층을 배치한 뒤, 각 팀에 자체 데이터의 선별된 일부를 제공하고 필요할 경우 해당 데이터를 팀 전용 Prometheus로 복제하는 것이다.
중앙 Prometheus를 개방하는 것만으로는 왜 충분하지 않은가?
두 저자는 팀에 중앙 Prometheus의 쿼리 엔드포인트에 대한 읽기 권한을 부여하면 두 가지 문제에 부딪힌다고 설명한다. 첫 번째는 보안이다. Prometheus 쿼리 엔드포인트는 네임스페이스를 인식하지 않으므로 PromQL 쿼리를 실행할 수 있는 사용자는 이론적으로 요청률이나 용량 계획과 같은 다른 팀의 데이터를 요청할 수 있다.
두 번째 문제는 성능이다. 중앙 저장소는 전체 플릿의 메트릭을 제공하며, 수백 명의 엔지니어가 실행하는 길거나 최적화되지 않은 쿼리는 리소스를 소모하고 모든 사용자의 응답 시간을 늘릴 수 있다. 따라서 공유 저장소를 개방하는 것은 가시성 문제를 해결하지 못하며, 오히려 동일한 인프라에 데이터 유출 위험과 시끄러운 이웃 문제를 추가할 수 있다.
세 가지 책임을 지는 중간 계층
이 설계는 Prometheus 앞에 다음 세 가지 연계 기능을 수행하는 얇은 계층을 둔다.
- 식별: 요청자를 인증하고 해당 요청자가 속한 테넌트를 파악한다.
- 격리: 모든 쿼리를 테넌트의 네임스페이스로 제한하고, Prometheus에 쿼리가 도달하기 전에 이 제한을 적용하여 PromQL을 통해 우회할 수 없게 한다.
- 전달: 필요할 때 선별된 테넌트 메트릭 집합을 주기적으로 해당 테넌트 전용 Prometheus로 복제한다.
읽기 경로는 Nginx를 사용해 부하를 분산한 다음 kube-rbac-proxy를 통해 인증과 권한 부여를 수행한다. 이후 요청은 Kubernetes API를 통해 Prometheus 서버를 검색하고 정상 서버에서 결과를 수집하는 프록시로 전달된다. 쓰기 경로는 remote write를 사용해 선별된 메트릭을 테넌트 전용 Prometheus로 전송한다. 고가용성 환경에서는 Pod의 DNS 이름을 통해 모든 복제본으로 데이터를 전송한다.
격리는 신원에서 시작해 데이터에서 끝난다
kube-rbac-proxy는 Kubernetes 신원과 RBAC를 사용해 요청자를 식별한 다음, 테넌트 신원을 네임스페이스 확인 정보의 형태로 전달한다. prom-label-proxy는 쿼리 시점에 격리를 적용한다. 요청을 다시 작성해 Prometheus로 보내기 전에 네임스페이스 선택자를 추가하는 방식이다. 따라서 격리는 사용자에게 권고되는 정책에 그치지 않고 모든 쿼리에 적용되는 제약이 된다.
소스는 프록시 자체를 강화하기 위한 조치도 언급한다. 여기에는 UID 65534의 비 root 사용자로 실행하기, 읽기 전용 루트 파일 시스템 사용하기, 모든 추가 권한 제거하기, 권한 상승 방지하기, 가능한 최소 권한을 가진 서비스 계정 부여하기 등이 포함된다.
비용과 성능은 실제로 어떻게 달라지는가?
격리는 다른 사용자의 데이터를 보지 못하게 하는 데 그치지 않는다. metricIsolation 설정을 사용하면 메트릭 수집 단계부터 네임스페이스 필터를 적용할 수 있으므로, 테넌트 전용 Prometheus에는 해당 테넌트에 속한 시계열만 저장된다. 두 저자의 실험에 따르면 일반적인 테넌트의 저장 시계열 수가 1만 개 이상에서 수백 개로 약 97% 감소할 수 있다.
이러한 감소는 더 작은 저장소, 더 빠른 쿼리, 더 낮은 스토리지 비용을 의미한다. 또한 필요하지 않은 메트릭이 애초에 전용 저장소에 도달하지 않으므로 데이터 유출 가능성도 줄어든다. 이 설계는 대시보드와 일상적인 알림을 공유 저장소에 계속 의존하지 않고 테넌트 저장소로 이동시켜 중앙 Prometheus의 부하도 완화한다.
셀프서비스 운영에는 명확한 한계가 필요하다
팀은 Kubernetes에서 MetricAccess라는 사용자 지정 리소스를 정의한다. 이 리소스는 네임스페이스, 필요한 메트릭, remote write 대상 및 수집 주기를 지정한다. 테넌트는 특정 메트릭 이름이나 정규 표현식, PromQL 선택자를 선택할 수 있다. 대상 Prometheus에서는 web.enable-remote-write-receiver를 활성화해야 하며, 그 밖의 인프라는 일반적인 Prometheus 및 Kubernetes 구성 요소를 기반으로 한다.
이 글은 네임스페이스별 평균 GPU 사용률, 1시간 동안 사용률이 5% 미만인 GPU 수, 사용 중인 메모리 비율, 전력 소비량, 요청 트래픽 없이 사용 중인 GPU, GPU가 유휴 상태인데 요청이 존재하는 상황 등 유용한 쿼리 유형 6가지를 제시한다. 예시는 DCGM 계열의 메트릭을 기반으로 하며, 실제 사용하는 익스포터에 맞게 이름을 조정해야 한다고 경고한다.
이 실험은 셀프서비스 운영이 장벽을 제거한다는 의미는 아님을 보여준다. 선별하는 메트릭 집합과 서로 다른 수집 주기는 부하를 제한하는 할당량으로 작동한다. 또한 실제 대시보드와 알림을 보유한 팀에 remote write를 할당해야 하며, 소규모 팀에는 쿼리 시점의 제한된 접근만으로 충분할 수 있다.
certi.news의 시각
여기서 중요한 변화는 또 다른 모니터링 도구를 추가하는 것이 아니라, 인프라의 통제 아래 격리를 유지하면서 가시성에 대한 통제권을 플랫폼 팀 단독에서 테넌트로 이전하는 것이다. 이는 보안, 비용, 성능 문제를 동시에 해결한다. 그러나 해결책이 자동으로 운영되는 것은 아니다. 메트릭 선택, cardinality 조정, 재시도 처리, 고가용성 복제본으로의 쓰기, 익스포터 버전 고정은 모두 지속적으로 수행해야 하는 운영 책임이다.
약 97%의 시계열 감소를 비롯한 수치 결과는 저자들의 실험과 ‘일반적인 테넌트’에 해당하며, 모든 클러스터에 적용되는 보장은 아니다. 따라서 광범위하게 도입하기 전에 각 환경의 메트릭 이름, 시계열 규모, 수집 주기를 기준으로 이 패턴을 테스트해야 한다. 프로젝트는 Apache 2.0 라이선스로 제공되며, 글에는 GitHub의 prometheus-multi-tenant-proxy 저장소 링크가 포함되어 있다.