분산 추적: 과거, 현재, 미래

분산 추적은 의견이 분분한 주제입니다. 모든 KubeCon의 기본 기술이었던 이 기술은 관측 가능성에 혁명을 일으킬 것으로 예상되었습니다.

5년이 지난 지금, 과대광고는 어느 정도 가라앉았고, 고통에 대한 이야기가 더 많아 졌으며, 채택률은 적당했습니다. 한편, 기술 확장 및 표준화를 위한 꾸준한 활동이 계속되고 있습니다. Open Telemetry(OpenTracing 기반)는 Kubernetes 다음으로 두 번째로 큰 CNCF 프로젝트 입니다. 그렇다면 분산 추적과의 거래는 무엇입니까? 즉시 구현해야 할까요, 아니면 기다려 봐야 할까요?

이 문서에서는 분산 추적을 자세히 살펴보겠습니다.

1. 분산 추적의 특별한 점은 무엇이며 왜 필요한가요?
2. 오늘날 분산 추적의 문제점은 무엇입니까?
3. 다가오는 개발은 무엇이며 기존 과제를 어떻게 해결합니까?

소개 - 분산 추적 작동 방식

초보자를 위한 분산 추적은 분산 환경의 여러 구성 요소/마이크로 서비스를 통과하면서 단일 요청을 추적할 수 있는 기술입니다. 요청 경로에서 이루어진 각 네트워크 호출은 캡처되어 범위로 표시됩니다.

이를 활성화하기 위해 분산 추적 도구는 고유한 추적 컨텍스트(추적 ID)를 각 요청의 헤더에 삽입하고 추적 컨텍스트가 요청 경로 전체에 전파되도록 하는 메커니즘을 구현합니다.

분산 추적이 요청 경로를 나타내는 방법

우선 분산 추적이 필요한 이유

분산 추적은 관찰 가능성의 단위로 요청 에 초점을 맞춘다는 점에서 독특합니다. 모니터링/측정 플랫폼에서 구성 요소 (예: 서비스, 호스트)는 관찰되는 기본 단위입니다. 시간이 지남에 따라 이 단위 전체의 동작에 대해 이러한 플랫폼에 질문을 할 수 있습니다. 예를 들어 특정 기간 동안 이 서비스의 상태/처리량/오류율은 어떻습니까?

로그에서 관찰되는 기본 단위는 이벤트 입니다. 예를 들어 코드 실행 중에 이벤트가 발생할 때마다 일부 정보를 인쇄합니다. 이러한 "이벤트"는 개발자가 코드를 작성하는 동안 주관적으로 정의됩니다. 로그의 문제점은 모든 구성요소가 분리되어 있고 각 구성요소가 고유한 형태의 로그 메시지를 별도로 인쇄하며 서로 연결하여 이해하기 쉬운 방법이 없다는 것입니다.

이와 대조적으로 분산 추적에서는 여러 구성 요소를 통과하는 단일 요청이 관찰됩니다. 이를 통해 우리는 분산 시스템 전체에 대해 질문하고 복잡하고 상호 연결된 시스템에서 어떤 일이 발생했는지 이해할 수 있습니다.

분산 추적의 기본 사례는 요청에 대한 이러한 방향이 최종 사용자의 경험 에 가장 가깝다는 주장에 있습니다. 결과적으로 이는 분산 아키텍처를 검사하고 문제를 해결하는 방법에 있어서 가장 직관적이기도 합니다.

분산 추적의 발전

지난 10년 동안 분산 소프트웨어 아키텍처가 널리 채택되면서 분산 추적의 중요성이 높아졌습니다.

최신 마이크로서비스 기반 아키텍처는 요청-응답 시스템을 사용하는 것이 일반화되었던 90년대 후반 인터넷 성장 스토리에서 발전된 것입니다.

"90년대 후반과 인터넷의 폭발적인 성장으로 인해 웹 서버 프런트엔드와 데이터베이스 백엔드를 갖춘 2계층 웹사이트와 같은 요청-응답 시스템이 엄청나게 확산되었습니다... 요청은 시스템에 대한 추론을 위한 새로운 차원이었습니다. , 전체적으로 하나의 기계 또는 프로세스와 직교합니다."

- 실제 분산 추적, O'Reilly Media

이러한 마이크로서비스 아키텍처에서는 모든 단일 요청이 결국 수많은(10~100개의 마이크로서비스)에 도달하고 그 사이에 여러 네트워크 호출이 발생합니다. 3000개 이상의 서비스가 있는 Uber의 마이크로서비스 아키텍처는 아래를 참조하세요.

2018년 Uber의 마이크로서비스 아키텍처. 출처: https://www.uber.com/en-IN/blog/microservice-architecture/

이러한 복잡한 시스템에서는 모든 형태의 문제 해결에 분산 추적이 중요합니다. 결과적으로 분산 추적은 대규모의 복잡한 분산 환경을 사용하는 얼리 어답터인 대기업에 의해 개척되었습니다.

• 2010년에 발표된 Google의 Dapper 논문은 분산 추적의 시작이었습니다.

  
  

• 향후 몇 년 동안 두 회사가 더 많은 회사가 자체 분산 추적 시스템을 오픈 소스화했습니다(2012년 Twitter 오픈 소스 Zipkin, 2017년 Uber 오픈 소스 Jaeger). Zipkin과 Jaeger는 오늘날에도 계속해서 가장 인기 있는 분산 추적 도구 중 하나입니다.

  
  

• 2016년부터 OpenTracing 프로젝트를 통해 구성 요소 전반에 걸쳐 분산 추적을 표준화하려는 상당한 노력이 있었습니다. OpenTracing은 결국 2019년에 OpenTelemetry 가 되었습니다. OpenTelemetry는 널리 사용되며 전 세계적으로 수천 명의 기여자를 보유하고 있습니다.

  
  

• 이제 분산 추적은 측정항목 및 로그와 함께 관찰 가능성의 세 번째 "기둥"으로 널리 간주됩니다. 대부분의 주요 모니터링 및 관측 가능성 플레이어는 제품의 일부로 분산 추적 도구를 제공합니다.

분산 추적의 상태: 이론과 현실

그러나 이러한 기대와 기대, 커뮤니티의 노력에도 불구하고 현재 분산 추적 채택률은 약 25%입니다. 분명히 분산 추적이 필요함에도 불구하고 로그와 메트릭을 사용하는 마이크로서비스 아키텍처를 사용하는 회사를 찾는 것은 드문 일이 아닙니다.

동시에, 오늘날 전 세계적으로 평균 해결 시간 생산 오류가 증가하고 있습니다. 73%의 기업이 현재 생산 문제를 해결하는 데 1시간 이상 걸린다고 보고했습니다 .

개발자에게 인생에서 가장 고통스러운 순간이 무엇인지 물어보면 수백 명의 사람들이 숨을 헐떡이는 것처럼 보이는 프로덕션 환경에서 Sev-1 오류를 디버깅하는 데 소요된 시간에 대해 이야기할 것입니다.

그렇다면 MTTR(거의 모든 회사)에 관심이 있는 모든 회사는 분산 추적을 사용해야 하며 이 환경에서 채택이 급증했어야 합니다. 그러나 실제 숫자는 이를 뒷받침하지 않습니다. 그렇다면 무엇이 제공됩니까?

오늘날 분산 추적의 과제

오늘날 분산 추적에는 기업이 가치를 얻기 위해 극복해야 하는 몇 가지 문제가 있습니다. 이 모든 문제는 주류 이야기에서 널리 논의되지 않습니다.

1. 구현이 어렵다!

현재 서비스에서 분산 추적을 구현하려면 코드를 변경하고 릴리스해야 합니다. 코드 변경은 관찰 가능성을 요구하는 일반적인 요구 사항이지만 특히 분산 추적의 과제는 분산 추적 또는 추적 중단을 얻으려면 모든 서비스 또는 구성 요소를 계측해야 한다는 것입니다.

모니터링이나 로깅처럼 단일 서비스를 시작하고 가치를 실현할 수는 없습니다. 분산 추적에서는 사용 가능한 추적을 생성하기 위해 집합적인 서비스 집합 에 대한 계측이 필요합니다.

이를 위해서는 서비스를 변경하기 위해 여러 팀과 서비스 소유자 간의 조정이 필요합니다. 따라서 이는 조직의 문제가 됩니다. 가치를 실현하기 전에 수백 개의 팀이 몇 달에 걸쳐 서비스를 계측한다고 상상해 보십시오.

이것이 오늘날 분산 추적의 가장 큰 과제입니다.

2. 복잡한 샘플링 결정의 필요성

다음으로, 분산 추적으로 생성된 추적 데이터의 양이 엄청날 수 있습니다. 각각의 단일 요청 에 대해 소량의 추적 데이터를 내보내는 수백 개의 서비스를 상상해 보십시오. 이는 초당 수백만 건의 요청이 될 것이며, 분산 추적은 저장소와 네트워크 대역폭 측면에서 비용이 많이 듭니다.

로깅도 동일한 작업을 수행하지만(요청당 더 많은 데이터를 내보내고 대규모 로그 집계 도구로 관리됨) 차이점은 오늘날 대부분의 회사가 이미 로깅을 갖추고 있다는 것입니다. 로깅만큼 방대할 데이터 유형을 하나 더 도입하는 것은 어려운 작업이며 지출이 두 배로 늘어날 가능성이 높습니다.

이러한 비용 문제를 처리하기 위해 오늘날 모든 분산 추적 시스템은 샘플링을 사용하고 추적의 하위 집합만 기록합니다. 오늘날 실제로 일반적인 샘플링 속도는 0.1%에서 2% 사이입니다. 그 근거는 샘플의 1%라도 성능 병목 현상이 있는 위치에 대한 적절한 종합적 그림을 제공하기에 충분하다는 것입니다.

오늘날 대부분의 플랫폼에서는 고객이 샘플링 전략을 선택하고 비용과 가시성을 스스로 절충할 수 있습니다. 그러나 이러한 결정 프로세스는 분산 추적 시스템을 계측하고 관리하는 데 있어 이미 복잡한 오버헤드를 추가합니다.

3. 그러나 샘플링은 가치를 의미있게 감소시킵니다.

회사가 모든 서비스/구성 요소를 계측한 다음 큰 손실이 발생하지 않도록 샘플링 전략을 결정하는 노력을 한다고 가정해 보겠습니다.

이제 어떻게 될까요? MTTR이 급격히 떨어질 것으로 예상해야 할까요? 아니요. 개발자는 샘플링으로 인해 분산 추적을 사용하여 실제로 문제를 해결할 수 없기 때문입니다.

개발자의 경험을 상상해 보십시오. " 내가 알고 있는 문제를 찾을 수 없습니다. 오류를 생성했지만 해당 추적을 찾을 수 없습니다."

그러면 어떻게 되나요? 개발자는 분산 추적 데이터의 품질에 대한 신뢰를 중단하고 디버깅/문제 해결을 위한 일반적인 방법(예: 로그 사용)으로 되돌아갑니다.

4. 개발자 사용 빈도가 낮습니다.

이러한 제약 조건을 고려하여 오늘날 분산 추적은 주로 성능 문제를 해결하는 방법으로 판매됩니다.

기본 분산 추적은 실제로 누가 전화했는지, 각 범위에 걸린 시간을 알려준다는 점을 기억하세요. 분산 추적은 오류/긴 대기 시간을 유발한 서비스 내에서 어떤 일이 발생했는지 알려주지 않습니다. 이를 위해 개발자는 여전히 로그 메시지를 확인하거나 로컬에서 문제를 재현하여 디버그해야 합니다.

일반적인 회사에서는 성과 문제가 전체 문제의 10% 미만일 가능성이 높습니다. 따라서 실제로 분산 추적은 이 작은 문제에만 유용합니다.

서비스를 제공하고 소유하는 평균 개발자는 분산 추적 도구를 1년에 2~3회 정도 사용합니다.

이러한 모든 과제의 영향

요약하자면:

1. 분산 추적은 구현하기 어렵습니다.
2. 분산 추적에는 비용을 제어하기 위해 광범위한 샘플링이 필요합니다.
3. 그러나 샘플링을 하면 값이 상당히 감소합니다.
4. 결과적으로 개발자는 이상한 일회성 성능 사용 사례에만 추적을 사용합니다.

이 모든 것이 분산 추적에 대한 RoI 사례를 매우 모호하게 만듭니다.

전형적인 과대광고 사이클에서 우리가 말할 수 있는 것은 이제 우리는 과장된 기대의 단계를 지나 환멸이 자리잡기 시작했다는 것입니다.

하지만 최종 상태 측면에서 생각해 보면 컴퓨팅 시스템의 미래가 분산되어 있다면 분산 추적은 당연히 관찰 가능성을 위한 가장 기본적인 벡터입니다. 그 세계에서 분산 아키텍처를 사용하는 모든 회사는 오늘날 우리가 사용하는 시스템의 수동적 모니터링에 비해 프로덕션에서 발생하는 모든 문제를 해결하기 위한 기본 메커니즘(진정한 "관찰 가능성")으로 추적을 사용합니다.

하지만 최종 상태에 도달하려면 현재 상태에 비해 몇 가지 개선이 필요합니다. 좋은 소식은 이 중 많은 부분이 이미 진행되고 있다는 것입니다. 각각을 살펴보겠습니다. 그렇다면 우리는 미래에 무엇을 볼 수 있을까요?

분산 추적의 미래

코드 변경 없이 즉각적인 계측

에이전트를 투입하고 코드 변경 없이 전체 분산 시스템(모든 서비스, 구성 요소)을 한 번에 처리할 수 있다고 상상해 보십시오.

이는 향후 2~3년 안에 현실적으로 가능할 것으로 보인다.

OpenTelemetry의 자동 계측 라이브러리는 이미 일부 프로그래밍 언어에서 이 기능을 지원합니다(그러나 Go와 같은 컴파일된 언어에서는 부족함). 이와 동시에 eBPF와 같은 기술은 코드 변경 없이 시스템 전체에 계측을 가능하게 하기 위해 발전하고 있습니다. 둘 사이에서 우리는 계측 문제가 몇 년 안에 해결될 것이라고 안전하게 기대할 수 있습니다.

샘플링을 통해 AI 기반 관심 요청 선택이 가능해졌습니다.

LLM 세계에서는 무작위 샘플링이 암흑기의 유물처럼 보이기 시작합니다. 이상적으로는 흔적을 100% 조사하고, 이상해 보이는 모든 것을 식별하고, 향후 검사를 위해 저장할 수 있어야 합니다. 더 이상 무작위 샘플링이 없습니다.

생각해 보면 우리는 ~95%의 "행복한 요청"에 대해 별로 신경 쓰지 않습니다. 우리는 오류, 예외, 긴 대기 시간 또는 일종의 소프트 오류 등 비정상적인 추적의 ~5%에만 관심을 갖습니다. 따라서 우리는 100%를 보고 흥미로운 5%를 골라낼 수 있는 방법이 필요합니다.

오늘날 이를 수행하는 것을 목표 로 하는 꼬리 기반 샘플링 과 같은 메커니즘이 있습니다. 테일 기반 샘플링에서 시스템은 요청의 모든 범위가 완료될 때까지 기다린 다음 전체 추적을 기반으로 이를 유지해야 하는지 여부를 결정합니다.

테일 기반 샘플링의 주요 과제는 전체 요청이 완료될 때까지 트레이스의 모든 범위를 저장한 다음 트레이스를 유지할지/삭제할지 여부를 결정해야 한다는 것입니다. 즉, 특정 기간(요청이 완료될 때까지) 동안 모든 범위의 모든 단일 요청을 저장합니다. 이를 위해서는 매우 복잡하고 비용이 많이 드는 로드 밸런싱, 저장 및 처리를 위한 구성 요소가 포함된 별도의 데이터 아키텍처가 필요합니다.

OpenTelemetry에는 테일 기반 샘플링 수집기가 있지만 아직 성숙하지 않았으며 위에서 언급한 문제로 인해 몇 가지 확장성 문제가 있습니다. 한편, ZeroK.ai를 포함한 여러 회사는 AI를 사용하여 이상 탐지를 효율적이고 확장 가능하게 만들기 위해 노력하고 있습니다.

이 분야의 빠른 개발 속도로 인해 우리는 이 문제도 향후 3~5년 내에 해결될 것이라고 합리적으로 예상할 수 있습니다.

모든 디버깅을 가능하게 하는 "풍부한" 분산 추적의 출현

차세대 추적으로의 진정한 도약은 추적이 "성능 문제만" 영역에서 "모든 문제"로 발전할 때일 것입니다. 이때 분산 추적의 진정한 힘이 발휘됩니다.

이것이 가능하려면 각 추적에 풍부한 컨텍스트가 있어야 합니다.

각 추적의 각 범위에 다음이 포함된 시나리오를 상상해 보세요.

• 요청 및 응답 페이로드(PII 마스킹 포함)

• 모든 예외에 대한 스택 추적

• 로그

• 쿠버네티스 이벤트

• 포드 상태

• 그리고 그 기간 동안 발생한 다른 모든 것

  
  

하나의 통합된 원활한 흐름으로 모두 가능합니다.

그리고 찾고 있는 추적을 매우 쉽게 찾을 수 있다고 상상해 보십시오. 샘플링 관련 데이터 공백이 없고 문제가 중복 제거 및 그룹화되며 여러 차원에 걸쳐 필터링될 수 있습니다.

그러면 이것이 개발자가 소프트웨어 문제를 디버깅하는 데 필요한 전부입니다. 그리고 잠재적으로 모든 AI 모델은 개발자에게 무엇이 잘못되었는지 진단하고 지적해야 합니다.

이 세계에서는 추적이 로깅을 대체하여 관찰 가능성의 기본 축이 됩니다. 이것이 분산 추적의 최종 상태입니다. 아직은 아니지만 현재 우리가 있는 곳에서는 볼 수 있습니다.

이를 가능하게 하는 데 가장 큰 장애물은 이 모든 컨텍스트 데이터를 저장하면 데이터 볼륨이 폭발적으로 증가한다는 것입니다. 이를 가능하게 하려면 데이터 처리 및 저장 아키텍처에 대한 근본적인 혁신이 필요합니다. 아직 초기 단계이므로 여기서 무슨 일이 일어나는지 기다려야 합니다.

요약

요약하면, 분산 추적은 프로덕션에서 분산 애플리케이션 아키텍처를 관찰할 수 있는 데 필요한 필수적이고 직관적인 보기입니다.

1세대 분산 추적은 유망하지만 회사가 추적에서 가치를 얻기 어렵게 만드는 여러 가지 과제로 인해 어려움을 겪었으며 이로 인해 채택이 다소 방해되었습니다.

그러나 추적을 현재보다 더 쉽고, 간단하고, 더 강력하게 만들어 미래에는 관찰 가능성을 더욱 원활하게 만들 것으로 예상되는 몇 가지 흥미로운 개발이 이 분야에서 일어나고 있습니다.