分散トレーシング: 私たちのやり方は間違っていました

ノート。 翻訳。: この資料の著者は、API 開発、特にマイクロサービス テストを専門とする imgix のエンジニアである Cindy Sridharan です。 この資料の中で、彼女は、分散トレースの分野における現在の問題についての詳細なビジョンを共有しています。彼女の意見では、差し迫った問題を解決するための真に効果的なツールが不足しています。

[イラスト引用元] 他の素材 分散トレースについて。]

それが信じられている 分散トレーシング 実装が難しく、そのリターンも よく言っても疑わしい。 トレースに問題がある理由は数多くありますが、多くの場合、各リクエストで適切なヘッダーを送信するように各システム コンポーネントを構成する手間が挙げられます。 この問題は確かに存在しますが、決して克服できないものではありません。 ちなみに、開発者がトレースを (すでに機能している場合でも) 嫌う理由は説明されていません。

分散トレースの主な課題は、データの収集、結果の配布と表示のための形式の標準化、いつ、どこで、どのようにサンプリングするかを決定することではありません。 想像しようとしてるんじゃないよ つまらない これらの「わかりやすさの問題」は、実際には非常に重要な技術的問題であり、(真のオープンソースを考慮している場合) 標準とプロトコル) これらの問題が解決されたとみなされるためには、克服する必要がある政治的課題。

しかし、これらの問題がすべて解決されたと想像すると、大きな変化は起こらない可能性が高いです。 エンドユーザーエクスペリエンス。 トレースは、展開された後でも、最も一般的なデバッグ シナリオでは実用的ではない可能性があります。

こんなに違う痕跡

分散トレーシングには、いくつかの異なるコンポーネントが含まれています。

• アプリケーションとミドルウェアに制御ツールを装備する。
• 分散コンテキスト転送。
• トレースの収集。
• トレースストレージ。
• それらの抽出と可視化。

分散トレースについての多くの話では、分散トレースを、システムを完全に診断することを唯一の目的とする一種の単項演算として扱う傾向があります。 これは主に、分散トレースに関する考え方が歴史的にどのように形成されてきたかによるものです。 で ブログエントリ、Zipkin ソースが開かれたときに作成された、と述べられていました。 それ [Zipkin] は Twitter を高速化します。 トレース用の最初の商用製品も、 APMツール.

ノート。 翻訳。: 本文を理解しやすくするために、次の XNUMX つの基本用語を定義しましょう。 OpenTracing プロジェクトのドキュメント:

• スパン — 分散トレースの基本要素。 これは、名前、開始時間と終了時間、タグ、ログ、コンテキストを含む特定のワークフロー (データベース クエリなど) の説明です。
• 通常、スパンには他のスパンへのリンクが含まれており、複数のスパンを結合できるようになります。 トレース — 分散システム内を移動するリクエストの存続期間を視覚化します。

トレースには、実稼働テスト、災害復旧テスト、エラー挿入テストなどのタスクに役立つ非常に貴重なデータが含まれています。 実際、一部の企業はすでに同様の目的でトレースを使用しています。 まずは始めましょう ユニバーサルコンテキスト転送 単純にスパンをストレージ システムに移動する以外にも、次のような用途があります。

• たとえば、ウーバー 使用する 結果をトレースして、テスト トラフィックと運用トラフィックを区別します。
• Facebook 使用する クリティカル パス分析および定期的な災害復旧テスト中のトラフィック スイッチング用のトレース データ。
• ソーシャルネットワークも 当てはまる 開発者がトレース結果に対して任意のクエリを実行できる Jupyter ノートブック。
• 付着物 LDFI (リネージ主導の障害注入) 使用する エラー挿入によるテスト用の分散トレース。

上記のオプションはどれもこのシナリオに完全には当てはまりません デバッグその間、エンジニアはトレースを調べて問題を解決しようとします。

それが来たとき まだ デバッグ スクリプトに到達しても、プライマリ インターフェイスはダイアグラムのままです トレースビュー （そう呼ぶ人もいますが、 "ガントチャート" または 「ウォーターフォール図」）。 下 トレースビュー я つまり トレースを構成するすべてのスパンと付随するメタデータ。 すべてのオープンソース トレース システムとすべての商用トレース ソリューションは、 トレースビュー トレースの視覚化、詳細化、フィルタリングのためのユーザー インターフェイス。

私がこれまで見てきたすべてのトレース システムの問題は、その結果、 視覚化 (トレースビュー) トレース生成プロセスの特徴をほぼ完全に反映しています。 ヒートマップ、サービス トポロジ、レイテンシー ヒストグラムなどの代替の視覚化が提案された場合でも、最終的には次のようになります。 トレースビュー.

昔、私は 不平を言った UI/UX トレースにおけるほとんどの「イノベーション」は次のことに限定されているようです。 オン 追加のメタデータを追跡し、カーディナリティの高い情報をそれらに投資します (高基数) または、特定のスパンにドリルダウンしたり、クエリを実行したりする機能を提供します。 トレース間およびトレース内。 この場合は、 トレースビュー は依然として主要な視覚化ツールです。 この状況が続く限り、分散トレーシングはデバッグ ツールとして (良くても) メトリクス、ログ、スタック トレースに次ぐ 4 位に位置し、最悪の場合はお金と時間の無駄になるでしょう。

トレースビューの問題

目的 トレースビュー — 単一のリクエストが関連する分散システムのすべてのコンポーネントにわたる、そのリクエストの動きの全体像を提供します。 一部のより高度なトレース システムでは、個々のスパンをドリルダウンして、時間の経過に伴う内訳を表示できます。 内部 XNUMX つのプロセス (スパンに機能境界がある場合)。

マイクロサービス アーキテクチャの基本前提は、組織構造が企業のニーズに応じて成長するという考えです。 マイクロサービスの支持者は、さまざまなビジネス タスクを個別のサービスに分散することで、小規模で自律的な開発チームがそのようなサービスのライフサイクル全体を制御できるようになり、それらのサービスを独立して構築、テスト、デプロイできるようになると主張します。 ただし、この配布の欠点は、各サービスが他のサービスとどのように相互作用するかに関する情報が失われることです。 このような状況では、分散トレーシングは不可欠なツールであると主張しています。 デバッグ サービス間の複雑な相互作用。

もし本当に 驚くほど複雑な分散システムそうすると、誰もそれを頭の中に留めることができなくなります。 満員 写真。 実際、それが可能であるという前提に基づいてツールを開発することは、一種のアンチパターン (非効率的で非生産的なアプローチ) です。 理想的には、デバッグには役立つツールが必要です。 検索範囲を狭めるこれにより、エンジニアは検討されている問題シナリオに関連するディメンションのサブセット (サービス/ユーザー/ホストなど) に集中できます。 エンジニアは、障害の原因を特定する際に、障害中に何が起こったのかを理解する必要はありません。 すべてのサービスを一度になぜなら、そのような要件はマイクロサービス アーキテクチャの考え方そのものに矛盾するからです。

ただし、traceview は すなわち これ。 はい、一部のトレース システムでは、トレース内のスパンの数が多すぎて XNUMX つのビジュアライゼーションで表示できない場合に、圧縮されたトレースビューを提供します。 しかし、このような必要最低限​​のビジュアライゼーションにも大量の情報が含まれているため、エンジニアは依然として 強制された それを「ふるいにかけて」、問題の原因となっているサービスのセットに手動で選択を絞り込みます。 残念なことに、この分野では、機械は人間よりもはるかに高速で、エラーが発生しにくく、結果の再現性が高くなります。

私が Traceview が間違っていると考えるもう XNUMX つの理由は、Traceview が仮説に基づくデバッグに適していないためです。 デバッグの中心となるのは、 反復的な 仮説から始まり、さまざまなベクトルに沿ってシステムから得られたさまざまな観察と事実の検証、結論/一般化、そして仮説の真実性のさらなる評価が続くプロセス。

機会 速くて安い 仮説をテストし、それに応じてメンタルモデルを改善することは、 礎石 デバッグデバッグ ツールは次のようにする必要があります。 相互の作用 検索スペースを狭めたり、誤ったリードの場合には、ユーザーがシステムの別の領域に戻って集中できるようにします。 完璧なツールがこれを実現します 積極的に、潜在的な問題領域にユーザーの注意を即座に引き付けます。

悲しいかな トレースビュー インタラクティブなインターフェイスを備えたツールとは言えません。 これを使用するときに期待できる最善のことは、遅延増加の原因を見つけて、それに関連付けられている可能性のあるすべてのタグとログを調べることです。 これはエンジニアが識別するのには役立ちません パターン 遅延分布の詳細など、トラフィック内のデータを分析したり、さまざまな測定値間の相関関係を検出したりできます。 一般化されたトレース分析 これらの問題のいくつかを回避するのに役立つかもしれません。 本当に、 例があります 機械学習を使用した分析に成功し、異常なスパンを特定し、異常な動作に関連する可能性のあるタグのサブセットを特定します。 ただし、Traceview や DAG (有向非巡回グラフ) とは大きく異なるスパンに適用された、機械学習やデータ マイニングの結果の説得力のある視覚化をまだ見たことがありません。

スパンのレベルが低すぎます

トレースビューの根本的な問題は、 スパン これらは、遅延分析と根本原因分析の両方にとって低レベルのプリミティブすぎます。 これは、バックトレースのような、より使いやすい高レベルのツールがあることを知りながら、例外を解決しようとして個々のプロセッサ コマンドを解析するようなものです。

さらに、私は自由に次のことを主張します。理想的には、 全体像 リクエストのライフサイクル中に発生しました。これは最新のトレース ツールで表されます。 代わりに、どのようなものであるかに関する情報を含む、何らかの形の高レベルの抽象化が必要です。 間違えた (バックトレースと同様) いくつかのコンテキストとともに。 トレース全体を見るよりも、それを見ることを好みます часть、何か面白いことや珍しいことが起こる場所。 現在、検索は手動で行われています。エンジニアはトレースを受け取り、興味深いものを探してスパンを独自に分析します。 不審なアクティビティを検出することを期待して個々のトレース内のスパンを観察するというアプローチは、まったく拡張できません (特に、スパン ID、RPC メソッド名、スパン期間など、さまざまなスパンでエンコードされたすべてのメタデータを理解する必要がある場合) 'a、ログ、タグなど)。

トレースビューの代替手段

トレース結果は、システムの相互接続された部分で何が起こっているかについての重要な洞察を提供する方法で視覚化できる場合に最も役立ちます。 これが起こるまで、デバッグプロセスはほとんど残ります。 不活性な そして、正しい相関関係に気づき、システムの正しい部分をチェックし、パズルのピースを組み立てるユーザーの能力に依存します。 計器、ユーザーがこれらの仮説を立てるのに役立ちます。

私はビジュアル デザイナーでも UX の専門家でもありませんが、次のセクションでは、これらのビジュアライゼーションがどのようなものになるかについて、いくつかのアイデアを共有したいと思います。

特定のサービスに焦点を当てる

業界がアイデアを中心に統合しつつある今 SLO (サービスレベル目標) と SLI (サービスレベル指標)、個々のチームがサービスがこれらの目標に沿っていることを確認することを優先するのは合理的だと思われます。 したがって、 サービス指向 視覚化はそのようなチームに最適です。

トレース (特にサンプリングなし) は、分散システムの各コンポーネントに関する情報の宝庫です。 この情報は、ユーザーに情報を提供する狡猾なプロセッサに供給される可能性があります。 サービス指向 ユーザーが痕跡を見る前であっても、それらは事前に特定できます。

1. 非常に顕著なリクエストのみのレイテンシ分布図 (異常値のリクエスト);
2. サービスの SLO 目標が達成されない場合の遅延分布の図。
3. クエリ内で最も「一般的」、「興味深い」、「奇妙な」タグ 繰り返す;
4. 以下の場合のレイテンシの内訳 зависимости サービスが SLO 目標を達成していない。
5. さまざまなダウンストリーム サービスの遅延の内訳。

これらの質問の一部は、組み込みのメトリクスでは単純に答えられず、ユーザーはスパンを精査する必要があります。 その結果、非常にユーザーに対して敵対的なメカニズムができあがっています。

これにより、異なるチームによって制御される多様なサービス間の複雑な相互作用はどうなるのかという疑問が生じます。 そうじゃない トレースビュー はそのような状況を強調するのに最も適切なツールであると考えられませんか?

モバイル開発者、ステートレス サービスの所有者、マネージド ステートフル サービス (データベースなど) の所有者、およびプラットフォームの所有者は、別のことに興味があるかもしれません。 プレゼンテーション 分散システム。 トレースビュー これらの根本的に異なるニーズに対するソリューションとしては汎用的すぎます。 非常に複雑なマイクロサービス アーキテクチャであっても、サービス所有者は XNUMX つまたは XNUMX つ以上のアップストリーム サービスとダウンストリーム サービスについての深い知識を必要としません。 基本的に、ほとんどのシナリオでは、ユーザーは次の質問に答えるだけで済みます。 限定されたサービスセット.

これは、サービスの一部を精査するために虫眼鏡で見るようなものです。 これにより、ユーザーは、これらのサービスとその直接の依存関係の間の複雑な相互作用に関して、より差し迫った質問をすることができるようになります。 これは、エンジニアが知っているサービスの世界におけるバックトレースに似ています。 その 間違っているが、周囲のサービスで何が起こっているかをある程度理解して理解する必要がある 理由.

私が推進しているアプローチは、トップダウンのトレースビュー ベースのアプローチとは正反対で、分析はトレース全体から始まり、徐々に個々のスパンにまで到達します。 対照的に、ボトムアップ アプローチでは、インシデントの潜在的な原因に近い小さな領域を分析することから始まり、必要に応じて検索範囲を拡大します (より広範囲のサービスを分析するために他のチームを導入する可能性もあります)。 XNUMX 番目のアプローチは、最初の仮説を迅速にテストするのに適しています。 具体的な結果が得られれば、より焦点を絞った詳細な分析に進むことができます。

トポロジの構築

サービス固有のビューは、ユーザーが知っていれば非常に便利です。 何 サービスまたはサービスのグループは、遅延の増大やエラーの原因となります。 ただし、複雑なシステムでは、特にサービスからエラー メッセージが報告されなかった場合、障害発生時に問題のサービスを特定するのは簡単な作業ではない可能性があります。

サービス トポロジの構築は、どのサービスでエラー率の急増や遅延の増加が発生し、サービスの著しい低下を引き起こしているかを特定するのに非常に役立ちます。 トポロジの構築について話すとき、私が言っているのは、 サービスマップ、システムで利用可能なすべてのサービスとその特徴が表示されます。 デス・スターの形をした建築の地図。 このビューは、有向非巡回グラフに基づくトレースビューと何ら変わりません。 代わりに見たいのは 動的に生成されるサービス トポロジ、エラー率、応答時間、または特定の不審なサービスの状況を明確にするのに役立つユーザー定義パラメータなどの特定の属性に基づいています。

例を挙げてみましょう。 架空のニュース サイトを想像してみましょう。 ホームページサービス （表紙） Redis、推奨サービス、広告サービス、ビデオ サービスとデータを交換します。 ビデオ サービスは、S3 からビデオを取得し、DynamoDB からメタデータを取得します。 レコメンデーション サービスは、DynamoDB からメタデータを受信し、Redis および MySQL からデータをロードし、Kafka にメッセージを書き込みます。 広告サービスは MySQL からデータを受信し、Kafka にメッセージを書き込みます。

以下は、このトポロジの概略図です (多くの商用ルーティング プログラムがトポロジを構築します)。 サービスの依存関係を理解する必要がある場合に役立ちます。 ただし、その間、 デバッグ特定のサービス (ビデオ サービスなど) の応答時間が増加している場合、そのようなトポロジはあまり役に立ちません。

仮想ニュースサイトのサービス図

以下の図の方が適しています。 サービスに問題があります （ビデオ） ちょうど真ん中に描かれています。 ユーザーはすぐにそれに気づきます。 この視覚化から、S3 応答時間の増加によりビデオ サービスが異常に動作しており、メイン ページの一部の読み込み速度に影響を与えていることがわかります。

「興味深い」サービスのみを表示する動的トポロジー

動的に生成されたトポロジは、特に柔軟な自動スケーリングのインフラストラクチャでは、静的なサービス マップよりも効率的です。 サービス トポロジを比較対照できるため、ユーザーはより関連性の高い質問をすることができます。 システムに関するより正確な質問は、システムがどのように機能するかをより深く理解することにつながる可能性が高くなります。

比較表示

もう XNUMX つの有用な視覚化は、比較表示です。 現在、トレースは並べて比較するのにはあまり適していないため、通常は比較が行われます。 スパン。 そして、この記事の主な考え方は、スパンが低レベルすぎてトレース結果から最も価値のある情報を抽出できないということです。

XNUMX つのトレースを比較する場合、基本的に新しい視覚化は必要ありません。 実際には、トレースビューと同じ情報を表すヒストグラムのようなもので十分です。 驚くべきことに、この単純な方法でも、単に XNUMX つのトレースを別々に研究するよりもはるかに多くの成果をもたらすことができます。 さらに強力な可能性があります 視覚化 トレースの比較 合計で。 GC (ガベージ コレクション) を有効にするために最近デプロイされたデータベース構成の変更が、数時間規模でダウンストリーム サービスの応答時間にどのような影響を与えるかを確認することは、非常に役立ちます。 ここで私が説明していることが、インフラストラクチャ変更の影響に関する A/B 分析のように聞こえる場合は、 多くのサービスで トレース結果を使用すれば、真実からそれほど遠くはありません。

まとめ

私はトレース自体の有用性には疑問を持っていません。 私は、トレースに含まれるデータほど豊富で、因果関係があり、文脈に沿ったデータを収集する方法は他にないと心から信じています。 ただし、すべてのトレース ソリューションがこのデータを非常に非効率的に使用しているとも私は考えています。 トレース ツールがトレースビュー表現に留まっている限り、トレースに含まれるデータから抽出できる貴重な情報を最大限に活用する能力が制限されます。 さらに、完全に不親切で直感的でないビジュアル インターフェイスがさらに開発され、アプリケーションのエラーをトラブルシューティングするユーザーの能力が大幅に制限されるリスクがあります。

複雑なシステムのデバッグは、最新のツールを使用したとしても非常に困難です。 ツールは、開発者が仮説を立ててテストするのに役立つ必要があります。 積極的に提供する 関連情報、異常値を特定し、遅延の分布における特徴に注目します。 開発者が本番環境の障害のトラブルシューティングを行ったり、複数のサービスにまたがる問題を解決したりするときにトレースが最適なツールとなるためには、それらのサービスを作成および運用する開発者のメンタル モデルとより一貫性のある独自のユーザー インターフェイスと視覚化が必要です。

分析と推論を容易にするために最適化された方法で、トレース結果で利用可能なさまざまな信号を表すシステムを設計するには、多大な精神的労力が必要になります。 ユーザーが個々のトレースやスパンを確認することなく盲点を克服できるように、デバッグ中にシステム トポロジを抽象化する方法を考える必要があります。

優れた抽象化機能と階層化機能 (特に UI) が必要です。 これは、質問を繰り返して仮説をテストできる仮説主導型のデバッグ プロセスによく適合します。 すべての可観測性の問題を自動的に解決するわけではありませんが、ユーザーが直観を研ぎ澄まし、より賢明な質問を立てるのに役立ちます。 私は視覚化に対して、より思慮深く革新的なアプローチを求めます。 ここには視野を広げる本当の展望があります。

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes ポッドでデバッグするための kubectl-debug プラグイン";
• «マイクロサービス: Kubernetes を使用している場合でも、サイズは重要です";
• «モニタリングと Kubernetes (レビューとビデオ レポート)'。

出所： habr.com