DevOpsは、アプリケーションを開発して公開し、サポートからのフィードバックを反映していく方法として主流になりつつあります。しかし、DevOpsを成功に導くには、組織面での複雑さやマシンデータの収集といった課題を克服する必要があります。
OpenTelemetryは、オープンソースのオブザーバビリティフレームワークです。クラウドネイティブアプリケーションとそれを支えるインフラのパフォーマンスや健全性を示すテレメトリデータを収集するための、ベンダーに依存しないAPI、ソフトウェア開発キット(SDK)、その他のツールを提供します。
今日の複雑な分散環境では、パフォーマンスを管理することが極めて困難です。DevOpsチームやITチームがシステムの動作やパフォーマンスを把握するには、テレメトリデータの収集が欠かせません。サービスやアプリケーションの動作を包括的に理解するには、使用しているすべてのプログラミング言語のフレームワークとライブラリをインストルメントする必要があります。
しかし、組織内のすべてのアプリケーションからこれらのデータを収集できる単一の商用インストルメント技術やツールはまだありません。アプリケーションごとに異なるツールを使用すると、データがサイロ化するなど不透明になり、トラブルシューティングやパフォーマンスの問題の解決が一層難しくなります。
OpenTelemetryは、テレメトリデータを収集してバックエンドプラットフォームに転送するための方法を標準化する点で重要なフレームワークです。すべてのサービスに共通のインストルメンテーション形式を提供して、可視性のギャップを埋めます。バックエンドプラットフォームが変更されるたびに、エンジニアがコードのインストルメントをやり直したり、プラットフォーム固有のエージェントをインストールしたりする必要もありません。さらに、新しいテクノロジーが登場したときに、商用のソリューションではベンダーが対応インテグレーションを開発するのを待つ必要がありますが、OpenTelemetryならそのまま使い続けることができます。
以下のセクションでは、OpenTelemetryの概要と仕組みのほか、システムの分散が進む中で組織がビジネス目標を達成するために必要なレベルのオブザーバビリティを実現する上でOpenTelemetryがどのように役立つかについて説明します。
テレメトリデータは、オブザーバビリティを実現するためにシステムソースから収集される出力を指します。これらの出力を統合的に分析することにより、分散環境でのシステム間の関係や依存関係がわかります。主に使用されるデータクラスはログ、メトリクス、トレースの3つで、これは「オブザーバビリティの3つの柱」とも呼ばれます。
- ログ：ログは、発生したイベントを各時点で記録したテキストです。コードブロックが実行されると、そのイベントが発生した日時やイベントに関する「ペイロード」を記録したログエントリーが生成されます。ログの形式には、プレーンテキスト、構造化、非構造化の3種類があります。プレーンテキストが最も一般的ですが、近年では、追加のメタデータを含み照会が容易な構造化ログも増えています。これに対して、非構造化ログは解析が困難です。ログは、通常、アプリケーションの動作を正確に示す情報源として使われます。システムで問題が発生したときに確認したり、開発者がコードの問題を解決して実行状況を検証するときに使用したりします。分散システムでの障害は、多くの場合、下層での問題(根本原因)が積み重なって発生しますが、ログを調べれば、特定のコードブロックが実行されたときの詳細を確認できます。
- メトリクス：メトリクスは、一定の期間にわたって測定された数値です。タイムスタンプ、イベント名、イベント値などの属性が記録されます。ログとは異なり、形式は構造化が基本であるため、照会が容易です。保存にも適しており、大量のメトリクスを長期間保存して、システムの過去の傾向を把握することもできます。大規模なデータセットを作成したり、データを定期的に収集したりして、ビジネス上の疑問の答えを導き出すのにも最適です。メトリクスは長期にわたって記録することが多く、そうしたデータは、今日の複雑なシステムで問題を分析して対応するために欠かせません。メトリクスを集約したり、問題の初期兆候を示す可能性のあるメトリクスを監視したりして、アラートの精度を高めることもできます。
- トレース：トレースは、分散システムでのリクエストの処理経路をエンドツーエンドで表すデータです。システムでリクエストが処理されるときは、さまざまな操作が実行されます。各操作は「スパン」と呼ばれ、操作の過程でトレースID、スパンID、操作名、開始/終了タイムスタンプ、ログ、イベント、その他のインデックス化データなどの重要情報がエンコードされます。この分散トレーシングと呼ばれる手法でトレースを確認することにより、実行パス全体を追跡して、エラー、遅延、リソースの可用性などの問題の原因となっているコードブロックを特定できます。トレースでメトリクスを生成することもできます。特に、RED (比率、エラー、期間)と呼ばれる形式のメトリクスを生成できます。さらに重要な点として、トラブルシューティングの際に、どのログやメトリクスがその問題と深く関係しているかを示すコンテキストをトレースから取得できます。
ログ、メトリクス、トレースはそれぞれ用途が異なりますが、すべてを組み合わせることで、分散システムの状況把握やトラブルシューティングに役立つ包括的かつ詳細なインサイトを獲得できます。
OpenTelemetryを使用すれば、分散システムでアプリケーションやそのホスト環境のトラブルシューティング、デバッグ、管理に役立つテレメトリデータを収集できます。ITチームや開発チームは、簡単にコードベースをインストルメントしてデータを収集したり、組織の成長に合わせて調整を行ったりできます。
OpenTelemetryでは、ログ、メトリクス、トレースを含む複数のクラスのテレメトリデータを収集し、処理のためにバックエンドプラットフォームに転送できます。このテレメトリデータを分析することで、多層構造のエコシステムを包括的に可視化して、システムの動作の監視とパフォーマンスの問題への対応を効率化できます。
OpenTelemetryフレームワークはいくつかのコンポーネントで構成されます。
- 言語別のOpenTelemetry API：データを収集するようにコードをインストルメントします。Java、Python、JavaScriptなどに対応しています。
- エクスポーター：テレメトリデータをバックエンドの任意のオブザーバビリティプラットフォームに転送します。
- 言語別のOpenTelemetry SDK：APIとエクスポーターの間の橋渡し役となります。
- OpenTelemetry Collector：ベンダーに依存することなくテレメトリデータを受信、処理、エクスポートすることができます。
OpenTelemetryは、アプリケーションの問題のアラート、トラブルシューティング、デバッグを効率化する点で、DevOpsにとって重要です。テレメトリデータはシステムの動作を把握するために以前から使われてきましたが、ネットワークが複雑化するにつれて、トレーシングデータの収集と分析が難しくなっていきました。複雑化したシステムでは、単一の問題の原因を探るだけでも、従来の方法では数時間から数日かかることがあります。
一方、OpenTelemetryを使用すれば、複雑なシステムでも、すべてのアプリケーションやサービスからトレース、ログ、メトリクスを収集、集約して、相関付けることにより、オブザーバビリティを向上させることができます。さらに、インストルメンテーションの手間も軽減されるため、DevOpsチームはアプリケーションパフォーマンス監視(APM)などの主要業務に集中できます。そして最終的には、インシデントの特定と解決の効率化、サービスの信頼性向上、ダウンタイムの削減につなげることができます。
OpenTelemetryにはさまざまなメリットがあります。特に重要なものを3つ紹介します。
一貫性：アプリケーションからテレメトリデータを収集する方法はOpenTelemetryの登場以前から存在しましたが、それは決して簡単なものではありませんでした。まず、適切なインストルメンテーションの方法を見付けること自体が難しく、良いソリューションやベンダーが見付かったとしても、その契約に縛られることになります。しかも、従来のソリューションではアプリケーションによって実装が異なる場合が多く、アプリケーションのパフォーマンスを包括的に把握するのはほぼ不可能でした。
一方、OpenTelemetryは、テレメトリデータを収集してバックエンドに送信するための共通の方法を提供します。インストルメンテーションを変更する必要もないため、クラウドネイティブアプリケーションでオブザーバビリティを実現する方法として事実上の標準になっています。また、開発チームやITチームは、インストルメンテーションに余分な時間をかけず、アプリケーション機能の開発に集中できます。
選択のシンプルさ：OpenTelemetryが登場する以前はOpenTracingとOpenCensusという2つの標準がありましたが、この2つはオブザーバビリティに対するアプローチが異なるため、どちらを導入するかを選択する必要がありました。OpenTelemetryは、この2つのフレームワークのコードを統合し、両者の長所を1つにまとめたソリューションです。さらに、これまでいずれかのフレームワークを使用していた場合は、OpenTelemetryに簡単に切り替えることができます。OpenTelemetryはどちらとも後方互換性があります。
オブザーバビリティの効率化：OpenTelemetryを使用すれば、アプリケーションの使用状況データやパフォーマンスデータをどのデバイスやWebブラウザからでも確認できます。そのため、開発者はオブザーバビリティデータをリアルタイムで追跡および分析できます。
OpenTelemetryの最大のメリットは何といっても、ビジネス目標の達成に必要なオブザーバビリティを実現できる点です。OpenTelemetryは、システムが適切に機能しているかどうかを把握し、パフォーマンスを悪化させる可能性のある問題を特定して、可能であればサービスに影響が及ぶ前に根本原因を解消するために必要なテレメトリデータを統合的に提供することで、安定性と信頼性を向上させ、ビジネスプロセスをサポートします。
OpenTelemetryで収集したデータをAIエンジンに転送すれば、実用的なインサイトを自動的に生成できます。たとえば、OpenTelemetryで収集したデータとその他の有用なデータをAIエンジンで継続的に分析して異常を検出することで、人手に頼らずにスタック全体で問題を特定できます。AIなら、分散システム内の何十億という依存関係をほぼ瞬時に特定して処理し、隠れたアクティビティを見付けだすことができます。また、問題の原因を自動的に割り出して、可能または必要であれば、エンドユーザーに影響が及ぶ前に問題を解決することもできます。こうした継続的なプロセスにおいて、AIはシステムの「正常な状態」を学習し、それに適応して対応を改善することで、パフォーマンスをさらに向上させます。最終的には、問題を未然に防ぐこともあります。
基本的に、OpenTelemetryをAIと統合すれば、状況分析から実用的なインサイトの獲得までのオブザーバビリティプロセスで手動作業を排除することにより、OpenTelemetryの価値を一層高めることができます。
OpenTelemetryは、OpenTracingとOpenCensusという2つのオープンソースの分散トレーシングプロジェクトを1つにまとめたものです。
OpenTracingは、Cloud Native Computing Foundation (CNCF)が主体となり、トレーシングのための標準化されたAPIを提供することを目指していました。特に、特定のベンダーにロックインされることなく開発者が一般的なライブラリや独自のコードにインストルメンテーションを組み込めるようにしました。当時、このようなコンセプトは珍しいものでした。OpenTracingは、開発者が切望していた柔軟性を提供する一方で、トレーシングのみにフォーカスしていたため用途が限られ、実装にもばらつきがあることが難点でした。
OpenCensusは、Google社が社内のトレーシングプラットフォームをベースに開発しました。後にオープンソース化され、Microsoft社をはじめとするベンダーやコントリビューターが関わるようになり、標準へと進化しました。OpenCensusは、アプリケーションの動作についてのメトリクスを収集する多言語ライブラリのセットです。収集したメトリクスデータは、任意のバックエンド分析プラットフォームに転送して、デバッグに活用できます。また、メッセージ、リクエスト、サービスを生成元から送信先までトレースすることもできます。ただし、OpenCensusをコードに組み込むためのAPIが提供されていないため、開発者はコミュニティで開発された自動インストルメンテーションエージェントを使用する必要がありました。
OpenTracingとOpenCensusの両プロジェクトは、CNCFの管理下で両者の長所を取り入れながら2つのコードベースを統合することで合意しました。こうして誕生したのがOpenTelemetryです。現在ベータ版であるOpenTelemetryは、あらゆるアプリケーションから分散トレースとメトリクス(近い将来にログも追加される予定)を収集して一般的なオブザーバビリティツールで分析できるようにするためのAPI、ライブラリ、エージェント、コレクターサービスのセットを提供します。
OpenTracingは、開発者がコードベースにトレース機能を簡単に組み込めるように、ベンダーに依存しない(特定のベンダーに所有されない)API仕様、フレームワーク、ライブラリを提供します。開発者が独自のコードをインストルメントするための標準的なメカニズムを定めることで、分散トレーシングプロセスを効率化し、トレース機能を提供する特定ベンダーへのロックインを回避できます。
分散トレーシング(分散リクエストトレーシング)は、マイクロサービスアーキテクチャで構築されたアプリケーションを監視する手法です。プログラマーは、トレーシングとその他のロギングを組み合わせて、アプリケーションの動作に関する情報を収集できます。また、この情報を活用して、開発者はデバッグを行い、システム管理者や技術サポート担当者はアプリケーションやサービスのトラブルシューティングを行うことができます。
オブザーバビリティとは、システムの出力からシステムの状態を測定することを指します。この言葉は、制御理論(自己調整システムについて説明し理解するための理論)に由来します。近年では、分散するITシステムのパフォーマンスを把握および改善するためにオブザーバビリティ向上を目指す企業が増えています。この用途でオブザーバビリティを実現するには、テレメトリデータを使用してシステムを詳細に可視化し、システムの動作に関するさまざまな疑問を解消できるようにする必要があります。
分散システムの管理が難しい理由の1つは、相互に依存する多数のコンポーネントが、疎結合した通信経路を介してつながるためです。これにより、対処すべき障害のタイプが多様化し、数も増えます。また、分散システムの現状を把握して問題を理解するのが困難になり、将来発生する問題の予測などとてもできません。基本的に、分散システムではシンプルなシステムと比べて「未知の未知」が増えます。しかし、従来の監視手法は「既知の既知」を想定しているため、このような複雑な環境で問題を特定するのには適していません。
オブザーバビリティはこの予測不可能性への対応に優れています。オブザーバビリティを実現すれば、最新の複雑なシステムを詳細に監視し、動作を簡単に把握できます。また、複雑な環境で発生する問題をすばやく特定し、根本原因を探ることもできます。さらに開発者は、「Xの故障原因は？」、「現在の遅延を引き起こしている要因は？」といった質問ベースのアプローチでシステムの障害に対応できます。
オブザーバビリティを実現するには、システムとアプリケーションから適切なテレメトリデータを収集するための方法が必要です。市販のオブザーバビリティプラットフォームを購入することも、オープンソースのソリューションを使用することも、独自のツールを開発することもできます。いずれの場合も、オブザーバビリティは4つの要素で構成されます。
- インストルメンテーション：測定ツールによって、CPU、コンテナ、サービス、アプリケーションなど、データを生成するシステムコンポーネントからテレメトリデータを収集します。これにより、インフラ全体を可視化し、新しいコンポーネントやデータタイプを追加しても可視性を維持できます。特に、導入を迅速化するには自動インストルメンテーションが不可欠です。
- データの相関付け：システムから収集したテレメトリデータを処理して相関付けます。これにより、コンテキストを生成し、オブザーバビリティツールでわかりやすく表示できるようにデータを自動的または独自に整形します。
- インシデント対応：障害に関する情報を適切な担当者やチームに自動的に送信します。
- AIOps：機械学習機能によってデータを自動的に集約し、相関付けて、優先順位付けします。これにより、アラートのノイズを取り除いて、問題の検出とインシデント対応を迅速化できます。
OpenTelemetryはオブザーバビリティを実現するための手段です。インフラをエンドツーエンドで可視化するには、インフラ全体にインストルメンテーションを組み込む必要があります。これを単一の市販ソリューションで実現するのは困難ですが、テレメトリデータの収集に必要なインストルメンテーションを標準化するOpenTelemetryなら実現可能です。
OpenTelemetryプロジェクトはまだ初期の段階です。現時点ではベータ版であり、トレースとメトリクスのみがサポートされ、ログのサポートは初期の計画段階です。さまざまなプロジェクトチームが、OpenTelemetryのコアコンポーネントの標準化、エージェントを介した自動インストルメンテーションの統合、言語互換性の追加、メトリクス機能の改善に取り組んでいる最中です。これが終われば、本番環境に適した品質のリリースの一般提供が始まるでしょう。OpenTelemetryは、CNCFの大規模なオープンソースプロジェクトの1つであり(ほかにはPrometheusやKubernetesなどがあります)、テクノロジーコミュニティから多大な支持を得ています。最終的には、クラウドネイティブのテレメトリ機能の中でオブザーバビリティフレームワークとして中心的な地位を確立することになるでしょう。
分散導入は、LAN単位の小規模な単一部門への導入から、グローバルレベルの大規模な導入までさまざまです。導入の際には、導入先の規模と全体的な複雑さに加えて、コンピューターネットワークの規模と容量、使用するデータの量、プロセスの実行頻度、プロセスがスケジュールされるかアドホックで実行されるか、システムにアクセスするユーザー数、データセンターのキャパシティ、データの精度と可用性の要件を考慮する必要があります。
これらの考慮事項に応じて、分散導入は部門単位、小規模企業、中規模企業、大規模企業に分類できます。中規模企業と大規模企業のレベルを分ける正式な基準はありませんが、この分類は分散コンピューティングシステムを導入するために必要なリソースを見積もるための出発点となります。また、分散システムは、企業の成長や事業の拡張に伴い、部門単位から小規模企業へと拡大していく可能性があります。
今日のコンピューティングは、分散システムなしでは成り立ちません。ワイヤレスネットワークやクラウドコンピューティングサービス、インターネットの運用に不可欠なものとなっています。分散システムが存在しなければ、これらの技術も存在しなかったでしょう。
しかし、大規模で複雑な通信ネットワークを使用しない企業レベルの業務にも分散システムは必要なのでしょうか。ほとんどの場合、その答えは「イエス」です。分散システムは、モノリシックなシステムでは成し得ない方法で拡張性とパフォーマンスの向上を実現します。また、分散システムは、他のコンピューティングデバイスやプロセスの機能を活用できるため、単一のシステムでは開発が困難または不可能な機能を提供することができます。
たとえば、サーバーやアプリケーションのオフサイトバックアップでは、マスターカタログで復元に必要なセグメントビットが見付からない場合、他のオフサイトノードに依頼してそのセグメントを送信してもらうことができます。実際には、メールの送信、ゲームのプレイ、Webでの記事の閲覧など、今日、私たちがコンピューティングデバイスで行うあらゆる操作のどこかしらで分散システムが利用されています。
過去20年間で、デジタルトランスフォーメーションが新しい働き方を生み出し、モバイルアプリやWebアプリの重要性はかつてないほど高まりました。
こうしたクラウドネイティブアプリケーションの活用にデータ収集は欠かせませんが、多くの組織がそれを十分にできていません。さまざまな業界を対象にした調査では、57%の組織が、データの増加ペースが組織の管理能力をすでに超えていると回答し、47%が、今のペースでデータが増加し続けるといずれ競争から脱落すると回答しています。多くの組織が組織全体の成功とイノベーションにデータが不可欠だと考える一方で、組織内のデータのうち半分以上が未活用(ダークデータ)であると回答した組織は3分の2にのぼり、前年から10%増加しました。
OpenTelemetryは、テレメトリデータを管理して、オブザーバビリティの向上に必要な包括的な可視化を実現するための鍵を握ります。OpenTelemetryに対応したツールなら、特定のベンダーの仕様にロックインされることなく、テクノロジースタック全体からデータを収集できます。そして最終的には、アプリケーションのパフォーマンス向上と、より大きなビジネス成果の達成につなげることができます。
