変化に対応するためのDevOps 3つのステップと4つの指標
ITの世界で変化に適応する能力に関わる概念として、Splunk Services Japan 大谷 和紀氏はDevOpsを挙げた。大ざっぱに言えば、DevOpsとは開発担当者と運用担当者が連携して「いい感じ」に成果を出すということ。『Effective DevOps』によると「DevOpsはものの考え方であり、仕事の進め方である」とある。
「具体的なプロセスやプラクティスがあるわけではないため、そこが面白いところであり、難しいところです」と大谷氏と言う。とはいえ暗中模索では進まない。いいガイドとして大谷氏が挙げるのがIT REVOLUTIONに掲載されたブログ記事「The Three Ways: The Principles Underpinning DevOps」、ジーン・キム氏がまとめたDevOpsを進めていくための3ステップだ。
最初のステップは「業務の流れ／システム全体を考慮する」。特定のワークやパフォーマンスだけではなく、システム全体に目を向けて判断することを心がけること。例えば、既知の欠陥を下流に流さない、局所的な最適化のために全体で劣化をおこさないなど、全体を俯瞰して判断し「システムの深い理解を常に追求する」ことがポイントだ。
次のステップは「フィードバックループを強化する」。OpsからDevへのフィードバックを作るだけではなく、ループをより短く、より増幅して必要な調整を継続的に行えるようにする。
最後のステップは「文化を根付かせる」。DevOpsで重要な「継続的な実験、リスクを取る、失敗から学ぶこと」と「反復と練習が習得の前提だと理解すること」の2つを育む文化を定着するようにする。例えばリスクを取ったことで失敗したとしても、失敗を発見できたことで「チームが報われた」とポジティブに受けとめる文化や儀式を作っていく。さらなる先に進むとレジリエンスを高めるためにシステムに意図的に欠陥を発生させることもある。
また、DevOpsを評価するための指標は4つある。それがデプロイ頻度、変更のリードタイム（例えばGitHubにプルリクがマージされてから実際にユーザーが使えるようになるまで）、サービス復元時間（問題が発覚してから解消されるまで）、変更失敗率（デプロイに不具合があり修正した割合）。事業で成功している企業はこれらの指標がハイパフォーマーになるという。DevOpsがうまくいくほど、事業も成功していくわけだ。
こうしてDevOpsを通じてデプロイ頻度を高めようとしていくと、マイクロサービスへと発展していく。マイクロサービスは「独立デプロイ可能性を確保する」とも言える。メリットは組織をスケールできてこと、担当範囲が小さくなるため理解が容易になること、インターフェースさえ守ればいいので技術選択の自由度が高まることが挙げられる。ただしシステム全体が不安定になるリスクもある。デメリットのコストを払うことでメリットを獲得できているため「マイクロサービスは選択肢を買い与える」と考えることもできる。
今は変化に迅速に対応できること、より具体的にはDevOpsやマイクロサービスなどを通じてシステムを素早く刷新できる能力や文化を育てていくことが求められている。成功すればビジネスの推進力になるものの、複雑性や不安定さのリスクにも対峙していかなくてはならない。
オブザーバビリティはモニタリングとどう違うのか
どうすればいいか。その答えとなるのが「オブザーバビリティ（可観測性）」だと大谷氏は言う。
今やマイクロサービスでシステムは複雑に連携している。「サクサク動かない」とクレームが届いたとしても、何がボトルネックで遅延が生じているのか発見するのは簡単ではない。フロントエンドのJavaScriptかもしれないし、あるいはユーザー環境に起因する何か、経路のネットワークの問題、連携する外部サービス、データベースサーバーなど、可能性は多岐にわたる。
オブザーバビリティの話をする前にモニタリングとの違いを確認しておこう。大谷氏は次のように説明している。モニタリングは「おかしいと認識できる点を注視していくためのもの」であり、オブザーバビリティは「予期せぬ事象を発見し、なぜ起きたかを解明するためのもの」。
例えば、CPU使用率が高まれば不具合が起きやすくなるなど、認識しているが理解していないものがモニタリング。一方、未知の現象から原因を解明するなど、認識も理解もしていないところで行うのがオブザーバビリティとなる。ちなみに認識も理解もできているのはQAやテストであり、認識していないが理解しているものは「これはきっとまずい」となぜか察知できる経験者の勘が該当する。
例えば、まだ使ったことのないミドルウェアを導入するとしよう。ある程度、事前に調査や検証するものの「やってみないと、どこがボトルネックになるか分からない」こともある。こうした状況の時にオブザーバビリティのプラクティスが有効になる。
オブザーバビリティで3本柱となるのが、メトリクス、トレース、ログ。メトリクスは何が起きているのかを検知するもので、SLIやKPIに関係する。トレースはどこで問題が起きているのかを対処してくためのもので、依存関係を見ていく。ログはなぜ問題が発生したのか根本原因を詳細に探る。
ユーザーが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ではほぼリアルタイムで状況を把握できて、オーバーヘッドが少ないことも注目しておきたい。
最後に大谷氏はケント・ベック氏の言葉「問題というのは、変化が起こること自体ではなく、変化が起こった時にそれに対処できないことです」を挙げ、「問題が起きた時のために備えておきましょう」と呼びかけた。
