🚀 요약
SUMMARY
관측가능성 스택을 ELK → LGTM → SigNoz로 두 번 갈아탔다. 최종적으로는 라이선스 리스크와 통합 관리 편의성을 이유로 SigNoz 단일 스택에 정착했다.
💡 개요
관측가능성(Observability)은 시스템 밖에서 관찰되는 신호만으로 내부 상태를 유추할 수 있는 능력을 말한다. 서비스를 잘게 쪼갤수록 “지금 어디서 뭐가 터졌는지” 파악하기 어려워지는데, 그걸 되찾아주는 게 관측가능성이다.
흔히 세 가지 데이터를 본다.
- 로그(Log): 이벤트가 날 때마다 남는 텍스트 기록
- 추적(Trace): 요청이 서비스 사이를 어떤 경로로, 얼마나 걸려 지나갔는지
- 메트릭(Metric): CPU, 메모리, 요청 지연 같은 수치
📋 선정 배경
사내 쿠버네티스 클러스터를 들이면서 마이크로서비스로 넘어갈 계획을 세웠는데, 그러면서 관측가능성 스택이 필요해졌다. 모놀리식일 땐 서버 하나의 로그와 메트릭만 보면 됐지만, 분산 환경에선 서비스 사이의 상호작용을 추적하고 전체 상태를 볼 도구가 있어야 했다.
찾던 조건은 이랬다.
- OpenTelemetry 표준 지원
- 온프레미스에서 안정적으로 굴러갈 것
- 라이선스 이슈가 없는 오픈소스
- 로그·메트릭·트레이스를 한곳에서 관리
- 리소스를 너무 잡아먹지 않을 것
INFO
OpenTelemetry(OTel)는 원격 측정 데이터를 표준화된 방식으로 생성·수집·처리·내보내기 위한 오픈소스 프레임워크다. 특정 벤더에 묶이지 않는다는 점 때문에 요즘 관측가능성 쪽에선 사실상 기본으로 깔고 간다.
📊 비교
세 번의 구성을 거쳤다. 각 단계의 파이프라인과 갈아탄 이유는 이렇다.
| 구분 | 최초 구성 (분산 스택) | 변경 1 (LGTM 스택) | 변경 2 (SigNoz) |
|---|---|---|---|
| 로그 | Fluentd → OTel Collector → Elasticsearch → Kibana | OTel Collector → Loki → Grafana | OTel Collector → ClickHouse → SigNoz |
| 추적 | OTel SDK → OTel Collector → Jaeger → Elasticsearch → Jaeger UI | OTel SDK → OTel Collector → Tempo → Grafana | OTel SDK → OTel Collector → ClickHouse → SigNoz |
| 메트릭 | Exporter → OTel Collector → Prometheus → Grafana | Exporter → OTel Collector → Prometheus → Grafana | Exporter → OTel Collector → ClickHouse → SigNoz |
| 장점 | 검증된 안정성, 풍부한 생태계, 강력한 검색 | 단일 UI 통합, Grafana의 시각화, 상대적으로 가벼움 | 완전한 통합, 단일 DB, 라이선스 이슈 없음, 준수한 성능 |
| 단점 | 복잡한 아키텍처, 높은 리소스, 관리 포인트 분산 | AGPL-3.0 라이선스 이슈, 여전히 구성이 복잡 | 상대적으로 새 솔루션, 커뮤니티가 얇음 |
| 변경 사유 | - | Grafana 한곳에서 다 보도록 구조 개선 | AGPL-3.0이 솔루션 패키징에 걸릴 수 있다고 판단 |
각 스택별 상세
분산 스택 최초 구성
로그는 ELK(Elasticsearch, Logstash, Kibana), 추적은 Jaeger, 메트릭은 Prometheus + Grafana. 데이터 유형마다 각각 다른 도구를 붙인 전통적인 조합이다. 하나하나는 오래 검증된 것들이라 안정성은 확실했다. 문제는 서로 다른 도구를 연동해야 하는 복잡함과, Elasticsearch 클러스터가 잡아먹는 메모리였다. 관리 포인트가 셋으로 흩어져 있다는 것도 부담이었다.
LGTM 스택 (Loki, Grafana, Tempo, Mimir)
Grafana Labs의 통합 스택으로 갈아탔다. 로그든 메트릭이든 트레이스든 Grafana 하나에서 다 볼 수 있다는 게 컸다. 각 컴포넌트가 용도별로 특화돼 있어 분산 스택보다 가벼웠다. 다만 Loki·Tempo·Mimir가 AGPL-3.0이라는 점이 걸렸다. 이때는 “일단 쓰자”였지만, 상용화를 생각하면 두고두고 마음에 남는 지점이었다.
SigNoz 기반 최종 구성
ClickHouse를 백엔드로 쓰는 통합 플랫폼이다. 모든 관측가능성 데이터를 단일 DB에 넣고 하나의 UI로 본다. 솔루션 하나로 요구사항이 다 덮이니 구성이 단순해졌고, ClickHouse 덕에 분석 성능도 괜찮았다. 결정적으로 MIT 라이선스라 상용화 제약이 없다.
NOTE
ClickHouse는 OLAP(Online Analytical Processing)에 최적화된 컬럼형 데이터베이스다. 대용량 집계·분석이 빠르고, 관측가능성 같은 시계열 데이터를 다루기에 잘 맞는다.
✅ 선정 사유
SigNoz로 정한 이유를 추리면 이렇다.
- 라이선스: MIT라 상용 솔루션에 얹어도 걸리는 게 없다. LGTM에서 넘어온 가장 큰 이유다. AGPL-3.0은 네트워크로 제공만 해도 소스 공개 의무가 생길 수 있어, 상용 서비스라면 무시하기 어려운 리스크였다.
- 단순함: 하나로 로그·메트릭·트레이스를 다 덮는다. 관리 포인트가 줄었다.
- OpenTelemetry 네이티브: OTel 표준을 그대로 받아준다.
- 비용: 단일 스택이라 인프라 비용과 운영 복잡도가 함께 내려갔다.
SigNoz로 굴린 지 6개월쯤 됐는데, 지금까지는 안정적이다. 단일 UI에서 셋을 한 번에 훑을 수 있으니 장애가 나도 원인을 찾는 시간이 확실히 줄었다.