オブザーバビリティ実現のベストプラクティス

近年、「オブザーバビリティ」という単語をITシステムの運用やセキュリティの文脈で目にする機会が増えてきた。

オブザーバビリティとは、英語で「Observability」と表記され、「Observe(観察する)」＋「ability(能力)」という2つの単語を組み合わせた言葉であり、日本語では「可観測性」と訳される。

本稿では、オブザーバビリティとは何か、オブザーバビリティを備えたシステムを実現するために収集するデータとは、という視点で概要を把握してもらった後、オブザーバビリティ実現のためのベストプラクティスについて述べる。

ITシステムのモダナイズによって注目集まる

オブザーバビリティでは、モニタリングでの監視項目に加えて、追加のデータを集めて、システム全体を可視化し、観察することを目指す。

システム全体を観察することで、通常と違う動きを「予兆」として捉え、「障害発生時」ではなく「障害が発生する前」に適切な対応を行うことを可能とする。

リソースが不足しているのか、純粋にアプリケーションへのアクセスが集中しているのか、アカウントが想定と異なる挙動をしていないかなどを観察し、運用面・セキュリティ面の両軸でシステムを観察できるようにする。

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

オブザーバビリティが注目されるようになった背景を把握するためには、ITシステムの構成要素の変遷について理解する必要がある。

1つ目の変化は、物理的な配置場所の変化である。従来のITシステムは、1つのデータセンターに配置されたサーバ上で稼働しているアプリケーションを、インターネットを通して、オフィスから利用する、というものであった。

近年のITシステムは、クラウドの利用が進んだことで、アプリケーションを多様なロケーションに配置することが可能となった。パブリッククラウドのIaaS(Infrastructure as a Service)やSaaS(Software as a Service)、プライベートクラウドなど、アプリケーションの特性に合わせた適切な配置が可能だ。

2つ目の変化は、アプリケーション開発手法の変化である。従来のアプリケーションは、複数の機能が密接に絡み合った1つのソフトウェアを作成し、1つのサーバ上で動作させていた。一方、近年では、機能単位で分割した複数のソフトウェアをまとめて1つのアプリケーションとする方法が出てきた。

機能単位で分割された小さいソフトウェアはいろいろな場所で動作させることができる。自社のプライベートクラウドにあるコンテナ上で動作させたソフトウェアと、他社がインターネット上に提供しているソフトウェアをAPI(Application Programming Interface)で連携させて1つのアプリケーションとして提供する、といったことも可能である。そうした開発手法は、アプリケーションの開発速度を上げるために生まれた技術である。

3つ目の変化は、責任分界点の複雑化である。自社のデータセンターにある自社のサーバでアプリケーションを動作させているときは、アプリケーションの挙動が通常と異なる場合、責任をもって修正するのは自社であることは明確であった。一方、クラウド上でアプリケーションを動作させ、他社提供のアプリケーションとAPIで連携させている場合、社外の対応者である可能性がある。

1つのサーバ上にある1つのアプリケーションが正しく動いているかどうかを確認するためには、サーバの電源が入っているか、サーバにアクセスするためのネットワーク経路に問題はないか、データベースに空き容量があるかなど、事前に決められたポイントをモニタリング(監視)しておくことで障害に気づくことができた。

モニタリングは、「今」システムが正しく動いているかを確認することであり、「障害発生時」に問題が発生したという事実を通知することに主眼が置かれている。

しかし、複数の場所に展開された、複数のソフトウェア群から構成されたアプリケーションが正しく動いているかどうかを確認するにはどうすればよいだろう。従来の方法では不足していることは明らかである。そこで、オブザーバビリティという考え方が注目されはじめた。

ログ・トレース・メトリクスを紐づけて時系列で把握

ITシステムのオブザーバビリティを実現するためには、「ログ」「トレース」「メトリクス」の3つデータの収集が求められる。

ログとは、サーバやミドルウェア、アプリケーションなど、各コンポーネントで何が発生しているのかを示すものである。発生日時と、発生した事象がわかるようになっており、インフラストラクチャーログ、システムログ、アプリケーションログ、監査ログ、セキュリティログなどがある。

これらのログを収集することで、「アプリケーション内部で何が起こっているのか」「セキュリティに関連する何らかの事象が発生しているのか」などを知ることができるため、事象の根本原因を分析するときに利用できる。例えば、Webサイトで本を購入するサービスがあった場合、ログには「2022/11/30 13:00 本を購入するボタンが押された」と記録される。

トレースとは、アプリケーションに何らかのリクエストが行われてから完了するまでのすべての処理を紐づけて示すものである。1つのリクエストを完了させるために複数のAPIを利用している場合、どの順番でどのAPIが呼び出され、各APIの処理時間がどの程度であったのかを把握できる。

例えば、Webサイトで本を購入するサービスの場合、本を購入するためのボタンが押されてから、入力されたクレジットカード情報が正しいことを確認し、本を発送するための連絡をする、といった一連の動きが記録される。

メトリクスとは、一定期間の間に発生したデータを集計したものである。代表的な集計方法として、最小、最大、平均、合計などが挙げられる。モニタリングで取得したデータや、ログ、トレースで取得したデータをもとに集計を行う。例えば、Webサイトで本を購入するサービスがあった場合、2022年11月に購入された本の合計、値段の平均値などが記録される。

ログ・トレース・メトリクスを紐づけることで、ITシステムの動きを時系列で把握し、関連イベントを一度に確認することができるようになる。また、よく利用するメトリクスやログなどはレポートとして定義し、素早くアクセスできるように準備する。

結果として、システム運用者やアプリケーション開発者が何らかの調査を実施したいとなった場合に、迅速にシステムの状態を把握し、システム障害の予兆やセキュリティインシデントの予兆に気づくことができるようになる。

スモールスタートで開始し、データを取捨選択

実際にオブザーバビリティを実現するとなった場合、自社内に展開済みの既存の監視システムに加えて、SaaSサービスの利用や、専用のソフトウェアの導入を検討することになる。その際、以下の点を意識するとよい。

• プロジェクトはスモールスタートから徐々に範囲を拡大する
• すべてのデータを集めず、目的に即したデータの収集を行う
• 継続してメトリクス・レポートの改善活動を行う

最初から「自社内の全てのITシステムを把握し可視化する」という大きな目的を立ててしまうと、検討するべき項目が多すぎて、効果を体感できる前に計画が頓挫してしまう。小さい範囲から始めて、順次、対象範囲を拡大するとよい。

例えば、最初の一歩として、ネットワークの可視化や、IaaSの正常性の確認など狭い範囲に限って導入を検討する、などが挙げられる。

次に、どの機器、どのアプリケーションからデータを集めてくるのか、必要なデータはどれかの検討が必要となる。この時に重要となるのは、「目的の達成に必要なデータを収集する」という意識を常に持つことだ。

関連機器、アプリのすべてのデータを集めておけば何かの役に立つのでは、という考えでデータを収集するのは好ましくない。データの保管や分析にはコストがかかるためである。

最後に、オブザーバビリティとは一度導入したら終わるものではない。メトリクスに設定した値を見直したり、可視性を高めるためのレポートを導入したり、レポート項目を追加、削除する、といった作業が必要になる。

連携先システムの追加・削除や、アプリケーションの追加・削除により可視化すべき範囲は常に変更される。ITシステムの可視性を担保するためには、継続した改善活動が必須となる。