OpenTelemetry がアプリのトレースと設計方法をどのように変えるか

クラウド ネイティブ アプリを実行する場合、複数の場所で実行されている多数のマイクロサービス間の相互作用からアプリの機能が生まれるため、可観測性が重要になります。 マイクロサービス アプリの疎結合の性質により、各マイクロサービスが独自の方法でそのアクティビティを報告する可能性があります。 テレメトリ データを収集して相関させるツールがなければ、トラブルシューティングに不可欠な、リクエストの処理を最初から最後まで追跡することは、不可能ではないにしても非常に困難です。

多機能な可観測性ツールを探していたとき、 NGINX Modern Apps Reference Architecture (MARA) プロジェクトのチームは OpenTelemetry を選択しました。 私たちの OSS チームがこの新しいプロジェクトを選んだことで、さらに深く掘り下げていきたいと思っています。 GlueCon 2022で、私は F5 の CTO オフィスのアーキテクトである Granville Schmidt 氏と会い、OpenTelemetry の現状と将来の提供内容に期待している理由について話し合いました。 以下の会話をご覧ください。また、このブログでは、OpenTelemetry がクラウドネイティブapplication環境にとって優れた資産である理由について詳しく説明しています。

OpenTelemetry が Observability 2.0 を強化

OpenTelemetry はバルセロナで開催された KubeCon 2019 で初めて発表され、熱心な貢献者の注目を集めています。 これは、貢献数の点でCloud Native Computing Foundation (CNCF) で 2 番目に人気のあるプロジェクトであり、過去 6 か月間の貢献率はこれまでで最も高くなっています。 この多数の貢献者は、OpenTelemetry が成熟し、アーリーアダプター (時代を先取りする意欲のある人) と実用主義者 (成熟した製品を望む人) の間の溝を越え始めていることを示しています。

OpenTelemetry はデータ、具体的にはapplicationsを最適に理解し、トラブルシューティングし、改善するために必要なデータとデータ ストリーム (テレメトリ) に重点を置いています。 データは、大規模に集約、分析、視覚化できる場合にのみ役立ちます。 OpenTelemetry はデータを視覚化する方法についての指示は提供しませんが、どのようなデータを取得できるかを心配する必要がなく、代わりにデータを使って何ができるかに集中できます。

OpenTelemetry では、ユーザー自身が相関関係を試行する必要はなく、データ ソース間で自然な相関関係を確立することもできます。 OpenTelemetry のアプリ間のイベントを相関させる機能は、クラウド内のapplicationアクティビティを測定するための新しいベンチマークである Observability 2.0 へと私たちを導きます。 データはすでに相関付けられているため、application空間の見方が変わります。 アプリが実行中かどうかを知ることだけに限定されなくなり、アプリ内でのあらゆるリクエストの経路を把握できるようになりました。

OpenTelemetry に先立って、2 つの注目すべきオープン ソース プロジェクトがありました。 OpenTracing (OT)とOpenCensus (OC) 。 どちらも、トレース データの形式を標準化するという課題に取り組み、必要な情報を取得し、それが最新のアプリにどのような影響を与えるかを理解できるようにしました。 各プロジェクトには類似点がありましたが、リソースをめぐって競合し、企業は多くの場合、1つだけを選択しなければなりませんでした。 2019 年 3 月、 2 つのプロジェクトは、トレース データの生成とフォーマットの方法を統一することを目的として、OpenTelemetry に統合すると発表しました。 OpenTelemetry プロジェクトでは、トレースと同じテレメトリ チャネルを介して他のクラスの観測データ (メトリックとログ) を取得するための標準をさらに定義し、統合と明確化をさらに進めています。

次に、OpenTelemetry の 2 つの興味深い機能面、分散トレースとアプリケーション インテリジェンスについて見てみましょう。

現代のアプリアーキテクチャに分散トレースが必要な理由

分散トレースは長年存在してきましたが、過去 10 年間の多くの変化により、その必要性が高まっています。 Cynefin フレームワークを使用すると、現代のapplicationsが現在直面しているいくつかの変化と課題を明らかにすることができます。

Cynefin フレームワークは、単純なものから複雑なものへと移行する際に、実践方法をどのように変更できるかを示しています。 問題は、私たちの動きにはそれぞれ独自の特徴を持つ 2 つの別々の道があり、単純なものから複雑なものへ直接近道を取ろうとすると混乱が生じ、進歩が不完全になることが多いことです。

最新のアプリとクラウドネイティブのジャーニーでパスを作成する要素を特定しましょう。 最初のパス (Cynefin 図の Y 軸) には、通常はマイクロサービス アーキテクチャである最新のアプリがあり、各アプリは特定のジョブを実行します。 2 番目のパス (X 軸) では、マイクロサービス インスタンスが需要に応じて起動および停止し、ネットワークの問題に応じて別のホストに移動されるため、複雑な環境は一時的なものになります。

また、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP) などのクラウド環境の出現と大幅な成長も考慮する必要があります。 このようなクラウドの利点は、弾力的な対応、つまり現在の需要レベルに合わせてリソースを拡大または縮小できることです。 コンテナ オーケストレーション (最も一般的には Kubernetes を使用) の影響が加わると、時間の経過とともにリソースの数と場所が変化するため、混沌とした動作が見られるようになります。 (この比較的制約されたビューでさえも混沌としており、サーバーレス関数などの要素によってさらに混沌とする可能性があります。)

最新のアーキテクチャでは、アプリの監視と保守に必要なテレメトリを生成する個別の部分が多数あるため、データの負荷が膨大で複雑になります。 インフラストラクチャと通信経路を完全に制御できないため、問題が確実に再現されなかったり、簡単に引き出せなかったりする可能性があります。 変化する環境を理解し、分析するためには、すべての活動と関連要素を追跡できるテクノロジーが必要です。

ここで OpenTelemetry が役立ちます。

OpenTelemetry による分散トレースの未来

分散トレースは、特にリクエストがメトリックを介してパフォーマンスの内部ビューを生成する方法を中心に、業界に大きな変化をもたらしています。 分散トレースを使用すると、さまざまな種類の新しいメトリックを追跡できますが、最も一般的なのは、時間単位あたりのリクエスト数、時間単位あたりのエラー数、およびその時間単位内で集約リクエストにかかる時間に関連するメトリックです。

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

OpenTelemetry は、イベントの相関関係を困難にするタイムスタンプのドリフトとスキューの問題を解決するのにも役立ちます。 OpenTelemetry は各リクエストにTraceId を割り当てますが、クラウドネイティブ アーキテクチャでよく発生するドリフトとスキューによってデータが影響を受ける可能性があります。 ドリフトとスキューは、期間が異なるレポート パス、またはさまざまなホストのクロック間の厳密な同期の欠如によって発生する可能性があります。 分散トレースでは、トラフィック処理中にコンポーネント間の通信を追跡することで、関連するアプリの詳細な計測を必要とせずに、OpenTelemetry が個々のスパン(トレースの作業単位と構成要素) を測定できるようになります。

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

• メトリクス– 「問題はありますか？」
• 痕跡– 「問題はどこにあるのか？」
• ログ– 「問題は何ですか?」

ここで Observability 2.0 に戻ります。 トレースを取得し、どのメトリックがどのトレースに対応しているかをすぐに確認できる機能は、非常に役立ちます。 たとえば、メトリックが問題を示している場合、分散トレースを使用すると、最初の問題の原因となった特定のリクエストまでさかのぼって、リクエスト実行の各ステップの進行状況を追跡できます。 トレースは発生順にスパンで構成されているため、リクエストの流れの各ステップを追跡できます。 最初のイベントから指摘された問題、そして最終結果に至るまで、何がどのような順序で発生したかを理解することで、アプリ内の「どこ」に注意を集中すべきかを正確に特定できます。

単純に聞こえるかもしれませんが、OpenTelemetry の分散トレース機能は、リクエストの成功と実行のタイミングのプロキシとして、ユーザーが体験していることに関する優れた洞察を提供します。 ユーザーとして、私は自分のリクエストを大切にしています。 サイト信頼性エンジニア (SRE) として、私は集約されたリクエストを重視しています。 OpenTelemetry は、すべてのアプリで必要なすべてのデータを利用できるように設計されているため、集計から詳細まで掘り下げる機能も提供してくれます。

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

OpenTelemetry からのこの新しいデータ ストリームにより、開発と運用の対応において適応性と自動化も可能になります。 蓄積されたデータをすべて活用することで、applicationをよりインテリジェントにすることができます。 F5 は現在、「適応型applications」と呼ばれるものの開発と導入に向けたお客様の支援に注力しています。 適応型アプリは、その名の通り、環境の変化に応じて動作を自動的かつインテリジェントに調整するapplicationsです。

そのため、さまざまなソリューションで人工知能(AI) と機械学習 (ML) がますます多く見られるようになっています。 しかし、それは単にトレンドの用語だからというだけではありません。AI と ML が便利なのは、因果関係について正確な結論を導き出し、適切な対応を設計するのに十分なデータが得られるようになったからです。

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

すべての背後にあるデータ サイエンスを理解し、テレメトリ データが AI および ML に関連していることを確認すれば、適応型アプリのデータ駆動型の性質が進化し、発揮されるようになります。

まとめ

テレメトリをコード化することは、OpenTelemetry のユーザーと、それをテレメトリ チャネルとして使用するapplicationsの両方にとって明らかなメリットです。 データは複数のソースから収集され、互換性のある集計および分析ツールに転送できます。 さらに、 OpenTelemetry Collectorにより、ベンダーはコレクターを独自に実装する必要がなくなります。 代わりに、意味のある分析を実行してインテリジェントなアクションを実行するためのコードを強化することに集中し、この複雑で混沌とした新しい世界を理解するのに役立つ新しいツールを構築できます。 実際、オープンソースのイノベーションに支えられた OpenTelemetry Collector は、テクノロジーを将来につなげながら、ほぼすべての既存の形式に対応できる優れた機能を備えています。

OpenTelemetry は、applicationsを理解するために必要な主要なデータ クラスに焦点を当てており、複雑な最新のapplicationの世界におけるパフォーマンスと問題の両方について、アプリケーションがより深い洞察を提供することを可能にしています。 OpenTelemetry は、データを相関させ、セマンティックおよび標準の規則に合わせることで、最新のapplicationsへの移行をより簡単にします。 プロジェクトが成熟し、採用が拡大するにつれて、OpenTelemetry は、より深い理解と、その複雑さを理解できるように AI および ML 技術を適用する能力への明確なアプローチとなります。

NGINX の OSS エンジニアが OpenTelemetry をどのように使用しているかについて詳しく知るには、モダン アプリ リファレンス アーキテクチャとサンプルapplication(Bank of Sirius) を試してみてください。

関連記事

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