OpenCensus/OpenTelemetry meetup vol.2
にブログ枠で参加してきました。
これは元々Googleが主導していたOpenCensusに関するミートアップとして始まったのですが、第一回開催前にOpenTracingプロジェクトとのマージが発表されたため、現在ではOpenCensusとOpenTracing、そしてマージ後のプロジェクト名であるOpenTelemetryに関するミートアップとなっています。プロジェクトの進捗については@kawasyさんが紹介してくれました。
イベントの雰囲気はTogetterもご覧ください。
個人的に興味深かったのが、「マイクロサービスじゃなくてもトレーシングしたい」勢の発表でした。要は、「分散トレーシングってマイクロサービスの文脈で出てきたものではあるものの、非マイクロサービスでもレイヤが複雑であったりログの収集が難しいようなシステムにも適用できるよね」という内容です。
というのも、私が普段関わっているHadoopを中心とした分散システムもやはりマイクロサービスとは呼べないものの、ストレージ層からバッチ処理層、リアルタイム処理層など互いに独立して開発されている複数のサービス群が、RPCで通信し合い一つのシステムを作り上げています。そこには確かにend-to-endトレーシングの需要があり、2014年頃からHadoop専用の分散トレーシングの仕組みとしてApache HTraceが開発され、本家Hadoopのコードベースにも導入されました。しかし残念ながらHTraceは思ったほど開発が進まずプロジェクトとしてはリタイアしたため、現在はHADOOP-15566にてOpenTracingへのリプレースが進んでいるという状況です。
また、周辺エコシステムでも同様にサポートするための開発が現在進められています。
私はClouderaでサポートをやっているので、日々お客様からHadoopエコシステムに関する障害報告を受けます。その中で、ログとメトリクス（あるいはスレッドダンプやプロファイラ）だけではどうしても潜りきれない事象も存在します。それはもちろん異なるサービス間の通信がトレースしにくいからというのもあるし、単一プロセス内であってもコンテキストが不明なため、どの呼び出しが根本原因となったか、という確証が持てないケースがあるのです。
UberでJaegerを開発し、OpenTracingのファウンダーでありOpenTelemetryの仕様策定にも大きく関わっているYuri Shkuro氏の著書、Mastering Distributed Tracingでもこの問題意識について触れられています。簡単ですが日本語でまとめます。
従来取得できていた情報
メトリクス
- ある時点での任意のカウンター、ゲージ、タイマーといった計測値を示す
- 収集コストは低く、値が正確
- 「あのときXXだった」ことは示せるがそれだけで問題の特定まで至れることは少ない
ログ
- Observabilityのためのより基本的なアイテム
- あるプロセスが何をしているか、を追いかけることができる
- ログを出しすぎるとオーバーヘッドになる
- マルチスレッド間での通信や、プロセス間通信が当たり前の世界では、ログから追いかけるのが困難となる
ここでYuri氏が引用しているのが、GoogleでDapperを開発し、OpenTracingのファウンダーでもあるBen Sigelman氏の資料です。一プロセス内で、ある程度シーケンシャルに処理が進むようなシステムであればログが有効ですが、並行性が上がりプロセス間通信が複雑になるにつれてこのアプローチは立ち行かなくなります。HadoopはここでいうAsync ConcurrencyとDistributed Concurrencyの世界です。
Yuri氏の著書に戻って、分散トレーシングのモチベーションについて氏は次のように述べています。
- メトリクスやログは「単位時間あたりのリクエスト数」や「あるスレッドで何が起こったか」を示すことはできるが、リクエスト間のコンテキストを情報として含んでいない
- まずはマクロにシステム全体のリクエストの流れを把握したい
- 必要に応じて各コンポーネント、特定のリクエストにドリルダウンし、何が起こってるかを把握したい
マクロからミクロへ、という方針はトラブルシューティングの基本ですが、ログとメトリクスだけで進めるのは大変です。分散トレーシングによって改善が進むことを期待したいですね。
最後に、HADOOP-15566で進んでいるOpenTracingとのインテグレーションを使って、シンプルに「クライアントからあるファイルをゲットする」シナリオでJaegerからどのように見えるか試してみました(注意: 本機能は2019年6月時点でClouderaがリリースしているディストリビューションには含まれません)。
クライアントがNameNode(マスター)のどのエンドポイントにアクセスし、その後どのDataNode(ワーカー)からデータを取得しているのかがend-to-endでトレーシングされています。また、タイムラインも明確なのでどこにボトルネックがあるのか非常にわかりやすいですね。
以上、イベントの感想とOpenTracingとHadoopのインテグレーションを試してみました。今後この界隈がいい感じに盛り上がってくるといいですね。各種スライドへのリンクは近日追加されると思います。
