DevOps용 LGTM 스택 도입기

AWS EKS 위에서 MSA로 운영되는 서비스가 수십 개로 늘어나자, 문제 지점을 찾는 데 드는 시간이 급격히 길어졌다. 여러 대시보드와 환경별 모니터링 체계를 오가야 했고, 운영비용도 함께 커졌다.

이 문제를 풀기 위해 Kubernetes Native하고 Object Storage를 지원하는 오픈소스 관측 스택을 찾았고, 최종적으로 LGTM을 선택했다. 목표는 메트릭, 로그, 트레이스를 한 화면에서 연결해 보고, 환경이 늘어나도 운영 복잡도를 키우지 않는 것이었다.

Metrics는 먼저 CloudWatch에서 Prometheus로 옮겼다. 시스템 가시성은 좋아졌지만, 환경이 늘수록 대시보드와 알람 설정을 반복해야 했고, 메트릭이 많아질수록 Prometheus의 리소스 사용량도 커졌다. 결국 Prometheus Agent 모드로 전환하고 Remote Write로 Mimir에 보내는 구조를 택했다.

Mimir를 선택한 이유는 다음과 같다.

• Prometheus 100% 호환: Remote Write, PromQL, alert까지 그대로 활용 가능
• 수평 확장: 클러스터 아키텍처로 확장성 확보
• Object Storage 지원: S3, GCS, Blob 사용 가능
• 고가용성: 복제 구조 지원
• 멀티 테넌시: 테넌시별 데이터 격리 가능

환경 구분은 external_label로 처리해, 하나의 대시보드와 쿼리를 여러 환경에 그대로 적용할 수 있게 했다. 예를 들어 node_memory_MemTotal_bytes{env="$Environment"}처럼 label만 바꿔 공통 대시보드를 유지한다.

Logs는 기존 EFK에서 Loki로 전환했다. 대부분의 사용이 로그 검색과 일부 알람, 대시보드였기 때문에 PoC와 VoC를 거쳐 UX 손실이 없다고 판단했다. Loki는 메타데이터만 인덱싱해 저장 효율이 좋고, Object Storage를 써서 비용과 용량 관리 부담이 적다.

Loki의 핵심 이점은 다음과 같다.

• Object Storage 지원
• Live tail로 실시간 로그 추적 가능
• Grafana와 자연스럽게 연동되어 메트릭·로그·추적 간 이동이 쉬움
• 멀티 테넌시 지원

로그 라벨 설계가 성능에 중요해서 Loki 관련 label best practice도 함께 참고했다. 또 Loki에 쌓인 로그를 바로 대시보드로 그리기보다, Recording Rule로 시계열화해 Mimir에 저장한 뒤 대시보드를 구성해 성능 문제를 피했다.

Traces는 Istio 도입 이후 수집을 시작했다. Jaeger와 Zipkin도 검토했지만, 더 가벼운 Object Storage 기반 저장소를 지원하는 Tempo를 선택했다. Istio 게이트웨이만으로는 전체 호출 흐름을 완전히 추적할 수 없어서, 서비스 레벨에서 트레이스 생성과 전달도 함께 붙였다.

백엔드는 대부분 Spring Boot로 구성돼 있어 2.x에서는 spring-cloud-sleuth, 3.x에서는 micrometer tracing을 사용했다. 여기에 OpenTelemetry Collector를 넣어 불필요한 데이터를 걸러내고 필요한 attribute를 주입했으며, Loki와 연계해 Trace -> Log, Log -> Trace 이동도 가능하게 만들었다.

결국 LGTM 도입의 핵심은 단순한 도구 교체가 아니라, 서비스 토폴로지, RED 지표, 로그, 트레이스를 하나의 운영 경험으로 묶는 데 있었다. 환경이 늘어도 반복 작업을 줄이고, 장애 원인을 더 빠르게 찾는 구조를 만들었다는 점이 가장 큰 성과다.