オブザーバビリティとは？
オブザーバビリティとは、データの収集と分析を通じてビジネスに関するあらゆる疑問の答えを明らかにしようとするマインドセットを指します。オブザーバビリティとは何かと尋ねると、「システムの出力を調査することによってその内部の状態を監視すること」といった制御理論に基づく無機質な定義を持ち出す人もいれば、「メトリクス、トレース、ログ」という極めて技術的な定義を口にする人もいるでしょう。いずれの答えも正解には違いありませんが、一方で、オブザーバビリティは、単に実装して「このシステムはオブザーバビリティを備えた」と誇らしげに宣言して終わりというものでもありません。ビジネスにオブザーバビリティを取り入れることで、ビジネスに関する疑問の答えを見つけることができるのです。
ビジネスに関する疑問とは？
「このエラーが急増したときにアプリケーションで何が起こっていたのか？」という初歩的な疑問の答えももちろんオブザーバビリティツールを見つけることができますが、オブザーバビリティの真の実力はその程度ではわかりません。オブザーバビリティのマインドセットが明らかにするのは、エラーが急増した理由そのものです。アプリケーションとそのすべての依存関係を知り尽くしていれば、通常の監視システムでもその答えを見つけることができるかもしれませんが、複雑化する今日のアプリケーションでは、すべての状態を覚えておくことは非常に困難です。ビジネスニーズへの対応、新機能のリリース、A/Bテスト、マイクロサービスへのリファクタリングなど、さまざまな要因が相まってシステムは複雑化の一途をたどっています。もはや適切なツールのサポートなしにシステムの状況を隅々まで把握することは不可能になりつつあります。
オブザーバビリティは、エラーがユーザーエクスペリエンスに実際にどのような影響を及ぼしたか(そもそも影響を及ぼしたのかどうか)という疑問の答えも明らかにします。オブザーバビリティで分析対象になるデータは、RUMデータから、購入量、一般的なビジネスメトリクス、マーケティングキャンペーン、カスタマーサポートチケット、ソーシャルメディアでのセンチメントまで、広範囲にわたります。その点でオブザーバビリティツールは、組織内の一部の人だけでなく誰もがインサイトを引き出すために活用できます。そして、幅広いデータから「何を」だけではなく「なぜ」、「どのように」を知ることができます。真のオブザーバビリティツールで答えが見つける疑問には以下のものがあります。
- 「なぜここで障害が起きたのか？」
- 「この広告にはどのくらいの効果があったか？」
- 「この新しいフロントエンド設計は売上の増加に貢献したか？」
- 「このサービス障害によってユーザーの満足度が低下したか？」
関心を持つべき理由
上記のような幅広いデータをシステムに統合すれば、たとえば最良顧客に送ったマーケティングメールでキャンペーンサイトのURLに誤りがあり、それをクリックした顧客にエラーページが表示されたといった具体的な問題を特定できます。もちろん、オブザーバビリティツールを使用しなくても、エラーページへのアクセス数が増加したことはわかるでしょう。しかし、アクセス数が増加した理由まではわかりません。「サーバーでエラーページのアクセス数がしきい値を超えた」という情報と「最良顧客向けのマーケティングキャンペーンが開始された」というイベントが同時に報告されたら、すばやく問題解決に取り掛かることができます。発生した問題だけでなく、その原因を示唆する情報が得られれば、その問題による組織の収益や評判に対する影響の調査も即座に開始できるでしょう。
監視の弱点
これまで述べてきたとおり、監視では問題が起きていることはわかりますが、その原因まではわかりません。また、監視対象として設定できるのは、問題が起こる可能性があると予測できる範囲、つまり「既知の既知」のみです。逆に言えば、監視対象として想定していないものは監視できないということです。さらに、その想定外の場所で問題が起き、後からそれを監視対象に追加したとしても、運用履歴データがない状態から始めることになります。監視では、どんな問題が起きるかもわからないうちに、問題の詳細を事前に検討する必要もあります。何を測定し、どのような状況でアラートを生成するかを具体的に決めておかなければなりません。それには時間がかかるうえ、見落としが生じやすいという問題もあります。
さらに監視ツールでは、どれだけ適切に監視対象を設定したとしても、その結果をビジネスと関連付けることができません。そもそもビジネスデータは監視ツールの評価対象に含まれず、そのため「未知の未知」を明らかにすることができないのです。通常、従来の監視ツールではビジネスメトリクスの追加はサポートされていないか、限定的にしかサポートされていません。Webアプリケーションのあらゆる要素がユーザーエクスペリエンスに影響することを考えれば、実際のユーザーデータが監視対象に含まれず、評価できないのは大きな損失です。
「3つの柱」の効果
メトリクス、トレース、ログはオブザーバビリティの「3つの柱」と呼ばれます。これらは、オブザーバビリティの本質を理解し、アプリケーションやビジネスに関するインサイトを獲得するために必須ですが、それで十分というわけでもありません。メトリクスは、問題が起きたことを教えてくれます。トレースは、問題の内容、たとえば失敗した呼び出しなどを教えてくれます。そしてログは、問題の原因を教えてくれます。特定のメトリクスやトレースについて、なぜそのような動きをするのかを明らかにします。この3種類のデータを収集することがオブザーバビリティのマインドセットの出発点です。そして、それは始まりにすぎません。
すべてのデータを収集することの重要性
オブザーバビリティの大きな課題の1つは、大量のデータの収集と保存が必要である点です。「今日のサービスで大量に生成されるすべての出力を1カ所に保存するなんて非現実的だ」と思うかもしれません。その解決策として多くのベンダーが取り入れているアプローチが「サンプリング」です。しかし私はこれを「一部のデータを捨てる」手法だと考えています。そして、その捨てられたデータこそが実は最も重要なユーザートランザクションであり、そのトランザクションがデータベースサーバーをクラッシュさせる予想外のバグを引き起こした、ということもあり得るのです。最悪なのは、多くのベンダーがこれを「コスト節約」のための機能と宣伝していることです。サンプリングが生む隠れたコストについては別のブログ記事で詳しく説明する予定です。
古典的な制御理論に従って重要なインフラを多角的に監視するときに、30%の観測データがあれば十分だと考えて残りの70%を破棄するでしょうか？もちろんしないでしょう。しかし、オブザーバビリティに関しては、多くのベンダーがデータの性質上そうすべきと推奨しているのです。正しいアプローチとはとても言えません。成熟したプラットフォームであれば、ビジネスに関するすべてのデータを漏れなく処理できます。
オブザーバビリティはプラクティスではなくマインドセット
この記事ではオブザーバビリティの実装の詳細について触れましたが、オブザーバビリティの真の意味は「メトリクス、トレース、ログの収集と保存」という行為ではありません。「ビジネスに関する疑問の答えを明らかにするためのデータを収集しよう」というマインドセットです。オブザーバビリティで重要なのはアプリケーションパフォーマンス監視やインフラ監視ではありません(それらもオブザーバビリティに含まれますが)。本当に重要なのは、すべてのデータを取り込むことの必要性を理解することです。実際のユーザーエクスペリエンスのメトリクスから、マーケティングキャンペーン、季節ごとのトラフィックの変化、倉庫スタッフの病欠の日数まで、「すべての」データです。
オブザーバビリティは、ビジネスやアプリケーションに関するデータの「信頼できる唯一の情報源」を構築し、それを開発者、運用チーム、製品チーム、経営幹部を含む組織の全員で共有することが必要だと認識するマインドセットなのです。ビジネスは何百万ものデータポイントで構成されます。オブザーバビリティは、各システムのすべてのデータを収集し、それらのデータに基づいて、アプリケーションという技術を超えたビジネスに関する疑問を解き明かします。
オブザーバビリティを最大限に活用するには、自由に拡張でき、システムの変更がユーザーやビジネスに与える影響について常にフィードバックを得られる、専用のストリーミングアーキテクチャが必要です。そして、多数のツールを単一の情報源に統合し、各ツールからのインサイトを集約するソリューションが必要です。
ぜひSplunk Observability Cloudの無料トライアル版で、オブザーバビリティによるインサイト獲得を体験してみてください。
トライアル版に臨む前に、オブザーバビリティについてさらに詳しく知りたい場合は、無料の『オブザーバビリティ(可観測性)ビギナーガイド』をご覧ください。
このブログはこちらの英語ブログの翻訳、池山 邦彦によるレビューです。
