OpenTelemetryとは

OpenTelemetryとは、システムの状態のオブザーバビリティ（Observability：可観測性）を向上させるために誕生した、オープンソースのフレームワークである。昨今、クラウドネイティブやコンテナのような分散型システムの利用が当たり前になっている中、オブザーバビリティを向上することを目的とした新たな標準化仕様として、OpenTelemetryの実装の需要が高まっている。

Telemetry（テレメトリー）とは「遠隔測定」を意味しており、システム監視の分野においては、離れた場所から稼働状況等のデータを収集・分析・監視するプロセスのことを指す。OpenTelemetryは、主にマイクロサービスと呼ばれるシステムにおいて、稼働状況に関するデータの収集・整形・エクスポートまでを行い、システムの状態を観測する上で非常に役立っている。

OpenTelemetryの有効性を理解するために、まず、マイクロサービスとオブザーバビリティの関係や課題について説明する。

OpenTelemetryが生まれた背景

OpenTelemetryの仕様が登場するまでに至った経緯を、以下のような流れに沿って解説する。

• マイクロサービスの普及
• オブザーバビリティの重要性
• マイクロサービスにおけるオブザーバビリティの課題
• OpenTelemetryの発足

マイクロサービスの普及

近年、クラウド環境（AWSやAzure等）やコンテナ技術（Docker、Kubernetes等）の利用がビジネスでも一般化されつつあり、複雑で動的な分散型システムが増えてきている。これに伴い、マイクロサービスのアーキテクチャの普及も進むようになった。

マイクロサービスとは、ソフトウェアやサービスを構成するアーキテクチャの一種である。このアーキテクチャスタイルでは、アプリケーションを複数の小さな独立したサービスに分散する。各サービスは特定の機能を担当し、それぞれ独立して開発・展開・スケーリングを行うことができるという特徴を持っている。

マイクロサービスを利用することで、以下のようなメリットがある。

• 大規模で複雑なアプリケーションの開発・保守が容易になる
• スケーラビリティと柔軟性を向上させる
• 異なるチームが異なるサービスを同時に開発できる

以上のようなメリットが享受できる一方で、マイクロサービスではさまざまなアプリやサービスが細分化されて動作するため、システムの状態を把握するのが難しいという課題がある。また、複数のコンポーネントに跨って通信を行うため、障害のタイプや量も増加し、原因の特定が難しいといった問題も生まれるようになった。

オブザーバビリティの重要性

こうしたマイクロサービスの課題を克服し、システムを安定して運用していくため、オブザーバビリティという概念が重視されるようになった。オブザーバビリティとは、「システムの内部的な状態を、どれだけ正確かつ迅速に観測できるか」を表す言葉である。つまり、オブザーバビリティが高ければ、システムで何が起きているかを理解するための手段が、それだけ十分に用意されているということが分かる。

オブザーバビリティを高めるためには、メトリクス、ログ、トレースという要素が重要となる。それぞれの概要について紹介する。

• メトリクス

  CPU使用率、メモリ使用量など、システムのパフォーマンスや使用状況を測定するための定量的な指標となる数値データ。

• ログ

  WEBサーバのアクセスログなど、システムで発生したイベントを記載するテキストやレコード。

• トレース

  プログラムで不具合が発生した時に処理されるリクエストの実行を、順番をたどって各段階の状態・状況を確認する作業のこと。システム内で発生したエラーや遅延等の問題を特定する上で重要な役割を持つため、OpenTelemetryやオブザーバビリティで最も重要な概念の1つである。

これら3つを含むデータを総称して、テレメトリデータと呼ぶ。なお、オブザーバビリティの詳細については以下の記事で詳しく解説している。

オブザーバビリティとは

マイクロサービスにおけるオブザーバビリティの課題

マイクロサービスにおいてオブザーバビリティの向上が重視されるようになったことで、技術者の管理上の手間が多く発生するようになった。その理由は、取得したテレメトリデータを可視化するための仕組みが乱立するようになったからである。テレメトリデータを収集・転送する仕様がアプリケーションごとに異なるため、従来の監視システムやクラウドベンダーに依存したツールなど、それぞれツールを使い分ける必要があった。そのため、ITオペレータやDevOpsチームの担当者が行う作業は、アプリケーション本体に専用の実装を加えたり、ツールに合わせたエージェントをインストールしたりと、複雑化した。これにより、組織全体でのシステムの稼働状況を把握することがより難しくなり、トラブルへの対応が遅れたり、セキュリティリスクが高まったりといった問題が生まれるようになった。

こうしたマイクロサービスにおけるオブザーバビリティの課題を解決するために、OpenTelemetryのフレームワークが登場した。

OpenTelemetryの発足

OpenTelemetryが登場する前までは、OpenTracingとOpenCensusという標準的な仕様が存在していた。それぞれが個々で始まったプロジェクトであったため、両者のメリットを1つに統合して生まれたのがOpenTelemetryである。

OpenTelemetryのプロジェクトは、クラウドネイティブソフトウェアの標準化団体であるCNCF(Cloud Native Computing Foundation) によって開始された。OpenTelemetryでは、テレメトリデータの計装（Instrumentation）と送信（Export）の標準的な仕様を策定している。また、仕様に基づいたプログラム実装やエージェントツールも提供している。

OpenTelemetryは、テレメトリデータの収集、整形、エクスポートまでの範囲を標準化している。つまり、製品、OSS、自作のソフトウェアに関わらず、同じ方法でテレメトリデータを収集し、エクスポートすることができる。一方で、エクスポートされたテレメトリデータを保存したり、可視化したりといったフローは範囲外であるため、OpenTelemetryだけでカバーすることはできない。このような機能を利用する際は、後述する「Jaeger」のような他のツールを別で用意して実装する必要がある。

OpenTelemetryのメリット

OpenTelemetryによってテレメトリデータの収集・転送の方法を標準化することで、次のようなメリットがある。

ベンダーやプラットフォームの形式に縛られない

それまで管理者は、特定のクラウドベンダーや監視プラットフォームに合わせた形式でデータを転送したり、必要なエージェントをインストールしたりしなければならなかった。OpenTelemetryはさまざまなツールと互換性を持っているため、API連携によってツールごとに異なっていた仕様を一本化することができる。そのため、管理者の負担を軽減しつつ、コストを抑えてオブザーバビリティを高めることができる。

オブザーバビリティの向上

OpenTelemetryにおける最大のメリットは、オブザーバビリティの向上を実現できる点にある。これにより、システム全体の状態を把握しやすくなり、リアルタイムな問題発見が可能となる。また、障害の原因となったポイントや、処理のボトルネックとなっている点をすぐに調べることができ、迅速な問題解決につながる。

自動計装かつ多様なプログラム言語に対応

OpenTelemetryを実装する方法として、Instrumentation（計装）というものが用意されている。Instrumentationは主要なプログラム言語のライブラリ（SDK）を提供しているため、一般的なアプリケーションであればほとんど実装することができ、開発者にとっても利便性が高い。Instrumentationで対応しているプログラミング言語は以下の通りである。

また、Instrumentation中でも、Automation Instrumentation（自動計装）を利用して実装することで、アプリケーションのコードに手を加えずにテレメトリデータを生成することができる。

ただし、言語によって、トレース、メトリクス、ログのそれぞれの機能の実装レベルが異なる。トレースは現在多くの言語で安定版としてリリースされているが、逆にログについては、ほとんどが実験段階の状態である。

エージェントツール「OpenTelemetry Collector」

OpenTelemetryを実装する方法には、前述のプログラム言語を使うほか、エージェントツールのOpenTelemetry Collectorを用いる方法もある。OpenTelemetry Collectorは、テレメトリデータを収集、処理、エクスポートするためのソフトウェアである。アプリケーション等から送出されるテレメトリデータの送信先を一元化したり、情報収集処理のロードバランシングをしたりするために利用される。いわば、OpenTelemetryの中継役を担うゲートウェイともいえる。OpenTelemetry Collectorは、コンテナやRPM/DEBパッケージなどで提供されている。

OpenTelemetry Collectorを導入することで、メトリクス情報を比較的手軽に取得することができる。ただし、複雑なトレースの情報などは取得できなかったり、独自のアプリケーションには対応していなかったりするため、多くの場合、メトリクスの送出には開発を伴う。

OpenTelemetry Collectorは、主にRecievers、Exporters、Serviceの3つのセクションで構成されている。

• Recievers

  Recieversセクションは、データソースからテレメトリデータを取得・受信するための設定である。サービス毎に定義することができ、現在githubには40件を越えるサービスについてのRecieversが存在する。ただし、ほとんどのRecieversが対応しているのはメトリクスの取得のみで、トレースやログなどには対応していない。また、開発状況もそれぞれ異なるため、利用前にマニュアルを確認する必要がある。

• Exporters

  Exportersセクションは、バックエンドにデータを送出するためのセクションである。Exportersもgithubのリポジトリで一覧が公開されている。

• Service

  Serviceセクションは、RecieverやExporterで定義したサービスを実際にどう使うかを定義するセクションである。

テレメトリデータの利用ツール「Jaeger」

OpenTelemetryではテレメトリデータの発信までが対象であるため、データを受け取り、利用するためのツールを別で用意する必要がある。特に、ログやメトリクスは既存の管理ツールが存在するが、概念として新しいトレース情報は、利用するためのツールが限られる。Jaegerは、トレース情報の可視化を行うツールとしては最も有名で、OpenTelemetryと同様、CNCFのプロジェクトとして管理されている。

Jaeger利用画面

Jaegerを活用してトレース情報を可視化することで、以下のような事を調べることができる。

• 各サービスの処理時間
• どのサービスまで処理が進んでいたのか
• 情報タグにより、どの基盤・コンテナで処理されたのか

つまり、さまざまな経路を通るマイクロサービスでも、トレース情報を見ていくことで、障害の原因となったポイントや処理のボトルネックをすぐに調べることができる。

OpenTelemetryの課題

OpenTelemetryを実装することでマイクロサービスの管理がしやすくなる一方で、以下のような課題も存在する。

• OpenTelemetryの考え方や仕様を理解するのが難しい
• トレース情報は、ほぼ必ずプログラムに実装が必要
• 開発ライブラリは提供されているものの、それ自体が比較的難しい

つまり、OpenTelemetryは簡単にサービスに実装できるものではない。また、実装する際も、そのサービスの動作を理解していなければどのような情報を送信したら良いのか分からないため、開発者自身で実装を行う必要がある。

デージーネットの取り組み

デージーネットでは、OpenTelemetryの公式ドキュメントに基づいた実装方法や関連ツールについて調査・検証し、「OpenTelemetry調査報告書」に詳細を掲載している。調査報告書は無料でダウンロードできる。今後はOpenTelemetryの課題を踏まえ、実装すること自体よりも、メトリクスデータを保存して可視化するツールなどの調査に注力していくことを考えている。