문제는 분명한 운영상의 역설에서 시작된다. Adobe 환경에서는 GPU 사용 데이터가 중앙 Prometheus에 매초 수집되고 있었지만, GPU 비용을 부담하는 팀들은 자신의 메트릭을 직접 볼 수 없었다. 엔지니어 Bingi Narasimha Karthik과 Ramkumar Nagaraj에 따르면, 이로 인해 11일 동안 사용률이 0인 상태로 유지된 GPU가 발견되었다. 해당 GPU는 할당되어 실행 중이었지만 담당 팀에는 보이지 않았다.
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를 통해 remote write 수신을 활성화해야 하며, 나머지 인프라는 일반적인 Prometheus 및 Kubernetes 구성 요소로 유지된다.
이 글은 네임스페이스별 평균 GPU 사용률, 한 시간 동안 사용률이 5% 미만인 GPU 수, 사용 중인 메모리 비율, 전력 소비량, 요청 트래픽 없이 사용 중인 GPU 탐지, GPU가 유휴 상태인데 요청이 존재하는 상황 탐지 등 유용한 쿼리 유형 여섯 가지를 제시한다. 예시는 DCGM 계열의 메트릭을 사용하며, 실제 사용하는 익스포터에 맞게 이름을 조정해야 한다고 설명한다.
실험은 자체 운영이 장벽을 제거한다는 뜻은 아님을 보여준다. 선별된 메트릭 집합과 서로 다른 수집 주기는 부하를 제한하는 할당량으로 작동한다. 또한 remote write는 실제 대시보드와 알림을 운영하는 팀에 할당해야 하며, 소규모 팀에는 쿼리 시점의 제한된 접근만으로 충분할 수 있다.
certi.news의 분석
여기서 중요한 변화는 또 다른 모니터링 도구를 추가하는 것이 아니라, 격리를 인프라의 통제 아래 유지하면서 가시성에 대한 통제권을 플랫폼 팀만의 영역에서 테넌트로 이전하는 것이다. 이는 보안, 비용, 성능 문제를 동시에 다룬다. 그러나 해결책이 자동으로 작동하는 것은 아니다. 메트릭 선택, cardinality 조정, 재시도 처리, 고가용성 복제본으로의 쓰기, 익스포터 버전 고정은 모두 지속적인 운영 책임이다.
약 97%의 시계열 감소를 포함한 수치 결과는 저자들의 실험과 ‘일반적인 테넌트’에 해당하는 것이며, 모든 클러스터에 대한 보장은 아니다. 따라서 광범위하게 도입하기 전에 각 환경의 메트릭 이름, 시계열 규모 및 수집 주기를 기준으로 이 패턴을 테스트해야 한다. 프로젝트는 Apache 2.0 라이선스로 제공되며, 글에는 GitHub의 prometheus-multi-tenant-proxy 저장소 링크가 포함되어 있다.