2019년 초 OpenTelemetry 프로젝트는 OpenTracing과 OpenCensus라는 두 프로젝트의 병합으로 탄생했다. 프로젝트의 초기 목표는 두 개의 프로젝트를 하나로 합치는 것이었지만 클라우드 네이티브 소프트웨어에 대한 관찰 가능성 프레임워크를 제공하겠다는 야심이 프로젝트를 큰 과제로 만들었다. OpenTelemetry는 기본적으로 OpenTracing과 OpenCensus의 개념을 결합한 것이기 때문에 우선은 이 둘을 잘 살펴볼 필요가 있다.
OpenTracing
2016년에 시작된 OpenTracing 프로젝트는 사용자가 시스템을 더 잘 이해하기 위한 수단으로 분산 추적을 채택하는 비율이 증가하는 것에 따른 문제를 해결하는 데 집중했다.
사용자들은 분산 추적 도입으로 인해 발생하는 비용과 third-party 라이브러리 품질 측정의 어려움 때문에 분산 추적 도입을 망설였는데, OpenTracing은 이 문제를 해결하기 위해 API 규격을 제공했다. 이 API는 분산 측정을 생성하는 구현과 독립적으로 활용될 수 있었기 때문에 애플리케이션 및 라이브러리 개발자가 API호출 코드를 내장할 수 있었다.
기본적으로 API는 no-op 오퍼레이터처럼 작동하므로 특정한 작동을 지정하지 않았다면 아무런 일도 하지 않는다.
이제 설명한 내용을 코드로 살펴보자. 특정 코드를 추적하기 위한 API 호출은 다음 예시 코드와 같다.
import opentracing
tracer = opentracing.global_tracer()
with tracer.start_active_span('doWork'):
# 작업 수행이 코드는 global_tracer 메서드를 이용하여 tracer 객체를 얻기 위해 전역 변수를 선언한다. tracer는 OpenTracing과 OpenTelemetry에서 추적 데이터를 생성하기 위한 메커니즘이다. 전역으로 설정된 tracer를 사용하는 것은 추적 코드 내에서 추가로 무언가를 설정할 필요가 없다는 것을 의미한다.
기본 no-op 구현은 계측 시 데이터 생성 및 수집 방법에 관해 개발자가 아무런 결정을 하지 않더라도 계측할 수 있다는 것을 말해준다. 또한 애플리케이션 내에서 분산 추적을 원하지 않는 계측 라이브러리 사용자가 tracer를 설정하지 않음으로써 받을 수 있는 성능상의 페널티 없이 라이브러리를 계속 사용할 수 있게 한다. 반대로 분산 추적을 설정하고 싶은 사용자는 계측 데이터를 어떻게 생성할지 선택할 수 있다. 이러한 라이브러리 및 애플리케이션 사용자는 tracer 구현을 선택하고 설정한다. 규격을 준수한 tracer 구현체는 정의된 API를 따르기만 하면 된다. 이 API는 다음과 같은 메서드를 포함한다.
- 새로운 스팬의 시작
- 전달자(carrier)에게 이미 존재하는 스팬의 context를 주입
- 전달자로부터 스팬을 추출
이러한 API 규격과 함께 OpenTracing은 시맨틱 표기법(symantic convention)을 제공한다. 이 표기법은 계측으로 수집된 원격 측정 결과의 품질을 개선하기 위한 가이드라인을 포함한다.
OpenCensus
OpenCensus는 'Census'라는 이름으로 구글 내부에서 시작된 프로젝트이지만, 2017년 오픈소스로 공개된 후 커뮤니티의 폭넓은 지지를 받으면서 인기를 얻었다. 이 프로젝트는 애플리케이션 개발자가 쉽게 애플리케이션을 추적하고 메트릭을 생산 및 수집할 수 있도록 라이브러리를 제공했다. 또한, 독립적인 에이전트로 작동하면서 애플리케이션의 원격 측정 대상 역할을 하는 동시에 OpenCensus 컬렉터를 제공하여 백엔드 스토리지로 데이터를 전송 및 분석하도록 설정할 수 있다. 원격 측정 데이터는 OpenCensus에서 정의한 형식으로 가공되어 컬렉터로 전송된다. 컬렉터는 OpenCensus의 컴포넌트로 활용될 때 매우 강력한 효과를 가진다.
OpenCensus에서 분산 추적을 지원하는 API의 개념은 OpenTracing의 API와 비슷하다. 다만 OpenTracing과 달리 OpenCensus는 강하게 결합된 API와 SDK를 제공하므로 별도의 구현체를 설치하거나 설치하거나 설정할 필요 없이 OpenCensus를 이용할 수 있다.
이런 방식은 애플리케이션 개발자의 사용자 경험을 단순화시켰지만 동시에 특정 언어 환경에서 자신의 코드를 계측하고 싶은 서드파티 라이브러리 개발자도 OpenCensus가 제공하는 표준 SDK와 관련된 의존성을 따르도록 강제한다.
앞서 이야기한 것처럼 OpenCensus는 애플리케이션 메트릭을 만들 수 있는 API를 제공했으며, 이는 OpenTelemetry에서 중요하게 다뤄지는 다음과 같은 핵심 개념으로 이어졌다.
- 측정값 (measurement): 기록된 측정의 결과물 또는 생성된 메트릭 포인트
- 측정 (measure): 기록 대상이 되는 정의된 메트릭
- 집계 (aggregation): 측정값이 집계되는 방식
- 뷰 (view): 데이터를 내보내는 방식을 결정하기 위한 측정과 집계의 집합
개발자는 애플리케이션의 메트릭을 수집하기 위해 측정값 기록을 위한 측정 방법을 정의하고, 데이터를 백엔드로 내보낼 수 있도록 집계한 다음, 뷰를 구성한다. 제공되는 집계 방법으로는 count, distribution, sum, last value 등이 있다.
새로운 표준의 필요성
두 프로젝트가 인기를 얻으면서 사용자는 둘 중 어느 것을 이용하는 것이 더 적절한 방안인지 알기가 어려워지게 되었다. 또한, OpenCensus의 의존성 문제 때문에 OpenCensus를 필요로 하지만 라이브러리 충돌이나 OpenCensus 미지원 등의 이슈로 인해 OpenTracing과 OpenCensus을 혼합해서 사용하는 등 혼란스러운 상황이 증가하게 되었다.
결국 커뮤니티는 새로운 표준 분산 측정 방식에 대한 필요성을 강하게 느끼게 되었고, 이에 따라 등장하게 된 것이 OpenCensus과 OpenTracing을 마이그레이션한 새로운 표준 분산 측정 오픈소스 프로젝트인 OpenTelemetry가 등장하게 된 것이다.