OpenTelemetryがアプリのトレースと設計を変える

複数の場所で稼働する多数のマイクロサービスが相互に連携することで機能するクラウドネイティブアプリでは、オブザーバビリティが運用の鍵となります。マイクロサービスアプリは疎結合であるため、各マイクロサービスがそれぞれ異なる方法でアクティビティを報告する可能性があります。こうしたテレメトリデータを集約して相関付けるツールがなければ、トラブルシューティングに不可欠な、リクエスト処理の開始から終了までの追跡は極めて困難であり、不可能な場合もあります。

多機能なオブザーバビリティツールを探す中で、NGINX Modern Apps Reference Architecture（MARA）プロジェクトのチームはOpenTelemetryを選択しました。F5のOSSチームがこの新興プロジェクトを選んだことを受け、さらに詳しく掘り下げます。GlueCon 2022では、F5のOffice of the CTOでアーキテクトを務めるGranville Schmidtと、OpenTelemetryの現状と今後提供される機能に期待する理由について対談しました。以下で対談をご覧いただけます。また、このブログでは、OpenTelemetryがクラウドネイティブアプリケーションの分野で優れた資産となる理由を詳しくご紹介します。

OpenTelemetryがObservability 2.0を支える

バルセロナで開催されたKubeCon 2019で初めて発表されて以来、OpenTelemetryには熱意ある多くのコントリビューターが集まっています。コントリビューション数では、Cloud Native Computing Foundation（CNCF）で2番目に人気のあるプロジェクトであり、過去6か月間のコントリビューションのペースはこれまで以上に高まっています。この多数のコントリビューターは、OpenTelemetryが成熟し、時代を先取りすることをいとわないアーリーアダプターと、成熟した製品を求める現実主義者との間にあるキャズムを越え始めていることを示しています。

OpenTelemetryはデータに重点を置いています。具体的には、アプリケーションをより深く理解し、トラブルシューティングや改善を行うために必要なデータとデータストリーム（テレメトリ）です。データは、大規模に集約、分析、可視化できて初めて役立ちます。OpenTelemetryはデータの可視化方法を示すものではありませんが、どのようなデータを取得できるかを気にする必要がなくなり、そのデータで何ができるかに集中できるようになります。

OpenTelemetryでは、こうしたデータソース間の相関付けを自分たちで行う必要がなく、自然に相関付けることができます。アプリ間のイベントを相関付けるOpenTelemetryの機能は、クラウドにおけるアプリケーションのアクティビティを測定する新たな基準であるObservability 2.0への移行を促しています。データはすでに相関付けられているため、アプリケーション環境に対する見方が変わります。アプリが稼働しているかどうかを把握するだけでなく、あらゆるリクエストがアプリ内でたどる経路を把握できるようになります。

OpenTelemetryに先立ち、OpenTracing（OT）とOpenCensus（OC）という2つの注目すべきオープンソースプロジェクトがありました。どちらも、必要な情報を取得し、それが最新のアプリに与える影響を把握できるよう、トレースデータの形式を標準化するという課題に取り組んでいました。両プロジェクトには共通点があったものの、リソースをめぐって競合していたため、企業は多くの場合、どちらか一方を選ばなければなりませんでした。2019年3月、両プロジェクトはOpenTelemetryへの統合を発表しました。その目的は、トレースデータの生成方法と形式を統一することでした。OpenTelemetryプロジェクトではさらに、トレースと同じテレメトリチャネルを介して、その他の種類のオブザーバビリティデータ（メトリクスとログ）を取得するための標準策定を進めており、統合性と明確性の向上につながっています。

次に、OpenTelemetryの注目すべき2つの機能、分散トレーシングとアプリケーションインテリジェンスについて見ていきましょう。

最新のアプリケーションアーキテクチャに分散トレーシングが必要な理由

分散トレーシングは以前から存在しますが、過去10年間のさまざまな変化により、その必要性が高まっています。Cynefinフレームワークを用いることで、現代のアプリケーションが直面している変化や課題の一部を明らかにできます。

Cynefinフレームワークは、単純な領域から複雑な領域へ移行するにつれて、実践方法をどのように変えられるかを示しています。課題は、それぞれ異なる特性を持つ2つの別々の経路に沿って移行する必要があることです。単純な領域から複雑な領域へ直接近道しようとすると、混乱が生じ、移行が不完全なままになることが少なくありません。

モダンアプリとクラウドネイティブへの移行において、2つの経路を構成する要素を確認しましょう。第1の経路（Cynefin図のY軸）には、通常はマイクロサービスアーキテクチャを採用し、各アプリが特定の役割を担うモダンアプリがあります。第2の経路（X軸）では、需要に応じてマイクロサービスのインスタンスが起動・停止し、ネットワークの問題に応じて別のホストへ移動するため、複雑な環境は一時的なものとなります。

Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Platform（GCP）などのクラウド環境の登場と急速な拡大も考慮する必要があります。このようなクラウドの利点の1つは、現在の需要レベルに合わせてリソースを拡張または縮小できる弾力性です。さらに、コンテナオーケストレーション（最も一般的にはKubernetesを使用）の影響が加わると、リソースの数や配置が時間とともに変化し、カオス的な挙動が見られるようになります。（この比較的限定された見方でもカオス的であり、サーバーレス関数などの要素によって、その度合いがさらに増す可能性があります。）

最新のアーキテクチャでは、多数の独立した構成要素から、アプリの監視と保守に必要なテレメトリが生成されるため、データ量が膨大になり、複雑さも増します。インフラストラクチャや通信経路を完全には制御できないため、問題が確実に再現するとは限らず、意図的に発生させることも容易ではありません。変化し続ける環境を把握して分析するには、すべてのアクティビティと関連要素を追跡できるテクノロジーが必要です。

そこで役立つのがOpenTelemetryです。

OpenTelemetryが拓く分散トレーシングの未来

分散トレーシングは業界に大きな変化をもたらしており、特に、リクエストから得られるメトリクスを通じてパフォーマンスを内部的に可視化する方法に影響を与えています。分散トレーシングでは、さまざまな種類の新しいメトリクスを追跡できます。中でも一般的なのは、単位時間あたりのリクエスト数、単位時間あたりのエラー数、およびその単位時間内に集約されたリクエストの処理に要する時間に関するメトリクスです。

メトリクスは以前から利用されており、管理や保存が容易で、簡単に集約でき、数学的分析にも適しています。OpenTelemetryでは、メトリクスを生成するすべてのアプリが、テレメトリ（転送）レイヤーを介して共通の収集ポイントにメトリクスを送信できます。これにより、疎結合サービスが生成するデータを、基盤となるインフラストラクチャも含めて整合させやすくなります。つまり、OpenTelemetryを使用すると、メトリクスの取得と送信が容易になります。

OpenTelemetryは、イベントの関連付けを困難にするタイムスタンプのドリフトやスキューの問題解決にも役立ちます。OpenTelemetryは各リクエストにTraceIdを割り当てますが、クラウドネイティブアーキテクチャで頻繁に発生するドリフトやスキューの影響をデータが受ける可能性は残ります。ドリフトやスキューは、レポート経路ごとの所要時間の違いや、各ホストのクロックが厳密に同期されていないことによって発生する場合があります。分散トレーシングでは、トラフィック処理中のコンポーネント間の通信を追跡することで、関連するアプリに詳細な計装を施すことなく、個々のスパン（作業単位であり、トレースの構成要素）をOpenTelemetryで測定できます。

これら3つのシグナル（テレメトリのカテゴリー）を組み合わせることで、問題を修正し、アプリを本番環境で求められる品質に戻すことができます。

• メトリクス – 「問題は発生しているか？」
• トレース – 「問題はどこにあるか？」
• ログ – 「問題は何か？」

ここで再びObservability 2.0に戻ります。トレースを取得し、どのメトリクスがどのトレースに対応しているかを即座に確認できることで、強力な分析が可能になります。たとえば、メトリクスが問題を示している場合、分散トレーシングを使用すれば、最初の問題を引き起こした特定のリクエストまで遡り、そのリクエストが処理される各ステップを追跡できます。トレースは発生順に並んだスパンで構成されているため、リクエストの処理過程をステップごとに追跡できます。最初のイベントから、示された問題を経て最終結果に至るまで、何がどの順序で発生したかを把握することで、アプリ内で注意を向けるべき「場所」を正確に特定できます。

単純なことのように聞こえるかもしれませんが、OpenTelemetryの分散トレーシングは、リクエストの成否や実行タイミングを示す指標となるため、ユーザーがどのような状況を経験しているかを深く把握するのに役立ちます。ユーザーとして重視するのは、自分のリクエストです。サイト信頼性エンジニア（SRE）として重視するのは、集約されたリクエストです。OpenTelemetryは、すべてのアプリにわたって必要なデータを利用できるように設計されているため、その両方を把握できるだけでなく、集約データから個別の詳細へ掘り下げることもできます。

AIとMLによるアプリケーションインテリジェンス

OpenTelemetryから得られるこの新しいデータストリームにより、開発や運用上の対応を状況に応じて適応させ、自動化することも可能になります。蓄積されたすべてのデータを活用することで、アプリケーションをよりインテリジェントにできます。F5は現在、「アダプティブアプリケーション」と呼ぶアプリケーションの開発と導入に取り組むお客さまの支援に注力しています。アダプティブアプリケーションとは、その名のとおり、環境の変化に応じて動作を自動的かつインテリジェントに調整するアプリケーションです。

そのため、さまざまなソリューションで人工知能（AI）や機械学習（ML）の活用が大幅に増えています。しかし、単にこれらが流行の用語だからではありません。現在では、因果関係について正確な結論を導き出し、適切な対応を設計するのに十分なデータが得られるようになったため、AIとMLが役立つのです。

OpenTelemetryは、テレメトリデータを利用しやすく標準化することで、適応型アプリへの移行を大幅に容易にします。さまざまな種類の製品が同様のメトリクスを出力するようになり、OpenTelemetryで確立されたセマンティック規約を活用することで、リクエスト処理中の各製品の動作を関連付けやすくなります。さらに、その情報をMLおよびAIアルゴリズムに入力することで、アプリケーションとインフラストラクチャが動的に適応できるようになります。

その基盤となるデータサイエンスを理解し、テレメトリデータをAIやMLと確実に関連付けることで、アダプティブアプリのデータドリブンな特性を進化させ、その真価を発揮できます。

まとめ

テレメトリの標準化は、OpenTelemetryのユーザーにとっても、OpenTelemetryをテレメトリチャネルとして使用するアプリケーションにとっても、明らかなメリットがあります。複数のソースからデータを収集し、互換性のある任意の集約・分析ツールに転送できます。さらに、OpenTelemetry Collectorにより、ベンダーが独自にコレクターを実装する必要がなくなります。そのためベンダーは、有意義な分析とインテリジェントなアクションを実行できるようコードを強化することに注力し、この複雑で混沌とした新たな世界の理解に役立つツールを構築できます。実際、オープンソースのイノベーションに支えられたOpenTelemetry Collectorは、ほぼすべての既存フォーマットに対応しながら、将来のテクノロジーへの橋渡しもできる、非常に優れた機能を備えています。

OpenTelemetryは、アプリケーションを理解するうえで必要となる主要なデータクラスに重点を置くことで、複雑な最新アプリケーション環境のパフォーマンスと問題の両方について、アプリケーションからより深いインサイトを得られるようにしました。データを相互に関連付け、セマンティック規約や標準規約に準拠させることで、OpenTelemetryは最新アプリケーションへの移行をより取り組みやすいものにします。プロジェクトの成熟と普及が進むにつれ、複雑性への理解を深め、AIやMLの手法を適用してその複雑性を理解可能にするうえで、OpenTelemetryが明確なアプローチとなります。

NGINXのOSSエンジニアによるOpenTelemetryの活用方法について詳しくは、Modern Apps Reference Architectureとサンプルアプリケーション（Bank of Sirius）をお試しください。

関連記事

• Kubernetesでクラウドネイティブへの移行を始めるための3つのステップ