オブザーバビリティとは何か？まずはその概念を理解しよう

ダウンロード：「Splunk Observabirity Suite」製品資料

オブザーバビリティとは何か？まずはその概念を理解しよう←本記事です
Splunkが実現するクラウドネイティブ環境のオブザーバビリティ

はじめに

システムのクラウド移行が進み、コンテナやサーバーレスファンクションといったクラウドネイティブ技術の採用が進むにつれて、運用における新しい概念としてオブザーバビリティという単語を耳にする機会が増えてきているかと思います。この記事では、オブザーバビリティとは何か、モニタリングとは何が違うのかという点を解説します。

ただし、オブザーバビリティは「これをすれば全て解決」というものではなく、概念としての解釈や取り組み方は、サービスの稼働環境やシステムの特性、または組織や体制やカルチャーといった要素によって異なる場合があります。

そこで、この記事でオブザーバビリティの原理・原則や背景を中心に触れたいと思います。特に、オブザーバビリティという考え方の必要性や、今までの運用と何が違うものなのかということを重点的に理解していただくことを目指したものとなります。

オブザーバビリティとは？

オブザーバビリティは英語では Observability と表記し、しばしば「可観測性」と翻訳されることがあります。Observe （観察する）+ ability （能力） という単語の組み合わせで示す通り、端的に言えば「観察する能力」です。

もう少し踏み込んで言うと、「いかに容易に且つ的確に事象を捉え観察して正確な対処につなげられるかの指標」とも言えますが、これはどういう意味でしょうか？

生存者バイアスに見るオブザーバビリティ

下の図をご覧になったことはありますか？

(図：生還した航空機被弾箇所)

これは、第二次大戦中に数学者エイブラハム・ウォールドが航空機の損失を最小限にするため、生還した航空機が被弾した箇所を研究したものです。

生存率を上げるために航空機を強化する箇所を検討するにあたって、被弾した箇所を強化するという考えに至ってしまうかもしれませんが、それは誤りです。見落としてしまいがちなのは、このデータが「生還した」航空機のみから得られたものであり、逆に空白部分に被弾した航空機は「生還できなかった」ということになります。

従って、強化すべきは被弾した箇所ではなく、図の空白部分ということになります。

このように、あるプロセスを経て得られた事象のみに着目してしまうと、得られなかった事象を見落としてしまうのが生存者バイアスです。事象を注意深く観察し、得られたデータに耳を澄ませて考察することで、このような誤解を防ぐということが重要であり、これが生存者バイアスにおけるオブザーバビリティです。

これは航空機における生存者バイアスというだけではなく、システムの運用においても同様のことが言えるのです。

オブザーバビリティが生まれた背景

オブザーバビリティを語る上で欠かせないのは、DevOpsとクラウドのコンテキストでしょう。その背景について解説します。

DevOps

Dev（開発）とOps（運用）がお互い相反する利害関係の中であっても協力関係を築き、システムの開発と運用のサイクルを回してビジネスの継続的な運営と成長を目指す、というのがDevOpsの原則です。

それぞれが異なる役割を担いながらもシステムの開発・運用のサイクルを回す際に重要になるのが、DevとOpsの境目に当たるプロセスでしょう。特に、新しい機能やサービスのリリース後、その稼働状況を様々な観点で監視し、その結果を以て新たな取り組みへと進めることが継続的なサービス運営には欠かせないものとなります。

• リリースしたサービスが適切に稼働しているか
• 予期せぬエラーが出ていないか
• パフォーマンスが劣化していないか
• UXは向上したか
• ビジネスにポジティブなインパクトを与えているか

継続的にサービスを開発・運用してビジネスの成長につなげるためにはリリースしてお終いではなく、Monitorから再びPlanへとつなげることが肝要と言えます。

その際、Monitorは運用担当者だけの問題ではなくなってきます。リリースされたサービスの監視には開発者もまた当事者として携わることが求められます。

クラウド

クラウド移行というと、AWSやAzure、GCPのようなパブリッククラウドのへのシステム移行というイメージがあるかと思います。

それも間違いではありませんが、もう少し切り口を変えて、クラウドの活用をいくつかのフェーズに分けて見ていきましょう。

Retain & Optimize

モノリシックなアプリケーションを自社のオンプレ環境で動かし、ウォーターフォール型の開発手法で数ヶ月から年単位でのリリースサイクルで運用している状態です。クラウド移行の前の段階ですが、ここでは未だDevとOpsが切り離されている状態とも言えます。

Lift & Shift

クラウド移行の第1段階として、インフラコスト削減やサーバー調達の納期短縮、CAPEXからOPEXへのシフトを目指して、オンプレで稼働しているシステムをパブリッククラウドやプライベートクラウドのIaaS環境へと移行します。アプリケーションはそのままモノリシックな状態であることが多く、DevとOpsの間にもまだまだ距離があると言えます。

Re-Factor

その後、クラウドの様々なマネージドサービスやオートスケールを活用することで、システムそのもののアーキテクチャーや構成が見直されます。オンプレとは大きく異なり、リソースはエフェメラル(短命)なものとして捉える必要が出てきて、運用に大きな変化が現れます。Zabbixのようなツールでのホストごとの監視が難しくなり、また、アプリケーションのモジュール化により依存関係が複雑なものとなります。

Re-Architect / Cloud-Native

この段階では、サービスをよりスケーラブルに、柔軟なリリースやデプロイを実現するために、コンテナやサーバーレスファンクションといったクラウドネイティブ技術の活用が進みます。結果として、システムの持つ機能が小さな単位のサービスとしてお互いに疎結合するマイクロサービスアーキテクチャーが採用され、より複雑な相互依存となります。各サービスの言語やフレームワークはチームごとに多様なものとなり、ソースコードもコンパクトなものとなります。

また、DevとOpsが緊密に連携し、運用そのものにも開発者が当事者として関わることが必須となります。このフェーズでは、先述したDevOpsにおけるサービス稼働状況の監視において、監視項目やその手法はもちろん、監視そのものの概念を見直す必要が出てきます。ダイナミックに変化するインフラリソースとライフサイクルの短いコンテナ、サービスの複雑な相互依存関係を前提とした環境では、従来の監視では運用できません。

さらに、近年は可用性やパフォーマンスのサービスレベルが非常にシビアなものとなっています。eコマースでは100ミリ秒のレスポンス低下が7%の売り上げダウンにつながるとも言われています。

このように複雑化する環境においてユーザーが求めるサービスレベルを維持するためには、「何が起きているか」だけではなく、サービスレベル維持を阻害する要因に対して「何が障害の原因だったのか」「どこに影響があるのか」「どう対処すれば良いのか」を即座に判別して対処することが求められるようになります。

そこでオブザーバビリティという概念が重要なものとなります。

オブザーバビリティとモニタリングの違い

先に少し触れましたが、モニタリング（監視）は「何が起きているのかを見続けること」に対し、オブザーバビリティは「予期せぬことが起きたときになぜそれが起きたのかを把握すること」となります。

特にクラウドネイティブ環境においてはオブザーバビリティへのシフトが必須となりますが、モニタリングが不要というわけではありません。モニタリングとオブザーバビリティは相反するものではなく、適切に監視することも必要なものであるし、同時に観察することも求められます。

では、クラウドネイティブ環境を観察するためには何がポイントとなるのでしょうか？

オブザーバビリティの3本柱

従来のシステム監視では、ログに吐き出されるエラーメッセージを監視したり、ログでは判別できない詳細なエラーをAPMで監視したりと、監視ツールそのものが組織に合わせてサイロ化されていました。

しかし、クラウドネイティブ環境では、ログを監視するだけではダイナミックに変化するインフラ上でサービスの依存関係の全体像を把握することは困難なものとなります。また、従来のAPM技術では多様な言語やフレームワークへの対応やマイクロサービス特有のコンパクトなソースコードに与えるパフォーマンス劣化といった影響が大きな懸念となります。

そこで、メトリクス、トレース、ログという3種類のデータを活用することになります。

メトリクスで「何が起きているか」を秒単位で検知し、「どこで問題が起きているのか」をトレースで判別、「なぜ問題が発生したのか」をログから究明するというように、各データが相関づけられて連携することでオブザーバビリティのための活用へとつながるのです。

重要なのは、これらのデータを集めることそのものではなく、それらのデータを以て「どれほど容易に状況を把握し事象を正確に把握できるか」「容易に観測することがどれほど担保されているか」というのがオブザーバビリティとしてのポイントとなります。

また、クラウドネイティブ環境ではKubernetesのようなプラットフォームからIstioのようなサービメッシュアーキテクチャー、CI/CDや構成管理等に至るまで多くのオープンソースが使われています。これらオープンソースのツールが相互に連携し合ってクラウドネイティブのエコシステムが構成されるわけですが、オブザーバビリティに関しても例外ではありません。

これらのデータを収集するためのエコシステムとしてのオープンソースは欠かせないものと言えます。クラウドネイティブにおけるそれぞれのデータの性質や活用方法については別の記事で言及したいと思います。

Splunkのオブザーバビリティへの取り組み

Splunkと言えば、セキュリティやIT運用のユースケースを中心としたログ管理ツールというイメージをお持ちの方が多いかと思います。しかし、Splunkは2019年10月にクラウドのインフラ監視とマイクロサービスのトレースにおけるイノベーターであるSignalFxとOmnitionを買収しました。

その後、Omnitionの技術をSignalFxに統合したマイクロサービス向けのAPMや、Kubernetesの統合監視基盤となるKubernetes Navigatorをリリースし、2020年10月にはSplunk Observability Suiteと名付けて、次世代のオブザーバビリティプラットフォームを発表しました。

オブザーバビリティは今やセキュリティやIT運用に並んでSplunkのビジネスを支える大きな柱となりました。

では、Splunkのオブザーバビリティへの取り組みはどのようなものでしょうか？それについては次回以降の記事でご説明します。

関連ページ

Splunkが実現するクラウドネイティブ環境のオブザーバビリティ

「Splunk Observabirity Suite」紹介資料