オブザーバビリティとは、簡単に言えば、システムの出力を調査することによって内部の状態を測定する能力のことです。出力からの情報、すなわちセンサーデータのみを使用して現在の状態を推定できるシステムは「オブザーバビリティがある」とみなされます。
Splunkは、ガートナー社からオブザーバビリティとアプリケーションパフォーマンス監視のリーダーに認定されました。ガートナー社のマジック・クアドラントでその理由をご確認ください。ダウンロードはこちら→
Splunkのオブザーバビリティ製品とソリューションについて詳しくは、以下の各Webサイトをご覧ください。
「オブザーバビリティ」という用語は、単なる流行語ではなく、制御理論(自己調整システムについて説明し理解するための理論)に関連して数十年前に提唱された用語に由来します。今日では、分散型ITシステムのパフォーマンス向上の文脈でよく使用されます。組織にとって、オブザーバビリティはIT環境全体のシステムを安定稼働させるために欠かせないものです。最新の「オブザーバビリティの現状」の調査によると、今や87%の組織がオブザーバビリティの実践に携わるスペシャリストを置いています。
オブザーバビリティは、メトリクス、ログ、トレースの3種類のテレメトリデータを使用して分散システムを詳細に可視化し、さまざまな問題の根本原因の究明やシステムのパフォーマンス向上を実現します。
ここ数年、企業の間では、クラウドネイティブのアプリケーションやアマゾン ウェブ サービス(AWS)をはじめとするインフラサービスの導入が急速に進み、マイクロサービス、サーバーレス関数、コンテナテクノロジーの利用が拡大しています。これらの分散システムで問題の発生源を追跡するには、クラウド、オンプレミス、またはその両方の環境で実行されている何千ものプロセスを調査する必要があります。しかし、従来のIT監視手法とツールでは、分散アーキテクチャの通信経路や相互依存関係を追跡するのは容易ではありません。
監視とオブザーバビリティは概念が異なりますが、相互に依存しています。
厳密には、監視はシステムのパフォーマンスを継続的に観測する活動を指します。監視ツールを使ってシステムデータを収集および分析し、実用的なインサイトを引き出します。アプリケーションパフォーマンス監視(APM)などの監視テクノロジーを使うことで、システムの稼働と停止やアプリケーションのパフォーマンスの問題などに関する通知を受けられます。また、集約データや相関関係を監視することも、システムの全体的な状態を推測するのに役立ちます。たとえば、Webサイトやアプリケーションでは、読み込み時間を監視することでユーザーエクスペリエンスの状態を把握できます。
オブザーバビリティは、アプリケーションシステムの内部の状態を、その外部出力に基づいてどの程度正確に推定できるかを示す尺度です。つまり、監視を通じて得たデータとインサイトを使用して、健全性やパフォーマンスなど、システムの状態を包括的に把握します。そのため、システムのオブザーバビリティは、監視メトリクスからシステムのパフォーマンス指標をどのくらい正確に読み取れるかにある程度左右されます。
もう1つの重要な違いは、監視では、何を監視すべきかを事前に判断する必要があるのに対して、オブザーバビリティでは、システムのパフォーマンスを継続的に監視し、その結果について質問を投げかけることによって、何が重要かを判断できる点です。
オブザーバビリティがアプリケーション開発において重要なのは、複雑なシステムをより適切に管理できるためです。シンプルなシステムは可動要素が少なく、管理が容易です。通常は、CPU、メモリー、データベース、ネットワークの状態を監視するだけでシステムの状態を十分に把握し、問題に適切に対処できます。
一方、分散システムは、相互接続する要素がはるかに多いため、発生する障害の数と種類も多くなります。また、常に更新されるため、変更があるたびに、発生する可能性のある障害の種類が増えます。
分散環境では、現行の問題を理解することが非常に難しくなります。その大きな要因は、シンプルなシステムよりも「未知の未知」が増えるためです。監視では「既知の未知」が前提となるため、複雑な分散環境ではほとんどの問題に適切に対処できません。
オブザーバビリティは、分散システムの予測不可能性への対応に適しています。その大きな理由は、問題が発生したときにシステムの動作について「なぜXが故障したのか?」、「現在起きている遅延の原因は何か?」などの質問を投げかけて答えを得られることです。
コンテナやマイクロサービスのオブザーバビリティを高めれば、本番環境のアプリケーションの状態を可視化して、開発者がパフォーマンスの問題を特定および解決しやすくなります。
コンテナサービス(DockerやKubernetesなど)やマイクロサービスを使えば、クラウド環境やモノリシックなアプリケーションで発生するリスクの高いダウンタイムなどの問題を解消できます。これらの環境やアプリケーションでは、1つのコードベースの変更がアプリケーション全体とそれに依存するすべてのサービスに影響します。これに対して、コンテナやマイクロサービスでは、アプリケーションを複数の独立したサービスに分割することで、アプリケーション全体ではなく特定のサービスだけを変更して再デプロイできます。
ただし、コンテナベースのアーキテクチャは新たな課題を生みます。相互依存するマイクロサービスは通常、複数のホストに分散して配置します。また、インフラを拡張すると、本番環境のマイクロサービスの数も増えます。これにより、DevOpsチームは本番環境で実行中のサービスを把握するのが難しくなり、デリバリーサイクルの長期化やダウンタイムなどの問題につながります。
オブザーバビリティを高めて分散システムを可視化することで、アプリケーションのパフォーマンスや可用性をより正確に把握して、これらの課題に対応できます。また、障害が発生したときは、適切な情報に基づいてすばやくボトルネックを特定し、問題をデバッグまたは修正できます。
オブザーバビリティの軸となるデータクラスは、ログ、メトリクス、トレースの3つです。これらはよく「オブザーバビリティの3つの柱」と呼ばれます。
ログ:ログは特定の時点で発生したイベントのテキストレコードであり、発生日時を示すタイムスタンプとコンテキストを示すペイロードが記録されます。ログには、以下の3種類の形式があります。
プレーンテキストが最も一般的ですが、近年では、追加データとメタデータを含み照会が容易な構造化ログも増えています。システムで問題が発生したときは、通常、最初にログを確認します。
メトリクス:メトリクスは一定期間にわたって測定された数値であり、タイムスタンプ、名前、KPI、値などの属性が記録されます。ログとは異なり、形式は構造化が基本であるため、照会や保存先の最適化が容易で、長期の保存に適しています。
トレース:トレースは分散システムでのリクエストの処理経路をエンドツーエンドで表すデータです。ホストシステムでリクエストが処理される際に、リクエストに対して実行された各処理(スパン)が、それを実行したマイクロサービスに関する重要なデータとともにエンコードされます。
トレースには1つ以上のスパンが含まれているため、トレースを確認することで、分散システム内での処理経路を追跡し、ボトルネックや障害の原因を特定できます。
3つの柱の統合:これらのデータクラスを収集していても、別々に扱っていたり、それぞれ異なるツールで調査したりしていると、オブザーバビリティは保証されません。
オブザーバビリティを実現するには、ログ、メトリクス、トレースを単一のソリューションに統合する必要があります。そうすれば、問題の発生を検知できるだけでなく、その原因を特定できます。
オブザーバビリティを実現するには、システムとアプリケーションから適切なテレメトリデータを収集するためのツールを導入する必要があります。独自のツールを開発することも、オープンソースのソフトウェアを使用することも、市販のオブザーバビリティソリューションを購入することもできます。通常、オブザーバビリティは、以下の4つのコンポーネントで実現されます。
オブザーバビリティの実現に必要なコンポーネント
独自のソリューションを開発する場合でも、オープンソースや市販のソリューションを使用する場合でも、オブザーバビリティツールには以下の要件が求められます。
既存のツールとの統合:オブザーバビリティツールが現行のスタックと連携しなければ、オブザーバビリティ実現の取り組みは失敗に終わります。既存の環境、コンテナプラットフォーム、メッセージングプラットフォーム、その他重要なソフトウェアで使用されるフレームワークや言語にツールが対応していることを確認しましょう。
使いやすさ:ツールの習得や使用が難しいと、ワークフローに組み込まれず、オブザーバビリティの実現は遠のきます。
リアルタイムデータの提供:優れたオブザーバビリティツールは、ダッシュボード、レポート、クエリーを介して、問題とその影響や解決方法を理解するためのインサイトをリアルタイムで提供します。
最新のイベント処理技術への対応::スタック、テクノロジー、運用環境全体からすべての関連情報を収集し、価値のあるシグナルとただのノイズを切り分け、問題に対処するために十分なコンテキストを提供するツールが効果的です。
集約データの可視化:ダッシュボードやインタラクティブなサマリーなど、視覚的にわかりやすい方法でインサイトを提示するオブザーバビリティツールを使えば、状況をよりすばやく把握できます。
コンテンツの提供:オブザーバビリティツールは、インシデントが発生したときに、パフォーマンスの経時的変化、他の部分への影響、問題の範囲、影響を受けたサービスやコンポーネントの相互依存関係など、システムの状態を理解するのに十分なコンテキストを提供する必要があります。オブザーバビリティレベルのコンテキストがないと、インシデント対応は難しくなります。
機械学習の活用:データの処理とキュレーションを自動化する機械学習モデルが組み込まれたツールなら、異常やその他のセキュリティインシデントをよりすばやく検出して対応できます。
ビジネス価値の提供:デプロイの速度、システムの安定性、カスタマーエクスペリエンスなど、ビジネスに重要なメトリクスを基準にしてツールを評価することが大切です。
本番環境の分散システムでオブザーバビリティを実現すれば、DevOps開発者は、アプリケーション内部の状態をいつでも確認し、問題の発生時には正確な情報にアクセスできます。主なメリットをいくつか紹介します。
可視性の向上:分散システムが拡大すると、本番環境でどのサービスが稼働中であるか、アプリケーションのパフォーマンスは安定しているか、サービスの所有者は誰か、最後のデプロイ前のシステムはどのような状態だったかなどを把握することが難しくなりがちです。オブザーバビリティを実現すれば、本番環境のシステムをリアルタイムで可視化して、これらの疑問を解消できます。
アラート対応の向上:オブザーバビリティを活用すると、問題の発見と解決を迅速化できます。システムを詳細に可視化することで、すばやく変更箇所を特定し、問題をデバッグまたは修正し、変更による悪影響があれば、それを特定することができます。
ワークフローの向上:リクエストの処理をエンドツーエンドで追跡し、問題に関するコンテキストデータを確認できるようになるため、アプリケーションの調査とデバッグプロセスを効率化し、パフォーマンスを最適化できます。
情報収集の効率化:開発者がサービスの責任者や最後のデプロイの数日または数週間前のシステムの状態を確認するには、外部のサービスやアプリケーションを利用して情報を追跡しなければならないことがあります。適切なオブザーバビリティソリューションを導入すれば、これらの情報をすぐに入手できます。
開発スピードの向上:監視とトラブルシューティングを効率化することで、開発者の負担を減らすことができます。これにより、デリバリーを迅速化し、技術スタッフが組織や顧客のニーズを満たす革新的なアイデアを考えるための時間を増やすことができます。
開発者の業務を迅速化して成果の向上を支援
開発者とソフトウェアエンジニアがオブザーバビリティから得られるメリットは、外部および内製のアプリケーションやサービスを含むアーキテクチャ全体を可視化できる点です。可視化により、問題の修正と防止が容易になるだけでなく、システムのパフォーマンスとそのカスタマーエクスペリエンスへの影響に関する理解が深まります。その結果、ビジネスに利益をもたらす戦略的イニシアチブの立案により多くの時間を費やせるようになります。
チームとしても、アーキテクチャ、健全性、パフォーマンスの時系列の変化を包括的に理解して、環境に対する認識を共有できる点でメリットがあります。開発者、オペレーター、エンジニア、アナリスト、プロジェクトマネージャー、その他のチームメンバーの間で、サービス、顧客、その他のシステム要素に関するインサイトを共有できます。また、インシデント事後レビューの精度も高まります。サイロ化された個々のソースのイベントをつなぎ合わせる作業が不要となり、リアルタイムのシステム動作に関する記録文書を検証できるようになるからです。インシデントの原因を人の意見ではなくデータに基づいて判断することで、将来のインシデントに対してより効果的な防止および対応策を立てることができます。
そして、おそらく組織全体のメリットが最大のものです。オブザーバビリティを実現すれば、システムの状況を包括的に把握し、発生した問題をすばやく特定して改善または解決できるようになるので、システムの安定性を損なうことなくアプリケーションやサービスを変更できます。新しい機能を投入しながらダウンタイムを短縮することにより、顧客の満足度を高め、エンドユーザーエクスペリエンスと収益の向上につなげることができます。
オブザーバビリティは、インフラ全体の状態を把握するための重要かつ実用的なアプローチです。クラウド、コンテナ化、マイクロサービス、その他のテクノロジーにより、システムはかつてないほど複雑化しています。
総合的に見ればこれらのテクノロジーは非常に有用ですが、そのシステムの運用、トラブルシューティング、管理には困難が伴います。相互依存関係が増えることで問題が多様化し、ひとたび問題が発生すると、その検出と修正は容易ではありません。
幸い、これらの分散システムはさまざまなテレメトリデータを生成します。それらのデータを活用すれば、パフォーマンスをより正確に把握できます。効果的なオブザーバビリティツールは、インストルメンテーションと分析機能によって、システムの出力を捕捉し、コンテキストを生成して、システムの分散が進む今日の世界で成功するために必要なインサイトをもたらします。
このブログはこちらの英語ブログの翻訳です。
この記事について誤りがある場合やご提案がございましたら、ssg-blogs@splunk.comまでメールでお知らせください。
この記事は必ずしもSplunkの姿勢、戦略、見解を代弁するものではなく、いただいたご連絡に必ず返信をさせていただくものではございません。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。