OpenTelemetryによる効果的・効率的なオブザーバビリティ

スカイスキャナーのプリンシパルエンジニアで、Practical OpenTelemetryの著者であるDaniel Gomez Blanco氏は、QCon Londonで、数百のサービスにわたってOpenTelemetryを採用したことに基づく、自社での大規模なオブザーバビリティイニシアティブの経験、および組織全体でオープンスタンダードを採用することで得られた動機と価値について語った。

Blanco氏は次のようなフレーズでスタートした。システムが変わったとき、何が変わったのか、どうやって知ることができるのだろう？原始的な方法としてprint文がある。しかし、実際の分散システムではもっとうまくスケールさせる必要がある。例えばスカイスキャナーのシステムは複雑で、何百ものサービスが分散して展開され、それらの間には何千もの相互接続がある。

スカイスキャナーのような複雑なシステムの中で、ある変更が特定のサービスやその依存関係にどのような影響を与えたかを判断するにはどうすればよいか。そこで登場するのが「オブザーバビリティ」だ。

Blanco氏は、オブザーバビリティが重要な理由、オープンスタンダードがオブザーバビリティをどのように支援するか、組織で展開する方法、そして実際に採用する方法について説明する。オブザーバビリティは2つの異なる方法で役に立つ。1つ目は、デプロイ後に私のシステムは期待通りに動作しているかという問いに答えることだ。そして2つ目は、回帰テストで不具合が発生したときに、なぜ期待通りの動作ができないのか？

効果的なオブザーバビリティとは。

• 高い粒度：system transactions内の個々の操作に対応する詳細なテレメトリデータ。

• 豊富なコンテキスト：複数のテレメトリのシグナルと依存関係を、システムの1つの全体的なビューの下で考慮すること。

• シグナルの相関：メトリクス、トレース、ログを1つのイベントの流れの下にリンクさせること。

• サービス相関：異なるサービスからのテレメトリを同じ共通操作の一部として関連付けること。

次にBlanco氏は、OpenTelemetryを活用した効果的・効率的なオブザーバビリティの詳細、ベンダーから購入するかオープンソースを利用するかの購入対構築の判断と、スカイスキャナーにおけるOpenTelemetryの採用と展開について解説した。

そして最後に、いくつかの重要なポイントを紹介した。

• 複雑なシステムには、効果的なオブザーバビリティが必要である。
• オープンスタンダードでシンプルにする。
• OpenTelemetryでシグナルの有効活用を実現する。

InfoQでは、Daniel Gomez Blanco氏に、効果的・効率的なオブザーバビリティについてインタビューをした。

InfoQ: スカイスキャナーでは、どのようにOpenTelemetryの採用を推進したのか？

Daniel Gomez Blanco氏: スカイスキャナーでは、一般的に開発者支援に何年も投資しており、それは継続的に回収されています。OpenTelemetryをサービスオーナーに最小限の摩擦で展開するために、私たちのプラットフォームエンジニアは2つの主要な分野に取り組んでいました。

1つ目は、コア・ライブラリとベース・イメージのセットで、デフォルトの、意見を反映したコンフィギュレーションを含み、それらを使用するアプリケーションにコードの変更を要求することなく、我々のオブザーバビリティ戦略を推進できます。ある意味、これらは私たち自身のOpenTelemetry Distroのようなものです。スカイスキャナーで動作するアプリケーションは、これらのデフォルトを使用して、インスツルメンテーション・パッケージ、プラグイン、エクスポータなどの側面を設定です。これと Open Telemetry の OpenTracing (現在は非推奨) との互換性のおかげで、OpenTelemetry との最初の統合は、これらの内部ライブラリの小さなバージョンアップだけでした。

2つ目はOpenTelemetry Collectorsで、すべてのテレメトリデータを転送します。これは、観測可能なプラットフォームへのテレメトリと認証のラストホップを処理でき、必要に応じてデータを再集約し変換するのに役立ちます。これらを組み合わせることで、最適で負荷の低いパスを得ることができサービス・オーナーのためにすぐにでも観測可能な状態にできます。

InfoQ: OpenTelemetryを採用して得られるメリットは？

Daniel Gomez Blanco氏: OpenTelemetryを採用することで得られるメリットはたくさんあり、ひとつを選ぶのは難しいが、私の考えでは、Open TelemetryのAPIデザインによって、状況に応じてライブラリの作者、テレメトリの専門家、アプリケーションの保守担当者といった、最高の人材に委ねられることが最大のメリットでした。

このようなテレメトリは、オブザーバビリティの3本柱という古い概念ではなく、相関性のあるデータの1つの流れの下に結びつけることができます。メトリックス、トレース、またはログを特定のコンセプトに組み込む場合、バックエンドでデータを送信する場所を決めたり、そのために特定のSDKにライブラリ依存したりする必要がないです。これらの詳細はアプリケーションの起動時に設定でき、サービスオーナーは選択したテレメトリのバックエンドと統合したり、コード変更なしでそれらの間を切り替えたりすることが可能です。

重要なことは、アプリケーション、フレームワーク、およびライブラリを、分散システムの実行に必要な他のすべての依存関係とのコンテキストにおいて、ユビキタスで観察可能な方法で記述できることです。

InfoQ: もし、あなたの跡を継ぎたいと思う人がいたら、どのようなところから始めるのが良いのだろうか？

Daniel Gomez Blanco氏: 最良の出発点は、OpenTelemetryが特にあなたの組織にもたらす価値を理解し、それを効率的に伝えることができるようになることです。

これは、各チームや組織に特有の複数の要因によって異なる可能性があります。例えば、テレメトリをインスツルメントしたり、転送したりするレガシーシステムを多く持つ企業にとって、もっとも大きなROIは、テレメトリライブラリとエクスポートパイプラインの簡素化です。一方、前人未踏の開発プロジェクトでは、OpenTelemetryがすぐに提供できる高品質のテレメトリの量によって、もっとも大きな価値がもたらされます。この価値を伝えることで、採用を促進し、エンジニアリング・リード間の優先順位を合わせることができます。

とはいえ、いくつかの共通パターンが役に立つことは確かです。OpenTelemetryが提供する、サポートする言語用のインスツルメンテーション・ライブラリの評価は良い出発点でしょう。高品質のテレメトリを無料で手に入れられるだけでなく、大きな開発者コミュニティがインスツルメンテーション・ライブラリのあらゆる変更をサポートし、サービスをインスツルメンテーションする個々のチームの労力を軽減してくれます。さらに標準的な命名規則に従ってテレメトリを生成するため、すべての観測プラットフォームとエンジニアが同じ言語で話すことが可能になります。

OpenTelemetry環境のもう一つの重要な部分はコレクターです。コレクターは、オブザーバビリティエンジニアのスイスアーミーナイフのようなもので、既存の非OpenTelemetryソリューションとの統合を助け、標準フォーマットでデータを生成し始め、このデータを複数のニーズに合わせて変換を可能にします。OpenTelemetryが実際に動いているのを見ることから始めるのが一番ですが、それにはOpenTelemetryの公式デモプロジェクトが最適です。