현재 여러 개의 EKS 클러스터를 운영하고 있습니다. 각 클러스터에는 자체적으로 Prometheus 인스턴스가 설치되어 있고, 애플리케이션 메트릭을 수집하고 있습니다. 이제 중앙에서 모든 클러스터의 메트릭을 통합적으로 관리하고 시각화하고자 하는데, 어떤 아키텍처가 가장 현실적이고 관리 효율적인지 고민입니다.
제가 고려하고 있는 옵션은 다음과 같습니다:
각 클러스터의 Prometheus를 그대로 두고, central Prometheus 서버에서 remote_read / remote_write로 데이터를 가져오기
각 클러스터의 Prometheus가 데이터를 Thanos 또는 Cortex를 통해 중앙 오브젝트 스토리지에 저장하고, 이를 기반으로 중앙 Grafana에서 시각화
모든 클러스터에서 동일한 Alertmanager를 사용하게 구성
실제로 멀티 클러스터 환경에서 Prometheus 모니터링을 운영해보신 분이 있다면, 아키텍처 구성에 대한 조언을 부탁드립니다. 운영/확장성/보안 측면 모두 고려해서요.
멀티 클러스터 환경에서 Prometheus를 효율적으로 운영하려면, 단순히 데이터를 한 곳에 모으는 것 이상의 전략이 필요합니다. 아래는 실무 경험에 기반한 가장 효과적인 구성 방식입니다.
클러스터 로컬 Prometheus 유지 + Thanos 연동
각 클러스터에는 독립적인 Prometheus 인스턴스를 유지하고, Thanos Sidecar를 붙여서 중앙 오브젝트 스토리지(S3 또는 GCS 등)에 데이터를 업로드하게 합니다. 중앙에서는 Thanos Querier를 통해 모든 데이터를 통합 조회할 수 있습니다. 이 r구성이 확장성, 장애 복원성, 이중화 측면에서 매우 안정적입니다.
중앙 Grafana 설정
Grafana는 Thanos Querier 또는 Thanos Store를 데이터 소스로 삼아 중앙에서 모든 클러스터 데이터를 시각화할 수 있습니다. 이 방식은 관리 주체가 한 곳에 집중되기 때문에 시각화 및 대시보드 공유에도 유리합니다.
Alertmanager 구성
Alertmanager는 공유해도 되지만, 실제 운영에서는 각 클러스터에 로컬 Alertmanager를 두고, 필요할 경우 central Alertmanager로 forward 하는 방식이 더 안전합니다. 전체 장애가 발생했을 때도 개별 클러스터의 알림 기능이 유지되기 때문입니다.
보안 고려사항
클러스터 간 통신에는 mTLS 또는 VPC peering을 사용해야 합니다.
오브젝트 스토리지는 클러스터별 IAM Role 기반 접근 정책을 설정하세요.
Grafana 접근은 SSO와 팀별 RBAC을 연계하는 것을 추천합니다.
Prometheus + Thanos + 중앙 Grafana 구조는 현재 멀티 클러스터 환경에서 가장 많이 쓰이고 있는 베스트 프랙티스입니다.
