可観測性

可観測性とは

可観測性とは、システムの出力を分析して効果的なデバッグを可能にすることでシステムの内部状態を把握する能力です。今日のITシステムは、多くの場合、マイクロサービスやサーバーレス機能などのテクノロジーを使用しており、複雑で分散されています。従来の監視とは異なり、問題が予期しないものであっても、可観測性によってシステムの動作をより深く調査できます。可観測性は、評価基準、ログ、イベント、分散トレースなどの豊富なデータソースに依存します。

可観測性が他と異なるのは、システムに関して新しい予期しない質問をできる点です。従来の監視は、静的なダッシュボードと事前設定済みのアラートしきい値に依存し、「CPU使用率は90%を超えているか」といった既定義済みの質問に答えます。一方、可観測性は、「直近の展開の後にEMEA地域の特定のiOSバージョンバージョンのユーザーだけロードに時間がかかっているのはなぜか」といった新たな質問が生じたときにそれに答えるのに役立つ詳細なデータを提供します。

このような新たな質問に答える能力は、複雑なシステムにおける予期しない問題に対処するうえで非常に重要です。これまでに発生したことのない問題のアラートをセットアップすることはできません。可観測性により、エンジニアは新たな問題を調査して複数のサービスでその原因を追跡し、システムへの影響を把握するのに必要な詳細なデータを得ることができます。可観測性は、失敗は避けられないものと想定し、チームがデータを使用してそれらをすばやく分析できるようにします。

最新の可観測性は、システムパフォーマンスをビジネス成果に直接結び付けます。ユーザーのショッピングカートIDやサブスクリプションレベルなどのビジネスの詳細とAPI応答の遅延などの技術データを組み合わせることにより、チームは技術的な問題がビジネス目標にどのような影響を与えるのかを直接確認できます。たとえば、エンジニアはデータベースエラーを「チェックアウト失敗」イベントの増加に結び付けることにより、バグの財務的影響を測定し、技術的な緊急性ではなくビジネスへの影響に基づいて修正を優先順位付けできるようになります。

可観測システムの中核となるシグナルは、その動作を完全に理解するために収集されるテレメトリタイプです。可観測性は基本的な3つの要素に根差していますが、今日のアプローチは、複雑化の一途をたどるシステムアーキテクチャーの課題に対応するためにさらに拡張されています。

可観測性の3つの基本的な柱は、評価基準、ログ、トレースです。

• 評価基準は、一定の間隔で集計された数値の時系列データポイントです。これらは、システムの健全性を長期間にわたって追跡するのに不可欠であり、パフォーマンス、(CPUやメモリなどの) リソース使用率、エラー率に関する有益な情報をすばやく提供します。測定基準は、ダッシュボードを作成し、既知の条件でアラートをトリガーするのに役立ちます。
• ログは個別のイベントに関する不変のタイムスタンプ付きのレコードです。これらは、完全なスタックトレースを含むエラーメッセージやユーザーログインのレコードなど、豊富で詳細なコンテキストを持つイベントをキャプチャするために使用されます。評価基準は問題が発生したことを示し、ログはその理由を説明するコンテキストの詳細を提供します。
• 分散トレースは、システムにおけるリクエストのエンドツーエンドの経路を明らかにします。トレースは、単一のユーザーアクションが複数のマイクロサービス、データベース、API間を移動する様子を追跡してワークフロー全体を綿密に示します。これは、レイテンシのボトルネックを特定し、分散アーキテクチャーにおける依存関係を理解するうえで非常に有益です。ただし、複雑なクラウドネイティブ環境では、3つの柱だけでは不十分なことが少なくありません。データが膨大なうえにサービスは短命なため、異なるデータタイプを手動で関連付けて根本原因を特定するのは困難です。このことから、継続的なプロファイリングやビジネスイベントなど、より深く有益な情報を提供する新たなデータシグナルが利用されるようになっています。
• 継続的なプロファイリングは、機能や行番号に至るまでのCPU使用量とメモリ使用量を継続的に分析してリソースを大量に消費するコードを特定するのに役立ちます。サービスが遅い、またはリソースを大量に消費する理由を説明し、時間がかかっている場所を示すトレースデータと原因となっているコードそのものを結び付けます。
• ビジネスイベントの重要性は、技術的なパフォーマンスをビジネス成果に結び付ける点にあります。「cart_add」や「payment_processed」などの価値の高いアクションを最も重要なテレメトリとして扱うことにより、チームは (収益の損失などの) 技術的な問題がビジネスに与える影響を直接測定し、データ主導で優先順位付けを行うことができます。

可観測性戦略では、テクノロジー、標準、文化的態度に基づいてシステムの動作を理解します。可観測性は、単にツールを展開するのではなく、持続可能な規律を育むことに重点を置いています。

最新の可観測性パイプラインは、データの作成を有益な情報に結び付けます。インストゥルメンテーションとは、テレメトリを送信するようにアプリケーションとインフラストラクチャコードを構成することを意味します。(エージェントなどの) 収集レイヤーがこうしたデータを収集し、中央の処理およびストレージバックエンドに送信します。データは、インデックスを付けて相互に関連付けたうえで保存されます。最後の段階で、エンジニアがクエリ言語、ダッシュボード、アラートシステムを使用してデータを分析し、傾向を見つけ出してバグを修正します。

最新のインストゥルメンテーションは、Cloud Native Computing Foundation (CNCF) のプロジェクトと業界標準であるOpenTelemetry (OTel) に依存しています。OTelは、評価基準、ログ、トレースのベンダーニュートラルなAPI、SDK、ツールを統合します。主なメリットは、ベンダーロックインが生じないことです。OTelを使用してサービスを一度インストゥルメント化することでサポートされている任意のバックエンドへのデータのルーティングが可能になり、チームはアプリケーションコードを書き直すことなく分析プラットフォームを変更できるようになります。

ツールを選択するにあたり、組織は統合された可観測性プラットフォームと最適な組み合わせのソリューションを選択する場合があります。統合プラットフォームは、トレース、ログ、評価基準を自動的に関連付けてスムーズなデバッグを実現するシングルペインオブグラスを提供します。最適な組み合わせの戦略では、チームはログ記録やトレースなどの各機能に最適なツールを選択できますが、統合とメンテナンスの複雑さが増します。

最後に、テクノロジーだけでは不十分です。可観測性の成功には、データ主導の好奇心を生み出すための文化的変革が必要です。エンジニアには、単に通知に反応するのではなく、質問して「未知の未知」を調査する権限が必要です。これにより、観測可能なデータとインシデントを学習の機会と捉える非難のない文化が活用され、開発、運用、ビジネスチーム間のコラボレーションが促進されます。

可観測性と監視は目的が異なりますが、システムの信頼性を実現するためにはその両方が必要です。監視は、確立された測定尺度としきい値を使用して既知の問題を検出しますが、可観測性は、システムの外部出力 (すなわちログ、メトリック、トレース) を分析して内部状態を推測し、未知の問題を発見します。監視は、問題が発生した際の迅速な対応に役立ちます。一方、可観測性はシステム動作の理解に役立ちます。可観測性と監視はどちらもシステムの信頼性の維持に必要ですが目的が異なります。監視は、確立された測定尺度としきい値を使用して既知の問題を検出しますが、可観測性は、システムの外部出力 (すなわちログ、メトリック、トレース) を分析して内部状態を推測し、未知の問題を発見します。監視は問題が発生してからの対応に役立ちます。一方、可観測性は、問題の防止と修正のためにシステム動作を理解する上で役立ちます。

さらに詳しく分解すると次のようになります。

監視:

• フォーカス: メトリックを追跡して表示し、事前に設定されたシチュエーションに関して警告を発し、システム健全性の動的ビューを提供する。
• 目標: 問題を素早く特定して修正する。
• データ: ほとんどの場合、既定義済みメトリックとログデータを使用する。
• 例: メモリ消費量、HTTP応答時間、ディスクI/O を追跡して、パフォーマンスの問題を正確に特定します。

可観測性:

• フォーカス: システム出力に焦点を当てて未知の問題を発見し、複雑な動作を理解する。
• 目標: システムの動作に関する有益な情報を明らかにして問題をプロアクティブに検出し、根本原因を調査する。
• データ: 測定値、ログ、トレースを収集し、システムプロセスに関する記述を漏れなく入手する。
• 例: 分散トレースを使用してマイクロサービス全体のリクエストジャーニーをトラッキングしたり、ログを分析してサービスの不具合を識別したりします。

主な相違点:

• 可観測性は、ユーザーに影響が生じる前にエラーを防止することに重点を置いています。これに対し、監視は警告システムとして機能します。
• 監視は、確立されたメトリックを使用して、認識済みの障害に対処します。一方、可観測性はシステムの出力と動作を分析して未知の問題を発見します。
• 監視は個々のメトリックに重点を置きますが、可観測性はシステムの内部状態の全体像を示します。
• 可観測性は、システム全体のコンテキストの調査により、包括的な根本原因調査を示します。一方、監視は、十分なコンテキストを示さず、障害のみを示す場合があります。