分散トレーシング: 過去、現在、未来

分散トレーシングは意見が分かれるトピックです。かつては、毎回の KubeCon でこのテクノロジーが可観測性に革命を起こすと期待されていました。

5 年が経ち、誇大広告はいくらか沈静化し、痛みについての話題が多くなり、導入は穏やかになりました。一方で、テクノロジーの拡張と標準化に関する着実な活動が続いています。Open Telemetry (OpenTracing ベース) は、Kubernetes に次ぐ2 番目に大きな CNCF プロジェクトです。では、分散トレーシングはどうなるのでしょうか?すぐに実装すべきでしょうか、それとも静観すべきでしょうか?

この記事では、分散トレーシングについて詳しく見てみましょう

1. 分散トレーシングの何が特別で、なぜそれが必要なのでしょうか?
2. 現在の分散トレースにはどのような問題があるのでしょうか?
3. 今後の開発はどのようなもので、既存の課題にどのように対処するのでしょうか?

はじめに - 分散トレーシングの仕組み

初心者のために説明すると、分散トレーシングは、分散環境の複数の異なるコンポーネント/マイクロサービスを通過する単一のリクエストを追跡できるテクノロジーです。リクエストのパス内で行われた各ネットワーク呼び出しはキャプチャされ、スパンとして表されます。

分散トレースが必要な理由

これを可能にするために、分散トレース ツールは、一意のトレース コンテキスト (トレース ID) を各リクエストのヘッダーに挿入し、トレース コンテキストがリクエスト パス全体に確実に伝播されるようにするメカニズムを実装します。

分散トレースがリクエスト パスを表す方法

分散トレースがリクエスト パスを表す方法

そもそも分散トレーシングが必要な理由

分散トレーシングは、可観測性の単位としてリクエストに焦点を当てているため、独特です。モニタリング/メトリクス プラットフォームでは、コンポーネント(サービス、ホストなど) が観察される基本単位です。これらのプラットフォームに対して、このユニット全体の動作について、時間の経過とともに質問することができます。たとえば、特定の期間におけるこのサービスの健全性、スループット、エラー率はどれくらいですか?

ログでは、観察される基本単位はイベントです。たとえば、コードの実行中にイベントが発生するたびに、何らかの情報が出力されます。これらの「イベント」は、開発者がコードを作成する際に主観的に定義します。ログに関する課題は、ログがすべてばらばらであり、各コンポーネントが独自の形式のログ メッセージを分離して出力し、意味をなすようにそれらを結合する簡単な方法がないことです。

対照的に、分散トレースでは、複数のコンポーネントを横断する単一のリクエストが観察されます。これにより、分散システム全体について質問し、複雑で相互接続されたシステムのどこで何が起こったのかを理解できるようになります。

メトリクス、ログ、分散トレース全体を表示する

分散トレースの基本的なケースは、リクエストに関するこの方向性がエンドユーザーのエクスペリエンスに最も近いという主張にあります。その結果、分散アーキテクチャを調べてトラブルシューティングを行う方法にとって、これが最も直観的でもあります。

分散トレーシングの進化

過去 10 年間で分散ソフトウェア アーキテクチャが広く採用されたため、分散トレーシングの重要性が高まっています。

最新のマイクロサービスベースのアーキテクチャは、リクエスト/レスポンスシステムの使用が一般的になった 90 年代後半のインターネット成長ストーリーからの進化です。

「90 年代後半とインターネットの爆発的な成長に伴い、Web サーバー フロントエンドとデータベース バックエンドを備えた 2 層 Web サイトなどのリクエスト/レスポンス システムが大幅に普及しました。リクエストはシステムについての推論のための新しい次元でした、任意の 1 つのマシンまたはプロセスに直交する集合体。

- 分散トレーシングの実践、O'Reilly Media

これらのマイクロサービス アーキテクチャでは、すべてのリクエストが最終的に多数 (数十、場合によっては数百のマイクロサービス) に到達し、その間に複数のネットワーク呼び出しが行われます。 3000 以上のサービスがある Uber のマイクロサービス アーキテクチャについては、以下を参照してください。

Yeter からの Uber のマイクロサービス アーキテクチャのイメージ

2018 年の Uber のマイクロサービス アーキテクチャ。出典: https://www.uber.com/en-IN/blog/microservice-architecture/

このような複雑なシステムでは、分散トレースはあらゆる形式のトラブルシューティングにとって重要になります。その結果、分散トレーシングは、大規模で複雑な分散環境を早期に導入した大企業によって先駆けられました。

• 2010 年に発表された Google の Dapper 論文は分散トレースの始まりでした

  
  

• その後数年で、さらに 2 社が独自の分散トレーシング システムをオープンソース化しました (Twitter は 2012 年に Zipkin をオープンソース化し、Uber は 2017 年にイェーガーをオープンソース化しました)。 Zipkin と Yeter は、現在でも最も人気のある分散トレース ツールの 1 つです。

  
  

• 2016 年以来、OpenTracing プロジェクトを通じてコンポーネント間で分散トレーシングを標準化するための多大な取り組みが行われてきました。 OpenTracing は、2019 年に最終的にOpenTelemetryになりました。OpenTelemetry は広く普及しており、世界中で何千人もの貢献者がいます。

  
  

• 現在、分散トレーシングは、メトリクスやログと並ぶ可観測性の 3 番目の「柱」として広くみなされています。ほとんどの主要な監視および可観測性プレーヤーは、製品の一部として分散トレース ツールを提供しています。

分散トレーシングの現状: 理論と現実

しかし、期待、興奮、コミュニティの取り組みにもかかわらず、今日の分散トレーシングの導入率は約 25% です。明らかに分散トレースが必要であるにもかかわらず、マイクロサービス アーキテクチャを採用し、ログとメトリクスでなんとかしている企業を見つけることは珍しくありません。

分散トレーシングの採用

同時に、今日の世界では、生産エラーの平均解決時間が増加しています。現在、 73% の企業が生産上の問題を解決するのに 1 時間以上かかっていると報告しています。

生産MTTRの増加

開発者に人生で最もつらかった瞬間は何ですかと尋ねると、本番環境での Sev-1 エラーのデバッグに、数百人が首に息を吹きかけているような時間に費やした時間について話すでしょう。

したがって、MTTR を気にする企業 (ほぼすべての企業) は分散トレースを使用するはずであり、この環境では導入が急増しているはずです。しかし、実際の数字はそれを裏付けていません。それでは何が得られるのでしょうか?

現在の分散トレーシングの課題

今日の分散トレースには、企業が価値を得るために克服しなければならない問題がいくつかありますが、そのすべてが主流の物語ではそれほど広く議論されていません。

1. 導入は難しい！

現在サービスに分散トレースを実装するには、コードを変更してリリースする必要があります。コードを変更することは可観測性を求めるのに十分一般的なことですが、分散トレースに特有の課題は次のとおりです。分散トレースを取得するには、まさにサービスまたはコンポーネントをインストルメントする必要があり、そうしないとトレースが中断されます。

分散トレーシングの計測

モニタリングやロギングのように、ただ 1 つのサービスを開始して価値を実現することはできません。分散トレースでは、使用可能なトレースを生成するために、サービスの集合セットにわたるインストルメンテーションが必要です。

これには、サービスに変更を加えるために複数のチームとサービス所有者間で調整する必要があります。したがって、これは組織の問題になります。価値を実感できるようになるまでに、数か月かけて何百ものチームがサービスを導入できるようにすることを想像してください。

これは今日の分散トレースにおける最大の課題です。

2. 複雑なサンプリング決定の必要性

次に、分散トレーシングによって生成されるトレース データの量は膨大になる可能性があります。何百ものサービスが、それぞれのリクエストごとに少量のトレース データを発行していると想像してください。これにより、1 秒あたり数百万件のリクエストが発生し、ストレージとネットワーク帯域幅の両方の点で分散トレースのコストが高くなります。

ロギングも同じことを行います (リクエストごとにさらに多くのデータを出力し、大規模なログ集約ツールによって管理されます) が、異なる点は、今日のほとんどの企業がすでにロギングを行っていることです。ログ記録とほぼ同じくらい膨大な量になるデータ タイプをもう 1 つ導入することは困難な作業であり、費用が 2 倍になる可能性があります。

このコストの問題に対処するために、今日のすべての分散トレース システムはサンプリングを使用し、トレースのサブセットのみを記録します。現在実際に行われている一般的なサンプリング率は 0.1% ～ 2% です。その理論的根拠は、パフォーマンスのボトルネックがどこにあるのかを適切に全体的に把握するには、サンプルの 1% でも十分であるということです。

現在、ほとんどのプラットフォームでは、顧客がサンプリング戦略を選択し、コストと可視性のトレードオフを独自に行うことができます。ただし、この決定プロセスにより、分散トレース システムの計測と管理に伴うすでに複雑なオーバーヘッドがさらに増加します。

3. しかし、サンプリングは価値を大幅に減少させます

企業がすべてのサービス/コンポーネントを計測し、大金を支払わないようにサンプリング戦略を決定するという労力を費やしていると仮定しましょう。

さて、MTTR が劇的に低下すると予想すべきでしょうか?いいえ、サンプリングのため、開発者は分散トレースを使用して実際に問題のトラブルシューティングを行うことができないからです。

開発者の経験を想像してください - 「存在するとわかっている問題が見つかりません。エラーを生成しましたが、対応するトレースが見つかりません。」

それで何が起こるでしょうか？開発者は分散トレース データの品質を信頼するのをやめ、デバッグ/トラブルシューティングの通常の方法 (つまり、ログの使用) に戻ります。

4. 開発者の使用頻度は低い

これらの制約を考慮して、現在、分散トレーシングは主にパフォーマンスの問題をトラブルシューティングする方法として販売されています。

基本的な分散トレースでは、実際には誰が誰に電話をかけたか、そして各スパンにどれくらいの時間がかかったかがわかるだけであることに注意してください。分散トレースでは、エラーや高遅延の原因となったサービス内で何が起こったのかはわかりません。そのためには、開発者はログ メッセージを確認したり、問題をローカルで再現してデバッグしたりする必要があります。

一般的な企業では、パフォーマンスの問題は全体の 10% 未満である可能性があります。したがって、実際には、分散トレースはこの小さな部分の問題にのみ役立ちます。

サービスを出荷および所有する平均的な開発者は、おそらく年に 2 ～ 3 回、分散トレース ツールを使用します。

これらすべての課題の影響

要約すれば：

1. 分散トレーシングは実装が難しい
2. 分散トレーシングでは、コストを管理するために広範なサンプリングが必要です
3. ただし、サンプリングすると値が大幅に減少します
4. その結果、開発者は、奇妙な 1 回限りのパフォーマンスのユースケースに対してのみトレースを使用します。

これらすべてにより、分散トレースの RoI ケースは非常に曖昧になります。

典型的な誇大宣伝サイクルにおいて言えることは、私たちは現在、期待が膨らむ段階を過ぎ、幻滅が落ち着き始めているということです。

ハイプ サイクル - 分散トレーシング

ただし、最終状態の観点から考えると、コンピューティング システムの将来が分散型である場合、分散トレースは当然、可観測性の最も基本的なベクトルになります。その世界では、分散アーキテクチャを採用している企業は、今日のシステムの受動的な監視ではなく、運用環境で発生するあらゆるトラブルシューティングの主要なメカニズムとしてトレースを使用しています。つまり、真の「可観測性」です。

ただし、その最終状態に到達する前に、現状をいくつか改善する必要があります。良いニュースは、その多くがすでに進行中であるということです。それぞれを見てみましょう。では、将来的には何が起こるのでしょうか？

分散トレースの将来

コード変更なしの即時インスツルメンテーション

エージェントを導入すると、コードを変更することなく、分散システム全体 (すべてのサービス、コンポーネント) を一度にカバーできるようになることを想像してください。

これは今後 2 ～ 3 年以内に現実的に可能になりそうです。

OpenTelemetry の自動インスツルメンテーション ライブラリは、一部のプログラミング言語ではすでにこれを有効にしています (ただし、Go などのコンパイル言語では不十分です)。並行して、コードを変更せずにシステム全体の計測を可能にするeBPF などのテクノロジーも進化しています。この 2 つのうち、計装の問題は数年以内に解決されると期待できます。

サンプリングは AI ベースの関心のあるリクエストの選択に取って代わられます

LLM の世界では、ランダム サンプリングが暗黒時代の遺物のように見え始めます。理想的には、100% の痕跡を調べ、異常と思われるものを特定し、将来の検査のためにそれを保存できる必要があります。ランダムなサンプリングはもう必要ありません。

考えてみると、私たちは約 95% の「幸せなリクエスト」をあまり気にしていません。私たちが気にするのは、異常なトレースの最大 5% (エラー、例外、長い遅延、または何らかの形式のソフト エラー) だけです。したがって、100% を見て、興味深い 5% を抽出する方法が必要なだけです。

私たちが大切にしている痕跡

現在、これを目的としたテールベース サンプリングのようなメカニズムが存在します。テールベースのサンプリングでは、システムはリクエスト内のすべてのスパンが完了するまで待機し、完全なトレースに基づいて、それを保持する必要があるかどうかを決定します。

テールベースのサンプリングの主な課題は、リクエスト全体が完了するまでトレースのすべてのスパンを保存し、その後トレースを保持するか破棄するかを決定する必要があることです。これは、すべてのリクエストをすべてのスパンで一定期間 (リクエストが完了するまで) 保存することを意味します。これには、負荷分散、ストレージ、処理のためのコンポーネントを備えた別個のデータ アーキテクチャが必要ですが、これは非常に複雑で高価です。

OpenTelemetry にはテールベースのサンプリング コレクターがありますが、まだ成熟しておらず、(上記の問題により)スケーラビリティの課題がいくつかあります。一方、 ZeroK.aiを含むいくつかの企業は、AI を使用して異常検出を効率的かつスケーラブルにすることに取り組んでいます。

この分野の開発のペースが速いため、この問題も今後 3 ～ 5 年以内に解決されると予想できます。

あらゆるデバッグを可能にする「リッチな」分散トレースの登場

次世代のトレースへの真の飛躍は、トレースが「パフォーマンスの問題のみ」の領域から「すべての問題」に進化するときになります。このとき、分散トレースの真の力が発揮されます。

これを可能にするためには、各トレースに豊富なコンテキストが必要です。

各トレースの各スパンが次のとおりであるシナリオを想像してください。

• リクエストとレスポンスのペイロード (PII マスキングあり)

• 例外のスタック トレース

• ログ

• Kubernetes イベント

• ポッドの状態

• そしてその期間に沿って起こったその他のこと

  
  

オールインワンの統合されたシームレスなフロー。

そして、探しているトレースが非常に簡単に見つかるかどうかを想像してください。サンプリング関連のデータギャップがなく、問題は重複排除およびグループ化されており、複数の次元にわたってフィルタリングできます。

開発者がソフトウェアの問題をデバッグするために必要なのは、これだけです。そして潜在的に、すべての AI モデルは何が問題なのかを診断し、開発者に指摘する必要があります。

この世界では、トレースがログ記録に代わる可観測性の主な軸になります。これが、分散トレースの最終状態がどのようなものになる可能性があるかです。それはまだ実現していませんが、今日の私たちの状況からは見えています。

これを可能にする主な障壁は、このすべてのコンテキスト データを保存することによって引き起こされるデータ量の爆発です。これを可能にするためには、データ処理とストレージのアーキテクチャにおける大幅な革新が必要になります。まだ初期段階なので、ここで何が起こるか見守る必要があります。

まとめ

要約すると、分散トレーシングは、運用環境で分散アプリケーション アーキテクチャを観察できるようにするために必要な、直感的なビューです。

第 1 世代の分散トレーシングは有望ではありますが、企業がトレースから価値を得るのを困難にするいくつかの課題に悩まされており、その導入が若干妨げられてきました。

しかし、この宇宙ではいくつかのエキサイティングな開発が行われており、トレースが現在よりも簡単、シンプル、そして強力になり、将来的には観測がよりシームレスになることが期待されています。