OpenTelemetry란 무엇이며 어떻게 백엔드 품질을 향상시킬 수 있습니까?

과거에는 백엔드에 대해 이야기할 때 일반적으로 하나의 대규모 데이터베이스를 갖춘 하나의 대규모 애플리케이션을 언급했으며, 모니터링에는 로깅만으로 충분했습니다. 이제 Kubernetes 와 같은 기술 덕분에 마이크로서비스가 표준이 되었습니다. 애플리케이션은 더 많아지고 분산되어 있으며 기존 로깅으로는 애플리케이션의 문제를 디버깅 하고 진단하는 데 더 이상 충분하지 않습니다.

모니터링 구성을 위한 탁월한 솔루션은 분산 시스템의 디버깅 및 성능 분석에 사용할 수 있는 최신 툴킷인 OpenTelemetry입니다.

이 문서는 백엔드 최적화에 대한 지식을 확장하려는 IT 전문가를 위한 것입니다. 아래에서는 OpenTelemetry가 무엇인지, 핵심 개념과 해결에 도움이 되는 문제를 자세히 설명합니다. OpenTelemetry가 백엔드 시스템 모니터링 및 디버깅에 대한 접근 방식을 어떻게 변경하여 안정성과 효율성을 향상시킬 수 있는지 알고 싶다면 계속 읽어보세요.

OpenTelemetry의 간략한 역사

대규모 기술 기업은 2000년대 후반에 처음으로 분산 로깅 및 추적 문제에 직면했습니다. 2010년에 구글은 다음과 같은 논문을 발표했습니다. 대규모 분산 시스템 추적 인프라인 Dapper 는 2012년 출시된 트위터 추적 도구인 Zipkin의 기반을 마련했습니다.

2014년에는 마이크로서비스 및 기타 클라우드 분산 시스템의 개발을 크게 단순화하는 Kubernetes가 등장했습니다. 이로 인해 많은 회사에서 마이크로서비스의 분산 로깅 및 추적 문제에 직면하게 되었습니다. 분산 추적을 표준화하기 위해 CNCF에서 채택한 OpenTracing 표준과 Google의 OpenCensus 프로젝트가 만들어졌습니다.

2019년에 OpenTracing과 OpenCensus 프로젝트는 OpenTelemetry라는 이름으로 합병을 발표했습니다. 이 플랫폼은 수년간 축적된 모범 사례를 결합하여 복잡성에 관계없이 모든 시스템에 추적, 로깅 및 메트릭을 원활하게 통합할 수 있습니다.

오늘날 OpenTelemetry는 단순한 프로젝트가 아닙니다. 이는 원격 측정 데이터를 수집하고 전송하기 위한 업계 표준입니다. Google 및 Microsoft와 같은 시장을 선도하는 기업과 전문가 커뮤니티에서 개발하고 지원합니다. 프로젝트는 지속적으로 발전하여 통합 및 사용 프로세스를 단순화하는 새로운 기능을 확보하고 있습니다.

안에 무엇이 들어있나요?

OpenTelemetry는 애플리케이션이 외부 세계와 상호 작용하기 위해 생성할 수 있는 신호와 이러한 신호를 수집하고 시각화하여 애플리케이션 및 시스템 전체의 상태를 모니터링하는 방법을 정의하는 포괄적인 사례 및 도구 세트입니다. 세 가지 주요 신호 유형은 추적, 로깅 및 측정항목 수집 입니다.

**각 구성 요소를 자세히 살펴보겠습니다. \

컨텍스트

OpenTelemetry는 작업 컨텍스트라는 개념을 도입합니다. 컨텍스트에는 주로 `trace_id` (현재 작업의 식별자) 및 `span_id` (하위 요청의 식별자, 고유한 `span_id` 갖는 하위 요청의 각 재시도)와 같은 속성이 포함됩니다.

또한 컨텍스트에는 애플리케이션이 배포된 노드 이름이나 환경 이름(prod/qa)과 같은 정적 정보가 포함될 수 있습니다. OpenTelemetry 용어로 리소스라고 하는 이러한 필드는 더 쉬운 검색을 위해 모든 로그, 지표 또는 추적에 연결됩니다. 컨텍스트에는 로그, 지표 또는 추적 그룹에 선택적으로 연결할 수 있는 현재 엔드포인트의 식별자( `http_path: "GET /user/:id/info"` )와 같은 동적 데이터도 포함될 수 있습니다.

OpenTelemetry 컨텍스트는 컨텍스트 전파 프로토콜을 사용하여 다양한 애플리케이션 간에 전달될 수 있습니다. 이러한 프로토콜은 모든 HTTP 또는 gRPC 요청에 추가되는 헤더 세트 또는 대기열의 메시지 헤더로 구성됩니다. 이를 통해 다운스트림 애플리케이션은 이러한 헤더에서 작업 컨텍스트를 재구성할 수 있습니다.

다음은 컨텍스트 전파의 몇 가지 예입니다.

1. B3-Propagation 이것은 원래 Zipkin 추적 시스템용으로 개발된 헤더 세트( x-b3-* )입니다. OpenTracing에 적용되었으며 많은 도구와 라이브러리에서 사용되었습니다. B3-Propagation은 trace_id / span_id 와 샘플링이 필요한지 여부를 나타내는 플래그를 전달합니다.

   
   

2. W3C 추적 컨텍스트 W3C 작업 그룹에서 개발한 이 표준은 다양한 컨텍스트 전파 접근 방식을 단일 표준으로 통합하며 OpenTelemetry의 기본값입니다. 이러한 표준을 적용하는 좋은 예는 모니터링 및 디버깅 정확도를 저하시키지 않고 다양한 기술로 구현된 마이크로서비스를 통과하는 요청 실행을 추적하는 것입니다.

트레이싱

추적은 여러 마이크로서비스를 통해 요청 경로의 타임라인을 기록하고 시각화하는 프로세스입니다.

시각화에서 각 막대는 "span"이라고 하며 고유한 "span_id" 를 갖습니다. 루트 범위는 "trace" 라고 하며 전체 요청의 식별자 역할을 하는 "trace_id"를 갖습니다.

이러한 유형의 시각화를 사용하면 다음을 수행할 수 있습니다.

• 다양한 시스템과 데이터베이스에서 요청의 실행 시간을 분석하여 최적화가 필요한 병목 현상을 식별합니다.
• 서비스 간의 순환 종속성을 감지합니다.
• 중복 요청을 찾아보세요. 추적 데이터를 사용하면 마이크로서비스 맵을 생성하거나 작업 처리 중에 여러 시스템에 시간을 분배하는 등 추가 분석을 구축할 수도 있습니다. 타임라인을 시각화하기 위해 추적 데이터를 사용하지 않더라도 OpenTelemetry는 다른 신호에 사용할 수 있도록 trace_id 및 span_id 계속 생성합니다.

로그

명백한 단순성에도 불구하고 로깅은 여전히 문제 진단을 위한 가장 강력한 도구 중 하나입니다. OpenTelemetry는 상황별 정보를 추가하여 기존 로깅을 향상합니다. 특히 활성 추적이 있는 경우 `trace_id` 및 `span_id` 속성이 로그에 자동으로 추가되어 추적 타임라인에 연결됩니다. 또한 로그 속성에는 노드 식별자와 같은 OpenTelemetry 컨텍스트의 정적 정보뿐만 아니라 현재 HTTP 엔드포인트 식별자(`http_path: "GET /user/:id"`)와 같은 동적 정보도 포함될 수 있습니다.

`trace_id`를 사용하면 현재 요청과 관련된 모든 마이크로서비스에서 로그를 찾을 수 있으며, `span_id`를 사용하면 하위 요청을 구별할 수 있습니다. 예를 들어 재시도의 경우 다양한 시도의 로그는 서로 다른 'span_id'를 갖습니다. 이러한 식별자를 사용하면 전체 시스템 동작을 실시간으로 빠르게 분석할 수 있어 문제 진단 속도가 빨라지고 안정성과 신뢰성이 향상됩니다.

측정항목

지표 수집은 대기 시간, 오류율, 리소스 사용량 등과 같은 시스템 성능에 대한 정량적 데이터를 제공합니다. 지표를 실시간으로 모니터링하면 성능 변화에 신속하게 대응하고 장애 및 리소스 고갈을 방지하며 사용자를 위한 애플리케이션의 고가용성과 안정성을 보장할 수 있습니다.

Prometheus 및 Grafana와 같은 메트릭 스토리지 및 시각화 시스템과 통합하면 이 데이터를 더 쉽게 시각화하고 모니터링을 크게 단순화할 수 있습니다.

측정항목 수집기

OpenTelemetry 메트릭 수집기는 Prometheus 및 OpenMetrics 표준과 호환되므로 큰 변경 없이 OpenTelemetry 솔루션으로 쉽게 전환할 수 있습니다. OpenTelemetry SDK를 사용하면 측정항목과 함께 Trace_id 예제를 내보낼 수 있으므로 측정항목을 로그 예제 및 추적과 연관시킬 수 있습니다.

신호 상관관계

로그, 측정항목, 추적을 함께 사용하면 시스템 상태에 대한 포괄적인 보기가 생성됩니다.

• 로그는 시스템 이벤트에 대한 정보를 제공하므로 오류를 빠르게 식별하고 해결할 수 있습니다.
• 측정항목은 응답 시간, 오류율 등 시스템의 정성적, 정량적 성능 지표를 반영합니다.
• 추적은 다양한 시스템 구성 요소를 통해 요청 실행 경로를 표시하고 상호 관계를 이해하는 데 도움을 줌으로써 이러한 보기를 보완합니다. 로그, 추적 및 지표 간의 명확한 상관 관계는 OpenTelemetry의 독특한 기능입니다. 예를 들어 Grafana를 사용하면 사용자가 로그를 볼 때 해당 추적 및 요청 측정항목을 볼 수 있어 플랫폼의 유용성과 효율성이 크게 향상됩니다.

세 가지 핵심 구성 요소 외에도 OpenTelemetry에는 샘플링, 수하물 및 작업 컨텍스트 관리의 개념이 포함되어 있습니다.

견본 추출

로드가 높은 시스템에서는 로그 및 추적의 양이 엄청나므로 인프라 및 데이터 저장을 위한 상당한 리소스가 필요합니다. 이 문제를 해결하기 위해 OpenTelemetry 표준에는 추적 및 로그의 일부만 내보내는 기능인 신호 샘플링이 포함되어 있습니다. 예를 들어 요청 비율, 장기 실행 요청 또는 오류 요청에서 자세한 신호를 내보낼 수 있습니다. 이 접근 방식을 사용하면 상당한 리소스를 절약하면서 통계를 구축하기에 충분한 샘플링이 가능합니다.

그러나 각 시스템이 세부적으로 모니터링할 요청을 독립적으로 결정하는 경우 각 요청에 대한 단편적인 보기가 생성됩니다. 일부 시스템은 세부 데이터를 내보낼 수 있지만 다른 시스템은 부분적으로만 내보내거나 전혀 내보내지 않을 수 있습니다.

이 문제를 해결하기 위해 OpenTelemetry의 컨텍스트 전파 메커니즘은 `trace_id`/`span_id`와 함께 샘플링 플래그를 전송합니다. 이렇게 하면 사용자 요청을 수신한 초기 서비스에서 해당 요청을 자세히 모니터링해야 한다고 결정하면 다른 모든 시스템도 이를 따릅니다. 그렇지 않으면 모든 시스템은 자원을 절약하기 위해 신호를 부분적으로 내보내거나 내보내지 않아야 합니다. 이 접근 방식을 "헤드 샘플링"이라고 합니다. 이는 요청 처리 시작 시 무작위로 또는 일부 입력 속성을 기반으로 결정이 내려지는 방식입니다.

또한 OpenTelemetry는 모든 애플리케이션이 항상 모든 신호를 자세히 내보내지만 중간 버퍼가 존재하는 "테일 샘플링"을 지원합니다. 모든 데이터를 수집한 후 이 버퍼는 전체 데이터를 유지할지 아니면 부분 샘플만 유지할지 결정합니다. 이 방법을 사용하면 각 요청 범주(성공/장기/오류)의 보다 대표적인 샘플을 사용할 수 있지만 추가 인프라 설정이 필요합니다.

수하물

Baggage 메커니즘을 사용하면 임의의 키-값 쌍을 trace_id / span_id 와 함께 전송하여 요청 처리 중에 모든 마이크로서비스 간에 자동으로 전달할 수 있습니다. 이는 사용자 정보나 런타임 환경 설정 등 요청 경로 전체에 필요한 추가 정보를 전송하는 데 유용합니다.

W3C 표준에 따른 수하물 전송을 위한 헤더의 예: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

수하물 사용의 몇 가지 예는 다음과 같습니다.

• userId , productId 또는 deviceId 와 같은 비즈니스 컨텍스트 정보 전달은 모든 마이크로서비스를 통해 전달될 수 있습니다. 애플리케이션은 이 정보를 자동으로 기록하여 원래 요청에 대한 사용자 컨텍스트별 로그 검색을 허용합니다.

• SDK 또는 인프라에 대한 특정 구성 매개변수 설정입니다.

• 라우팅 플래그 로드 밸런서가 라우팅 결정을 내리는 데 도움이 되는 플래그입니다. 테스트 중에 일부 요청을 모의 백엔드로 라우팅해야 할 수도 있습니다. 수하물은 모든 서비스를 통해 자동으로 전송되므로 추가 프로토콜을 만들 필요가 없습니다. 로드 밸런서에 규칙만 설정하면 됩니다.

  
  

인프라 구현

인프라 수준에서 OpenTelemetry를 구현하려면 OpenTelemetry 백엔드를 애플리케이션 아키텍처에 통합하고 데이터 집계를 위한 인프라를 구성해야 합니다.

이 프로세스는 4단계로 구성됩니다.

1. 애플리케이션 통합 첫 번째 단계에서는 OpenTelemetry SDK가 애플리케이션에 직접 통합되어 메트릭, 로그 및 추적을 수집하여 각 시스템 구성 요소의 성능에 대한 지속적인 데이터 흐름을 보장합니다.

   
   

2. 내보내기 구성 수집된 데이터는 필요에 따라 로깅, 모니터링, 추적 또는 분석 시스템과 같은 추가 처리를 위해 내보내기를 통해 애플리케이션에서 외부 시스템으로 라우팅됩니다.

   
   

3. 집계 및 저장 이 단계에는 데이터 정규화, 추가 정보로 강화, 다양한 소스의 데이터 병합을 통해 시스템 상태에 대한 통합 보기가 포함될 수 있습니다.

   
   

4. 데이터 시각화 마지막으로 처리된 데이터는 Grafana(메트릭 및 추적용) 또는 Kibana(로그용)와 같은 시스템에서 대시보드로 표시됩니다. 이를 통해 팀은 시스템 상태를 신속하게 평가하고, 문제와 추세를 식별하고, 생성된 신호를 기반으로 경고를 설정할 수 있습니다.

애플리케이션 구현

애플리케이션과 통합하려면 사용 중인 프로그래밍 언어에 적합한 OpenTelemetry SDK를 연결하거나 OpenTelemetry를 직접 지원하는 라이브러리 및 프레임워크를 사용해야 합니다. OpenTelemetry는 알려진 라이브러리에서 널리 사용되는 인터페이스를 구현하는 경우가 많아 즉시 교체가 가능합니다. 예를 들어 Micrometer 라이브러리는 Java 생태계에서 메트릭 수집에 일반적으로 사용됩니다. OpenTelemetry SDK는 Micrometer 인터페이스 구현을 제공하므로 기본 애플리케이션 코드를 변경하지 않고도 메트릭 내보내기가 가능합니다. 또한 OpenTelemetry는 이전 OpenTracing 및 OpenCensus 인터페이스의 구현을 제공하여 OpenTelemetry로의 원활한 마이그레이션을 촉진합니다.

결론

IT 시스템에서 OpenTelemetry는 안정적이고 효율적인 백엔드의 미래를 여는 열쇠가 될 수 있습니다. 이 도구는 디버깅 및 모니터링을 단순화하고 새로운 수준에서 애플리케이션 성능 및 최적화를 깊이 이해할 수 있는 기회를 열어줍니다. OpenTelemetry 커뮤니티에 참여하여 백엔드 개발이 더욱 간단하고 효과적인 미래를 만들어 보세요!