オブザーバビリティをおさらい - なぜ今、理解できるシステムが必要なのか

近年、大規模なシステム障害のニュースを目にする機会が増えています。その影響は長期化・深刻化する傾向にあり、数時間どころか、時には数日、数週間、さらには数カ月に及ぶ障害も発生しています。

システム障害が企業に与える損失は数十億円規模に達することもあります。さらに、今や私たちの暮らしのあらゆるタッチポイントはスマートフォンなどを介したデジタルサービスが支えているため、それらの障害時にはSNSにおける批判の拡散や、社会インフラとしてのITサービスの停止による社会的影響など、その影響は甚大なものとなっています。

現代のITシステムが直面している根本的な課題

なぜ、このような状況が起きているのでしょうか？その背景には、現代のITシステムが直面している根本的な課題があります。DX(デジタルトランスフォーメーション)の加速により、ビジネスのあらゆる側面がITシステムに依存するようになっています。

かつての基幹系システムは、業務を「正確に処理する」ことが主な役割でしたが、現代のシステムには「ビジネスの変化に素早く対応する」ことも求められています。

この要求に応えるため、システムは急速に進化を続けています。クラウドの活用、アジャイル開発の一般化、CI/CD(継続的なデプロイメント)の採用など、システムの開発・運用方法は大きく変化しました。その結果、変更のスピードと頻度は劇的に向上しましたが、同時にシステムの複雑さも増大しています。

例えば、ある機能の改善は複数のチームが並行して開発を進め、一日に何度も本番環境に反映されます。システムは複数のクラウドサービスと連携し、さまざまなサードパーティーのAPIを利用します。さらに、AIやローコード開発といった新しい技術も次々と導入されています。

このように複雑化・高度化するシステムでは、従来の「正常か異常か」といった既知の問題を判断するだけの監視アプローチでは不十分です。問題が発生したとき、その原因が複雑に絡み合っていたとしても、システムのどの部分にあるのか、それがビジネスにどのような影響を与えているのかを素早く理解する必要があります。

ここで注目されているのが「オブザーバビリティ」というアプローチです。このオブザーバビリティという考え方は、実は私たちの身近なところにもあります。

• 

  現代のシステムは複雑化・高度化している

システムを“理解する” - オブザーバビリティとは何か

オブザーバビリティとは、システムの内部状態を外部から理解する能力のことを指します。この概念は元々、制御工学の分野で使われていた考え方です。システムの出力から、そのシステムの内部状態を推測・理解できる度合いを表しています。

例えば、現代の自動車を考えてみましょう。ドライバーは、速度計、燃料計、エンジン回転数、さまざまな警告灯など、複数の計器を通じて車の状態を理解します。

「何となく調子が悪い」では整備士も対応に困りますが、警告灯の点灯やエンジン音の変化といった具体的な情報があれば、問題の特定と対応が容易になります。さらに、最近の自動車には、より詳細な情報を提供する車載コンピュータが搭載されています。

走行距離、燃費履歴、タイヤ空気圧など、さまざまなデータを記録・表示することで、車の状態をより正確に把握し、故障の予防や効率的な運転が可能になっています。これは、システムの状態を「観測可能」にすることで、適切な判断と対応を可能にしている良い例といえるでしょう。

• 

  オブザーバビリティの概要

オブザーバビリティにおける4種類の基本的な情報

現代のITシステムで、どのようにオブザーバビリティを獲得するのでしょうか？それにはシステムの状態を表す、「Metrics(メトリクス)」「Events(イベント)」「Logs(ログ)」「Traces(トレース)」の4種類の基本的な情報(テレメトリーデータ)を活用します。

身近な例として、ECサイトを見てみましょう。オンラインショッピングでは、スムーズな購買体験を提供するために、さまざまな種類の情報を収集・分析しています。

メトリクスは、システムの状態を数値で表現したものです。例えば「1分間あたりのページビュー数」「現在のアクティブユーザー数」「商品検索の平均応答時間」といった数値を継続的に記録します。これらの数値は時間とともに集約でき、「平日の13時台は商品検索が遅くなる傾向がある」といった長期的な傾向分析が可能です。

イベントは、サイト上で発生する重要な操作を記録したものです。「ユーザーのログイン」「商品のカートへの追加」「注文の確定」「決済の完了」といった、ビジネスにとって重要な操作が該当します。それぞれのイベントには、「いつ」「誰が」「何を」したのかという情報が記録され、ユーザーの行動分析や問題発生時の状況把握に役立ちます。

ログは、システムの詳細な動作記録です。ユーザーの画面遷移、商品の検索条件、APIの呼び出し、データベースへのアクセスなど、システム内で発生するあらゆる動作を記録します。例えば、あるユーザーが商品を購入できなかった場合、その前後でどのような処理が行われ、システムがどのように応答したのかを詳細に確認することができます。

トレースは、一連の処理の流れを追跡する記録です。ECサイトでの商品購入を例にすると、「カートの更新」→「在庫の確認」→「ポイント計算」→「決済処理」→「注文の確定」→「配送手配」といった一連の処理が、複数のシステムをまたいでどのように実行されたのかを記録します。各処理にかかった時間も記録されるため、「決済処理に時間がかかっている」といった問題の特定が容易になります。

これら4種類のデータを組み合わせることで、システムの状態を総合的に理解することができます。例えば、あるユーザーにおける「注文完了まで時間がかかった」という問題があった場合、以下のような手順で理解につなげます。

1. メトリクスでその時間帯のシステム全体の混雑状況を確認
2. イベントで該当する注文処理の「いつ」・「誰が」・「何を」の開始から完了までを特定
3. トレースでその注文処理の中でどの部分に時間がかかったのかを追跡
4. ログで遅延が発生した箇所の詳細な状況を確認

• 

  オブザーバビリティにおけるデータの種類

このように、問題の原因を効率的に特定することができます。4種類のデータはそれぞれが異なる視点でシステムの状態を表現しており、それらを組み合わせることで、複雑なシステムの全体像から詳細までを把握することが可能になります。

オブザーバビリティ=理解できるシステムがもたらす価値

オブザーバビリティの本質的な価値は、システムを「理解できる状態」にすることで、ビジネスとテクノロジーの両面で持続的な価値を生み出せることにあります。

近年、デジタルサービスはビジネスの中核を担うようになり、システムの安定性と信頼性は、そのまま企業の競争力に直結します。前述したように、数時間のシステム障害が数十億円規模の損失を生むこともある現代において、システムを理解し、適切にコントロールできる状態を作ることは、経営の重要課題となっています。

オブザーバビリティは、この課題に対する具体的な解決策を提供します。例えば、サービスの遅延や障害が発生した場合、イベント情報から「いつ、誰が、何をしたときに」問題が発生したのかを特定し、その時点での詳細な状況から根本的な原因を把握することができます。

さらに、必要に応じてトレース情報で処理の流れを確認したり、メトリクスで傾向を分析したり、ログで詳細な状況を確認したりすることで、問題の全体像をより深く理解することができます。

このように、システムの状態を深く理解し根本的な原因をすぐに特定できるようになることで、問題が発生したときの的確な対応が可能になります。さらに、この理解を日々のシステム改善にも活かすことで、より信頼性の高いサービス提供が実現できるのです。

組織の視点でオブザーバビリティは「データに基づく意思決定」を可能にします。システムの状態が可視化され、共有されることで、開発チームとビジネス部門が同じ事実に基づいて議論できるようになります。例えば、新機能のリリースによるユーザー体験への影響や、システム改善の優先順位付けなど、技術的な決定とビジネス判断を密接に連携させることができます。

そして、エンジニアの視点でオブザーバビリティは「労苦からの解放」を意味します。深夜の緊急対応、属人的な障害対応、断片的な情報による推測と確認の繰り返し……これらの課題から解放されることで、エンジニアはより創造的な価値創出に注力できるようになります。

また、開発段階からオブザーバビリティを採用することで、本番環境へデプロイした際の影響やリスクを低減しながら開発サイクルを高速に回すことができるようになります。結果として、組織全体のイノベーション力が高まり、より良いサービス提供が可能になるのです。

以上のことから、オブザーバビリティは単なる技術的な仕組みではありません。それは、ビジネスの継続的な成長、組織の効率的な運営、そしてエンジニアの働き方改革を同時に実現する、現代のデジタルビジネスに不可欠な能力なのです。

今回は、オブザーバビリティの基本的な考え方と、なぜそれが必要とされているのかについて見てきました。しかし、実際の現場では、オブザーバビリティに関するさまざまな誤解や、陥りがちな落とし穴が存在します。

次回は、「オブザーバビリティの誤解」と題して、現場でよく見られる誤解や課題について、具体例とともに解説していきます。データを集めることは「目的」ではなく、「手段」であることを改めて考えていきましょう。