ユーザーがWebサイトで体験した遅延をSplunk Observabilityで調査する
ここからは実際にオブザーバビリティで使う「Splunk Observability」を見ていく。複数の製品群から構成されており、オブザーバビリティのためのプラットフォームとなっている。
構成要素には次のようなものがある。APM（アプリケーションパフォーマンス監視）は何が起きているのか把握する。RUM（Real User Monitoring）はエンドユーザーエクスペリエンスを可視化する。Log Observerはログ分析、Infrastructure Monitoringはインフラのメトリクスを収集して可視化、Synthetic Monitoringは死活監視、さらにOn-Callはアラートを適切な担当者にアサインする。単体での利用も可能だ。
特徴としては、リアルタイム性、分析力、オープンであること。リアルタイム性は独自のストリーム技術を用いることで、数秒から十数秒で状況を把握できる。SLAの担保やスピーディーな問題解決に役立つ。分析力はサンプリングを必要とせず、環境に関する全てのデータを完全かつ忠実に計測・収集できる。
必要な時にデータがある状態を確保するため、未知の障害を分析するのに役立つ。オープンであることはベンダーロックインから解放され、データを取得する粒度や場所などを自由にデザインできる。大谷氏は「Splunk Observabilityにはクラウドネイティブ技術によってもたらされるスピードと自由度があります」と強調する。
ここからECサイトで生じたパフォーマンス劣化を調査するデモに移る。ユーザーが商品をカートに入れて「Place Order」をクリックして注文を確定した時、数秒の遅延が発生した。この時の動きをSplunk Observabilityでどう計測されるか見ていくことにする。
まずはRUMを開く。ここではコアバイタルズ（ユーザー体験のパフォーマンス計測に重要な項目）が収集されており、問題が生じているメトリクス（例えばリクエスト、エラー、デュレーション）は赤で表示される。見ると、チェックアウト時のページのロード時間が悪化している。あるユーザーが操作した時を見ると、5秒近く待ったケースもあった。
続いてAPMを開く。エラーと表示されている部分を開くと、外部のペイメントサービスとの接続で401エラーが返されており、5回エラーするもリトライで成功していたことが判明した。外部サービスとの連携ではどちらに問題があるのか判別するのが難しい。次にLog Observerでエラーが生じた時のログを確認すると「Invalid Token」とあった。ここまで分かると、現場では「新しいバージョンのアプリケーションに問題がありそうなので、いったん取り下げよう（元のバージョンに戻そう）」など判断を下すことができる。
今回は特定のボタンを押した後に生じた遅延だったので、RUMからAPM、そしてLog Observerを開いて原因を探った。問題がありそうな部分は赤く表示されるため、すぐに問題にたどり着くことができる。Splunk Observabilityではほぼリアルタイムで状況を把握できて、オーバーヘッドが少ないことも注目しておきたい。
最後に大谷氏はケント・ベック氏の言葉「問題というのは、変化が起こること自体ではなく、変化が起こった時にそれに対処できないことです」を挙げ、「問題が起きた時のために備えておきましょう」と呼びかけた。
