이 글은 CloudNet@팀의 AWS EKS Workshop Study(AEWS) 3기 스터디 내용을 바탕으로 작성되었습니다.
AEWS는 CloudNet@의 '가시다'님께서 진행하는 스터디로, EKS를 학습하는 과정입니다.
EKS를 깊이 있게 이해할 기회를 주시고, 소중한 지식을 나눠주시는 가시다님께 다시 한번 감사드립니다.
이 글이 EKS를 학습하는 분들께 도움이 되길 바랍니다.
1. OpenTelemetry(OTel)란?
OpenTelemetry(OTel)는 Observability(관측성) 프레임워크 및 툴킷으로, 추적(Traces), 메트릭(Metrics), 로그(Logs) 등 원격 측정 데이터를 생성하고 관리하도록 설계되었습니다.
🔗 공식 문서: OpenTelemetry Docs
1.1 OpenTelemetry의 특징
- 특정 공급업체나 도구에 종속되지 않음
→ Prometheus, Jaeger, Zipkin과 같은 오픈소스 도구뿐만 아니라, Datadog, New Relic, AWS X-Ray, Azure Monitor 등의 상용 제품과도 통합 가능 - 언어, 인프라, 런타임 환경과 무관하게 계측 가능
→ 다양한 애플리케이션 및 시스템에서 활용할 수 있음 - 원격 측정 데이터를 생성, 수집, 관리, 내보내기(exporting)에 중점
→ 저장 및 시각화는 별도의 도구(Jaeger, Prometheus, Tempo 등)에서 담당
2. OpenTelemetry의 주요 개념
OpenTelemetry의 핵심 요소는 다음과 같습니다.
2.1 Signals(신호)
Observability 데이터는 다음과 같은 4가지 주요 신호(Signals)로 구성됩니다.
🔗 Signals 관련 문서: Docs
- Traces (추적):
- 분산 시스템에서 요청의 흐름을 추적하기 위한 데이터
- 트랜잭션 단위로 구성되며, 여러 개의 스팬(Span)으로 이루어짐
- Metrics (메트릭):
- 성능과 상태를 측정하는 정량적 데이터 (예: CPU 사용률, 응답 시간, 요청 수 등)
- Logs (로그):
- 이벤트와 관련된 텍스트 기반 기록 (예: 오류 메시지, 디버깅 정보 등)
- Baggage (전역 컨텍스트 데이터):
- 다수의 스팬(Span)에 전달 및 공유되는 데이터
- HTTP 헤더를 통해 전달됨
2.2 Instrumentation(계측)
애플리케이션 코드에 Observability 기능을 추가하는 방법을 의미합니다.
🔗 Instrumentation 관련 문서: Docs
OpenTelemetry에서는 3가지 방식으로 계측을 지원합니다.
- Zero-code Instrumentation:
- 애플리케이션의 코드 수정 없이 계측하는 방식
- 자동 계측(Auto Instrumentation)을 활용
- Code-based Instrumentation:
- 개발자가 직접 코드를 추가하여 계측하는 방식
@WithSpan등의 애너테이션을 활용하여 수동 계측 가능 (예: Java, Python 등)
- Instrumentation Libraries:
- OpenTelemetry에서 제공하는 다양한 라이브러리를 활용
2.3 Components(구성 요소)
OpenTelemetry의 주요 구성 요소는 다음과 같습니다.
🔗 Components 관련 문서: Docs
- API
- 애플리케이션에서 OpenTelemetry를 사용할 수 있도록 제공되는 인터페이스
- 개발자는 OpenTelemetry API를 활용하여 원격 측정 데이터를 생성
- SDK
- API의 기능을 구현하며, 데이터 수집, 처리 및 내보내기 기능을 제공
- Collector
- 원격 측정 데이터를 수집하고 다양한 백엔드로 전송하는 중앙 허브 역할
- 예: Prometheus, Jaeger, Datadog, AWS X-Ray, Elastic APM 등과 연동 가능
- Exporters
- 수집된 데이터를 외부 백엔드 시스템으로 내보내는 역할
- 예: PrometheusExporter, JaegerExporter, LoggingExporter 등
3. Distributed Tracing(분산 추적) 개념
🔗 Distributed Tracing 관련 문서: Docs
3.1 Distributed Tracing이란?
- 클라우드 네이티브 애플리케이션은 여러 마이크로서비스로 구성되며, 요청이 여러 애플리케이션을 거쳐 처리됨
- 이러한 환경에서는 요청이 어디에서 지연이 발생하는지, 오류가 어디에서 발생했는지 추적하기 어려움
- 이를 해결하기 위해 각 요청에 대한 식별자(Correlation ID)를 생성하여, 애플리케이션 간 요청 흐름을 추적
3.2 분산 추적의 핵심 개념
- Trace(추적)
- 하나의 트랜잭션 요청에 대한 전체 흐름을 추적하는 단위
Trace ID를 통해 고유하게 식별됨- 하나의 Trace는 여러 개의 Span으로 구성됨
- Span(스팬)
- 요청 처리의 각 단계를 나타내는 단위
- 시작 및 종료 시간(Timestamp) 기록
- Trace ID + Span ID 조합으로 고유하게 식별
- Tag(태그)
- 추가적인 메타데이터 (예: 요청 URI, 사용자 ID, 애플리케이션 버전 등)
3.3 OpenTelemetry를 활용한 분산 추적
- 애플리케이션은 요청을 받을 때 Trace ID와 Span ID를 생성
- 이를 HTTP 요청 헤더에 포함하여 다른 서비스에 전달
- OpenTelemetry SDK를 사용하여 Span을 자동으로 생성하고 수집
- 수집된 데이터를 Jaeger, Tempo, Zipkin 등의 트레이싱 백엔드로 전송하여 시각화
4. OpenTelemetry의 활용
4.1 OpenTelemetry와 분산 추적 백엔드
OpenTelemetry는 자체적으로 데이터를 저장하지 않으며, 분산 추적 데이터를 수집하고 외부 도구로 전달합니다.
대표적인 백엔드 도구는 다음과 같습니다.
| 백엔드 도구 | 설명 |
|---|---|
| Jaeger | CNCF 프로젝트로, 가장 널리 사용되는 분산 추적 시스템 |
| Tempo | Grafana Labs에서 제공하는 트레이싱 스토리지 |
| Zipkin | OpenZipkin에서 제공하는 경량 추적 시스템 |
| AWS X-Ray | AWS에서 제공하는 클라우드 기반 분산 추적 서비스 |
| Elastic APM | Elasticsearch 기반의 분산 추적 및 모니터링 솔루션 |
4.2 OpenTelemetry와 Prometheus의 차이점
| 비교 항목 | OpenTelemetry | Prometheus |
|---|---|---|
| 주요 목적 | 분산 추적(Tracing) + 메트릭 + 로그 관리 | 메트릭 수집 및 시각화 |
| 데이터 수집 방식 | 애플리케이션에서 직접 푸시 (Push 방식) | Prometheus가 데이터를 스크래핑 (Pull 방식) |
| 저장 방식 | 데이터를 저장하지 않으며, 백엔드 시스템으로 전송 | 자체 저장소에서 메트릭을 저장 |
| 주요 백엔드 | Jaeger, Zipkin, Tempo, Elastic APM 등 | Prometheus 자체 저장소, Grafana 연동 |
| 주요 활용 사례 | 마이크로서비스 트랜잭션 추적 | 인프라 및 애플리케이션 성능 모니터링 |
