OpenTelemetry の概念と Heroku

最終更新日 2024年12月04日(水)

テレメトリーとオブザーバビリティは、アプリケーションの健全性とパフォーマンスを維持するために重要です。OpenTelemetry (OTel) は、テレメトリーデータ収集の標準として登場しました。

Heroku の次世代に当たる Fir​ は OpenTelemetry を活用して堅牢なオブザーバビリティ機能を提供し、トレース、メトリクス、OpenTelemetry プロトコル (OTLP) をサポートしてログのシグナルのシームレスなエクスポートを実現します。

この記事では、Fir 世代のプラットフォームのコンテキストにおける OpenTelemetry の概念の基本について説明します。

テレメトリーとオブザーバビリティを理解する

テレメトリー​とは、システムのアーキテクチャ全体で、ログ、メトリクス、トレースを標準化された方法で生成および配信するツールです。このようなツールの 1 つが OpenTelemetry です。

オブザーバビリティ​とは、アプリケーションのパフォーマンスとデバッグに関する詳細なインサイトを得るために、アドホックなテレメトリーデータを収集して提示するサービスです。

OpenTelemetry を理解する

OpenTelemetry​ は、アプリケーションからテレメトリーデータを収集およびエクスポートするための標準化された方法を提供する、オープンスタンダードのフレームワークです。次の 3 つの主要なシグナルをサポートしています。

  • トレース​: システム経由のリクエストの実行パスを記録します。これらはリクエストのフローを把握し、レイテンシーの問題を診断するのに役立ちます。
  • メトリクス​: 実行時に取得したシステムの動作の定量的なメジャメントを提供します。メトリクスはシステムのパフォーマンスとリソースの稼働状況に関するインサイトを提供します。
  • ログ​: 発生する個別のイベントの推移を取得します。このシグナルタイプはイベントの詳細なコンテキストを提供するため、デバッグと監査に役立ちます。

これらのシグナルはコンテキスト伝播​を通じて関連付けられます。これにより、分散したシステムでテレメトリー情報を構築できるようになります。

Heroku Fir と OpenTelemetry

Fir 世代の Heroku プラットフォームは、OpenTelemetry をコアに直接統合することによって、アプリケーションのオブザーバビリティを簡素化するように設計されています。そのため、開発者は大規模な設定必要とせず、効率的な方法でテレメトリーデータを収集およびエクスポートできます。

Fir は OTLP プロトコル​で OpenTelemetry のトレース、メトリクス、ログのシグナルを全面的にサポートしています。OTLP の導入により、Heroku はオブザーバビリティのさまざまなバックエンドおよびツールとの互換性や相互運用性を確保します。この緊密な統合により、追加のオーバーヘッドなしでアプリケーションの自動インストルメンテーションが実現します。また、コンテキスト伝播はすぐに機能します。

Heroku テレメトリードレイン

アプリケーションまたはスペースに Heroku テレメトリードレインを設定して、テレメトリーをオブザーバビリティプロバイダーの宛先に送信できます。

ドレインは、テレメトリーシグナルを適切なオブザーバビリティプラットフォームにリダイレクトするマルチプレクサとして機能します。定義済みのルールと条件に基づいて、データを柔軟にルーティングできるようになります。

ドレインを設定すると、トレースとメトリクスを別々のバックエンドに送信できます。ドレインはアプリケーションレベルまたはスペースレベルで設定できます。

この図は、アプリまたはスペース用に設定された、Heroku エコシステム全体のトレース、メトリクス、ログを自動的に取得するドレインを表しています。ルーターログ、ランタイムイベント、リリースイベント、dyno メトリクスが含まれています。

Heroku テレメトリードレインアーキテクチャ

従来の Heroku アプリケーションのログ収集

Heroku は、アプリケーションはログを stdout にストリーミングすることだけを考慮すればよいというアイデアのパイオニア​です。OTel との統合の主な機能の 1 つは、標準出力 (stdout) と標準エラー (stderr) ログを OTLP ログに自動的に変換できることです。これらのログを OTel ログストリームにルーティングし、ドレインとして設定されたオブザーバビリティプロバイダーや Heroku CLI など、設定されたすべてのテレメトリーの宛先にエクスポートします。

Heroku のテレメトリー収集

Heroku インフラストラクチャとアプリケーションのログが OTel ログに変換されるとき、その他の OTel シグナルも Fir スペースから収集されてエクスポートされます。これらのシグナルには、dyno の健全性と使用状況、ルーティングトレース、ランタイム OTel ログに関するメトリクスが含まれます。

ドレインが設定されたスペースとアプリでは、設定されたオブザーバビリティプロバイダーにこれらのシグナルが自動的にルーティングされます。

アプリケーションの OTLP テレメトリーシグナルの収集

Heroku エコシステムによって生成されるテレメトリーに加えて、アプリケーションでビジネス固有の OTLP トレース、メトリクス、ログを生成できます。たとえば、ユーザーの商品検索経路のトレースや、購入までの時間に関連するメトリクスを取得できます。

OpenTelemetry は、さまざまな言語固有の SDK​ に柔軟に対応します。トレースプロバイダーやメトリクスプロバイダーで OTLP テレメトリーシグナルをエクスポートするように設定すると、残りのツールはこれらのシグナルを収集し、設定済みのドレインに一括処理でエクスポートします。

OLTP トランスポートプロトコルには gRPC と HTTP の 2 種類があります。詳細はこの記事の後半で詳しく説明します。すべての OTLP シグナルは、アプリケーションからローカルホストのデフォルトの OTLP ポート (gRPC の場合はポート 4317、HTTP の場合はポート 4318) にエクスポートされます。Heroku テレメトリーサービスは媒介役として機能し、テレメトリーデータを収集して中央の OpenTelemetry コレクターに転送します。

データの所在

アプリと Heroku のインフラストラクチャが生成したテレメトリーは、Fir スペース自体に残ります。たとえば、東京リージョン内の Fir スペースにアプリケーションをデプロイすると、そのアプリケーションと Heroku プラットフォームによって生成されたすべてのテレメトリーデータは東京リージョン内に残ります。

OpenTelemetry プロトコルの仕様

OpenTelemetry プロトコル (OTLP) の仕様​では、テレメトリーソース、コレクターなどの中間ノード、およびテレメトリーバックエンド間のテレメトリーデータのエンコード、トランスポート、配信のメカニズムを説明しています。

Heroku の Fir プラットフォームは、gRPC と HTTP の両方の OLTP トランスポートメカニズムをネイティブにサポートしています。gRPC と HTTP の違いについて続きを読むか、公式の OpenTelemetry OTLP プロトコルドキュメント​を参照してください。

いずれの場合も、言語、SDK、オブザーバビリティプロバイダーのデフォルトのプロトコルを使用することをお勧めします。

gRPC

  • パフォーマンスと効率: gRPC は、データの逐次化に HTTP/2 経由のプロトコルバッファ (Protobuf) を使用します。これは HTTP 経由の JSON よりも効率的です。この効率性によって CPU 使用率が低下し、ネットワークのオーバーヘッドが軽減されます。
  • 双方向ストリーミング: gRPC は全二重ストリーミングをサポートしており、クライアントとサーバーが複数のメッセージを双方向で個別に送信できます。このストリーミングは、ハイスループットでリアルタイムのアプリケーションに役立ちます。
  • 組み込みのフローコントロール: gRPC には組み込みのフローコントロールメカニズムが備わっており、バックプレッシャーの管理や、サーバーとクライアントの過負荷の防止に役立ちます。
  • 圧縮サポート: gRPC はメッセージの圧縮をネイティブにサポートしており、ネットワーク経由で送信されるデータ量を削減します。
  • ネイティブのトランスポートプロトコル: gRPC 経由の OTLP はネイティブのトランスポートプロトコルです。

HTTP

  • より広い互換性: HTTP/1.1 は広くサポートされており、既存のネットワークインフラストラクチャや媒介役との互換性が向上します。
  • 統合の容易さ: HTTP ライブラリになじみがあり、すぐに利用できる環境では特に、HTTP 経由でデータを送信するほうがシンプルになります。
  • ファイアウォールとプロキシに対応: 通常 HTTP トラフィックはファイアウォールとプロキシを介して許可されるため、接続の問題が発生する可能性が低くなります。
  • より簡単なデバッグ: cURL、Postman、ブラウザ開発者コンソールなどの標準ツールを使用して、HTTP リクエストおよびレスポンスを簡単に検査できます。

その他の資料