Prometheus/Grafana 시니어 기술면접

Thanos를 선택하겠습니다. Thanos는 오브젝트 스토리지(S3 등)를 활용해 장기 데이터 보관이 저렴하고, 글로벌 쿼리 기능으로 여러 리전의 메트릭을 통합 조회할 수 있습니다. Federation은 계층적 구조로 단순하지만 중앙 서버가 병목이 되고, Cortex는 멀티테넌시가 강력하지만 운영 복잡도가 높습니다. 1억 사용자 규모에서는 리전별 Prometheus + Thanos Sidecar 구조로 로컬 쿼리는 빠르게 처리하고, 글로벌 뷰는 Thanos Querier로 제공하는 것이 비용 대비 효율적입니다. Compactor와 Store Gateway를 통해 downsampling과 장기 보관을 자동화할 수 있어 운영 부담도 적습니다.

먼저 /metrics 엔드포인트에서 prometheus_tsdb_symbol_table_size_bytes, prometheus_tsdb_head_series 등을 확인해 시계열 증가 추이를 파악합니다. Cardinality 폭발이 의심되면 promtool tsdb analyze로 높은 cardinality를 가진 레이블을 식별합니다. 특히 user_id, request_id 같은 무한 증가 레이블이 있는지 확인하고, relabel_configs로 제거하거나 recording rule로 집계합니다. Retention 기간이 과도하면 --storage.tsdb.retention.time을 조정하고, 쿼리 패턴 문제라면 Grafana 대시보드의 무거운 쿼리를 최적화합니다. WAL 크기도 확인해 --storage.tsdb.wal-compression을 활성화하고, 필요시 샤딩이나 Federation으로 부하를 분산시킵니다.

Counter는 누적 증가만 가능한 메트릭으로 요청 수, 에러 수 등에 사용하고 rate() 함수로 초당 증가율을 계산합니다. Gauge는 증가/감소가 자유로운 메트릭으로 현재 메모리 사용량, 동시 접속자 수 등에 사용합니다. Histogram은 관측값을 미리 정의된 bucket에 분류해 저장하며, 서버 측에서 quantile을 계산할 수 있어 여러 인스턴스의 데이터를 집계 가능합니다. Summary는 클라이언트 측에서 quantile을 계산해 저장하므로 정확하지만 집계가 불가능합니다. 응답 시간처럼 분포를 알아야 하는 메트릭은 Histogram을 선택하고, 집계가 필요 없고 정확한 quantile이 필요하면 Summary를 사용합니다.

Recording rule을 생성해 미리 집계된 메트릭을 저장하고, 대시보드에서는 집계된 메트릭을 조회하도록 수정합니다. 예를 들어 1분마다 sum by (service)를 계산하는 rule을 만들면 쿼리 시 원본 시계열이 아닌 집계 결과만 읽어 성능이 크게 향상됩니다. 대시보드의 resolution을 조정해 30일 범위에서는 1분 단위가 아닌 1시간 단위로 데이터를 요청하도록 설정합니다. Thanos나 VictoriaMetrics를 사용 중이라면 자동 downsampling으로 오래된 데이터는 낮은 해상도로 저장되어 쿼리 성능이 개선됩니다. 쿼리 자체도 불필요한 레이블을 제거하고, sum 대신 avg나 max가 적절한지 검토합니다. 마지막으로 Grafana의 Query caching을 활성화해 동일 쿼리 반복 실행을 방지합니다.

Pull 모델은 Prometheus가 주기적으로 타겟에 접근해 메트릭을 수집하는 방식이고, Push 모델은 애플리케이션이 메트릭을 모니터링 시스템으로 전송하는 방식입니다. Prometheus가 Pull 모델을 채택한 이유는 타겟의 health 상태를 확인할 수 있고, 서비스 디스커버리와 통합이 쉬우며, 타겟이 과부하 상태일 때 메트릭 수집을 조절할 수 있기 때문입니다. 하지만 배치 작업이나 Lambda 같은 단기 실행 작업은 Prometheus가 scrape하기 전에 종료되므로 Pushgateway를 사용해야 합니다. Pushgateway는 단기 작업의 메트릭을 받아 저장하고, Prometheus가 주기적으로 수집해갑니다. 방화벽으로 Prometheus가 타겟에 접근할 수 없는 경우에도 Pushgateway를 중간 게이트웨이로 활용합니다.

Prometheus는 기본적으로 인증 기능이 없으므로 nginx나 OAuth2 Proxy를 앞단에 두어 인증을 구현하거나, Prometheus 자체의 Basic Auth를 활성화합니다. Grafana는 LDAP, OAuth, SAML 등 다양한 인증 방식을 지원하며, 팀별로 폴더와 대시보드 권한을 분리하는 RBAC을 설정합니다. 메트릭 수집 시 TLS를 활성화해 전송 구간을 암호화하고, Grafana-Prometheus 간 통신도 HTTPS로 설정합니다. Kubernetes 환경에서는 Network Policy로 Prometheus가 필요한 Pod에만 접근하도록 제한하고, 민감한 메트릭(비밀번호, API 키)이 노출되지 않도록 relabel_configs에서 제거합니다. Grafana의 API 키는 최소 권한 원칙으로 생성하고 정기적으로 rotate합니다.

동일한 설정의 Prometheus 인스턴스를 2개 이상 배포하고, 각각 독립적으로 동일한 타겟을 scrape하도록 구성합니다. StatefulSet으로 배포하고 각 인스턴스는 로컬 스토리지에 데이터를 저장합니다. Alertmanager를 클러스터 모드로 구성하고, Prometheus의 알림 설정에서 external_labels로 replica 레이블을 추가해 Alertmanager가 중복 알림을 제거하도록 합니다. 쿼리는 Thanos Query나 Promxy 같은 쿼리 레이어를 앞단에 두어 여러 Prometheus를 통합 조회하고, deduplication을 수행합니다. Grafana는 로드밸런서를 통해 여러 Prometheus에 분산 쿼리하거나, Thanos Query를 단일 데이터소스로 설정합니다. 한 인스턴스가 다운되어도 다른 인스턴스가 메트릭을 수집하므로 데이터 손실을 최소화할 수 있습니다.

Prometheus TSDB는 시간 기반으로 Block을 생성하고, 각 Block은 2시간 단위의 압축된 시계열 데이터를 포함합니다. Chunk는 개별 시계열의 샘플을 압축해 저장하는 단위로, XOR 기반 압축으로 높은 압축률을 달성합니다. WAL(Write-Ahead Log)은 새로 수집된 데이터를 먼저 기록해 장애 시 데이터 복구를 가능하게 합니다. Block은 불변(immutable) 구조로, 한번 생성되면 수정되지 않아 동시성 제어가 간단하고 캐싱이 효율적입니다. 오래된 Block은 Compaction 과정을 거쳐 더 큰 Block으로 병합되며, retention 기간이 지나면 삭제됩니다. 이러한 구조는 시계열 데이터의 시간 순서 삽입, 범위 쿼리, 압축 특성에 최적화되어 있습니다.

STAR 방식으로 답변을 구성하세요. Situation: 어떤 모니터링 시스템을 사용하고 있었고, 왜 전환이 필요했는지 배경을 설명합니다. Task: 전환 프로젝트에서 본인의 역할과 목표를 명확히 합니다. Action: 팀원들의 우려사항(학습 곡선, 기존 대시보드 마이그레이션 등)을 어떻게 파악하고, PoC를 통해 효과를 입증했는지, 교육과 문서화를 어떻게 진행했는지 구체적으로 설명합니다. 점진적 마이그레이션 전략, 롤백 플랜 등 리스크 관리 방법도 포함하세요. Result: 전환 후 달성한 정량적 성과(쿼리 성능 개선, 비용 절감 등)와 팀의 만족도 변화를 이야기합니다. 이 과정에서 배운 점과 다음에는 어떻게 개선할지도 언급하면 좋습니다.

promtool을 사용해 Recording Rule과 Alerting Rule의 문법을 검증하고, 유닛 테스트를 작성합니다. promtool check rules 명령으로 YAML 파일의 문법 오류를 탐지하고, promtool test rules 명령으로 테스트 케이스를 실행합니다. 테스트 파일에는 입력 시계열 데이터와 예상되는 알림 또는 Recording Rule 결과를 정의합니다. CI/CD 파이프라인에서는 PR 단계에서 promtool check와 test를 실행해 규칙 변경이 기존 동작을 깨뜨리지 않는지 검증합니다. GitOps 방식으로 규칙을 관리하면 코드 리뷰를 거쳐 승인된 변경만 프로덕션에 배포되도록 할 수 있습니다. Alertmanager의 라우팅 규칙도 amtool을 사용해 유사하게 검증합니다.