オブザーバビリティを高めるための5つのステップ
オブザーバビリティ（可観測性）の定義はさまざまだが、ITシステムやSRE（サイト信頼性エンジニアリング）のコンテキストでは、監視やログ収集、メトリクスなどを通じてシステムトラブル時に素早く原因特定、対応できるよう、安定稼働に必要な情報を常時収集することを指す。
「従来のモニタリングは稼働状況の指標でしかなかったが、これだけでは足りない。たとえばサーバーのCPU使用率が95％になってエラーが発生、アラート通知が管理者に届いたが、10分後にチェックしにいったらCPU使用率は20％に落ち着いていた場合、エラーログがなければ何が起きたか分からず、改善もできない」
New Relicの大谷和紀氏は、今後はオブザーバビリティを徐々に高めながら、受け身から攻めの運用監視に転じてビジネス価値を創出していく流れにあると説明する。
では、どうすればオブザーバビリティを高めることができるのか。大谷氏は講演で同社が提唱するオブザーバビリティ成熟モデルを紹介し、各ステップを紐解いた。
最初のステップは、計測を始めることだ。計測とは、正常に動作しているかどうかを判断するための材料を収集すること。オブザーバビリティを高める上での基本となる。
大谷氏は「オブザーバビリティの4つの柱」として、メトリック、イベント、ログ、トレースを挙げた。メトリックは、エラー率や遅延など、時間で区切ってグループ化された測定値の集合を指す。イベントは、サーバーがリクエストを受け付けたときにエラーが起こったといった、ある瞬間に発生する個別のアクションのこと。ログは、特定のコードブロックが実行されたときにシステムが生成する、シンプルなテキスト行。そしてトレースは、異なるコンポーネント間における一連のトランザクションの因果連鎖だ。この4つを基軸に、計測を開始する。
続くステップは、受動的対応を導入することだ。「アラート対応をちゃんとやろうという話」と簡潔にまとめた大谷氏は、「アラートが頻発するような状況であれば、まずはアラート対応をしっかりして、事態を収拾しなければ次に進めない」と指摘。サービス停止率や障害発生率、平均復旧時間（MTTR）を検証しながら、改善を繰り返すのがこの段階だ。
受動的対応に慣れてきたら、次は積極的対応にステップアップする。ここでは、不安定さをなくしてパフォーマンスを改善、サービスレベルを策定し、ユーザー体験の定義と計測を実施する。
具体例として、大谷氏はWebトランザクション時間のグラフを表示した。そのシステムのパフォーマンスは平均200ミリ秒で、グラフには2回のピークが発生。1回目は300ミリ秒弱、2回目は1000ミリ秒に達するピークとなった。では、どちらが問題か。大谷氏は「1回目の挙動は障害とはならないが、予測不能な、不安定な挙動。コントロールしづらいだけに、先回りしてできることをやって潰したい」と述べた。
パフォーマンスの改善には、求められるレスポンスタイムや可用性などサービスレベルを決めることが重要だ。また、どのようなユーザー体験を提供したいのかを考えることも必要だ。たとえば、ショッピングサイトで商品一覧ページが表示されるまでどれくらいの時間がかかるのか、何ミリ秒だとユーザーは離脱してしまうのかなどを計測データで見極め、改善していく。これをうまくライフサイクルに当てはめて回していくことが、積極的対応の成功の秘訣と大谷氏は言う。
不安定な挙動をコントロール下に置き、データ駆動でビジネス指標を向上
4つめは、予測的対応だ。この段階に到達する頃には、サービスが安定稼働しており、基軸が明確化し、改善のライフサイクルが回り始めているはずだ。ここでようやく、コスト削減に手を付ける。
「不安定な挙動があると、リソース計画やスケーリングの目処が立てづらい。結果、安全側に倒して3倍くらいのリソースを確保することになるだろう。だが、こうした挙動をコントロールできれば、リソースはその半分でも大丈夫という予測を立てることができるようになる。ちょうどよいスケーリングを見つけられるということだ」（大谷氏）
また、「避難訓練」を実施するのもこのステップだ。サービスレベル目標（SLO）で可用性を99％確保したいとした場合、エラーバジェットは1％になる。このエラーバジェットを使って行うのが避難訓練だ。
訓練は、本番環境で実施する。どこかのプロセスを止めたり、ネットワークを遮断したり、設定を変えたりして異常を発生させる。これを検知し、アラート通知が上がって対応、十分なサービスレベルを維持できるかを検証する。
「本当に本番環境で訓練するのかとよく聞かれるが、サービスレベルを定義していれば問題がないはず。障害時の対策を整備したら、実際に落としてみて確認する。うまくいかなかったら、修正すればいい」。そもそも訓練なので、深夜に突然発生するようなシナリオではなく、コントロールできる時間帯に実施できるから問題ないと大谷氏は笑う。
こうしたリスクある行動がとれるようになれば、実験的なデプロイも実施しやすくなる。どのタイミングでテストを実施するのか、本番環境に移行してから様子見するので問題ないかなど、デプロイのプロセスの幅ができる。
「実験的デプロイをどんどん試せるようになると、デプロイ頻度も上がる。成長企業の方がデプロイ頻度は高いという調査結果がある。いろいろ試せる環境があることで、機動性をもってビジネスの方向修正ができ、成功をつかみやすいということかもしれない。これはDevOps界隈でいま最も熱いトピックだ」（大谷氏）
最後のステップはデータ駆動。オブザーバビリティで得られるデータに基づき、ビジネス指標や顧客満足度の改善、向上につなげるのがこのステップだ。バグの修正や新機能の追加など、デプロイに期待される効果を正しく評価する、ネットスコアなどの中長期的改善で顧客満足度を向上させるなどが挙げられる。
ツールだけでなく文化も育てよう
New Relicは、クラウドベースの可観測性プラットフォームを提供している。クラウド上のデータベース「NRDB」を中心に、アプリケーションモニタリングを提供する「APM」、ブラウザやアプリケーションをモニタリングする製品群、外形監視サービスの「Synthetics」、ポータルの「New Relic ONE」でデジタルビジネスの監視および改善を支援する。国内では、SansanやGA technologies、VOYAGE GROUPのZucksなどが導入している。
大谷氏は、APMのポータルから遅延や外部通信の状況が可視化される様子をデモで紹介。どのアプリケーションで、どんなメソッドが何回動作し、どれくらいの時間がかかっているかなど、掘り下げてデータを参照できることを見せた。
だが、こうしたツールがあれば最終ステップのデータ駆動へとひとっ飛びに進み、パフォーマンスが改善されるわけではないと大谷氏は警告する。
「ツールだけでパフォーマンスが上がるということはない。だけど、ツールを変えれば運用は変わる。ある人によれば、運用が変われば文化が変わるという。その新しい文化が自社プロダクトを育てることになる。こうした改善を今後も支援していきたい」（大谷氏）
お問い合わせ
New Relic株式会社
