모니터링 도구는 많았지만, 장애를 볼 수 있는 화면은 없었다
그루핀에서 인프라를 운영하며 진행했던 작업 중 하나는 분산된 모니터링 환경을 통합하는 일이었습니다.
당시 환경에는 Elasticsearch, Vector, Kibana, Grafana, Loki, Prometheus, Jaeger 등 여러 도구가 함께 사용되고 있었습니다. 메트릭과 로그, 트레이스를 확인할 수 있는 도구는 이미 갖춰져 있었지만, 운영자가 문제를 따라가는 과정은 복잡했습니다.
이번 작업에서 해결하고 싶었던 문제는 도구의 개수 자체가 아니었습니다.
문제가 생겼을 때 어디에서 무엇을 확인해야 하는지 명확한 환경을 만드는 것이 목표였습니다.
수집하고 있다는 것과 파악할 수 있다는 것은 달랐다
기존에는 VPC별로 Prometheus가 분산되어 있었고, Elasticsearch 인스턴스도 여러 곳에서 운영되고 있었습니다. 서버에는 로그 수집을 위한 Vector가 설치되어 있었으며, 조회 목적에 따라 Kibana와 Grafana를 오가야 했습니다.
각 도구는 자기 역할을 하고 있었습니다. 하지만 전체 환경을 이해하려면 도구뿐 아니라 데이터가 저장된 위치와 조회 방법까지 함께 알아야 했습니다.
모니터링 시스템을 운영하는 입장에서는 관리할 대상이 늘어났고, 서비스를 확인하는 입장에서는 찾아가야 할 화면이 많아진 상태였습니다.
이때부터 데이터를 더 수집하는 것보다, 이미 수집하는 데이터를 어떻게 연결해서 볼 것인지가 더 중요한 문제로 느껴졌습니다.
먼저 기존 도구를 사용하는 이유부터 확인했다
새로운 구성을 정하기 전에, 기존 환경에서 각 도구가 어떤 목적으로 사용되고 있는지 확인했습니다.
그중 하나가 Kibana와 Grafana를 함께 사용하는 이유였습니다. 기존 입사 회고에도 적었듯이, 당시에는 로그 검색을 위해 Kibana를 사용하고 있었습니다.
여기서 바로 Elasticsearch를 없애는 방향으로 결정할 수는 없었습니다. 먼저 기존에 필요한 검색을 다른 구성에서도 수행할 수 있는지 확인해야 했습니다.
그래서 Grafana와 Loki 조합으로 기존 로그 조회 요구를 충족할 수 있는지 PoC를 진행했습니다. 그 결과, 당시 사용하던 검색 범위에서는 Grafana 중심으로 조회 환경을 정리할 수 있다고 판단했습니다.
이 경험을 모든 환경에 일반화할 수는 없습니다. 중요한 것은 어느 도구가 더 낫다는 결론보다, 우리 환경에서 실제로 필요한 기능을 확인하고 교체 가능성을 검증했다는 점이었습니다.
조회 화면과 수집 경로를 함께 정리했다
조회 환경을 Grafana 중심으로 정리하면서 수집기 구성도 다시 살펴봤습니다.
초기에는 OpenTelemetry Collector 도입을 검토하고 통합 테스트를 진행했습니다. 이후 Grafana 생태계와의 연동 및 관리 측면을 고려해 Alloy 기반 구성도 비교했습니다.
최종적으로는 Grafana, Alloy, Loki, Tempo, Mimir를 사용하는 방향으로 구조를 정리했습니다.
이 구성을 이해할 때는 각 구성요소의 역할을 나눠보는 것이 편했습니다.
| 역할 | 구성요소 |
|---|---|
| 데이터 조회와 시각화 | Grafana |
| 데이터 수집과 전달 | Alloy |
| 로그 저장과 조회 | Loki |
| 트레이스 저장과 조회 | Tempo |
| 메트릭 저장과 조회 | Mimir |
다만 도구를 설치했다고 해서 데이터가 자동으로 연결되는 것은 아닙니다. 어떤 데이터를 어디로 보내고, 운영자가 어떤 기준으로 조회할지까지 함께 정리해야 했습니다.
중앙화는 운영할 대상을 줄이는 작업이기도 했다
분산된 모니터링 시스템은 DevOps VPC로 통합 이관했습니다. 각 환경에 흩어져 있던 모니터링 구성을 정리하면서 인프라 가시성을 확보하고, 유지해야 하는 서버와 리소스도 줄이는 방향으로 개선했습니다.
이 작업은 조회 화면을 하나로 모으는 것에 그치지 않았습니다.
비슷한 목적의 시스템을 여러 곳에서 운영하면 각 시스템의 자원과 상태를 관리해야 합니다. 서비스를 관찰하기 위한 시스템 자체가 또 하나의 운영 부담이 될 수 있습니다.
그루핀에서는 분산된 Prometheus와 Elasticsearch 구성을 통합·정리하면서 인프라 유지 비용과 메모리 리소스를 줄일 수 있었습니다.
다만 이 결과를 특정 스택이 언제나 더 가볍다는 의미로 보지는 않습니다. 저희 환경에서는 중복되거나 분산된 구성을 정리한 것이 비용 개선으로 이어졌습니다.
도구 교체보다 조회 흐름의 변화가 중요했다
이번 작업에서 제가 중요하게 본 변화는 도구 이름보다 운영자가 문제를 확인하는 흐름이었습니다.
어떤 지표가 이상한지 확인한 다음 관련 로그를 찾으려 할 때, 새로운 화면과 검색 방식을 계속 떠올려야 한다면 조사 과정이 끊기기 쉽습니다.
Grafana 중심으로 조회 환경을 정리하면서 이런 전환을 줄이는 방향으로 개선할 수 있었습니다.
그렇다고 모든 장애 원인이 한 화면에서 곧바로 드러난 것은 아닙니다. 모니터링 통합은 문제를 자동으로 해결하는 작업이라기보다, 문제를 조사할 때 필요한 정보를 더 일관된 경로로 찾아갈 수 있게 만드는 작업에 가까웠습니다.
다음에는 무엇을 더 확인할까?
모니터링 환경을 다시 통합한다면, 조회 편의성 외에도 다음 항목을 더 명확하게 확인하려고 합니다.
- 중앙 모니터링 시스템에 문제가 생겼을 때의 영향 범위
- 네트워크 단절이나 수집 지연 상황에서의 데이터 처리
- 서비스와 환경을 구분하는 조회 기준
- 데이터 보관 기간과 저장 비용
- 통합 후에도 실제로 사용되는 대시보드와 알림
시스템을 중앙화하면 관리할 대상은 줄일 수 있지만, 중앙 시스템의 중요도는 높아집니다. 그래서 통합 이후에는 그 시스템 자체를 어떻게 안정적으로 운영할지도 함께 고민해야 한다고 생각합니다.
마치며
이번 경험을 통해 모니터링 환경의 완성도를 도구의 개수로 판단하기 어렵다는 것을 배웠습니다.
이미 여러 도구가 운영되고 있어도, 필요한 정보를 찾기 위해 많은 맥락을 알아야 한다면 개선할 여지가 있었습니다.
제게 모니터링 통합은 새로운 도구를 추가하는 작업보다, 기존 환경에서 필요한 기능을 확인하고 수집·저장·조회 경로를 정리하는 작업이었습니다.
좋은 모니터링 환경은 많은 화면을 제공하는 환경보다, 문제가 생겼을 때 다음에 무엇을 확인할지 알 수 있는 환경에 가깝다고 생각합니다.