オブザーバビリティとは 第1回

クラウド活用推進担当として、オブザーバビリティを中心とした領域のサービス化を担当しています。

今回、「オブザーバビリティとは？」というテーマで、2回に分けてお話をさせていただこうと思います。

インフラエンジニアとして今まで従事してきましたが、オブザーバビリティと旧来のモニタリングとの違いも最初はわかっておらず、最初は「オブザーバビリティ」にとっつきにくさがありました。

そのため、プロフェッショナル向けの説明というよりは、「オブザーバビリティとは？」といった言葉もわからない人に向けて作成しました。
どうぞ宜しくお願いいたします。

DTSでは、2024年に「AWS DevOps導入支援サービス」を公式発表しました。

お客様のビジネススタイル、プロジェクト特性に合わせた開発・リリーススピードの向上と安心・安全を両立するサービス・ファクトリ環境の実現を支援するサービスとなり、お客様の要件をヒアリングしながら要件定義を行い、AWS DevOpsガイダンス（DevOps Guidance - DevOps Guidance (amazon.com)）に沿ったサービス・ファクトリの導入支援を行います。

この中に「オブザーバビリティ導入支援サービス」があり、そのサービスの構築に携わってきました。
その中で習得したオブザーバビリティに関する知見をこちらで共有していきたいと思います。

オブザーバビリティとは、という説明はあらゆるところに記載されていますが、システムの内部状態を外部から観察・理解できる能力のことです。
Observe「観測する」とAbility「能力」を組み合わせた複合語となります。

誰にでもわかりやすいよう「医療」に例えてみますと、「身体に問題を抱えた患者」がシステムであり、「診察、治療する医師」がエンジニアとなります。

医師は患者の状態が分からなければ病名の診断も具体的な治療もできません。
そのため、具体的な症状や原因を探るため、体温や心電図や血液検査、レントゲンなど様々な検査を行います。
これらの検査結果を基に医師は診断を行い、その後、適切な治療が出来るようになるのです。
これをシステムに置き換えたものが、オブザーバビリティとなります。

旧来の方法では身体に大きな症状が出てから原因を特定し、そこから治療を開始しますので、どうしても対応が後手後手となります。
それを新たな方法として、過去の知見やAIを基に事前に予防を行っていく、過去の傾向から自動的に問題箇所を特定し診察しやすくする、それがオブザーバビリティとなります。
「医療」を例にとってみましたが、伝わりましたでしょうか。

なお、英語でオブザーバビリティを表記すると「Observability」となりますが、最初の"O"と最後の"y"の間の11文字を略して、「O11y」と表記されることもあります。

「オブザーバビリティとは？」といったイメージを掴んでいただいたところで、次は「オブザーバビリティの必要性」についてとなります。

オブザーバビリティはなぜ必要なのでしょうか。
従来のモニタリングと比較しながら、オブザーバビリティが必要な理由を説明いたします。

まず、従来のモニタリングは、システムから出力されるログ等の情報からシステムの状態を把握し、異常を検知すればアラートを発砲して、システム管理者に通知するというものでした。
このような従来のやり方でインフラやアプリの状態をモニタリングするだけでは、クラウド・ネイティブ時代においては不十分であり、不測の事態に対して迅速に対応することができません。
また、現代的なITシステムでは「マイクロサービスアーキテクチャ」が採用されることが増えてきており、複雑化するシステムで発生する障害の原因を特定することはなかなか難しい現状です。

これらのような従来のモニタリングにおける課題に対応するため、オブザーバビリティ（可観測性）の導入が近年注目されてきました。
このオブザーバビリティの導入により、膨大な情報の中からシステムの状況を把握するためのデータを収集し、アプリの動作の可視化が可能となります。

また、従来の異常検知に加えて、異常の原因を突き止めて解決策を導き出す、事前検知して自動的に修復を行うなど、予期せず発生したトラブルに対して大きな効果をもたらすことでしょう。
更には、人的な対応が減り障害対応の時間が低減することで、顧客満足度とロイヤリティの向上に繋がります。

オブザーバビリティが求められる理由と近い部分がありますが、オブサーバビリティを導入するメリットにも触れたいと思います。
もちろん、メリットはこれだけに限りませんが、サービス化の対応を行ってきた中で実感したものとして４つのメリットを挙げました。

AWSでは、「AWS Observability Best Practices」を公開しており、オブザーバビリティの「基本概念」や「実装パターン」、「運用プラクティス」が記載されています。

そして、その中に「AWS オブザーバビリティ成熟度モデル」が紹介されており、企業のオブザーバビリティの能力を診断し、どの部分に改善が必要なのかを分析するための指針が示されています。
※ステージ１の「基本的なモニタリング テレメトリーデータの収集」からステージ４の「予測的オブザーバビリティ 自動かつ予測的な根本原因の特定」まで、段階的ロードマップとなっている。

また、このベストプラクティスにも「概要」や「メリット」や「ここで見つかるもの」といった内容で一から丁寧に説明があるため、成熟度モデルと合わせて全体的にまずは一読することを推奨します。
※私自身も長い期間に渡って繰り返し読んできました。
当初は頭に入ってこなかった内容も、経験していく中で新たに理解できたものもありました。

AWSにはセキュリティ成熟度モデルといった別の成熟度モデルがあり、AWS セキュリティ成熟度モデル評価ツールというものがAWSから提供されています。

このことからわかる通り、セキュリティの方がオブザーバビリティよりも歴史が古く、成熟度モデルとして充実した内容となっています。

セキュリティとは違い、オブザーバビリティ成熟度モデルは現時点で評価ツールは用意されていないため、企業のオブザーバビリティの能力の診断を行うためのチェックシートをDTS独自で作成しました。

オブザーバビリティのベストプラクティスと成熟度モデルに加え、AWSのDevOpsガイダンスで定義された内容をベースに診断項目を作成し、観点ごとの採点やステージ判定を行うことができます。

また、必ずしも次のステージを目指すことが正解ではありません。
お客様に合った形のロードマップを導き出すため、この診断チェックシートを使用していきます。

今回は「オブザーバビリティとは？」という概念的なところから、AWSの成熟度モデル、独自の診断チェックシートといったところをお話させていただきました。

今年の6月にはAWS Summitに参加して、オブザーバビリティのセッションに参加し刺激を受けました。
そういった刺激をよりこのオブザーバビリティ関連業務に活かしたいと思います。

次回は「オブザーバビリティとは？」の第2弾として、「具体的な導入方法」や「最適なツール選定」といったお話をさせていただきます。
皆さんのオブザーバビリティの理解向上に少しでも繋がれば幸いです。