MSA(Microservices Architecture) 기반 서비스가 증가하면서 서비스 간 의존성과 상호작용이 복잡해지고 있다.
예를 들어 사용자가 주문 버튼을 누르면
유저서비스 → 상품서비스 → 재고서비스 → 결제서비스 → 주문서비스 → 알림서비스...
이렇게 엮여있다보니, 주문이 안들어왔을 경우에, 어디서 막혔는지 찾는게 쉽지 않게 되어버렸다.
클라우드 환경에서도 마찬가지다.
클라우드 환경에서도 가끔 알 수 없는 문제가 발생한다.
예를 들어 트래픽이 몰려 자동 스케일링으로 인해 잠깐 서비스에 문제가 발생 한다던가, 네트워크가 갑자기 느려져 타임아웃이 발생한다던가 말이다.
예전의 모니터링 툴에서는 CPU나 메모리만 보면 정상처럼 보이기 때문에 잡아내는게 어렵다.
이로 인해 Observability (서비스 관측성)이 중요해지고 있다.
단순히 "서버가 살아있나" 를 보기보다 내 요청이 어디로 가서 얼마나 걸리고 어디서 막히는지 실시간으로 추적이 필요해졌기 때문이다.
오늘은 Observability를 위한 다양한 오픈 소스 중에 CNCF(Cloud Native Computing Foundation)의 프로젝트인 OpenTelemetry에 대해서 공부해보고자 한다.
OpenTelemetry란 무엇일까?
OpenTelemetry는 줄여서 OTel이라 표기하기때문에 지금부터 OTel로 표현하도록 하겠다.
OTel은 Trace, Metrics, Logs 이 3가지 핵심 관찰성 데이터를 생성하고 수집하고 관리하는 통합 표준이라고 볼 수 있다.
Metrics: 시간에 따른 숫자 측정값(CPU 사용률, 응답 시간, 요청 수)
Log: 이벤트 기록(에러 메세지, 디버그 정보 등). 디버깅에 사용
Traces: 분산 시스템에서 요청의 전체 경로 추적. 호출 관계와 성능 병목 파악 가능다만, OTel 자체에서는 데이터 저장이나 쿼리 기능을 제공하지 않는다.
대신 표준화된 방식으로 Telemetry 데이터를 생성하고 수집한 뒤, 다양한 백엔드 시스템으로 전송하는 역할만 담당하고 있다.
-
상용 서비스의 경우:
Dataodg,New Relic,Groundcover와 같은 SaaS 플랫폼 -
오픈소스 백엔드의 경우:
Grafana,Prometheus,Jaeger등의 자체 호스팅 솔루션
Grafana 대시보드라면 많이들 들어봤을 것이다.
Grafana에서 OTel로 수집한 데이터를 활용해 실시간 모니터링 대시보드를 구축할 수 있다.
결국, OTel은 어떻게 관찰성 데이터를 만들고 보낼 것인가에 대한 표준이지 어디에 저장하고 어떻게 볼 것인가는 OTel의 역할이 아니라고 볼 수 있다.
OpenTelemetry 아키텍처 및 구성 요소
OTel은 개발 언어별로 SDK, 데이터 변환 수집, 변환 및 데이터 내보내기 등 여러 구성 요소로 구성된다.
SDK (Software Development Kit)
개발자가 애플리케이션에 관찰성 기능을 쉽게 추가할 수 있도록 제공되는 라이브러리 세트
Java, Python, Go, JavaScript, PHP 등 주요 언어를 지원한다.
https://opentelemetry.io/docs/languages/
- API :
- 텔레메트리 데이터 생성을 위한 인터페이스
- 언어별로 제공
- SDK :
- 코드에서 자동으로 메트릭, 로그, 트레이스 생성
- HTTP 요청, 데이터베이스 쿼리, 외부 API 호출 등을 자동 추적
- 수동으로 커스텀 매트릭 가능
- 예) Otel SDK 추가 후 설정 코드 추가 -> Otel Collector가 데이터 수집
- Collector :
- 텔레메트리 데이터 수신, 처리, 전송
- 다양한 백엔드로 데이터 라우팅 가능
OpenTelemetry Collector
Otel Collector는 측정 데이터인 Metrics, Traces, Logs를 수집하고 처리해서 여러 백엔드로 동시에 전송 가능하다.
콜렉터가 없다면 각각의 백엔드 서비스마다 다른 설정을 해야하지만, Collector를 사용하면 각 백엔드 앱마다 설정을 따로 하지 않아도 된다.
Collector 없이:
앱1 → Prometheus
앱2 → Jaeger
앱3 → Datadog
각각 다른 설정, 복잡함
Collector 있으면:
앱1,2,3 → OTel Collector → Prometheus
→ Jaeger
→ DatadogOpenTelemetry Collector의 구성
OTel Collector의 경우 수집 (receive), 처리 (process), 전송 (export)로 구성된다.
- Receiver(수집):
- 여러 애플리케이션에서 보내는 메트릭, 로그, 트레이스를 수신 받는다.
- 하나 이상의 수집기를 구성할 수 있다.
- Processor(처리):
- 수신한 데이터를 백엔드로 보내기 전에 데이터를 필터링, 변환, 샘플링한다.
- 민감한 정보를 제거할 수 있고
- 데이터 포맷을 변환할 수 있다.
- Exporter(전송):
- 여러 백엔드로 동시 전송이 가능하다.
이 OTel Collector의 경우 yaml로 설정할 수 있는데 아래의 예와 같다.
# collector-config.yaml
receivers:
# OTLP 프로토콜로 데이터 수신
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
http:
endpoint: 0.0.0.0:4318
# Prometheus 메트릭 스크래핑
prometheus:
config:
scrape_configs:
- job_name: 'my-app'
static_configs:
- targets: ['localhost:8080']
processors:
# 샘플링 (10%만 저장)
probabilistic_sampler:
sampling_percentage: 10.0
# 메모리 제한
memory_limiter:
limit_mib: 400
spike_limit_mib: 100
# 배치 처리
batch:
timeout: 1s
send_batch_size: 1024
# 리소스 속성 추가
resource:
attributes:
- key: environment
value: production
action: upsert
exporters:
# Jaeger로 트레이스 전송
jaeger:
endpoint: jaeger-collector:14250
tls:
insecure: true
# Prometheus로 메트릭 전송
prometheus:
endpoint: "0.0.0.0:8889"
# Datadog으로 전송
datadog:
api:
key: "${DD_API_KEY}"
site: datadoghq.com
service:
pipelines:
# 트레이스 파이프라인
traces:
receivers: [otlp]
processors: [memory_limiter, probabilistic_sampler, batch]
exporters: [jaeger, datadog]
# 메트릭 파이프라인
metrics:
receivers: [otlp, prometheus]
processors: [memory_limiter, resource, batch]
exporters: [prometheus, datadog]
# 로그 파이프라인
logs:
receivers: [otlp]
processors: [memory_limiter, batch]
exporters: [datadog]모니터링 앱에서 OpenTelemetry를 사용하는 이유
지금까지 글을 읽어보면 단번에 대답할 수 있을 것이다.
우선 각 백엔드별로 개별 설정 파일이 필요하다.
버전 업데이트도 따로따로할테고, 문제가 생기면 어느 에이전트 때문인지 알기 어렵다.
만약 Datadog을 쓰다가 New Replic으로 바꾸게 되어도 코드를 전체 다 다시 작성해야할 것이다.
그러나 Otel을 사용하면, Collector의 설정값만 바꾸면 되기 때문에 데이터 수집은 OTel에 맡기고, 데이터 분석과 시각회에 집중할 수 있어 더 나은 모니터링 앱을 만들 수 있을 것이다.
