OpenTelemetry는 OpenTracing과 OpenCensus라는 두 가지 이전 프로젝트를 합친 것입니다. 이 두 프로젝트는 모두 동일한 문제, 즉 코드를 계측하고 원격 측정 데이터를 식별 가능성 백엔드로 보내는 방법에 대한 표준이 없다는 문제를 해결하도록 구축되었습니다. 그러나 두 프로젝트 모두 자체적으로 문제를 완전히 해결할 수 없었기 때문에 두 프로젝트를 합쳐 OpenTelemetry를 형성했습니다. 두 프로젝트의 장점을 결합하여 진정한 단일 표준을 제공할 수 있도록 말입니다.

중요한 것은 OpenTelemetry는 벤더 및 도구에 구애받지 않는다는 점입니다. 즉, Jaeger 및 Prometheus와 같은 오픈 소스 도구뿐만 아니라 상용 제품을 비롯한 다양한 식별 가능성 백엔드와 함께 사용할 수 있습니다. OTel은 CNCF(Cloud Native Computing Foundation) 프로젝트로, 여러 언어를 포괄하는 강력하고 이식성이 뛰어나며 측정하기 쉬운 솔루션으로 기능하도록 구축되었습니다. 애플리케이션에서 분산 트레이스 및 메트릭을 캡처하도록 API, 라이브러리, 에이전트, 수집기 서비스 세트를 제공합니다. OpenTelemetry는 진정한 식별 가능성을 실현합니다.

‘식별 가능성’은 소프트웨어 엔지니어링 및 시스템 관리 분야에서 그 의미가 매우 희미해질 정도로 상당한 관심을 끌었던 용어입니다. 오늘날에는 IT 분야에 종사하는 사람들조차 모든 종류의 시스템 가시성을 의미하는 데 이 용어를 사용합니다. 그렇다면 식별 가능성이란 정확히 무엇이고, 기존 모니터링과 어떻게 다를까요?

식별 가능성은 모니터링과는 엄연히 다릅니다.

모니터링은 일반적으로 사전 정의된 임계값과 경보를 사용하여 시스템의 상태를 적극적으로 감시하고 확인하는 프로세스입니다. 모니터링을 할 경우 문제가 발생할 경우 영향을 받는 시스템에 주의를 기울일 수 있지만, 문제가 발생한 이유나 최상의 해결 방법에 대한 인사이트를 얻을 수는 없는 경우가 많습니다.

반면 식별 가능성은 보다 포괄적인 접근 방식으로, 외부 출력을 분석하여 시스템 내부의 상황을 파악하는 능력을 의미합니다. 식별 가능성을 사용하면 알고 싶은 내용을 사전에 정의하지 않고도 언제든지 발생한 상황에 대해 질문할 수 있습니다. 기본적으로 모니터링은 문제가 발생한 시점을 알려줄 수 있지만, 식별 가능성은 문제가 발생한 이유를 이해하는 데 도움을 줍니다.

트레이스, 메트릭 및 로그

식별 가능성에 필수적인 세 가지 핵심 요소는 다음과 같습니다.

• 트레이스
  트레이스는 시스템을 통해 전달되는 요청의 전체 경로를 나타내며, 서비스 상호 작용에 대한 상세한 정보를 제공할 수 있습니다. OpenTelemetry 트레이스는 속성과 이벤트를 포함하는 스팬으로 구성되어 다양한 프로세스와 서비스에서 수행되는 작업을 설명하고 컨텍스트화합니다.
• 메트릭
  메트릭은 시간 간격에 따라 측정된 데이터를 수치로 표현한 것입니다. 이를 통해 시스템 성능 및 동작을 지속적으로 모니터링할 수 있습니다. OpenTelemetry에서 Metrics API를 사용하여 시스템 메트릭을 기록, 설정, 추가할 수 있으며, 나중에 필터링 및 분석 집계 도구를 제공합니다.
• 로그
  로그는 시스템 및 애플리케이션에서 생성되는 텍스트 기반 기록입니다. 이벤트를 시간순으로 설명하며 시스템 동작을 디버깅하고 이해하는 데 매우 중요합니다.

이러한 세 가지 요소는 오랫동안 식별 가능성의 가장 중요한 필수 요소로 간주되었지만, 현대적 분산 시스템의 규모와 복잡성이 증가함에 따라 이 기존 모델도 진화해야 했습니다. 실무자들은 이 세 가지 핵심 요소가 격리되어 있지 않고 기본적으로 상호 연결되어 있으며 서로 조율을 통해 사용되어야 한다는 사실을 인식하기 시작했습니다.

OpenTelemetry는 분산된 마이크로서비스 기반 시스템에서 식별 가능성을 지원하는 데 중요한 역할을 합니다. 대부분의 언어, 특히 익스포트 도구 및 수집기 모델에서 이식성, 구현 가용성, 소프트웨어 개발 키트(SDK)에 중점을 두면서 OpenTelemetry는 시스템에 적합한 데이터를 수집하고 배포하는 데 핵심 도구가 되었습니다.

OpenTelemetry를 통해 팀은 시스템 동작을 분석하는 데 필요한 주요 트레이스 및 메트릭 데이터를 효율적으로 수집할 수 있습니다. 이러한 식별 가능성 관행에 맞춰 조정하면 시스템 성능을 보다 심도 있게 이해할 수 있으므로 문제를 진단하고 해결할 수 있는 능력이 개선됩니다.

OpenTelemetry에서 추적이란?

트레이스가 식별 가능성의 세 가지 핵심 요소 중 하나인 것처럼 추적은 소프트웨어 개발의 중요한 관행이며, 일반적으로 특수 디버깅 도구를 통해 애플리케이션 코드를 프로파일링하고 분석하는 데 사용됩니다. OpenTelemetry라는 맥락에서 추적은 보다 미묘한 의미를 가지는데, 오늘날의 복잡한 아키텍처에서 필수적 개념인 분산 추적을 지칭하는 경우가 많습니다.

분산 추적

분산 추적은 최신 마이크로서비스 기반 애플리케이션에 기존 추적 기술을 적용하는 것을 나타냅니다. 장애를 진단하는 데 단일 스택 트레이스가 포함될 수 있는 모놀리식 애플리케이션과 달리, 분산 시스템은 이 접근 방식을 적용하기에는 너무 복잡합니다. 애플리케이션이 수많은 호스트에서 실행되는 수천 개의 서비스로 구성되면 개별 트레이스만으로는 부족합니다. 분산 추적은 서로 다른 서비스 경계를 넘어 이동할 때 요청을 프로파일링하여 분석을 위한 고품질 데이터를 생성함으로써 이 문제를 해결합니다. 이 방법은 다음과 같은 기능을 제공합니다.

• 이상 탐지 
• 작업 부하 모델링 
• 정상 상태 문제 진단

트레이스 및 스팬

OpenTelemetry에서 트레이스는 연결된 스팬의 모음으로, 요청의 작업 단위를 나타내는 이름과 시간이 지정된 작업입니다. 스팬에는 상위 항목이 있거나, 전체 트레이스의 엔드 투 엔드 지연 시간을 나타내는 루트 스팬일 수도 있습니다. 하위 스팬은 트레이스 내의 하위 작업을 나타냅니다.

• 루트 스팬
  전체 요청의 지연 시간을 나타내는 트레이스의 상위 또는 시작 지점입니다. 
• 하위 스팬
  트레이스 내의 특정 하위 작업입니다.

스팬은 작업의 이름, 시작 및 종료 타임스탬프, 이벤트, 스팬 기간 동안 발생한 속성을 포함하여 필수 정보를 캡슐화합니다. 또한 다른 스팬과 작업 상태에 대한 링크도 포함합니다.

속성 및 이벤트

분산 시스템 트레이스 데이터의 복잡성을 고려할 때 컨텍스트 및 기타 관련 세부 정보에 액세스할 수 있으면 데이터 분석에 긍정적인 영향을 줄 수 있습니다. OpenTelemetry에서는 이러한 태그를 속성 및 이벤트라고 합니다.

• 속성
  트레이스 데이터 분석을 지원하기 위해 스팬에 추가할 수 있는 키-값 쌍(OpenTracing에서는 ‘태그’라고 함)입니다.
• 이벤트
  추가 설명을 제공하여 보다 자세한 분석을 가능하게 하는 선택적 속성 세트가 포함된 타임스탬프 문자열입니다.

추적기 및 전파기

OpenTelemetry의 스팬은 현재 활성 스팬을 추적하고 새로운 스팬을 생성할 수 있는 개체인 추적기에서 생성합니다. 전파기 개체는 분산 시스템에서 추적의 중요한 측면인 프로세스 경계 간의 컨텍스트 전송을 지원합니다. 추적기는 완료된 스팬을 OTel의 SDK 익스포트 도구로 디스패치하고 추가 분석을 위해 스팬을 백엔드 시스템으로 전송합니다.

추적은 개별 요청 및 운영에 대한 자세한 인사이트를 제공하지만, 메트릭을 비롯한 OpenTelemetry 내의 식별 가능성이라는 광범위한 맥락과도 연관됩니다. 트레이스 데이터를 관련 메트릭과 연결함으로써 조직은 시스템의 동작과 성능을 포괄적으로 이해할 수 있습니다.

OpenTelemetry의 맥락에서 Metrics API는 원시 측정값을 지속적으로 처리하고 요약하도록 설계되었습니다. 이를 통해 조직은 프로세스 메모리 사용률, 오류율 등을 비롯한 중요한 운영 메트릭에 대한 가시성을 높일 수 있습니다. 메트릭은 집계 및 기록을 위해 다양한 기기로 전송될 수 있습니다. OpenTelemetry Metrics API는 메트릭 기기가 익스포트하는 최종 가치 유형이 아닌 시맨틱에 따라 메트릭 기기를 분류합니다.

OpenTelemetry의 메트릭 기기

Metrics API는 각각 특정 기능을 수행하는 6개의 개별 메트릭 기기를 제공합니다. 이러한 기기는 사용자의 SDK 엔트리포인트인 Meter API 호출을 통해 생성 및 정의됩니다. 메트릭 기기는 동기식 또는 비동기식이 있습니다.

동기식 기기

동기식 기기는 요청 내에서 호출되며 연결된 분산 컨텍스트를 소유합니다. 동기식 기기에는 다음이 포함됩니다.

• Counter
  Counter 기기는 Add() 함수를 사용해 양의 값을 허용합니다. 이 카운터는 수신된 바이트, 완료된 요청 등의 데이터를 계수하고 오류 인시던트를 측정하는 데 적합하며, 특히 데이터량을 측정하는 데 적합합니다.
• UpDownCounter
  카운터 기능을 확장한 UpDownCounter는 Add() 함수를 통해 양의 증분과 음의 증분을 모두 처리합니다. 이 카운터는 활성 요청, 사용 중인 메모리, 큐 크기와 같은 수량을 모니터링하는 데 유용합니다.
• ValueRecorder
  ValueRecorder 기기는 Record() 함수를 사용하여 이산 이벤트의 값을 캡처합니다. 이는 지연 시간, 요청 크기, 큐 길이를 캡처하는 데 사용되며 값의 분산을 강조합니다.

비동기식 기기

동기식 기기와 달리 비동기식 기기에는 관련 컨텍스트가 없습니다. 이러한 기기는 콜백에 의해 보고되며 수집 간격당 한 번만 호출됩니다. 동기식 기기에는 다음이 포함됩니다.

• SumObserver
  SumObserver 기기는 비동기 단조 합계에 Observe() 함수를 사용하며 캐시 누락 및 시스템 CPU와 같은 데이터에 가장 적합합니다. 
• UpDownSumObserver
  UpDownSumObserver는 Observe() 함수로 양의 합계와 음의 합계를 허용하는 비단조 비동기식 카운터입니다. 이 기기는 프로세스 힙 크기와 같이 합계의 상승과 하락을 캡처하는 측정에 사용됩니다.
• ValueObserver
  마지막으로 ValueObserver를 사용하면 조직은 Observe() 함수를 사용하여 비가산 측정을 세밀하게 제어할 수 있습니다. 이 기기는 분포를 측정하는 데 적합합니다.

메트릭 이벤트의 구성

모든 기기에서 캡처한 메트릭 이벤트는 타임스탬프, 계측 정의(이름, 종류, 설명, 측정 단위), 라벨 세트(키 및 값), 값(정수 또는 부동 소수점 숫자), SDK와 연결된 자원, 분산 컨텍스트(동기 이벤트에만 해당)로 구성됩니다. 사용 가능한 다양한 메트릭 기기는 다양한 유형의 데이터를 유연하게 캡처할 수 있으므로, 다양한 시스템 속성의 분석 및 모니터링에 도움을 줍니다.

오류율, 지연 시간 또는 자원 사용률을 모니터링하는 경우 OpenTelemetry의 메트릭 기기는 개발자가 애플리케이션에 대한 중요한 인사이트를 얻을 수 있는 다양한 옵션을 제공합니다.

익스포트 도구는 분석 및 경보를 위해 원격 측정 데이터를 백엔드 시스템으로 일괄 처리 및 전송하는 역할을 담당합니다. OpenTelemetry의 익스포트 도구 모델은 다음 세 가지 수준에서 계측을 통합할 수 있도록 지원합니다.

• 서비스 수준 통합
  여기에는 코드 내의 관련 OpenTelemetry 패키지에 대한 종속성을 선언하고 그에 따라 배포하는 작업이 포함됩니다.
• 라이브러리 종속성
  서비스 수준 통합과 유사하지만, 일반적으로 라이브러리별로 OpenTelemetry API에 대한 종속성만 선언합니다.
• 플랫폼 종속성
  Envoy 및 Istio와 같이 서비스를 지원하는 독립 소프트웨어 구성요소입니다. OpenTelemetry의 사본을 배포하고 서비스에 유용한 트레이스 컨텍스트를 내보냅니다.

OpenTelemetry SDK에 의해 구현되는 익스포트 도구 인터페이스는 데이터를 전송하기 전에 원격 측정 데이터를 특정 백엔드 시스템에 필요한 형식으로 변환하는 플러그인 모델을 사용합니다. 이 모델은 또한 익스포트 도구의 구성과 체이닝을 지원하여 다양한 프로토콜 간에 기능을 공유할 수 있도록 합니다.

OpenTelemetry 접근 방식의 중요한 이점 중 하나는 익스포트 구성요소를 쉽게 전환하거나 추가할 수 있다는 것입니다. 이는 시스템을 변경하기 위해 전체 추적기 구성요소를 교체해야 하는 OpenTracing과 구분됩니다.

익스포트 도구 모델은 매우 편리하지만, 특정 조직적 제약 또는 기술적 제약으로 인해 새로운 익스포트 도구를 추가하기 위해 서비스를 쉽게 재배포하지 못할 수 있습니다. OpenTelemetry 수집기는 ServiceNow 클라우드 식별 가능성, Jaeger 또는 Prometheus와 같은 다양한 백엔드 시스템으로 익스포트하여 여러 프로세스의 원격 측정 데이터를 위한 '저장소'로 작동하도록 설계되었습니다. 수집기는 서비스와 함께 에이전트로 배포하거나 원격 애플리케이션으로 배포할 수 있습니다.

• 에이전트
  서비스와 함께 배포되어 별도의 프로세스 또는 사이드카로 실행됩니다. 
• 원격 수집기
  컨테이너 또는 가상 머신에 별도로 배포되어 각 에이전트로부터 원격 측정 데이터를 수신하고 백엔드 시스템으로 익스포트합니다.

OpenTelemetry는 다음과 같은 주요 구성요소로 구성됩니다.

• 모든 구성요소의 사양
• 원격 측정 데이터의 형태를 정의하는 표준 프로토콜
• 일반적인 원격 측정 데이터 유형에 대한 표준 명명 체계를 정의하는 시맨틱 규칙
• 원격 측정 데이터 생성 방법을 정의하는 API
• 공통 라이브러리 및 프레임워크의 계측을 구현하는 라이브러리 에코시스템
• 코드 변경 없이 원격 측정 데이터를 생성하는 자동 계측 구성요소
• 원격 측정 데이터의 사양, API, 익스포트를 구현하는 언어 SDK
• 원격 측정 데이터를 수신, 처리, 익스포트하는 프록시인 OpenTelemetry 수집기
• 기타 다양한 도구(예: Kubernetes용 OpenTelemetry 오퍼레이터)

호환성

다양한 오픈 소스 에코시스템 통합과 호환되는 OpenTelemetry는 수많은 벤더의 지원을 받고 있으며, 이들 중 다수는 OpenTelemetry에 대한 상업적 지원을 제공하고 프로젝트에 직접 기여하고 있습니다.

확장성

OpenTelemetry는 확장이 가능하도록 설계되었습니다. 확장 방법의 몇 가지 예는 다음과 같습니다.

• 사용자 지정 소스의 원격 측정 데이터를 지원하기 위해 OpenTelemetry 수집기에 수신기 추가
• 사용자 지정 계측을 SDK로 로드
• 특정 사용 사례에 맞춘 SDK 또는 수집기 배포 생성
• 아직 OpenTelemetry 프로토콜(OTLP)을 지원하지 않는 사용자 지정 백엔드에 대한 새 익스포트 도구 생성
• 비표준 컨텍스트 전파 양식에 대한 사용자 지정 전파기 생성

대부분의 사용자는 OpenTelemetry를 확장할 필요가 없지만 프로젝트는 거의 모든 수준에서 확장 가능하도록 설계되었습니다.

OpenTelemetry가 중요한 이유

클라우드 컴퓨팅과 마이크로서비스 아키텍처가 등장하고 비즈니스 요구 사항이 갈수록 복잡해지면서 식별 가능성에 대한 필요성이 더욱 커졌습니다.

시스템을 관찰할 수 있게 만들려면 계측이 필요합니다. 즉, 코드는 트레이스, 메트릭, 로그를 내보내야 합니다. 그런 다음 계측된 데이터를 식별 가능성 백엔드로 보내야 합니다.

OpenTelemetry는 두 가지 중요한 역할을 합니다.

• 독점 데이터 형식이나 도구에 얽매이지 않고 생성한 데이터를 소유할 수 있습니다.
• 단일 API 및 규칙 세트로 학습할 수 있습니다.

이러한 두 가지 요소의 결합으로 팀과 조직은 오늘날의 컴퓨팅 세계에서 필요한 유연성을 확보할 수 있습니다.

OpenTelemetry는 Jaeger, Prometheus 또는 상용 벤더와 같은 식별 가능성 백엔드가 아닙니다. OpenTelemetry는 원격 측정 데이터의 생성, 수집, 관리 및 익스포트에 중점을 둡니다. 해당 데이터의 저장 및 시각화는 의도적으로 다른 도구를 통해 이루어집니다.

엔드 투 엔드 가시성이 필요한 경우가 점점 더 많아지고 있습니다. OpenTelemetry는 다양한 애플리케이션과 프로그래밍 언어에 걸쳐 원격 측정 데이터 수집에 대한 표준화된 접근 방식을 제공합니다. OTel은 시스템 동작에 대한 포괄적인 인사이트를 제공하여 조직이 성과를 최적화하고 문제를 해결하며 원활한 사용자 경험을 제공할 수 있도록 지원합니다. 그러나 식별 가능성의 경우 항상 개선의 여지가 있습니다.

ServiceNow 클라우드 식별 가능성(이전 명칭: Lightstep)은 요청이 서비스 및 기타 인프라를 통해 전송될 때 원격 측정 데이터(트레이스, 로그, 메트릭)를 가져오는 방법으로 OpenTelemetry를 지원합니다. 클라우드 식별 가능성은 기본 OpenTelemetry 프로토콜(OTLP)을 통해 OpenTelemetry 데이터를 수집합니다. 그런 다음 HTTP 또는 gRPC를 통해 OTLP 데이터를 클라우드 식별 가능성으로 익스포트할 수 있습니다.

클라우드 네이티브 환경에서 식별 가능성과 거버넌스를 더욱 개선하기 위해 ServiceNow는 OpenTelemetry용 서비스 그래프 커넥터(SGC)도 출시했습니다. OpenTelemetry 데이터와 ServiceNow 클라우드 식별 가능성 백엔드를 활용하는 이 솔루션은 기업이 클라우드 네이티브 애플리케이션과 Kubernetes 인프라에 대한 가시성과 인사이트를 얻는 방법을 혁신합니다. SGC는 서비스 종속성을 자동으로 검색하고 매핑하여 정확한 최신 서비스 토폴로지를 생성합니다. 이 솔루션은 조직이 변경의 영향을 평가하고, 인시던트 관리를 간소화하고, 부서 간 공동 작업을 촉진할 수 있도록 지원하여 효율성을 개선하고, 위험을 줄이며, 복잡한 IT 환경에 대한 최상의 식별 가능성을 보장합니다.

OpenTelemetry용 서비스 그래프 커넥터의 혁신적인 기능을 경험하려면 지금 ServiceNow에 문의하세요.