DevOpsやマイクロサービスの先に訪れる不安定さには、オブザーバビリティが欠かせない【デブサミ2021夏】

【C-2】DXを支えるオブザーバビリティの重要性

　2020年末に経済産業省が発表した、デジタルトランスフォーメーションの加速に向けた研究会の中間報告書『DXレポート2（中間取りまとめ）』では、「DXの本質」について言及されていた。それによると「単にレガシーなシステムを刷新する、高度化するといったことにとどまるのではなく、事業環境の変化へ迅速に適応する能力を身につけると同時に、その中で企業文化（固定概念）を変革（レガシー企業文化からの脱却）すること」とのこと。では実際、変化に適応するにはどうしたらいいのか。何が必要か。

Splunk Services Japan 合同会社 Senior Sales Engineer, Observability 大谷和紀氏

変化に対応するための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、4つの指標

　こうしてDevOpsを通じてデプロイ頻度を高めようとしていくと、マイクロサービスへと発展していく。マイクロサービスは「独立デプロイ可能性を確保する」とも言える。メリットは組織をスケールできてこと、担当範囲が小さくなるため理解が容易になること、インターフェースさえ守ればいいので技術選択の自由度が高まることが挙げられる。ただしシステム全体が不安定になるリスクもある。デメリットのコストを払うことでメリットを獲得できているため「マイクロサービスは選択肢を買い与える」と考えることもできる。

　今は変化に迅速に対応できること、より具体的にはDevOpsやマイクロサービスなどを通じてシステムを素早く刷新できる能力や文化を育てていくことが求められている。成功すればビジネスの推進力になるものの、複雑性や不安定さのリスクにも対峙していかなくてはならない。

オブザーバビリティはモニタリングとどう違うのか

　どうすればいいか。その答えとなるのが「オブザーバビリティ（可観測性）」だと大谷氏は言う。

　今やマイクロサービスでシステムは複雑に連携している。「サクサク動かない」とクレームが届いたとしても、何がボトルネックで遅延が生じているのか発見するのは簡単ではない。フロントエンドのJavaScriptかもしれないし、あるいはユーザー環境に起因する何か、経路のネットワークの問題、連携する外部サービス、データベースサーバーなど、可能性は多岐にわたる。

パフォーマンスのボトルネックはどこに？

　オブザーバビリティの話をする前にモニタリングとの違いを確認しておこう。大谷氏は次のように説明している。モニタリングは「おかしいと認識できる点を注視していくためのもの」であり、オブザーバビリティは「予期せぬ事象を発見し、なぜ起きたかを解明するためのもの」。

　例えば、CPU使用率が高まれば不具合が起きやすくなるなど、認識しているが理解していないものがモニタリング。一方、未知の現象から原因を解明するなど、認識も理解もしていないところで行うのがオブザーバビリティとなる。ちなみに認識も理解もできているのはQAやテストであり、認識していないが理解しているものは「これはきっとまずい」となぜか察知できる経験者の勘が該当する。

　例えば、まだ使ったことのないミドルウェアを導入するとしよう。ある程度、事前に調査や検証するものの「やってみないと、どこがボトルネックになるか分からない」こともある。こうした状況の時にオブザーバビリティのプラクティスが有効になる。

　オブザーバビリティで3本柱となるのが、メトリクス、トレース、ログ。メトリクスは何が起きているのかを検知するもので、SLIやKPIに関係する。トレースはどこで問題が起きているのかを対処してくためのもので、依存関係を見ていく。ログはなぜ問題が発生したのか根本原因を詳細に探る。