OpenTelemetryとは

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

OpenTelemetryの名前の一部になっている「Telemetry（テレメトリー）」とは「遠隔測定」を意味しており、システム監視の分野においては、離れた場所から稼働状況等のデータを収集・分析・監視するプロセスのことを指す。OpenTelemetryは、主にマイクロサービスと呼ばれるシステムにおいて、稼働状況に関するデータ（テレメトリデータ）の収集・整形・エクスポートまでを行い、システムの状態を観測する役割を持つ。OpenTelemetryのプロジェクトは、クラウドネイティブソフトウェアの標準化団体であるCNCF（Cloud Native Computing Foundation) によって開始された。また、OpenTelemetryの仕様に基づいたプログラム実装やエージェントツールも提供されている。OpenTelemetryはベンダーやプラットフォームの形式に依存せず動作し、複雑化したシステムのオブザーバビリティを向上するソリューションとして非常に役立っている。

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

OpenTelemetryが生まれた背景

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

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

マイクロサービスの普及

OpenTelemetryが必要とされる背景には、近年のクラウド環境（AWSやAzure等）やコンテナ技術（Docker、Kubernetes等）を利用する機会が増加したことが関係する。これらがビジネスにおける最新のシステムでも一般化されたことで、複雑で動的な分散型システムが増え、マイクロサービスと呼ばれるアーキテクチャの普及が進むようになった。

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

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

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

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

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

こうしたマイクロサービスの課題を克服し、システムを安定して運用していくため、オブザーバビリティという概念が重視されるようになった。オブザーバビリティとは、Observe（観察する）とAbility（能力）を組み合わせた造語であり、日本語では「可観測性」「観察する能力」と訳される。IT業界においては、「システムの内部的な状態を、どれだけ正確かつ迅速に観測できるか」を表す言葉である。従来のモニタリングとは対処のアプローチが異なり、オブザーバビリティでは、個々の計測データを関連づけ、監視ツールを一元的に分析・可視化することができる。つまり、オブザーバビリティが高ければ、システムで何が起きているかを理解するための手段が、それだけ十分に用意されているということが分かる。

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

• メトリクス

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

• ログ

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

• トレース

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

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

オブザーバビリティとは

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

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

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

OpenTelemetryの発足

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

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

OpenTelemetryのメリット

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

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

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

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

以前までは、管理者は、特定のクラウドベンダーや監視プラットフォームに合わせた形式でデータを転送したり、必要なエージェントをインストールしたりしなければならなかった。

しかし、さまざまなツールと互換性を持つOpenTelemetryの登場によって、API連携によってツールごとに異なっていた仕様を一本化することができるようになった。ベンダーやツールに依存せず、JaegerやPrometheusなどのオープンソースツールや、DatadogやSplunkなどの商用製品を含む、さまざまなバックエンドツールで使用可能である。また、AWSやAzure、GCPといったクラウドプラットフォームでも対応が進んでいる。これにより、テレメトリデータの収集・転送のプロセスがシンプルになり、管理者の業務負担を軽減しつつ、コストを抑えてオブザーバビリティを高めることが可能となる。

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

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

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

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

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

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

OpenTelemetry Collectorを導入することで、Prometheus等で作成したメトリクス情報を比較的手軽に取得することができるというメリットがある。ただし、複雑なトレースの情報や独自のアプリケーションの情報などは取得できないことがあり、全てのメトリクス情報に完全に対応しているわけではない。そのため、メトリクスの送出にはユーザーによる開発を伴う場合が多い。

次の3つのセクションを基本として構成されている。

• Recievers

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

• Exporters

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

• Service

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

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

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

Jaeger利用画面

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

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

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

今後の課題

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

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

これらの課題をクリアする必要があることから、サービスへの実装は簡単とは言えない。また、実装先のサービスの動作を理解していなければどのような情報を送信したら良いのか分からないため、サービスの開発者自身による実装が必要となる点も課題の一つである。

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

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

また、デージーネットでは、オープンソースソフトウェアの監視ツールやログ管理ツールを活用し、オブザーバビリティを実現するソリューションを提案している。お客様のご要件やご要望に合わせ、最適なシステムやシステム構成を提案し、管理者やユーザーが使いやすいサーバの構築を実現している。