🏗️ OpenTelemetry의 아키텍처: API, SDK, 그리고 Collector

OpenTelemetry를 성공적으로 구현하려면 먼저 주요 구성 요소인 API, SDK, 그리고 Collector 사이의 엄격한 관심사 분리(separation of concerns)를 이해해야 합니다. 이러한 디커플링(decoupling)은 텔레메트리(telemetry) 구현과 백엔드 목적지(backend destinations)의 변경으로부터 애플리케이션 코드를 보호하는 핵심 설계 패턴입니다.

⚙️ API (Application Programming Interface)

API는 애플리케이션 코드에 직접 추가하는 의존성(dependency)입니다. 이는 트레이스(traces), 메트릭(metrics), 로그(logs)를 캡처하기 위한 프로그래밍 모델, 데이터 유형 및 인터페이스를 정의합니다. 결정적으로, API에는 운영 로직이 포함되어 있지 않습니다. 이는 기본적으로 no-op (no-operation) 구현을 반환하는 추상 인터페이스 세트입니다.

이러한 설계는 OTel API로 애플리케이션을 계측(instrument)하되 SDK를 구성하지 않더라도, 애플리케이션이 예외를 발생시키거나 성능 오버헤드를 유발하지 않고 실행되도록 보장합니다. 이는 비즈니스 로직을 텔레메트리 구현으로부터 완전히 분리하여, 개발자가 데이터가 어떻게 또는 어디로 전송되는지에 대해 걱정하지 않고 코드를 계측할 수 있게 해줍니다.

SDK (Software Development Kit)

SDK는 API의 구체적인 구현체입니다. 이는 텔레메트리 데이터의 상태 관리, 인메모리 버퍼링(in-memory buffering), 샘플링(sampling), 처리(processing) 및 내보내기(exporting)를 관리합니다. 애플리케이션 시작 시(일반적으로 의존성 주입(dependency injection) 또는 초기화 스크립트를 통해) SDK를 구성하며, 데이터를 백엔드로 직접 보내거나, 가급적 중간 Collector로 전송하기 위해 Exporter와 결합합니다.

SDK는 배치(batching), 컨텍스트 전파(context propagation), 네트워크 통신과 같은 무거운 운영 작업을 처리하기 때문에, SDK의 구성은 애플리케이션의 리소스 소비에 직접적인 영향을 미칩니다. 버퍼 크기나 샘플링 비율과 같은 SDK 파라미터를 잘못 구성하면 높은 처리량(high-throughput) 조건에서 메모리 고갈이나 CPU 스파이크(spikes)가 발생할 수 있습니다.

The Collector

The Collector

OpenTelemetry Collector는 애플리케이션과 독립적으로 실행되는 고성능 프록시(proxy) 스타일의 서비스입니다. 이는 중앙 집중식 텔레메트리 파이프라인 (telemetry pipeline) 역할을 수행하며, 다양한 형식(OTLP, Jaeger, Zipkin, Prometheus 포함)의 텔레메트리 데이터를 수신, 처리 및 내보낼 수 있습니다.

Collector를 배포하면 애플리케이션 프로세스로부터 처리 오버헤드 (processing overhead)를 분리할 수 있습니다. 각 마이크로서비스 (microservice) 인스턴스가 서로 다른 백엔드 (backend)를 위해 여러 연결과 직렬화 (serialization) 작업을 관리하는 대신, 로컬 또는 중앙 집중식 Collector로 gRPC 또는 HTTP/2를 통해 가공되지 않은 OTLP (OpenTelemetry Protocol) 데이터를 전송합니다. 그러면 Collector가 배치 (batching), 필터링 (filtering), PII 마스킹 (PII masking) 및 다중 목적지 라우팅 (multi-destination routing)을 처리합니다.

이러한 아키텍처는 애플리케이션의 실행 공간과 텔레메트리 라우팅 인프라 사이에 명확한 경계를 설정합니다. 내부 와이어 프로토콜 (wire protocol)로 OTLP를 표준화함으로써, 애플리케이션 코드를 단 한 줄도 수정하지 않고 오직 Collector의 설정만 변경하여 백엔드 관측 가능성 (observability) 플랫폼을 교체, 분할 또는 복제할 수 있는 유연성을 얻을 수 있습니다.

OpenTelemetry가 CNCF 내에서 졸업함에 따라, 클라우드 네이티브 관측 가능성 (cloud-native observability)의 표준이 세워졌습니다. 이 가이드는 OTel의 핵심 아키텍처를 분석하고, 프로덕션 환경에 즉시 적용 가능한 Collector 설정을 제공합니다.

Collector 구현: 구성, 파이프라인 및 처리

OpenTelemetry Collector는 파이프라인 (pipelines)을 정의하는 단일 YAML 파일을 통해 구성됩니다. 파이프라인은 네 가지 별개의 구성 요소로 이루어진 유향 비순환 그래프 (DAG, directed acyclic graph)입니다.

• Receivers (수신기): 데이터가 Collector로 들어오는 방식(push 또는 pull, 프로토콜, 포트)을 정의합니다.
• Processors (프로세서): 데이터에 대한 작업(배칭 (batching), 메모리 제한 (memory limiting), 속성 조작 (attribute manipulation), 샘플링 (sampling))을 수행합니다.
• Exporters (내보내기): 처리된 데이터가 전송될 위치(OTLP 엔드포인트, 벤더 백엔드, 로컬 파일)를 정의합니다.
• Connectors (커넥터): 서로 다른 파이프라인을 연결하여, 하나의 파이프라인(예: traces)에서 다른 파이프라인(예: span에서 유도된 metrics)으로 데이터를 라우팅할 수 있게 합니다.

안정적인 프로덕션급(production-grade) Collector를 실행하려면 프로세서를 특정 순서로 구성해야 합니다. 구체적으로, memory_limiter 프로세서는 메모리 부족 (OOM, out-of-memory) 충돌을 방지하기 위해 파이프라인에서 항상 가능한 한 앞부분에 배치되어야 하며, 그 뒤를 이어 네트워크 처리량 (throughput)과 압축을 최적화하기 위한 batch 프로세서가 배치되어야 합니다.

아래는 보안 OTLP 수집 (ingestion), 메모리 보호 장치, 그리고 멀티 백엔드 라우팅을 포함하여 이러한 원칙을 보여주는 매우 견고하고 프로덕션 준비가 된 Collector 설정 예시입니다:

receivers:
  otlp:
    protocols:
...

주요 프로세서 메커니즘

• memory_limiter: 이 프로세서는 서킷 브레이커 (circuit breaker) 역할을 합니다. Collector의 힙 (heap) 사용량을 모니터링합니다. 메모리 소비가 80%(위에서 설정한 값)를 초과하면, 데이터 드롭을 시작하고 수신기(receivers)에 에러를 반환하여 업스트림 클라이언트가 재시도하도록 강제합니다. 이는 갑작스러운 트래픽 급증 시 OS 커널에 의해 Collector가 강제 종료되는 것을 방지합니다.
• batch: 배칭 (batching)은 네트워크 효율성과 백엔드 수집 제한 모두에 있어 매우 중요합니다. 위의 설정은 span과 metrics가 최대 10,240개의 항목으로 그룹화되거나, 1초마다 플러시 (flush)되도록 보장하며, 둘 중 먼저 발생하는 쪽을 따릅니다. 이는 HTTP/gRPC 요청 오버헤드를 획기적으로 줄여줍니다.
• transform: 이 프로세서는 OpenTelemetry 변환 언어 (OTTL, OpenTelemetry Transformation Language)를 사용하여 텔레메트리 (telemetry)를 실시간으로 검사하고 수정합니다. 예시에서는 데이터가 네트워크 경계를 벗어나기 전에 span 속성을 스캔하고 password나 token과 같은 민감한 키를 삭제(redact)하도록 구성했습니다.

🏗️ 아키텍처 트레이드오프 (Architectural Trade-offs): 에이전트(Agent) vs. 게이트웨이(Gateway), 메모리 및 성능

OpenTelemetry 배포 토폴로지(topology)를 설계할 때, 근본적인 아키텍처 결정을 내려야 합니다. Collector를 에이전트 (Agent) (sidecar/daemonset)로 배포할 것인가, 아니면 게이트웨이 (Gateway) (standalone cluster)로 배포할 것인가 하는 점입니다.

제 경험상 가장 최적의 패턴은 하이브리드 접근 방식이지만, 귀하의 특정 인프라에 맞는 정보에 기반한 결정을 내리기 위해서는 각 모델의 트레이드오프 (trade-offs)를 이해해야 합니다.

하이브리드 패턴 (The Hybrid Pattern): 권장 실무

엔터프라이즈급 배포를 위해 저는 계층형 아키텍처 (tiered architecture)를 권장합니다. 모든 노드에 Collector를 **에이전트 (Agent)**로 배포하거나 (AWS Fargate와 같은 서버리스 환경에서는 sidecar로 배포), 애플리케이션 SDK가 gRPC를 통해 localhost를 거쳐 이 로컬 에이전트에 연결하도록 합니다.

이 로컬 에이전트는 가벼운 작업들을 수행합니다. 데이터를 수신하고, 노드 수준의 메타데이터(예: resourcedetection 프로세서를 사용하여 Kubernetes pod 이름이나 클라우드 제공업체의 인스턴스 ID 추가)를 추가한 뒤, 즉시 중앙 집중식 게이트웨이 (Gateways) 풀로 전달합니다.

오토스케일링 그룹(autoscaling group) 또는 Kubernetes 수평 포드 오토스케일러(Horizontal Pod Autoscaler, HPA)에 의해 관리되는 게이트웨이 풀은 다음과 같은 무거운 작업들을 처리합니다: 전역 속도 제한 (global rate limiting), 복잡한 OTTL 변환 (transformations), 로그 파싱 (log parsing), 그리고 여러 외부 백엔드로의 라우팅 (routing). 이 하이브리드 모델은 네트워크 장애로부터 애플리케이션을 격리하고, 애플리케이션 측의 CPU 사용량을 최소화하며, 보안 및 이그레스 (egress) 설정을 중앙 집중화합니다.

메모리 및 성능 튜닝 (Memory and Performance Tuning)

Collector가 병목 현상 (bottleneck)이 되는 것을 방지하려면 런타임 환경을 튜닝해야 합니다. Collector는 Go 언어로 작성되었으므로, 가비지 컬렉션 (garbage collection, GC) 일시 중단 (pauses) 및 메모리 오버헤드 (memory overhead)의 영향을 받습니다.

만약 Gateway 인스턴스에서 높은 메모리 churn (메모리 변동) 현상이 발생한다면, GOGC 환경 변수를 더 낮은 값(예: GOGC=80 또는 GOGC=50)으로 설정할 것을 권장합니다. 이렇게 하면 Go 런타임이 더 공격적으로 가비지 컬렉션 (garbage collection, GC)을 수행하도록 강제하여, CPU 사용량이 미미하게 증가하는 대신 메모리 사용량 (memory footprint)을 안정적으로 유지할 수 있습니다. 또한, 컨테이너 오케스트레이터 (container orchestrator)에서 항상 memory_limiter 프로세서 임계값과 일치하도록 명시적인 CPU 및 메모리 제한을 설정하십시오.

마이그레이션 전략: 독점적 APM에서 OpenTelemetry로의 전환

기업을 기존의 독점적 (proprietary) APM 에이전트에서 OpenTelemetry로 전환하는 것은 단계적이고 리스크를 완화하는 접근 방식이 필요한 운영상의 과제입니다. 모든 애플리케이션을 하룻밤 사이에 새로 작성하고 에이전트를 교체할 수는 없습니다.

저는 기존 구성 요소를 체계적으로 교체하면서 지속적인 가시성 (visibility)을 유지하도록 설계된 4단계 마이그레이션 프레임워크를 권장합니다.

1단계: 이중 수신기 Collector 배포 (The Dual-Receiver Collector Deployment)

애플리케이션 코드를 변경하는 것부터 시작하지 마십시오. 대신, 인프라의 게이트웨이 (gateway)로서 OpenTelemetry Collector를 배포하십시오. Collector가 표준 OTLP 데이터와 기존 레거시 포맷을 모두 수신할 수 있도록 구성하십시오 (많은 독점 벤더들이 OTel 호환 수신기 또는 API를 제공하며, OTel 자체적으로도 Zipkin, Jaeger, Prometheus 메트릭을 위한 수신기를 보유하고 있습니다).

Collector가 데이터를 기존의 독점적 APM 백엔드로 직접 내보내도록(export) 구성하십시오. 이를 통해 애플리케이션 런타임 환경을 변경하지 않고도 데이터 파이프라인 제어 평면 (control plane)을 구축할 수 있습니다.

⚙️ 2단계: 자동 계측 (Auto-Instrumentation) 및 Zero-Code 접근 방식

즉각적인 추진력을 얻으려면 OpenTelemetry의 자동 계측 (auto-instrumentation) 기능을 활용하십시오. OTel은 코드 변경 없이 시작 시점에 애플리케이션 런타임에 계측을 동적으로 주입하는 언어별 에이전트 및 오퍼레이터 (예: OpenTelemetry Kubernetes Operator)를 제공합니다.

예를 들어, Java, Node.js 또는 Python의 경우 컨테이너 환경 변수를 통해 OTel 에이전트 jar/에이전트 모듈을 부착할 수 있습니다. 이를 통해 표준 HTTP, 데이터베이스 및 gRPC 스팬 (spans)을 즉시 방출하기 시작합니다. 이러한 자동 계측 (auto-instrumented) 에이전트가 1단계에서 구축된 Collector 게이트웨이로 데이터를 보내도록 설정하십시오.

3단계: 타겟팅된 수동 계측 (Targeted Manual Instrumentation)

자동 계측 (Auto-instrumentation)은 훌륭한 수평적 커버리지 (시스템 경계, 네트워크 호출, 데이터베이스 쿼리)를 제공하지만, 비즈니스 컨텍스트 (business context)가 부족합니다. 자동 계측 파이프라인이 안정화되면, 개발 팀이 OpenTelemetry API를 사용하여 수동 계측 (manual instrumentation)을 추가하도록 과업을 부여하십시오.

수동 계측은 다음과 같은 고가치 영역에 집중하십시오:

• 도메인 특화 비즈니스 메트릭 (예: 결제 금액, 활성 사용자 세션) 캡처.
• 고카디널리티 (high-cardinality) 디버깅을 지원하기 위한 커스텀 스팬 속성 (예: tenant.id, order.type) 추가.
• 네트워크 수준의 자동 계측으로는 확인할 수 없는, 복잡하고 CPU 집약적인 내부 알고리즘 주변에 명시적 스팬 (explicit spans) 생성.

4단계: 백엔드 분리 및 벤더 평가 (Backend Decoupling and Vendor Evaluation)

이제 애플리케이션 코드가 표준화된 OTLP 데이터를 Collector 게이트웨이로 방출함에 따라, 완전한 벤더 독립성 (vendor independence)을 달성했습니다.

새로운 관측 가능성 (observability) 벤더를 평가하거나 Jaeger 또는 Grafana Mimir와 같은 오픈 소스 백엔드를 채택하기로 결정하더라도, 개발자에게 코드를 수정하거나 서비스를 재배포하도록 요청할 필요가 없습니다. 단순히 Collector YAML 설정에서 exporters 및 pipelines 블록을 업데이트하고 변경 사항을 적용하기만 하면, 기존 목적지와 병렬로 새로운 목적지에 텔레메트리 (telemetry)를 스트리밍할 수 있습니다. 검증이 완료되면 기존 백엔드를 안전하게 폐기할 수 있습니다.

🎯 결론

OpenTelemetry의 CNCF 졸업 (graduation)은 독점적인 텔레메트리 (telemetry) 수집 시대가 끝났음을 알리는 명확한 신호입니다. 계측 (instrumentation) API를 운영용 SDK와 분리하고, 고도로 설정 가능한 Collector를 도입함으로써, OpenTelemetry는 엔지니어링 팀에게 관측 가능성 (observability) 데이터, 성능 오버헤드 (performance overhead), 그리고 벤더 관계 (vendor relationships)에 대해 전례 없는 제어권을 제공했습니다.

이 표준을 활용하기 위해, 저는 즉시 실행해야 할 세 가지 조치를 권장합니다:

• OTLP 표준화: 모든 신규 내부 서비스가 트레이싱 (tracing) 및 메트릭 (metrics)을 위해 OpenTelemetry API와 SDK를 사용하도록 의무화하십시오.
• Collector 게이트웨이 배포: 위에서 설명한 메모리 보호 장치 (memory safeguards) 및 배치 (batching) 설정을 사용하여 중앙 집중식의 고가용성 (highly available) Collector 클러스터를 구축하십시오.
• 자동 계측 (Auto-Instrumentation) 시작: OTel Kubernetes Operator 또는 언어별 런타임 에이전트 (runtime agents)를 구현하여, 즉각적인 코드 재작성 없이도 기존 레거시 애플리케이션 전반에 걸쳐 즉시 기초적인 가시성 (visibility)을 확보하십시오.