OpenTelemetry がクラウドネイティブを新たな高みに引き上げる理由

​翻訳者 |ブガッティ

校正：孫淑娟

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

このようなきめ細かいステップバイステップのトレースは、トラブルシューティングとパフォーマンスのチューニングに不可欠です。オールインワンの可観測性ツールを探していたとき、NGINX モダン アプリケーション リファレンス アーキテクチャ (MARA) プロジェクトのチームは OpenTelemetry を選択しました。このブログ記事では、OpenTelemetry がマイクロサービス アーキテクチャにとってなぜそれほど重要なのか、そしてそれがクラウド ネイティブ アプリケーションの環境をどのように変えているのかについて説明します。

OpenTelemetry が可観測性 2.0 を推進

OpenTelemetry は KubeCon Barcelona 2019 で初めて発表され、それ以来熱心な貢献者を集めてきました。現在でも、Cloud Native Computing Foundation (CNCF) で人気のプロジェクトとなっています。貢献者数の増加は、OpenTelemetry が成熟し、新しいものを試してみたいという初期採用者と成熟した製品を求める実用主義者の間のギャップを埋め始めていることを示しています。

OpenTelemetry はデータ、特にアプリケーションを最も効果的に理解、計測、改善するために必要なデータとデータ フロー (テレメトリ) に重点を置いています。データは、大規模に集約、分析、視覚化できる場合にのみ役立ちます。 OpenTelemetry はデータの視覚化に関するガイダンスを提供しませんが、取得するデータについて心配する必要がなくなり、そのデータを使って何ができるかに集中できるようになります。

OpenTelemetry は、データ ソースとアプリケーション間でイベントを相関させるタスクを簡素化します。これにより、クラウド内のアプリケーション アクティビティを測定するための新しいベンチマークである Observability 2.0 が誕生しました。データが自動的に相関付けられるため、アプリケーションが実行中かどうかを知るだけに限定されなくなりました。これで、アプリケーションを通過するリクエストの正確なデータ パスを把握できるようになりました。

これを実現するには、OpenTelemetry の 2 つの機能面、つまり分散トレースとアプリケーション インテリジェンスが重要です。

最新のアプリケーション アーキテクチャに分散トレースが必要なのはなぜですか?

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

Cynefin フレームワークは、単純なものから複雑なものに移行するときに、実践やアプローチがどのように変化するかを示します。課題は、それぞれ独自の特徴を持つ 2 つの異なる道を進むことです。単純なものから複雑なものへ直接近道を取ろうとすると、混乱したり不完全な進捗に終わることがよくあります。

モダン アプリケーションとクラウド ネイティブへの道を築く要素を見てみましょう。最初のパス (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 は、これら 3 つの機能すべてを提供し、さらに、すべてのアプリケーションのすべてのデータを使用可能にするように設計されているため、集約されたコンテンツから詳細を抽出する機能も提供します。

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

OpenTelemetry からのこの新しいデータ ストリームにより、開発と運用の両方の対応において適応性と自動化が可能になります。蓄積されたデータを活用することで、アプリケーションをよりインテリジェントかつ適応性の高いものにすることができます。適応型アプリケーションは、その名の通り、環境の変化に応じて動作を自動的かつインテリジェントに調整するアプリケーションです。

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

要約する

テレメトリを正規化することは、OpenTelemetry のユーザーと、それをテレメトリ チャネルとして使用するアプリケーションにとって当然の動きです。複数のデータ ソースからデータを収集し、互換性のある集計および分析ツールに転送できます。さらに、OpenTelemetry Collector により、ベンダーはコレクターを独自に実装する必要がなくなります。代わりに、意味のある分析を実行してインテリジェントなアクションを実行するためのコードの改善に取り組むことができ、この複雑で混沌とした新しい世界を理解するのに役立つ新しいツールを構築することができます。実際、OpenTelemetry Collector (オープンソースのイノベーションに基づく) は、テクノロジーを将来にわたって使用できるものにしながら、ほぼすべての既存の形式を処理できます。

OpenTelemetry は、アプリケーションを理解するために必要なデータの主なカテゴリに重点を置いており、複雑な最新のアプリケーション環境におけるパフォーマンスと問題について、アプリケーションがより深い洞察を提供できるようにします。 OpenTelemetry は、データを相関させ、セマンティクスと標準規則に準拠することで、最新のアプリケーションへの移行をスムーズにします。

OpenTelemetry プロジェクトが成熟し、採用が拡大するにつれて、これが私たちにとって理解を深める明らかな方法となります。また、OpenTelemetry が AI と ML の技術を適用して複雑な問題を解決し、修復を自動化し、クラウドネイティブ アプリケーションの適応性とパフォーマンスを向上させる方法を示すことにも役立つことを期待しています。

OpenTelemetry がクラウド ネイティブを新たな高みに引き上げる理由