## Memo - ![[Pasted image 20240609171059.png|600]] ## Memo with LLM ### 要約 #### 問題意識 分散システムにおけるエッジケース（まれな異常ケース）のトラブルシューティングが困難であることが問題視されています。現在の分散トレーシングフレームワークは、特定のリクエストをトレースするために多大なオーバーヘッドを伴うか、逆にエッジケースを見逃してしまうというトレードオフに直面しています。 #### 既存手法とその課題 1. **ヘッドサンプリング（head sampling）**: - システムに入るリクエストを無差別にトレースする方法。 - エッジケースを捕捉する可能性が低い。 2. **テイルサンプリング（tail sampling）**: - 全てのリクエストをトレースし、後でエッジケースのみを保持する方法。 - 高いオーバーヘッドとデータ処理コストが問題。 これらの手法は、エッジケーストレースを大規模に行う上で実用的ではありません。 #### 解決の提案 **Hindsight**という軽量で常時稼働の分散トレーシングシステムを提案しています。これは以下の特徴を持ちます： - **レトロアクティブサンプリング（retroactive sampling）**: 問題の症状が検出された後でトレースデータを遡って取得するアプローチ。 - 症状がプログラム的に検出可能なエッジケース（高い遅延、エラー、ボトルネックなど）に対して効果的。 Hindsightは、通常のリクエスト処理中にトレースデータを生成し、それを保持しつつ、症状が検出された場合にのみデータを収集します。これにより、オーバーヘッドを最小限に抑えつつ、必要なエッジケーストレースを確実に捕捉することが可能になります。 #### 評価結果 Hindsightは以下の特性を持つことが評価により示されました： - リクエストあたりナノ秒レベルのオーバーヘッドでトレースデータを生成。 - 1秒あたり数百万のリクエストを処理可能。 - 高遅延やエラー発生時に詳細なトレースを保存できることが実証。 これにより、Hindsightは既存のトレーシングシステムと比較して、より効率的かつ効果的にエッジケーストレースを提供します。 **Hindsight**は、分散システムのエッジケース（まれな異常ケース）を効率的にトレースするための分散トレーシングシステムです。以下にその具体的な特徴と仕組みを説明します。 ### Hindsightの特徴 1. **軽量で常時稼働**: - 常に動作しており、通常のリクエスト処理中にトレースデータを生成します。 2. **レトロアクティブサンプリング**: - 問題の症状が発生した後にトレースデータを取得する仕組みです。 - トレースデータは事前にすべて収集されるのではなく、問題が検出されたときにのみ必要なデータが収集されます。 3. **症状に基づくトリガー**: - 高遅延やエラーなど、問題の症状が検出された際にトリガーが発動し、トレースデータが保存されます。 ### Hindsightの仕組み 1. **トレースデータの生成**: - 各リクエストに対して一意のトレースIDが付与され、そのリクエストに関するすべてのイベントが記録されます。 - イベントごとにデータが生成され、ローカルメモリに保存されます。 2. **トリガーメカニズム**: - リクエストが処理される過程で、異常（エラーや高遅延など）が発生すると、トリガーが発動します。 - トリガーが発動すると、関連するトレースデータが収集され、後から解析できるように保存されます。 3. **ブレッドクラム**: - リクエストが分散システム内を移動する際に、その経路（ブレッドクラム）が記録されます。 - 異常が検出された場合、この経路をたどって関連するすべてのトレースデータが収集されます。 4. **データの保存と解析**: - トリガーが発動した際に収集されたデータは、バックエンドのトレースコレクターに送信されます。 - このデータを解析することで、問題の根本原因や影響範囲を特定することができます。 ### 利点 - **低オーバーヘッド**: 通常のリクエスト処理にほとんど影響を与えずに動作し、問題が発生したときにのみデータを収集するため、全体的なシステムパフォーマンスへの影響が少ない。 - **スケーラビリティ**: 大量のリクエストを処理する能力があり、広範な分散システムにも適用可能。 - **高い精度**: 問題が発生したリクエストに関連する詳細なトレースデータを提供し、問題の診断と修正を迅速に行える。 Hindsightは、このような特徴を持つことで、従来のトレースシステムが抱えるオーバーヘッドとエッジケース検出のトレードオフを解決し、効率的かつ効果的なトレースを実現しています。 Hindsightの限界や弱点については、以下の点が挙げられます。 ### 1. メモリとバッファプールの制約 - **バッファプールのサイズ**: Hindsightはローカルメモリにトレースデータを保存しますが、バッファプールのサイズに制約があります。バッファプールが小さいと、トリガーが発動する前にデータが上書きされるリスクがあります。十分なメモリがない場合、トレースデータを長期間保持することが難しくなります。 ### 2. トリガーの検出遅延 - **トリガー発動の遅延**: 問題の症状が検出されてからトリガーが発動するまでの遅延がある場合、重要なトレースデータが失われる可能性があります。特に短時間で発生する問題に対しては、トリガーが間に合わないことがあります。 ### 3. エージェントの信頼性 - **エージェントの故障**: Hindsightのエージェントがクラッシュすると、そのエージェントが管理しているトレースデータは失われる可能性があります。エージェントのクラッシュによって、トレースデータの一部が欠落し、全体としてのデータの一貫性が損なわれる可能性があります。 ### 4. クロスレイヤーのトレース - **他のレイヤーのトレースとの統合**: Hindsightは主にアプリケーションレベルの問題に焦点を当てています。ネットワークやハードウェアレベルの問題をトレースするためには、他のテレメトリーデータとの統合が必要ですが、これにはさらなる研究と開発が必要です。 ### 5. イベントホライゾンの制約 - **イベントホライゾン**: イベントホライゾン（トリガー発動からデータが上書きされるまでの時間）は限られており、これが短すぎるとトリガー発動前に重要なデータが失われます。特に高負荷時には、イベントホライゾンが短くなる可能性があります。 ### 6. 高負荷時のパフォーマンス - **高負荷時のスケーラビリティ**: 高負荷状態では、トリガーが頻繁に発動し、エージェントやバックエンドのトレースコレクターに大きな負荷がかかります。これにより、ネットワーク帯域幅の消費が増加し、システム全体のパフォーマンスが低下する可能性があります。 ### 7. データの一貫性 - **データの一貫性維持**: トリガーが発動した際に、関連するすべてのトレースデータが一貫して収集される必要がありますが、システムが過負荷になると、データの一貫性を維持するのが難しくなる場合があります。 これらの限界や弱点を認識し、それに対応するための適切な対策や追加のメカニズムを導入することが、Hindsightの実際の運用において重要です。 ## Abstract 今日の分散トレースフレームワークは、稀なエッジケースリクエストをトラブルシュートするのに適していない。問題の核心は、特異性とオーバーヘッドのトレードオフである。一方では、フレームワークはシステムに入ってきたリクエストを無差別に選んでトレースすることができます（ヘッドサンプリング）が、これは関連するエッジケースのトレースを捕捉する可能性が低いです。一方、フレームワークはすべてをトレースし、後で興味深いエッジケースのトレースだけを残すことができますが（テールサンプリング）、これはトレースされたアプリケーションに高いオーバーヘッドと膨大なデータ取り込みコストがかかります。 本論文では、高いテールレイテンシ、エラー、ボトルネックになったキューなど、プログラムで検出可能な症状を持つあらゆるエッジケースについて、このトレードオフを回避する。トレースを熱心に取り込んで処理する代わりに、Hindsightは問題の症状が検出された後にのみ、トレースデータを遅延的に取得します。Hindsightは車のダッシュ・カムに似ており、突然の衝撃を検知すると、過去1時間の映像を保存する。Hindsightを使用する開発者は、過度のオーバーヘッドや運に依存することなく、希望するエッジケースのトレースを正確に得ることができます。我々の評価では、Hindsightは毎秒数百万のリクエストに対応し、トレースデータを生成するためにナノ秒レベルのオーバーヘッドを追加し、ノードあたりGB/秒のデータを処理し、既存の分散トレースシステムと透過的に統合し、エッジケースの問題が検出されたときに実際のユースケースで完全で詳細なトレースを永続化することに成功しています。