可観測性とは？ Wallarmによる完全ガイド

可観測性とは何か？

貴社のネットワークについて何でも問いただすための技術とプロセスが必要です。これが可観測性の根幹です。

これは数学、特に制御理論の研究に由来する理論です。システムの出力から初期状態の値を推測できれば、「可観測」と言われます。

ネットワークが「制御可能」と呼ばれるためには、可観測であり、かつ制御可能である必要があります。すなわち、入力を変えることでシステムの状態を変更できなければなりません。情報システムにおいて「可観測性」は、ソフトウェアネットワーク全体の動作状況を把握する力を意味します。

急速に発展している新たな分野です。DevOpsやソフトウェアエンジニアリングのチームも活用しています。可観測性エンジニアリングは、あらかじめ定義されたデータを収集することなく、特徴やパターンを把握できる点で他の監視システムと一線を画します。

可観測性を活用する企業は、アプリの技術基盤だけでなく、様々な情報源からデータを集約し、監視体制を強化できます。

可観測性により、アプリのステージングやビジネスに関わるデータについて自由に疑問を持ち、問題を迅速に特定・切り分けることが可能です。結果として、エンドユーザの満足度向上や、市場投入までの時間短縮も期待でき、イノベーションに専念しやすくなります。これらは情報が適切な文脈で整理されることによって実現されます。

‍

可観測性の重要性

現代のシステムは、Kubernetesクラスタ上で稼働するクラウドベースかつオープンソースのマイクロサービスとなっています。分散したチーム体制がさらなる迅速性を生み、DevOpsや継続的なデリバリー、アジャイルな成長がソフトウェアのリリースを容易にしていますが、同時にバグの発見が難しくなっています。

かつては、メインフレームや安定運用の時代、あらかじめ設定された静的なダッシュボードがオペレーターに情報を提供していました。しかし、そのシステムは同じ失敗を繰り返す傾向がありました。

システムが複雑化する中、監視技術はプログラムの性能を把握しようと試みました。時系列データと監視データの解析により、アプリの動作状況を追跡できるようになりました。

今日では、障害の原因は多様で、手に負えないと感じることもあります。

可観測性が欠如すると、ネットワークや分散システム内の異常箇所を特定するのが難しくなります。マイクロサービス設計が一般化する中、チームはそれぞれの責任を分担するため、自社で管理していないアプリ部分の調査やデバッグが必要となります。分散トレースを利用することで、要求やボトルネックをシステム全体で追跡できます。

‍

可観測性と監視の違い

監視は可観測性の一部と見なすことも可能です。監視は、ビジネス全体を拡張可能かつ可観測にするための第一歩です。一方、可観測性は記録、指標、トレースを用いてネットワークの健康状態や問題を把握し、外部の結果から内部の状況を評価します。

可観測性を支える3つの要素とは

記録、指標、トレースの管理は可観測性の基盤を成す重要な要素です。これらの情報はシステムの全体像を完全に保証するものではありませんが、強固なネットワークを構築するための貴重なツールとなります。

1. ログ

ログはシステムの生データを提供し、データベースの状態を把握する助けとなります。出来事の記録は、特定の時刻に行われた操作の履歴です。ログが対応する3種類のフォーマットには、日付、ペイロード、背景情報が含まれます。

• プレーンテキスト：文字列のみで記録される形式。最も一般的な形式です。
• 構造化：JSONなど、構造化された形式で送信されるログです。
• バイナリ：Protobufログ、MySQLのBinLog（複製や任意時点の復元用）、Systemdジャーナルログ、BSDファイアウォールpfのPFLOG形式などが含まれます。

2. 指標

指標は、サービスや構成部品の動作状況を時系列で示します。名称、値、ラベル、タイムスタンプによって、SLA、SLO、SLIの情報が伝えられます。

これは個々のイベントではなく、計測可能なシステム性能の数値であり、インフラ要素の関連性を示して、システムの健康状態と能力を効率的に管理します。データ検索や保全にも役立ちます。

初期の段階では、探索的分析やフィルタリング機能が不足していました。旧来のGraphiteの階層的指標方式では、タグやラベルが存在しなかったのです。

現在の監視システム（Prometheusや高次元のGraphiteなど）では、各時系列に指標名とキー・バリュー型のラベルが含まれています。

3. トレース

ログや指標でシステムの健康状態は把握できますが、分散システムにおいて要求の発生源を突き止めるには不十分です。

そのため、複数のシステムにまたがる要求や操作の全体的な流れを把握する「トレース」という別の手法が用いられます。

分散ネットワークでは、各ノードの経路をトレースすることで、要求や操作の行方が明らかになります。特にサーバーレス、マイクロサービス、コンテナ化されたアプリの環境において、この手法は大いに役立ちます。

トレースデータを分析することで、システムのパフォーマンス低下を特定し、迅速にバグを修正し、最適化による効果が高い部分を見極めることが可能です。

‍

可観測性の利点

デジタル化が進展し複雑になる中でも、可観測性ツールはエンジニアや開発者が顧客体験を向上させる支援をします。これにより、様々なテレメトリーデータを収集し、解析、通知、連携することが可能です。

システムの可観測性を高めることで、運用効率や事業成長に弾みがつきます。例えば、可観測性プラットフォームを活用して重要な事象の原因を解明し、再発防止策を講じることで、MTTRの短縮とダウンタイムの削減が実現されます。

新たなビルドがリリースされた際、エラー発生数の増加や応答遅延など不審な変化の原因を追究することで、アプリの動作への影響を把握し、不具合のあるノードを迅速に特定できます。

これらの利点に加え、可観測性には以下の特徴もあります：

• 関連運用データを一元管理できる信頼性
• 実績のある信頼性と効率性
• デジタル企業のパフォーマンス変動を即時に把握可能
• 部門間の連携強化による迅速な問題解決
• イノベーションを促す組織文化
• 運用効率の向上により市場投入までの時間短縮とソフトウェア品質の向上
• 投資効果を最大化し、より確かなデータに基づいた経営判断が可能

‍

可観測性の課題とは

従来の監視ソリューションは、モノリシックなシステム内の1つのアプリやサーバのみを対象とすることが多いです。一方、可観測性には以下のような課題があります：

• 複雑な動的環境

新技術の急速な導入により、膨大なデータと変化しやすい監視設定が生じます。手動ツールや従来の監視では、IT部門が環境の動作を十分に把握するのは困難です。依存関係を明らかにし、抜け落ち部分を減らすためのツールが求められます。

• コンテナやマイクロサービスの監視

コンテナやマイクロサービスは現代のソフトウェア開発を促進しますが、その動的な性質により、コンテナ上の作業負荷を即時に把握するのは難しくなります。

適切なツールがなければ、ユーザ要求をマイクロサービス間で追跡することは困難で、システム設計者への確認や推測に頼るしかなくなります。

• データ量、速度、多様性

増加するデータをツールやダッシュボードで解析し、変化する環境の中で基準値を設定する必要があります。しかし、未知の問題を追跡するのは容易ではなく、IT部門はタイムスタンプや推測で静的なダッシュボードから情報を引き出し、システムの不調を示そうとします。

• 可観測性のビジネス面での影響測定の難しさ

多くのエンジニアは可観測性ツールやベストプラクティスの必要性を認識していますが、ビジネスの正当性を示すのは容易ではありません。

コンテナとマイクロサービスにおける可観測性

開発者が運用上の問題を特定し解決するため、マイクロサービスやコンテナにおける可観測性は、本番環境の状態を可視化します。しかし、その導入により、多くの独立した要素がサーバ群に分散して存在することになります。

調査によると、CIOの70%がコンテナ化されたマイクロサービスを即時に監視するのは不可能だと考えています。可観測性ソリューションは、分散ネットワークに実際のユーザ監視を提供することで、アプリの動作速度と可用性の向上に寄与します。

‍

DevOpsにおける可観測性

DevOpsは、高品質な製品の迅速な提供と反復を重視する働き方です。頻繁なリリースは、アプリや製品の信頼性が前提となるため、堅牢かつエラーに強い設計が求められます。

DevOpsでは、「可観測性」とは、DevとOpsのチームが分散ネットワークから即時の性能情報を記録・収集・相関・解析できる仕組みやプロセスを指し、アプリの状態把握・改善を容易にします。

‍

ソフトウェアエンジニアリングにおける可観測性

一般的には、出力ログがネットワーキング情報を提供し、管理者やソフトウェア開発者が状況を把握できると定義されます。さらに、このデータは顧客がアプリをどのように利用しているかを理解する手助けとなり、新機能の追加や利用者の利便性向上に寄与します。

ソフトウェア開発の現場では、プロジェクトの全体的な健康状態、パフォーマンス、エラー履歴を把握するために可観測性が実践され、エンジニアは手順、指標、ログ、トレースを通じてシステムの状態を評価します。

‍

可観測性の活用事例

可観測性は一括して語られることがありますが、実際には複数の異なる手法が含まれます。主にITシステム、機能、インフラに関するものであり、ITスタックの一部として捉えられ、データやモデルの可観測性は別途考える必要があります。

• 可観測性：主にITシステム全体に関し、運用データを分析するための場を提供
• データの可観測性：ITシステム全体ではなくデータ層に焦点を当て、データ品質保証を前倒しで実施し、問題の早期解消およびシステム全体の品質低下を防ぐ。これにより、企業は質の高いデータを基に判断できる。
• モデルの可観測性：モデル成果物を解析することで、機械学習開発者がエラーの発生場所やタイミングを把握し、より正確なモデル構築と意思決定を支援する。

優れた可観測性ツールの条件

オープンソース、商用、カスタム、クラウドといった各種可観測性ツールには共通の特徴があります。適切なツールを選ぶためには、以下の点を確認してください：

1. 使いやすさ：シンプルであること
2. 即時データ：ダッシュボード、レポート、検索で即時の情報を提供すること
3. 既存のエコシステムや技術基盤と連携でき、各種コンテキストや言語に対応していること
4. 集約されたデータをダッシュボード、グラフ、チャートなどで視覚化できること
5. イベント処理機能：多様な情報源、技術基盤、技術、運用環境から関連データを取得し、重要な情報とそうでない情報を選別して文脈を提供すること
6. 文脈の提供：問題発生時に根本原因、影響範囲、他要素との依存関係、システム全体への影響を明らかにするための情報を提示できること
7. AI/MLの活用：反復的な処理を自動化し、パターンを解析して根本原因の評価に役立てること
8. ビジネス価値の提供：迅速なデプロイ、システムの安定運用、顧客体験の向上など、ビジネス面でのメリットを実現すること

可観測性の実装方法

システムを可視化する方法が気になる場合、可観測性を構成する5つの要素は以下の通りです：

• インストゥルメンテーション：オープンソースまたはベンダー固有のテレメトリーデータを活用し、インフラの状況を把握する。
• 分散トレース：システム内のマイクロサービスがどのように連携しているかを明らかにし、ユーザ要求の経路を可視化する。
• 可観測性プラットフォームには、適切なIT担当者へ通知するインシデントアラート機能が必要である。
• テレメトリーデータの相関分析により、グラフやチャートを作成し、収集データのピークや変動を把握できること。
• 機械学習モデルがインシデントデータを集約・相関・優先順位付けし、AI Opsツールが対応時間を短縮しMTTRを改善すること。