AWS Distro for OpenTelemetryによるシームレスなオブザーバビリティ

Pulisher : Cloud Technology Center チュ・ジェビン
Description : OpenTelemetry Lambda 層を使用してアプリケーションを計測し、互換性のあるバックエンドにデータを送信する方法についての紹介セッション

はじめに

私は最近、オブザーバビリティの技術スタックを確保するための計画を立てていましたが、Open Telemetryを知り、デモをすることが最初の課題です。HoneyComb社はオブザーバビリティサードパーティベンダーですが、ここのCTOでAWS HeroのLizさんがOTelの概要を説明するセッションを用意していたので、ちょうどいいタイミングで受講を申し込みました。

セッションの概要紹介

オブザーバビリティ(Observability)
品質は、システム内部で起こっていることを理解することができます。寝ている間にアラートメールを受け取って起きて、問題の原因を突き止めるために多くの時間を費やすのは、ITオペレーターにとって最悪の一日になるでしょう。
システムが複雑になればなるほど、トラブルシューティングとデバッグのために可視化インフラを確保する必要があります。システムの動作とパフォーマンスに関する遠隔モニタリングデータをより簡単に収集し、変換してバックエンドに送信するオープンソース標準のOpen Telemetryを使用すると、ベンダー固有の方法ではなく、標準化された方法でアプリケーションとインフラストラクチャを計測することができます。

ロギングは、開発者が最も身近に使っているもので、システムの個別プロセス別の動作状況を表現します。ログファイルの形で算出され、アップロードされます。ログストリームは1つのプロセスで発生した情報を含んでいるため、分散システムでログを集計・分析するのに苦労することがあります。

メトリックは、システム内部の状況を表現する統計量であり、時系列で表示して確認することもあります。 インフラレベルとアプリケーションで測定されるメトリックがあります。

トレースとは、ユーザーの要求がシステムで処理されるフローをエンドツーエンドで表示します。 そして、正確な問題点を示すことができます。

トレースはスパン集合で、スパンは作業単位を意味します。ここに任意に構造的なメタデータを含めることができるので、ログやメトリックに相当するデータを含めることができ、視覚的にわかりやすい仕組みを持っています。 そのため、講演者はトレースの活用性を積極的にアピールしています。

Cloud Native Computing Foundation（CNCF）のオープンスタンダードであるOpenTelemetryは、分散型テレメトリを収集するためのAPI、ライブラリ、エージェントを定義しています。OTelの歴史を少し説明すると、2010年代以降、IT業界には継続的にObservability関連のツールがリリースされ、2つのオープン標準であるOpenTracingとOpenCensus標準を統合してOpenTelemetryが誕生しました。

OTel collectorはルーティングコンポーネントで、非オープンテレメトリデータをオープンテレメトリデータに変換し、複数の宛先に送信します。観測性領域で活躍しているベンダー（CloudWatch、X-Ray、Datadog、New Relic、Honeycomb…）は、設定ファイルの数行を変更することで、open-telemetryデータを受け取ることができます。

現在11種類の言語をサポートする開発キットを含んでおり、各言語で有名なフレームワークと統合されます。例えば、NodeJS Expressとシームレスに統合できます。

OTelは、インスツルメント（追跡/測定機能）、テレメトリ生成を実現しつつ、データの保存方法にとらわれないのが特徴です。

自動インストゥルメントライブラリは、アプリケーションにインストゥルメントをシームレスに実装することができます。OTel operatorは、言語とワークロードを自動的に判断し、追跡機能を有効にします。例えば、NodeJS Expressアプリケーションが受け取るすべてのHTTPリクエストを追跡します。C++のように自動インストゥルメントがまだできない場合は、構成設定とSDKのコンパイルが必要です。

このようなOTel operatorの実装はAWSでも提供していますが、ADOT(AWS Distro for OpenTelemetry)を利用すれば、AWS上のワークロードとより簡単に統合することができます。ADOTがロギングをサポートし始めたので、CWログを作成するためにCW Logs Agentは必要ありません。

EKS Add-OnとしてもADOTを利用することができ、YAML/JSON構成で追跡対象タスクと、データアップロード先、テレメトリタイプ（ログ、メトリック、トレース）を設定します。

AWS LambdaでOTelを使う簡単な方法は、関数Invokeをラップすることです。

AWS Lambdaはネイティブにラッパースクリプト実行機能(LAMBDA_EXEC_WRAPPER環境変数)を持っています。OTelラムダレイヤーを付けて自動インストゥルメントスクリプトを指定すると、ユーザのラムダ関数コードを修正することなく、すぐにOTelが適用されます。

AWSのX-Ray、Prometheus、CloudWatchだけでなく、OTelをサポートする様々なISVが追加機能を持っている可能性があります。要件に合わせて様々なバックエンドを試してみることをお勧めします。

一方、RDSやElasticacheなどのAWSネイティブサービスから収集されるメトリックデータは、CloudWatch – KDFを経由してopen-telemetryデータとして収集することが可能です。この方法は、各CWメトリックをAPIでスクレイピングするよりも費用対効果が高いです。CloudWatchでDelievery Streamを作成し、HoneyComb社のHTTPエンドポイントに輸送する形でソリューションが導入されました。

自動インストルメント以外に、私たちが興味のあるカスタムテレメトリを追加するにはどうすればよいでしょうか？Javaを例にします。Spanを追加設定します。文字列以外にも様々なデータ型を追加することができます。

そして、スパンがある関数を作るためラッピングする時はアノテーション/デコレータ(Java/Python)を使います。

直接書かなければならなかったスニペットと比較してみてください。

一方、CLI作業をインストゥルメントするアプリケーションであるotel-cliが存在します。ChefとTerraformでOTelの連携ができるのも印象的でした。

セッションを終えて

HoneyCombのCTOがOTel & ADOTでAWSサービスとインストゥルメント、統合する方法をまとめてくれました。GO Otel SDKのコントリビューターとして、Go言語でインストゥルメントするためのツールやその他の便利なオープンソースツールを紹介していただきました。 (QRコードに複数のリンクがありますので、ご参照ください)。

多くの人が同じ課題を解決するために、それぞれのソリューションを構築しています。多くの反復が行われ、互換性を確保するためには協議が必要ですが、標準を定めることで、パターン化されたソリューションが多くの人に提供され、問題へのアプローチが容易になります。このフレームワークの活用性を検証するために、まずは様々な言語のランタイムでワークロードを定義し、インストゥルメント、収集、保存を実行してみたいと思います。他の方々もOTelやADOTと一緒にAWSのワークロードを観察していただき、多くの声を聞かせていただければと思います。