分散トレースとサンプリングについて知っておくべきこと

分散トレーシングを活用したい分散システムで全てのトレースデータを収集し可視化すると、そのデータ量の多さ故に非常に扱いづらいことになるでしょう。そこでトレースデータをサンプリングする必要が出てきます。実はこのサンプリングの方法、大きく2種類あり、New Relicはその両方に対応する機能をリリースしました。機能そのものの説明の前に今日は、サンプリング方法の違いとそれがお客様にとってどんな違いをもたらすのかについて、2020年4月30日に投稿された「What You Need to Know About Distributed Tracing and Sampling」の抄訳をお届けします。

多くのソフトウェアチームがモノリスからマイクロサービスへの移行を行っており、マイクロサービスを使用してアプリを開発することは明らかにメリットがあります。サービスをより小さくてわかりやすく分けることで、独立してデプロイ、拡張、更新することができます。また、アプリケーションをより小さなサービスに分解することで、各コンポーネントに最適なテクノロジーやフレームワークを柔軟に選択することができます。この柔軟性により、ソフトウェアをコードから本番に反映するまでのスピードを上げることができます。しかし、その一方でより複雑さも増します。

現代のアプリケーション環境で働くDevOps チームは、サービスが多くの依存関係を持ち、他の多くのサービスと通信できる、高度に分散されたシステムを担当しています。さらに、各サービスが異なるテクノロジー、フレームワーク、インフラストラクチャを使用して実行しており、異なるデプロイメカニズムを使用している可能性があるため、さらに複雑さが増しています。また、現実の環境ではほとんど、レガシーなモノリスアプリと最新のマイクロサービスベースのアプリが混在しています。

このような複雑さは、問題を追跡して解決しなければならないときに大きな頭痛の種となります。例えば、基本的なEコマースのアプリケーションスタックを考えてみましょう。エンドユーザーがオンラインで購入すると、一連のリクエストが多数の分散サービスとバックエンドデータベースを経由します。これらのリクエストの経路は、ストアフロント、検索、ショッピングカート、インベントリ、認証、サードパーティのクーポンサービス、支払い、配送、CRM、ソーシャル統合などを通過する可能性があります。これらのサービスのいずれかに問題があると、顧客体験が損なわれる可能性があります。ある調査によると、回答者のなんと95%が悪い体験が原因でウェブサイトやアプリを離れるという結果が出ています。

複雑さを切り抜ける

複雑な分散システムのエラーやボトルネックを、エンドユーザーに影響が及ぶ前に迅速にトラブルシューティングする必要があります。分散トレーシングを使用することで、各トランザクションが分散システムを通過する際の経路を追跡し、それが触れるすべてのサービスとの相互作用を分析することができます。この機能により以下のことが可能になります。

• すべてのサービスのパフォーマンスを深く理解する
• サービスの依存関係を可視化する
• パフォーマンスの問題をより迅速かつ効果的に解決
• システム全体の健全性を測定する
• 価値の高い分野を優先順位をつけて改善する

迅速な問題解決とは、「数ホップ先」の下流サービスがどのようにして重要なボトルネックを生み出しているかを理解することです。同様に重要なことは、効果的な問題解決とは、コードを最適化するなどの方法で再発を防ぐ方法についての洞察を得ることです。問題がいつ、なぜ、どのようにして発生したのかを特定できなければ、小さな欠陥がプロダクションに残り続ける可能性があります。「Perfect Storm」が発生すると、システムは一斉に壊れてしまいます。分散トレースは、個々のリクエストの詳細なビューを提供するので、より大きなシステムのどの部分に問題があるのかを正確に把握することができます。

分散トレースで有用な情報を浮上させる

分散トレーシングは強力なツールですが、すべてのトレースが同じように実行可能なわけではありません。分散トレースツールを使用する場合、次のようないくつかの重要な質問に素早く答えようとしている可能性が高いです。

• 分散システムの全体的な健全性とパフォーマンスは？
• 分散システム全体のサービスの依存関係は？
• 分散システムにエラーが発生しているのか、発生している場合はどこにあるのか？
• サービス間やサービス内で異常な遅延が発生していないか？発生している場合、その原因は何か？
• 管理しているサービスの上流と下流にはどのようなサービスがありますか？

分散システム内のすべてのサービスがトレーステレメトリを発している場合、たとえ一握りのサービスであっても、データ量はあっという間に圧倒的なものになります。そして、分散システム全体のトランザクションリクエストの大部分は何の問題もなく完了するため、ほとんどのトレースデータは統計的には面白くなく、問題を迅速に発見して解決するのには一般的に役に立ちません。

エラーやレイテンシを見つけるためにあらゆるトレースをふるいにかけると、典型的な「干し草の山の中の針」の問題になります。人間がリアルタイムで分散システムを横断してすべてのトレースを観察し、分析したところで、意味のあるものにすることはできないでしょう。分散トレースツールを使ってデータをサンプリングすることで、最も有用な情報を抽出して行動に移すことができます。

ここでは、分散トレースのためのいくつかの異なるタイプのサンプリング方法を見てみましょう。

headベースのサンプリングの概要

大量のトレースデータを処理するために、ほとんどの伝統的な分散トレースソリューションは、ヘッドベースのサンプリングを使用します。ヘッドベースのサンプリングでは、分散型トレースシステムは、多くのサービスを通過し終える前にトレースをランダムに選択してサンプリングします（そのため、「ヘッドベース」という名前がついています）。ここにヘッドベースサンプリングの利点と限界があります。

利点：  

• トランザクションのスループットが低いアプリケーションに適しています。
• 迅速かつ簡単に立ち上がることができます。
• モノリスとマイクロサービスが混在する環境に適しています。
• アプリケーションのパフォーマンスへの影響はほとんどありません。
• トレースデータをサードパーティベンダーに送信するための低コストソリューションです。
• 統計的なサンプリングにより、分散システムに十分な透明性を与えます。

制限：  

• トレースはランダムにサンプリングされます。
• トレースが多くのサービスを通過してパスが完全に完了する前にサンプリングされるため、どのトレースが問題に遭遇するかを事前に知る方法はありません。
• 高スループットのシステムでは、エラーや異常な遅延を伴うトレースがサンプリングされ、見逃してしまうことがあります。

tailベースのサンプリングの概要

重要なサービスを含む高スループットの分散システムでは、すべてのエラーを観測する必要があり、テールベースのサンプリングがソリューションとして活用できます。tailベースのサンプリングでは、分散トレースソリューションはトレースの100%を観測し分析します。サンプリングはトレースが完全に完了した後に行われます。従って「tail」ベースと呼ばれています。サンプリングはトレースが完全に完了した後に行われるため、エラーや異常なレイテンシといった最も実用的なデータを持つトレースをサンプリング対象にし、可視化することができ、問題がどこにあるのかを素早く正確にピンポイントで特定することができます。この機能は、古典的な「干し草の山の中の針」の問題を解決するのに役立ちます。ここでは、テールベースのサンプリングの利点と限界を説明します。

利点：  

• 100%のトレースを計測し、分析します。
• サンプリングは、トレースが完全に完了した後に行われます。
• エラーやこれといって特徴のない遅さのトレースをより迅速に可視化することができます。

（既存のソリューションの）制限：

• サンプリングを実行するソフトウェアを実行するには、追加のゲートウェイ、プロキシ、サテライトといったものが必要です。
• サードパーティ製ソフトウェアの管理とスケーリングには、さらに苦労しなければなりません。
• 膨大なデータを転送して保管するための追加費用が発生します。

選択する柔軟性 

ソフトウェアの世界では、新しいテクノロジーの採用が拡大しているため、アプリケーション環境はますます複雑になっています。DevOpsやソフトウェアチームは、モノリス環境とマイクロサービス環境の両方でアプリケーションを開発・管理することになり、あらゆるテクノロジースタックの問題を迅速に発見・解決するための分散トレースツールが必要になります。

すべてのトレースが同じというわけではなく、分散トレースデータのサンプリングの種類にはそれぞれ利点と限界があります。各アプリケーションのモニタリングニーズを考慮して、ユースケースとコスト/ベネフィット分析に基づいて最適なサンプリング方法を選択する柔軟性が必要です。