🥇분산 추적: 우리는 모든 것을 잘못했습니다

메모. 번역: 이 자료의 저자는 API 개발, 특히 마이크로서비스 테스트를 전문으로 하는 imgix의 엔지니어인 Cindy Sridharan입니다. 이 자료에서 그녀는 시급한 문제를 해결하기 위한 효과적인 도구가 부족한 분산 추적 분야의 현재 문제에 대한 자세한 비전을 공유합니다.

[다음에서 가져온 그림 다른 재료 분산 추적에 대해.]

그것은 생각됩니다 그 분산 추적 구현하기 어렵고 그에 따른 수익 기껏해야 모호하다. 추적이 문제가 되는 데에는 여러 가지 이유가 있으며, 각 요청과 함께 적절한 헤더를 전송하기 위해 각 시스템 구성 요소를 구성하는 데 관련된 작업을 종종 언급합니다. 이 문제가 존재하기는 하지만 결코 극복할 수 없는 것은 아닙니다. 그건 그렇고, 개발자가 추적을 별로 좋아하지 않는 이유는 설명되지 않습니다(이미 작동하고 있는 경우에도).

분산 추적의 주요 과제는 데이터 수집, 결과 배포 및 표시 형식 표준화, 샘플링 시기, 장소 및 방법 결정이 아닙니다. 상상하려고 노력하는 게 아니야 하찮은 이러한 "이해성 문제"는 실제로 매우 중요한 기술적 문제이며 (진정한 오픈 소스를 고려한다면) 표준 및 프로토콜) 이러한 문제가 해결되기 위해서는 극복해야 할 정치적 과제입니다.

그러나 이 모든 문제가 해결되었다고 가정하면, 측면에서 크게 달라지는 것은 없을 가능성이 높습니다. 최종 사용자 경험. 추적은 배포된 후에도 가장 일반적인 디버깅 시나리오에서 여전히 실용적으로 사용되지 않을 수 있습니다.

이렇게 다른 흔적

분산 추적에는 여러 가지 개별 구성 요소가 포함됩니다.

애플리케이션과 미들웨어에 제어 도구를 장착합니다.
분산 컨텍스트 전송;
흔적 수집;
추적 저장;
추출 및 시각화.

분산 추적에 대한 많은 이야기는 이를 유일한 목적이 시스템을 완전히 진단하는 데 도움이 되는 일종의 단항 작업으로 취급하는 경향이 있습니다. 이는 주로 분산 추적에 대한 아이디어가 역사적으로 어떻게 형성되었는지에 기인합니다. 안에 블로그 항목, Zipkin 소스가 공개되었을 때 만들어진 내용에는 다음과 같은 내용이 언급되어 있습니다. [Zipkin]은 트위터를 더 빠르게 만듭니다. 추적을 위한 최초의 상용 제품도 다음과 같이 홍보되었습니다. APM 도구.

메모. 번역: 추가 텍스트를 더 쉽게 이해할 수 있도록 다음에 따라 두 가지 기본 용어를 정의하겠습니다. OpenTracing 프로젝트 문서:

스팬 — 분산 추적의 기본 요소입니다. 이름, 시작 및 종료 시간, 태그, 로그 및 컨텍스트가 포함된 특정 워크플로(예: 데이터베이스 쿼리)에 대한 설명입니다.
스팬에는 일반적으로 다른 스팬에 대한 링크가 포함되어 있어 여러 스팬을 여러 스팬으로 결합할 수 있습니다. 더듬다 — 분산 시스템을 통해 이동하는 요청의 수명을 시각화합니다.

추적에는 프로덕션 테스트, 재해 복구 테스트, 오류 주입 테스트 등과 같은 작업에 도움이 될 수 있는 매우 귀중한 데이터가 포함되어 있습니다. 실제로 일부 회사에서는 이미 유사한 목적으로 추적을 사용하고 있습니다. 시작해보자 범용 컨텍스트 전송 단순히 범위를 스토리지 시스템으로 이동하는 것 외에 다른 용도로 사용됩니다.

예를 들어, 우버 использует 테스트 트래픽과 프로덕션 트래픽을 구별하기 위한 추적 결과.
페이스북 использует 주요 경로 분석 및 정기적인 재해 복구 테스트 중 트래픽 전환을 위한 추적 데이터입니다.
또한 소셜 네트워크 적용 개발자가 추적 결과에 대해 임의 쿼리를 실행할 수 있는 Jupyter Notebook입니다.
지지자 LDFI (리니지 기반 실패 주입) 사용하다 오류 주입 테스트를 위한 분산 추적.

위에 나열된 옵션 중 어느 것도 시나리오에 완전히 적용되지 않습니다. 디버깅, 그 동안 엔지니어는 추적을 확인하여 문제를 해결하려고 시도합니다.

그것이 올 때 아직 디버깅 스크립트에 도달하면 기본 인터페이스는 다이어그램으로 유지됩니다. 트레이스뷰 (어떤 사람들은 그것을 그렇게 부르기도 하지만 "간트차트" 또는 "폭포 다이어그램"). 아래에 트레이스뷰 я 내 말은 추적을 구성하는 모든 범위 및 관련 메타데이터. 모든 오픈 소스 추적 시스템과 모든 상업용 추적 솔루션은 다음을 제공합니다. 트레이스뷰 추적을 시각화하고, 자세히 설명하고 필터링하기 위한 사용자 인터페이스입니다.

지금까지 본 모든 추적 시스템의 문제점은 결과적으로 시각화(트레이스뷰) 추적 생성 프로세스의 기능을 거의 완벽하게 반영합니다. 히트맵, 서비스 토폴로지, 대기 시간 히스토그램 등 대체 시각화가 제안되더라도 궁극적으로 최종 결과는 다음과 같습니다. 트레이스뷰.

예전에는 내가 불평하다 대부분의 UI/UX 추적 "혁신"은 다음으로 제한되는 것 같습니다. 켜기 추적 중인 추가 메타데이터, 카디널리티가 높은 정보에 투자 (높은 카디널리티) 또는 특정 범위를 드릴다운하거나 쿼리를 실행하는 기능 제공 추적 간 및 내부 추적. 이 경우, 트레이스뷰 주요 시각화 도구로 남아 있습니다. 이러한 상황이 계속되는 한 분산 추적은 디버깅 도구로서 메트릭, 로그 및 스택 추적에 이어 4위를 차지할 것이며 최악의 경우에는 돈과 시간 낭비가 될 것입니다.

Traceview 문제

목적 트레이스뷰 — 관련된 분산 시스템의 모든 구성 요소에서 단일 요청의 이동에 대한 완전한 그림을 제공합니다. 일부 고급 추적 시스템을 사용하면 개별 범위를 자세히 살펴보고 시간 경과에 따른 분석을 볼 수 있습니다. 이내 하나의 프로세스(범위에 기능적 경계가 있는 경우)

마이크로서비스 아키텍처의 기본 전제는 조직 구조가 회사의 요구에 따라 성장한다는 아이디어입니다. 마이크로서비스 지지자들은 다양한 비즈니스 작업을 개별 서비스에 분산하면 소규모의 자율적인 개발 팀이 해당 서비스의 전체 라이프사이클을 제어할 수 있어 해당 서비스를 독립적으로 구축, 테스트 및 배포할 수 있다고 주장합니다. 그러나 이 배포의 단점은 각 서비스가 다른 서비스와 상호 작용하는 방식에 대한 정보가 손실된다는 것입니다. 이러한 상황에서 분산 추적은 다음 작업에 없어서는 안 될 도구라고 주장합니다. 디버깅 서비스 간의 복잡한 상호 작용.

만약 당신이 정말로 엄청나게 복잡한 분산 시스템, 그러면 한 사람도 그것을 머릿속에 담을 수 없습니다 가득 찬 그림. 실제로 가능하다는 가정을 기반으로 도구를 개발하는 것은 일종의 반패턴(비효과적이고 비생산적인 접근 방식)입니다. 이상적으로 디버깅에는 다음을 수행하는 데 도움이 되는 도구가 필요합니다. 검색 영역을 좁혀라이를 통해 엔지니어는 고려 중인 문제 시나리오와 관련된 차원(서비스/사용자/호스트 등)의 하위 집합에 집중할 수 있습니다. 고장의 원인을 판단할 때 엔지니어는 고장 동안 무슨 일이 일어났는지 이해할 필요가 없습니다. 모든 서비스를 한번에, 그러한 요구 사항은 마이크로 서비스 아키텍처의 아이디어와 모순되기 때문입니다.

그러나 트레이스뷰는 즉 이것. 예, 일부 추적 시스템은 추적의 범위 수가 너무 커서 하나의 시각화에 표시할 수 없는 경우 압축된 추적 보기를 제공합니다. 그러나 이렇게 단순화된 시각화에도 많은 양의 정보가 포함되어 있기 때문에 엔지니어들은 여전히 강제적 인 문제의 원인이 되는 서비스 집합으로 선택 범위를 수동으로 좁혀서 이를 " 선별"합니다. 불행히도 이 분야에서 기계는 인간보다 훨씬 빠르며 오류가 발생할 가능성이 적고 결과가 더 반복 가능합니다.

Traceview가 잘못되었다고 생각하는 또 다른 이유는 가설 기반 디버깅에 적합하지 않기 때문입니다. 디버깅의 핵심은 반복적 인 가설에서 시작하여 다양한 벡터, 결론/일반화 및 가설의 진실성에 대한 추가 평가를 통해 시스템에서 얻은 다양한 관찰 및 사실을 검증하는 프로세스입니다.

기회 빠르고 저렴하다 가설을 테스트하고 이에 따라 정신 모델을 개선하는 것은 기초 디버깅 모든 디버깅 도구는 다음과 같아야 합니다. 인터렉티브 검색 공간을 좁히거나 잘못된 리드의 경우 사용자가 다시 돌아가 시스템의 다른 영역에 집중할 수 있도록 합니다. 완벽한 도구가 이를 수행합니다. 적극적으로, 잠재적인 문제 영역에 사용자의 주의를 즉시 집중시킵니다.

아아 트레이스뷰 대화형 인터페이스를 갖춘 도구라고 할 수 없습니다. 이를 사용할 때 기대할 수 있는 최선의 방법은 대기 시간이 증가하는 원인을 찾고 이와 관련된 가능한 모든 태그 및 로그를 살펴보는 것입니다. 이는 엔지니어가 식별하는 데 도움이 되지 않습니다. 패턴 지연 분포의 세부 사항과 같은 트래픽에서 정보를 확인하거나 다양한 측정치 간의 상관 관계를 감지합니다. 일반화된 추적 분석 이러한 문제 중 일부를 해결하는 데 도움이 될 수 있습니다. 정말, 예가 있습니다 비정상적인 범위를 식별하고 비정상적인 동작과 연관될 수 있는 태그의 하위 집합을 식별하기 위해 기계 학습을 사용한 성공적인 분석입니다. 그러나 Traceview 또는 DAG(방향성 비순환 그래프)와 크게 다른 범위에 적용되는 기계 학습 또는 데이터 마이닝 결과의 강력한 시각화를 아직 본 적이 없습니다.

스팬 수준이 너무 낮습니다.

Traceview의 근본적인 문제는 범위 대기 시간 분석과 근본 원인 분석을 모두 수행하기에는 너무 낮은 수준의 기본 요소입니다. 이는 작업하기 훨씬 더 편리한 역추적과 같은 훨씬 더 높은 수준의 도구가 있다는 것을 알고 예외를 해결하기 위해 개별 프로세서 명령을 구문 분석하는 것과 같습니다.

더욱이, 나는 다음을 자유롭게 주장할 것입니다: 이상적으로는 우리는 필요하지 않습니다. 전체 그림 최신 추적 도구로 표현되는 요청 수명 주기 동안 발생했습니다. 대신, 무엇에 관한 정보를 포함하는 어떤 형태의 더 높은 수준의 추상화가 필요합니다. 잘못됐다 (역추적과 유사) 일부 컨텍스트와 함께. 전체 추적을 보는 것보다 추적을 보는 것이 더 좋습니다. часть, 흥미롭거나 특이한 일이 일어나는 곳입니다. 현재 검색은 수동으로 수행됩니다. 엔지니어는 추적을 수신하고 흥미로운 것을 찾기 위해 범위를 독립적으로 분석합니다. 의심스러운 활동을 탐지하기 위해 개별 추적에서 범위를 응시하는 사람들의 접근 방식은 전혀 확장되지 않습니다(특히 범위 ID, RPC 메서드 이름, 범위 기간 등 다양한 범위에 인코딩된 모든 메타데이터를 이해해야 하는 경우). 'a, 로그, 태그 등).

Traceview의 대안

추적 결과는 시스템의 상호 연결된 부분에서 무슨 일이 일어나고 있는지에 대한 중요한 통찰력을 제공하는 방식으로 시각화될 수 있을 때 가장 유용합니다. 이런 일이 발생하기 전까지는 디버깅 프로세스가 크게 남아 있습니다. 둔한 그리고 올바른 상관 관계를 알아차리고, 시스템의 올바른 부분을 확인하고, 퍼즐 조각을 맞추는 사용자의 능력에 따라 달라집니다. 도구, 사용자가 이러한 가설을 공식화하는 데 도움이 됩니다.

저는 비주얼 디자이너나 UX 전문가는 아니지만 다음 섹션에서는 이러한 시각화가 어떤 모습일지에 대한 몇 가지 아이디어를 공유하고 싶습니다.

특정 서비스에 집중

업계가 아이디어를 중심으로 통합되고 있는 시대 SLO(서비스 수준 목표) 및 SLI(서비스 수준 지표), 개별 팀이 서비스가 이러한 목표에 부합하도록 우선순위를 지정하는 것이 합리적으로 보입니다. 그것은 다음과 같습니다 서비스 지향 시각화는 이러한 팀에 가장 적합합니다.

특히 샘플링이 없는 추적은 분산 시스템의 각 구성 요소에 대한 정보의 보고입니다. 이 정보는 사용자에게 정보를 제공하는 교활한 프로세서에 공급될 수 있습니다. 서비스 지향 사용자가 추적을 보기 전에도 사전에 식별할 수 있습니다.

매우 중요한 요청에 대한 지연 시간 분포 다이어그램 (이상치 요청);
서비스 SLO 목표가 달성되지 않은 경우의 지연 분포 다이어그램
가장 자주 검색되는 쿼리에서 가장 "일반적인", "흥미로운" 및 "이상한" 태그 반복된다;
다음과 같은 경우의 지연 시간 분석 зависимости 서비스가 SLO 목표를 달성하지 못합니다.
다양한 다운스트림 서비스에 대한 지연 시간 분석.

이러한 질문 중 일부는 기본 제공 측정항목으로 답변되지 않아 사용자가 범위를 면밀히 조사해야 합니다. 결과적으로 우리는 극도로 사용자에게 적대적인 메커니즘을 갖게 되었습니다.

이는 다음과 같은 질문을 제기합니다. 서로 다른 팀이 관리하는 다양한 서비스 간의 복잡한 상호 작용은 어떻습니까? 그렇지 않나요? 트레이스뷰 그러한 상황을 강조하는 가장 적절한 도구로 간주되지 않습니까?

모바일 개발자, 상태 비저장 서비스 소유자, 관리형 상태 저장 서비스(예: 데이터베이스) 소유자 및 플랫폼 소유자는 다른 것에 관심이 있을 수 있습니다. 프레젠테이션 분산 시스템; 트레이스뷰 근본적으로 다른 요구 사항에 대한 너무 일반적인 솔루션입니다. 매우 복잡한 마이크로서비스 아키텍처에서도 서비스 소유자는 XNUMX~XNUMX개 이상의 업스트림 및 다운스트림 서비스에 대한 깊은 지식이 필요하지 않습니다. 기본적으로 대부분의 시나리오에서 사용자는 다음에 관한 질문에만 대답하면 됩니다. 제한된 서비스 세트.

이는 자세히 조사하기 위해 돋보기를 통해 서비스의 작은 하위 집합을 보는 것과 같습니다. 이를 통해 사용자는 이러한 서비스와 즉각적인 종속성 간의 복잡한 상호 작용에 대해 더 긴급한 질문을 할 수 있습니다. 이는 엔지니어가 알고 있는 서비스 세계의 역추적과 유사합니다. 그 틀렸으며, 주변 서비스에서 무슨 일이 일어나고 있는지 어느 정도 이해하고 있습니다. 이유.

제가 홍보하는 접근 방식은 분석이 전체 추적에서 시작하여 점진적으로 개별 범위까지 진행되는 하향식 추적 보기 기반 접근 방식과 정반대입니다. 이와 대조적으로 상향식 접근 방식은 사건의 잠재적 원인에 가까운 작은 영역을 분석하는 것부터 시작한 다음 필요에 따라 검색 공간을 확장합니다(다른 팀을 참여시켜 더 광범위한 서비스를 분석할 가능성이 있음). 두 번째 접근 방식은 초기 가설을 빠르게 테스트하는 데 더 적합합니다. 구체적인 결과가 나오면 보다 집중적이고 상세한 분석으로 넘어갈 수 있을 것이다.

토폴로지 구축

사용자가 알고 있는 경우 서비스별 보기는 매우 유용할 수 있습니다. 무엇 서비스 또는 서비스 그룹은 대기 시간을 늘리거나 오류를 유발합니다. 그러나 복잡한 시스템에서는 오류가 발생한 동안 문제가 되는 서비스를 식별하는 것이 쉽지 않을 수 있습니다. 특히 서비스에서 오류 메시지가 보고되지 않은 경우라면 더욱 그렇습니다.

서비스 토폴로지를 구축하면 오류율이 급증하거나 대기 시간이 증가하여 서비스 성능이 눈에 띄게 저하되는 서비스를 파악하는 데 큰 도움이 될 수 있습니다. 제가 토폴로지 구축에 관해 이야기할 때, 서비스 지도, 시스템에서 사용 가능하고 알려진 모든 서비스를 표시합니다. 죽음의 별 모양의 건축 지도. 이 보기는 방향성 비순환 그래프를 기반으로 하는 Traceview보다 나을 것이 없습니다. 대신 보고싶다 동적으로 생성된 서비스 토폴로지, 오류율, 응답 시간 또는 특정 의심스러운 서비스의 상황을 명확히 하는 데 도움이 되는 사용자 정의 매개변수와 같은 특정 속성을 기반으로 합니다.

예를 들어 보겠습니다. 가상의 뉴스 사이트를 상상해 봅시다. 홈페이지 서비스 (첫 장) 추천 서비스, 광고 서비스 및 비디오 서비스를 통해 Redis와 데이터를 교환합니다. 비디오 서비스는 S3에서 비디오를 가져오고 DynamoDB에서 메타데이터를 가져옵니다. 추천 서비스는 DynamoDB에서 메타데이터를 수신하고, Redis 및 MySQL에서 데이터를 로드하고, Kafka에 메시지를 씁니다. 광고 서비스는 MySQL로부터 데이터를 수신하고 Kafka에 메시지를 씁니다.

다음은 이 토폴로지를 도식적으로 표현한 것입니다(많은 상용 라우팅 프로그램이 토폴로지를 구축합니다). 서비스 종속성을 이해해야 하는 경우 유용할 수 있습니다. 그러나, 동안 디버깅, 특정 서비스(예: 비디오 서비스)의 응답 시간이 증가하면 이러한 토폴로지는 그다지 유용하지 않습니다.

가상의 뉴스 사이트의 서비스 다이어그램

아래 다이어그램이 더 적합할 것입니다. 서비스에 문제가 있습니다 (비디오) 바로 중앙에 그려져 있습니다. 사용자는 이를 즉시 알아차립니다. 이 시각화를 통해 S3 응답 시간 증가로 인해 비디오 서비스가 비정상적으로 작동하고 있으며 이는 메인 페이지 일부의 로딩 속도에 영향을 미치고 있음이 분명해졌습니다.

"흥미로운" 서비스만 표시하는 동적 토폴로지

동적으로 생성된 토폴로지는 특히 탄력적이고 자동 확장되는 인프라에서 정적 서비스 맵보다 더 효율적일 수 있습니다. 서비스 토폴로지를 비교 및 대조하는 기능을 통해 사용자는 보다 관련성이 높은 질문을 할 수 있습니다. 시스템에 대해 보다 정확한 질문을 하면 시스템 작동 방식을 더 잘 이해할 수 있습니다.

비교 표시

또 다른 유용한 시각화는 비교 표시입니다. 현재 추적은 병렬 비교에 적합하지 않으므로 일반적으로 비교는 범위. 그리고 이 기사의 주요 아이디어는 정확하게 스팬이 추적 결과에서 가장 가치 있는 정보를 추출하기에는 너무 낮은 수준이라는 것입니다.

두 개의 추적을 비교하는 데는 근본적으로 새로운 시각화가 필요하지 않습니다. 실제로, Traceview와 동일한 정보를 나타내는 히스토그램과 같은 것만으로도 충분합니다. 놀랍게도 이 간단한 방법조차도 단순히 두 가지 흔적을 별도로 연구하는 것보다 훨씬 더 많은 성과를 가져올 수 있습니다. 더욱 강력한 가능성이 있을 것입니다. 시각화하다 흔적의 비교 전체적으로. GC(가비지 수집)를 활성화하기 위해 최근 배포된 데이터베이스 구성 변경이 몇 시간 단위로 다운스트림 서비스의 응답 시간에 어떤 영향을 미치는지 확인하는 것은 매우 유용합니다. 여기서 설명하는 내용이 인프라 변경의 영향에 대한 A/B 분석처럼 들린다면 많은 서비스에서 추적 결과를 사용하면 진실에서 그리 멀지 않습니다.

결론

나는 추적 자체의 유용성에 대해 의문을 제기하지 않습니다. 나는 추적에 포함된 것만큼 풍부하고 인과적이며 상황에 맞는 데이터를 수집하는 다른 방법은 없다고 진심으로 믿습니다. 그러나 나는 또한 모든 추적 솔루션이 이 데이터를 매우 비효율적으로 사용한다고 생각합니다. 추적 도구가 Traceview 표현에 머물러 있는 한 추적에 포함된 데이터에서 추출할 수 있는 귀중한 정보를 최대한 활용하는 능력이 제한됩니다. 또한, 애플리케이션 오류를 해결하는 사용자의 능력을 심각하게 제한하는 완전히 비우호적이고 직관적이지 않은 시각적 인터페이스를 더욱 개발할 위험이 있습니다.

최신 도구를 사용하더라도 복잡한 시스템을 디버깅하는 것은 엄청나게 어렵습니다. 도구는 개발자가 가설을 공식화하고 테스트하는 데 도움이 되어야 합니다. 적극적으로 제공 관련 정보, 특이점 식별 및 지연 분포의 특징 지적. 추적이 생산 실패 문제를 해결하거나 여러 서비스에 걸쳐 있는 문제를 해결할 때 개발자가 선택하는 도구가 되려면 해당 서비스를 만들고 운영하는 개발자의 정신 모델과 더욱 일치하는 독창적인 사용자 인터페이스와 시각화가 필요합니다.

분석 및 추론의 용이성을 위해 최적화된 방식으로 추적 결과에서 사용할 수 있는 다양한 신호를 나타내는 시스템을 설계하려면 상당한 정신적 노력이 필요합니다. 사용자가 개별 추적이나 범위를 보지 않고도 사각지대를 극복하는 데 도움이 되는 방식으로 디버깅 중에 시스템 토폴로지를 추상화하는 방법에 대해 생각해야 합니다.

좋은 추상화와 계층화 기능이 필요합니다(특히 UI에서). 반복적으로 질문하고 가설을 테스트할 수 있는 가설 중심 디버깅 프로세스에 잘 맞는 것입니다. 모든 관찰 가능성 문제를 자동으로 해결하지는 않지만 사용자가 직관을 날카롭게 하고 더 현명한 질문을 공식화하는 데 도움이 됩니다. 나는 시각화에 대한 보다 사려 깊고 혁신적인 접근 방식을 요구합니다. 여기에는 지평을 확장할 수 있는 진정한 전망이 있습니다.

번역가의 추신

블로그에서도 읽어보세요.

출처 : habr.com

분산 추적: 우리가 모두 잘못했습니다