コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第166回　Googleの分散トレーシングツールDapper（パート3）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第166回　Googleの分散トレーシングツールDapper（パート3） (中井悦司) 2024年1月

はじめに

　前回に続いて、2010年に公開された論文「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」に基づいて、Google社内で使用されている分散トレーシングツールDapperを紹介していきます。今回は、Google社内での実際の利用例を紹介します。

システム開発時の活用例

　Dapperは、複数のマイクロサービスが連携する際のパフォーマンスのボトルネックを分析することを目的に開発されましたが、Google社内のさまざまなチームが利用を始めると、その他の場面でも役立つことが分かってきました。論文の中では、そのような典型例として、新しいシステムを開発する際にDapperが役立った例が紹介されています。AdWordsの開発チームは、広告レビューシステムの一つをスクラッチで再開発する際に、Dapperで次の様な問題を解決しました。

性能改善: 開発中のサービスに対してDapperのトレースを定期的に分析することで、性能改善の効果が大きそうな場所を特定し、開発段階から継続的な性能改善を実現しました。また、本来は並列に処理できるサービスが誤ってシリアルに実行されている箇所などもDapperのトレースから特定できました。
データベースアクセスの問題発見: 開発中のシステムは、読み書き可能なマスターと読み込み専用の複数のレプリカに別れた分散データベースを使用していました。レプリカにアクセスするべき処理が誤ってマスターにアクセスしている箇所がDapperのトレースから特定できました。
テストへの組み込み: 新しいコードをリリースする際のインテグレーションテストにDapperによるトレーシング処理を組み込み、Dapperのトレースログからシステムの不正な挙動を発見しました。
例外監視システムとの連携: Googleのコンテナ実行基盤であるBorgには、実行中のプロセスが例外（Exception）を発生して停止した場合、これを検知してレポートを発行する仕組みがあります。停止したプロセスがDapperによるトレーシングの対象だった場合、該当のTrace IDとSpan IDがレポートに付与されるため、例外発生の原因分析にもトレースログが活用できました。

Webサーチの性能改善

　Webサーチでは、例外的にレスポンスが遅い検索処理が発生することがあります。このような例外的な問題の根本原因を推測するのは容易ではありません。Webサーチの開発チームでは、Dapperのトレースログを利用して、根本原因の分析を行っています。例えば、図1は、検索処理のトレース中に、ネットワーク処理の大きな遅延が確認されたものの割合を検索のレスポンス時間ごとにグラフ化したものです。これを見ると、ネットワーク処理の遅延がレスポンス時間に影響していることがはっきりと分かります。ここに含まれるネットワーク遅延は、システム全体のスループットには影響しない突発的な遅延のため、Dapperのトレースログがなければ発見は難しかったと想像されます。

fig01

図1 検索のレスポンス時間とネットワーク処理の遅延の関係（論文より抜粋）

　また、Webサーチでは、特定の検索処理がシステムの意図しない挙動を引き起こすこともあります。Dapperのトレースログから、例外的にレスポンスが遅い検索処理をフィルタリングして、これらに共通の処理のパターンを分析することもあるそうです。

その他の利用例

　論文内では、この他にも次の様な分析にDapperが利用されていることが紹介されています。

サービス依存関係の分析: Googleのプロダクション環境には、複数のシステムから共通に利用されるマイクロサービスが多数あります。このような共有サービスがさらに他の共有サービスを利用していることもあり、複数のシステムにまたがった複雑な依存関係が生まれます。「Service Dependenciesプロジェクト」チームでは、Dapperを利用して、このような依存関係の把握を自動化しています。
共有リソースに対する依存の分析: マイクロサービス間の依存関係に加えて、複数のシステムから利用されるBigtableの共有テーブルなど、共有リソースに対する依存性の把握にもDapperが利用されています。例えば、Dapperのアノテーション機能を利用して、アクセス対象のテーブル名をトレースログに追加することで、特定のテーブルを利用するシステムが把握できます。
共有ストレージシステムの分析: 上記の共有リソースの一例と言えますが、Googleの分散ストレージシステムでは、ミドルウェアレベルでの多層的な依存関係が発生します。例えば、第7回の記事で紹介したMegastoreでは、Megastore→Bigtable→Google Filesystemのような階層構造がありました。この時、Dapperのアノテーション機能を利用すれば、BigtableからGoogle Filesystemへのアクセスが、Megastoreの特定ユーザーからのアクセスに偏っていないかなどの分析が可能になります。
クラスター間通信の分析: 一般的なネットワーク監視システムでは、クラスター間のネットワーク通信おいて、全体的な通信量は把握できても、具体的にどのシステムやマイクロサービスが通信を行っているかまでをリアルタイムに把握するのは困難でした。Googleのネットワーク管理チームは、Dapperのトレースログからアプリケーションレベルでのクラスター間通信を把握して、突発的な通信量の増加などの際は、その原因となるアプリケーションの特定に利用しています。

次回予告

　今回は、2010年に公開された論文「Dapper, a Large-Scale Distributed Systems Tracing Infrastructure」に基づいて、Google社内で使用されている分散トレーシングツールDapperについて、Google社内での実際の利用例を紹介しました。
　次回は、Googleの分散データベースの代表と言える、Spanner、Bigtable、BigQueryの性能プロファイリングに関する論文を紹介します。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡