표준으로 마이크로서비스 Observability 구축하기

Kubernetes 환경에서 서비스가 늘어나면서, 분산된 모니터링 도구를 통합하고 문제 추적을 단순화할 필요가 커졌다. 그 해법으로 OpenTelemetry와 SigNoz를 조합해 Metric, Log, Trace(MLT) 를 한 흐름으로 다루는 관측성 체계를 구축했다.

기존 환경의 문제는 도구가 흩어져 있고, 각각 따로 학습하고 운영해야 하며, 장애 원인 추적에도 시간이 많이 든다는 점이었다. 표준화된 텔레메트리 수집 체계가 있으면 벤더 종속을 줄이고, 다양한 백엔드와 연결하면서도 운영 비용을 낮출 수 있다.

OpenTelemetry를 선택한 이유는 관측성의 핵심 신호를 통합하고, Context Propagation으로 서비스 간 상관관계를 이어줄 수 있기 때문이다. 컨텍스트에는 스팬 ID와 트레이스 ID가 담기며, 전파는 주로 자동 계측 라이브러리가 처리하고 필요하면 Propagators API로 수동 제어할 수 있다. 기본 전파자는 W3C TraceContext 기반 HTTP 헤더를 사용한다.

수집 계층은 OpenTelemetry Collector로 구성했다. Collector는 벤더 중립적으로 데이터를 Receive -> Process -> Export 하며, 하나의 Collector로 여러 Agent를 따로 운영할 필요를 줄여준다.

• Receivers: OTLP 같은 네트워크 입력을 받거나 스크래핑으로 데이터를 수집
• Processors: memory_limiter, filter, metricspan, batch 등으로 데이터 가공
• Exporters: OTLP, Kafka, Elasticsearch 등 목적지별로 전송

파이프라인 구성에서는 순서가 중요했다. 먼저 memory_limiter로 Collector 메모리를 제어하고, filter로 불필요한 데이터를 줄인 뒤, metricspan으로 Span과 Metric을 연결하고, 마지막에 batch로 묶어서 전송 효율을 높였다. 동일한 수신기를 여러 파이프라인에 fan-out 할 수도 있어 유연하게 설계할 수 있다.

애플리케이션 계측은 Auto-Instrumentation으로 적용했다. CertManager와 OpenTelemetry Operator를 설치한 뒤 Instrumentation CR을 만들고, Deployment의 template.metadata.annotations에 언어별 inject 설정을 추가했다. 예를 들어 Java는 instrumentation.opentelemetry.io/inject-java: "true"를 사용하고, OTEL_SERVICE_NAME, OTEL_TRACES_EXPORTER, OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_EXPORTER_OTLP_PROTOCOL 같은 환경변수로 동작을 맞췄다.

초기에는 LGTM 같은 오픈소스 조합도 검토했지만, 각 구성요소를 따로 배워야 하고 Helm Chart도 독립적이라 복잡성이 커진다고 판단했다. 대신 SigNoz를 선택해 하나의 백엔드로 통합했고, ClickHouse 기반 처리와 직관적인 UI, OTel 연동성, 활발한 커뮤니티를 장점으로 봤다.

결국 목표는 여러 모니터링 도구를 흩어 쓰는 대신, OpenTelemetry + SigNoz 조합으로 점진적으로 수렴하는 것이었다. 아직 로그와 트레이스 보관 전략, Collector와 ClickHouse 운영 고도화 같은 과제는 남아 있지만, 운영 편의성과 유지보수 효율은 분명히 개선됐다.