OpenTelemetry란 무엇인가요?

OTel은 프로그래밍 언어, 인프라, 런타임 환경에 관계없이 텔레메트리 데이터를 수집하는 방식을 단순화하며, 개발자가 어떤 관측 가능성 백엔드에서도 표준화된 텔레메트리 데이터를 생성, 수집 및 내보낼 수 있도록 합니다. 이 표준화된 프레임워크는 관측 가능성 기능을 강화하고 확장하며, IT 및 DevOps 팀에 더 큰 유연성을 제공합니다.  

OTel은 애플리케이션, 시스템, 장치와 백엔드 솔루션 사이에 구현되며, 스토리지와 시각화는 의도적으로 다른 툴에 맡겨져 있어 조직이 자신에게 가장 적합한 툴을 자유롭게 선택할 수 있습니다.

관측 가능성은 외부 아웃풋을 분석하여 시스템의 내부 작동에 대한 인사이트를 얻을 수 있는 능력입니다. IT 운영(ITOps) 및 클라우드 컴퓨팅에서 원격 측정 데이터(예: 로그, 지표 및 추적)는 시스템 성능 및 상태를 평가하는 데 사용됩니다. DevOps 전문가는 애플리케이션 및 시스템에 코드를 추가하여 원격 측정 데이터를 생성하고 캡처하는 계측을 사용하여 관측 가능한 시스템을 만듭니다.

이러한 계측은 현대적인 환경에서 복잡한 작업이 되는 경우가 많습니다. 예를 들어 하이브리드 클라우드와 멀티클라우드 환경, 마이크로서비스 기반 애플리케이션, Kubernetes 컨테이너, 그리고 최신 컴퓨팅 환경의 다른 기능들이 그 예입니다. 이러한 분산 시스템과 여기에 통합된 다양한 프로그래밍 언어 및 런타임은 백엔드 런타임, 시각화 및 분석을 위해 계측, 수집 및 내보내기에 복잡한 배열을 제공합니다.

네트워크 서비스 및 애플리케이션 성능을 포괄적으로 이해하려면 엔지니어가 전체 인프라에서 애플리케이션 및 시스템에 대한 맞춤형 계측을 구성해야 합니다. OpenTelemetry는 이 문제를 해결하는 데 도움이 됩니다.

OTel은 통합 관측 가능성 데이터를 수집하고 전송하는 표준 방법을 제공함으로써 분산 시스템에서 모니터링을 간소화하는 데 도움을 줍니다. 또한 공급업체 중립적인 통합 라이브러리와 API를 사용하여 원격 측정 데이터를 수집하고 백엔드 플랫폼으로 전송합니다. OpenTelemetry 도입을 통해 팀은 관리하는 애플리케이션이나 사용하는 관측 가능성 도구에 관계없이 복잡한 시스템에서 원격 분석을 균일하게 수집하고 처리할 수 있습니다.

사용되는 계측 코드는 매우 다양했습니다. 또한 네트워크의 모든 앱과 서비스에서 데이터를 수집할 수 있는 툴을 제공하는 상용 제공업체가 없었기 때문에 기업에서 다양한 언어와 형식으로 데이터를 수집하거나 백엔드를 변경하는 것이 어려웠습니다.

예를 들어, 개발팀이 백엔드 도구를 새것으로 교체하려면 코드를 완전히 다시 구현하고 새로운 에이전트를 구성하여 원격 측정 데이터를 새 서버로 전송해야 합니다. 이러한 파편화된 접근 방식은 데이터 사일로와 혼란을 초래하여 성능 문제를 효과적으로 해결하기 어렵게 만듭니다.

OpenTelemetry는 텔레메트리 데이터를 수집, 분석, 백엔드 플랫폼으로 전송하는 방식을 표준화했기 때문에 관측 가능성 툴에서 중요한 발전을 의미했습니다. 이는 시스템 동작과 보안에 관한 데이터를 수집하기 위해 커뮤니티 주도 표준을 기반으로 한 오픈 소스 솔루션을 제공하여, 팀이 분산 에코시스템에서 모니터링과 관측 가능성을 간소화할 수 있도록 돕습니다. 따라서 OTel은 네트워크 애플리케이션과 서비스에서 중요한 데이터를 수집하기 위한 개방적이고 일관된 접근 방식을 기업에 제공합니다.

OpenTelemetry는 OpenTracing과 OpenCensus의 분산 추적 기능을 단일 도구로 결합하여 만들어졌습니다. OpenTracing은 Cloud Native Computing Foundation(CNCF)에서 설계한 오픈 소스 프로젝트로, 분산 추적 계측을 애플리케이션에 추가하기 위한 공급업체 중립적 API를 엔지니어에게 제공합니다. 또한 원격 측정 데이터의 일관성을 보장하는 데 도움이 되는 일련의 시맨틱 규칙을 수립했습니다.

하지만 OpenTelemetry와 달리 OpenTracing은 그 자체가 추적 구현은 아니었습니다. 오히려 추적 시스템이 플랫폼 간 호환성을 극대화하기 위해 구현할 수 있는 인터페이스를 제공했습니다. OpenTracing은 현재는 중단된 프로젝트로(현재는 사용자가 OpenTelemetry로 이전하도록 권장하고 있음), 여전히 다양한 소프트웨어와 추적 솔루션이 그 API에 의존하고 있습니다.

OpenCensus는 애플리케이션 지표 및 분산 추적을 수집하기 위해 Google에서 개발한 일련의 계측 라이브러리로, 실시간으로 데이터를 다양한 백엔드로 내보낼 수 있습니다. 일관된 전파 태그와 메타데이터를 사용하여 데이터를 수집하며, 이는 현재 OpenTelemetry에 "리소스"로 존재하는 개념입니다.

OpenCensus를 사용하면 애플리케이션이 특정 요구 사항에 따라 데이터를 가져오고 내보낼 수 있으므로 지표와 추적을 관측 가능성 백엔드로 전송하는 방식에 유연성을 보장할 수 있습니다. OpenCensus는 OpenTracing처럼 공식적으로 중단되지 않았으며, 여전히 정기적인 유지보수 및 보안 업데이트를 받고 있습니다. 그러나 활발한 개발은 대부분 OpenTelemetry로 옮겨갔습니다.

두 프로젝트 모두 동일한 문제를 해결하는 것을 목표로 했습니다. 당시 개발 팀에는 코드를 계측하고 원격 측정 데이터를 백엔드 관측 가능성 도구로 전송하기 위한 표준 방법이 없었습니다.

하지만 두 프로젝트 모두 이 문제를 자체적으로 해결할 수 없었습니다. 그래서 CNCF는 각 솔루션의 최고의 기능을 결합하는 OpenTelemetry 프로젝트를 후원했습니다. OpenTelemetry는 OpenTracing의 API 표준화와 OpenCensus의 데이터 수집 기능을 결합하여 백엔드 관측 가능성 플랫폼에 원격 측정 데이터를 전송, 수집 및 이전할 수 있는 단일 통합 플랫폼을 제공합니다.

빠르고 고가용성의 네트워크와 애플리케이션을 운영하는 데 있어 핵심 요소는 Full Stack Observability(또는 가시성)을 확보하는 것이며, 이를 위해서는 텔레메트리 데이터에 대한 액세스가 필요합니다. 관측 가능성 솔루션은 원격 측정 데이터를 수집, 모니터링 및 분석하여 시스템의 상황을 확인한 다음 IT 팀에 수리 및 최적화를 위한 실행 가능한 인사이트를 제공합니다.

OpenTelemetry에 대해 더 깊이 이해하기 위해 원격 측정 데이터가 무엇이며 조직에서 이를 어떻게 사용하는지 자세히 알아보겠습니다. OpenTelemetry는 특정 데이터 유형, 즉 로그, 지표 및 추적에서 수집된 아웃풋(종종 '관측 가능성의 세 가지 핵심 요소')을 지원합니다.

지표는 시스템 성능과 리소스 사용량을 수치로 평가한 것입니다. 이는 지연 시간, 패킷 손실, 대역폭 활용도, 장치 CPU 사용률과 같은 주요 성능 지표(KPI)를 수집하여 네트워크 상태에 대한 상위 수준의 개요를 제공합니다.

지표는 일반적으로 대시보드 및 기타 시각화를 사용하여 요약됩니다. 이는 팀에게 시스템 또는 애플리케이션 성능 문제의 첫 징후를 제공하는 경우가 많습니다.

로그는 환경 내에서 발생하는 모든 이벤트 또는 작업에 대한 자세한 기록입니다. 무슨 일이 발생했는지, 언제 발생했는지, 네트워크의 어디에서 발생했는지에 대한 세부적인 정보를 제공하여 팀에 문제 해결, 디버깅 및 포렌식 분석을 위한 귀중한 컨텍스트를 제공합니다.

로그는 디바이스 구성 변경, 인증 실패 및 연결 끊김과 같은 시스템 이벤트를 자세히 설명하여 문제의 근본 원인을 보여줍니다.

추적은 네트워크 전반의 데이터 흐름을 캡처하여 패킷이 여러 디바이스와 시스템을 통과할 때 패킷의 경로와 동작에 대한 인사이트를 제공합니다. 분산 시스템을 이해하고 지연 시간 문제를 진단하는 데 필수적입니다.

데이터 추적을 통해 IT 팀은 트랜잭션의 전체 여정을 엔드투엔드로 볼 수 있으므로 복잡한 다계층 환경에서 발생하는 지연과 장애를 정확히 찾아낼 수 있습니다.

OpenTelemetry는 데이터 수집을 성공적으로 수행하기 위해 다음과 같은 여러 구성 요소와 프로세스를 사용합니다.

API는 소프트웨어 애플리케이션이 서로 통신하여 데이터, 특징 및 기능을 교환할 수 있도록 하는 일련의 규칙 또는 프로토콜입니다.

OpenTelemetry는 개발자가 원격 측정 데이터 수집을 위해 애플리케이션을 계측하는 데 사용할 수 있는 언어별 API(예: Java, Ruby, JavaScript, Python, 기타 언어)를 제공합니다. OpenTelemetry API는 네트워크 인프라에서 앱을 분리하여, 팀에 계측 코드와 일치하는 엔드포인트를 사용할 수 있는 유연성을 제공합니다.

OpenTelemetry SDK를 사용하면 엔지니어가 API 동작을 구성하고 사용자 정의할 수 있습니다. SDK는 API와 수집기 사이의 가교 역할을 하며, 일반 라이브러리의 수동 계측을 수동 앱 계측에 연결할 수 있게 해줍니다. 

OTel은 다양한 프로그래밍 언어용 SDK를 제공하므로, 개발자는 OTel API를 사용하여 선택한 언어와 백엔드에 맞는 관측 가능성 데이터(텔레메트리 데이터)를 생성하고 내보낼 수 있습니다. OTel SDK는 OpenTelemetry 커뮤니티에서 아직 지원하지 않는 사내 프레임워크를 위한 사용자 지정 계측도 지원합니다.

컬렉터는 OpenTelemetry로 계측된 애플리케이션에서 텔레메트리 데이터를 수집하는 에이전트입니다. 수신기, 프로세서, 집계기 및 내보내기 구성 요소로 이루어진 컬렉터는 공급업체 중립적인 중개자로서, 애플리케이션에서 데이터를 받아 관측 가능성 플랫폼이나 다른 분석 대상으로 전달합니다.

OpenTelemetry 컬렉터는 OpenTelemetry 프로토콜(OTLP), Prometheus, Jaeger 등 다양한 형식의 데이터를 수집하고 여러 백엔드로 내보낼 수 있는 컨트리뷰션 패키지를 지원합니다. 경우에 따라 중복성을 위해 동시에 여러 곳으로 내보내기도 합니다. 컨트리뷰션 패키지는 하위 모듈 형식으로 개발팀에 계측, 샘플러, 전파기 및 리소스 탐지기를 제공하는 타사 확장 기능입니다.

또한 수집기는 원격 측정 데이터를 내보내기 전에 처리 및 필터링하여 가장 중요한 데이터 전송을 우선시하고 문제 해결 및 디버깅 프로세스를 가속화할 수 있습니다.

내보내기 구성 요소는 컬렉터의 일부로서, 애플리케이션 텔레메트리 데이터를 지정된 하나 이상의 관측 가능성 백엔드로 전송하는 역할을 합니다. 컬렉터가 전체적인 데이터 흐름을 관리하는 반면, 내보내기 구성 요소는 데이터를 목적지로 외부 전송하는 데 중점을 둡니다.

OpenTelemetry 데이터 내보내기 구성 요소는 계측과 백엔드 구성을 분리하고, 각 관측 가능성 플랫폼에 맞게 데이터를 변환합니다(예: 추적 데이터를 Zipkin 프로토콜로 변환). 이러한 구조 덕분에 컬렉터는 동일한 텔레메트리 데이터를 여러 백엔드로 전송할 수 있어, 코드의 계측 로직을 수정하지 않고도 목적지를 변경하기가 쉬워집니다.

자동 계측은 앱이 최소한의 코드 수정 또는 코드 변경 없이도 자동으로 텔레메트리 데이터를 생성할 수 있게 해주는 라이브러리와 프레임워크를 제공합니다. 이 과정은 개발자의 계측 작업을 단순화하여 수동 코딩 작업을 줄이거나 경우에 따라 제거해 줍니다.

하지만 자동 계측은 수동 계측에 비해 특정 데이터 수집 방식에 대한 제어권이 적을 수 있습니다. 자동 계측의 범위는 언어 런타임, 컴퓨팅 환경, 관측 가능성 프레임워크에 대한 커뮤니티 지원 수준에 따라 달라질 수 있습니다.

OpenTelemetry는 API, SDK, 컬렉터 및 자동 계측 프로세스를 결합하여 데이터를 수집하고 대상 시스템으로 전송합니다.

먼저 DevOps 팀은 OTel API로 애플리케이션 코드를 계측하고, 어떤 지표, 추적 및 로그를 수집할지와 그 수집 방식을 지정합니다. OTel SDK 컬렉터는 데이터를 수집하고 처리 및 내보내기를 준비한 뒤, 데이터 샘플링, 필터링, 의존성 및 다른 데이터 소스와의 상관관계를 수행합니다.

처리된 데이터가 적절한 형식으로 변환되면, SDK는 데이터를 시간 기반 배치로 묶고(필요하다면 추가 필터링 수행) 지정된 백엔드 시스템으로 보냅니다.

OpenTelemetry의 주요 목표는 원격 측정 데이터를 수집하거나 내보내고, 관측 가능성을 개선함으로써 조직에 공급업체 중립성과 플랫폼 및 통합을 용이하게 하는 도구를 제공하는 것입니다. DevOps 팀과 사이트 안정성 엔지니어(SRE)가 애플리케이션과 시스템을 관리하고 디버그할 수 있도록 지원하므로, 정보에 입각한 결정을 내리고 비즈니스 요구 사항의 변화에 따라 민첩성을 유지할 수 있습니다.

OTel의 이점은 다음과 같습니다.

• 일관된 데이터 수집을 구현합니다. OpenTelemetry를 통해 팀은 다양한 앱, 시스템 및 사용 사례에서 원격 측정 데이터를 일관되게 수집할 수 있습니다.

• 공급업체 종속을 방지합니다. OTel은 공급업체 중립적인 솔루션이기 때문에 개발자가 계측 코드를 크게 변경하지 않고도 백엔드 관측 가능성 도구 및 제공업체를 교체할 수 있습니다.

• 관측 가능성 간소화. OTel은 IT 인력이 소스 코드나 메타데이터를 수정할 필요 없이 텔레메트리 데이터를 수집하여 관측 가능성을 단순화합니다. 또한 개발자가 어떤 관측 가능성 백엔드나 공급업체를 사용하더라도 전체 스택 가시성을 유지할 수 있게 해줍니다.

• 미래 지향적인 IT 에코시스템. OpenTelemetry는 오픈 소스 커뮤니티와 CNCF가 지원하기 때문에, 컴퓨팅 기술과 관측 가능성 요구가 변화함에 따라 발전하도록 설계되었습니다. 예를 들어, OTel은 최근 기본 텔레메트리 신호 그룹에 지속적 프로파일링 기능을 추가했습니다.¹

• 리소스 사용량 추적.OpenTelemetry는 서버 간 데이터 요청을 캡처하여 그룹별로 리소스 사용량을 분류할 수 있으므로, IT 팀이 공유 시스템 간의 활용도를 추적할 수 있습니다.

• 데이터 요청의 우선순위를 지정합니다. OpenTelemetry는 아키텍처 내에서 데이터 요청에 대한 우선순위 파이프라인을 생성하므로, 경쟁하는 요청들이 미션 크리티컬한 순서대로 네트워크를 통과합니다.

• 모니터링 데이터에 대한 액세스를 확장합니다. OTel을 통해 개발자는 원격 측정 데이터를 모니터링하고 모든 웹 브라우저 또는 디바이스에서 경고를 수신할 수 있으므로, 소프트웨어 성능과 전반적인 시스템 상태를 실시간으로 간편하게 추적할 수 있습니다.