해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 29 - A Practical introduction to OpenTelemetry tracing
1. 옵저버빌리티 (Observability)
최근 마이크로서비스 아키텍처 (MSA)와 같은 분산 시스템이 보편화되면서, 시스템의 동작을 한눈에 파악하고 문제를 추적하는 '옵저버빌리티 (Observability)'의 중요성이 커지고 있다.
옵저버빌리티 (Observability)과 모니터링은 모두 유사한 데이터 (메트릭, 트레이스 및 로그) 에 의존하지만 옵저버빌리티는 사전 예방을 허용하는 반면 모니터링은 반응적이다.
모니터링: 애플리케이션의 상태와 성능을 이해하기 위해 대시보드 및 경고와 함께 미리 구성된 원격 측정 데이터를 사용하는 프로세스
옵저버빌리티: 사용 가능한 모든 출력을 실시간으로 분석하여 진화하는 시스템의 내부 상태를 이해하는 능력
모니터링은 옵저버빌리티의 하위집합!
옵저버빌리티를 구성하는 세 가지 요소는 '메트릭 (Metric), 로깅 (Loggin), 트레이싱 (Tracing)' 이다.
- 메트릭 (Metric) : 숫자 값을 사용하여 시스템 애플리케이션 성능 및 리소스 사용률을 나타냄.
해당 데이터를 그래프 형식으로 입력하여 시간 경과에 따른 시스템 성능을 확인할 수 있으며, DevOps 팀은 게이지, 델타 및 누적 지표를 사용함.
-
로깅 (Loggin) : 소프트웨어에서 발생하는 이벤트를 기록함.
이러한 이벤트는 개발자가 오류가 발생한 위치를 이해하고 실행 가능한 통찰력을 얻는 데 도움이 되며, 메트릭은 일반적으로 문제의 첫 징후를 볼 수 있는 곳이지만 로그는 문제가 작업에 미치는 영향에 대한 추가 컨텍스트를 제공함. -
트레이싱 or 추적 (Tracing) : 옵저버빌리티 시스템 전체에서 작업이 한 노드에서 다른 노드로 이동하는 방식을 보여줌.
이를 통해 특정 사용자 작업 또는 API 호출에 대한 문제 해결을 맥락화할 수 있음.
해당 프레젠테이션에서는 특히 분산 시스템의 문제를 해결하는 데 통찰력을 제공하는 OpenTelemetry 트레이싱에 대하여 설명한다.
2. 트레이싱 (Tracing)
분산 시스템에서는 하나의 비즈니스 요청을 처리하기 위해 수많은 Component (서비스)가 함께 작동한다.
만약 이 과정 중 어딘가에서 문제가 발생한다면, 어떤 Component가 원인인지 파악하기 어렵다.
Tracing은 해당 문제를 해결하기 위한 기술로, '비즈니스 요청이 네트워크를 통해 여러 Component를 거치는 전 과정을 추적하는 기술과 도구의 집합' 이다.
이를 통해 전체 요청의 흐름을 시각화하고, 병목 지점이나 오류가 발생한 지점을 찾아낼 수 있다.
과거에는 Zipkin, Jaeger, OpenTracing 등 여러 트레이싱 도구들이 각자의 독자적인 인터페이스와 구현을 가지고 있었다. 이는 도구 간 호환성 문제를 야기시키게 되었다.
이러한 파편화를 해결하기 위해 'W3C 트레이스 컨텍스트 (Trace Context)'라는 표준이 등장하였으며, OpenTelemetry는 해당 표준을 기반으로 한다.
트레이싱을 이해하기 위해서는 두가지 개념을 알아야 한다.
-
트레이스 (Trace): 비즈니스 트랙잭션의 전체 여정
요청이 시스템에 들어와서, 여러 Component를 거치고, 다시 응답이 나가기까지의 모든 과정을 하나의 '트레이스' 라고 부름. -
스팬 (Span): 트레이스 (전체 여정)를 구성하는 개별 작업 단위
단일 Component 내에서 실행되는 특정 작업 (ex. API 호출, DB 쿼리)를 하나의 '스팬' 이라고 함.
이 스팬 (Span)들은 부모-자식 관계로 연결된다.
첫 번째 Component (부모)가 Span ID를 생성하면, 그다음 자식 Component는 부모의 Span ID를 참조하여 자신의 Span ID를 생성한다. 해당 연결 관계를 통해 전체 요청의 Trace를 재구성할 수 있다.
3. OpenTelemetry(OTel)
OpenTelemetry(OTel)는 이러한 옵저버빌리티를 구현하기 위한 도구와 표준의 집합이다.
-
표준 구현체: OTel은 W3C 트레이스 컨텍스트 표준을 따르는 구현체
-
프로젝트 통합: 과거 OpenTracing과 OpenCensus라는 두 경쟁 프로젝트가 더 나은 표준을 만들기 위해 하나로 통합된 사례임.
-
CNCF 프로젝트: 현재 CNCF (Cloud Native Computing Foundation)의 프로젝트로 등록되어 있어, 장기적인 지원과 발전을 기대할 수 있음.
-
확장성: W3C 표준이 주로 웹 (HTTP)에 중점을 둔다면, OTel은 Kafka나 다른 메시징 시스템 등 웹이 아닌 다양한 컴포넌트에 걸친 트랜잭션까지 추적할 수 있도록 확장되었음.
3-1. OTel 아키텍처의 작동 방식
OTel의 아키텍처는 'Client-Side, Collector, Backend'로 구성된다.
-
애플리케이션 (Client-Side) : 트레이싱 대상이 되는 각 컴포넌트 (서비스)
-
OTel 컬렉터 (Collector) : 애플리케이션에서 보낸 트레이스 데이터를 수집하고 저장하는 역할 (OTel 컬렉터 자체는 데이터를 특정 형식으로 저장만 하고 데이터를 검색하거나 시각화하는 UI를 제공하지 않음.)
-
백엔드 (Backend) : 컬렉터에서 저장된 데이터를 검색하고 시각화 하는 도구
핵심은 Jaeger나 Zipkin 같은 기존 트레이싱 도구들이 OTel 데이터 형식을 수용하도록 인터페이스를 추가했다는 점이다.
즉, 애플리케이션에서는 OTel 표준에 맞추어 데이터를 전송하고, 해당 데이터를 Jaeger나 Zipkin의 컬렉터가 받아서 처리할 수 있다. 이미 Jaeger 등을 사용하고 있었다면, 데이터 형식과 포트만 변경하여 OTel로 쉽게 이전할 수 있다.
3-2. OTel 적용 방법:
OTel을 실제 애플리케이션에 적용할 수 있는 방법은 2가지가 존재한다.
-
자동 계측 (Auto Instrumentation)
-
작동 원리: JVM (Java), Python, Node.js 등 런타임이 있는 환경에서만 가능하다.
런타임 에이전트가 애플리케이션의 코드를 수정하지 않고도 메서드 진입, 종료, 외부 호출 등을 자동으로 감지하여 트레이스 데이터를 생성한다. -
장점: 애플리케이션 코드가 OTel에 전혀 종속되지 않음 (No Coupling). 개발자는 트레이싱 관련 코드를 한 줄도 작성할 필요가 없음.
-
권장: 분산 시스템을 사용한다면 당장 적용하는 것이 좋다.
-
-
수동 계측 (Manual Instrumentation)
-
자동 계측으로 부족한, 더 세밀한 트레이싱이 필요할 때 사용함.
-
작동 원리: Java, Python, Rust 등 사용 중인 기술 스택에 맞는 OTel 라이브러리를 애플리케이션 코드에 직접 추가 (의존성 추가)
-
구현: 개발자가 코드 내에서 직접 API를 호출하거나 어노테이션(@)을 사용하여 특정 메서드나 작업 단위를 스팬으로 명시적으로 지정
-
장점: 비즈니스 로직상 중요한 특정 부분이나 내부 변수 값 등을 스팬에 담아 더 자세히 추적할 수 있음.
-
즉, OpenTelemetry (OTel) 는 분산 시스템의 복잡성을 해결하기 위한 표준이자 도구이며, W3C 표준을 기반으로 한 Trace와 Span 개념을 통해 전체 요청 흐름을 파악할 수 있게 해준다.
특히, 자동 계측 기능을 활용하면, 코드 변경 없이도 즉각적인 시스템 통찰력을 얻을 수 있으며, 필요에 따라 수동 계측을 통해 더 깊이 있는 분석이 가능하다.
분산 시스템의 안정성과 성능을 높이고 싶다면 OpenTelemetry 도입을 고려해보자!
4. 정리
OpenTelemetry(OTel)는 분산 시스템의 옵저버빌리티(Observability)를 구현하기 위한 표준화된 도구이자 프레임워크이다.
W3C 트레이스 컨텍스트 표준을 기반으로 하며, 전체 요청 여정인 트레이스(Trace)와 개별 작업 단위인 스팬(Span) 개념을 사용해 복잡한 서비스 간의 요청 흐름을 명확하게 추적한다.
OTel은 코드 수정 없이 런타임 에이전트를 통해 쉽게 적용할 수 있는 '자동 계측' 방식과, 코드에 직접 라이브러리를 추가하여 세밀한 추적이 가능한 '수동 계측' 방식을 모두 지원한다.
이를 통해 개발자는 시스템의 병목 지점과 오류를 신속하게 파악하여, 분산 시스템의 안정성과 성능을 효과적으로 높일 수 있다.
