ニュース

グーグル・クラウドがシステム管理の方法論「サイト信頼性エンジニアリング」を解説

適切な信頼性の指標を設定・維持しているJCBの導入事例も紹介

 グーグル・クラウド・ジャパンは29日、Googleが提唱しているシステム管理とサービス運用の方法論であるSRE(Site Reliability Engineering:サイト信頼性エンジニアリング)について解説する記者説明会を開催した。

 さらに、Googleの支援のもとで2021年4月からSREチームを発足させてSREを実践しているクレジットカード会社の株式会社ジェーシービーが登壇し、取り組み内容を紹介した。

「信頼性の指標と目標値を定義し、測定し、定期的に調整していく」

 グーグル合同会社 シニア デベロッパーリレーションズ エンジニアの山口能迪氏は、SREを「Webサイトやサービスの信頼性をどのように確保しながら運用していくかの手法」と説明。一言でいうと「本番システムを信頼性高く開発・運用するための一連のプラクティスと心構え、および職務」だとした。

グーグル合同会社 シニア デベロッパーリレーションズ エンジニア 山口能迪氏
SREを一言でいうと

意思決定にデータを使い、運用をソフトウェアエンジニアリングの問題として扱う

 背景として山口氏は、ソフトウェアでコストがかかるのは、開発よりローンチして運用に入ってからだという研究を紹介した。「そのことは、運用だけに必要なコンポーネントが設計に入っていないことがある、ということからもわかる」と氏は言う。

 これは、開発と運用のインセンティブが一致していないことによると山口氏。開発担当は俊敏性を求め、運用部門は安定性を求める。これは、組織のサイロ化にもつながる。

 こうした開発と運用のサイロの壁を解決するものとしては、DevOpsも提唱されている。SREとDevOpsの関係について、山口氏は「DevOpsはチーム間のサイロの壁を取り除くための文化的なプラクティスであり、SREはDevOpsを実践するための具体的な方法とそのための職務を定義している」と述べた。

 SREを採用した運用では、意思決定にデータを使い、運用をソフトウェアエンジニアリングの問題として扱う。これは、ソフトウェア開発のスキルを持った人が運用を自動化することでもあり、システムを事後に改修するのではなく始めから信頼性が高くなるように設計することでもある。

 これをふまえ、山口氏は、SREチームの役割を「ソフトウェアを書いて、システムをスケールして、信頼性が高く効果的な形で設計する」と説明した。

ソフトウェアでコストがかかるのは、開発より、ローンチして運用に入ってから
開発者と運用担当者のインセンティブの不一致
開発と運用など組織のサイロ化
SREはDevOpsの概念の実装
SREを採用した運用
SREチームの役割

エラーバジェットにより開発と運用が合意する指標ができる

 続いて山口氏は「その中で最も重要な概念」として、エラーバジェットについて解説した。

 「重要なのは、信頼性の定義と、それを計測すること」と山口氏。信頼性の指標(SLI)としては、合計時間のうち快適に動作していた時間の割合を表す可用性が簡単だ。しかし、現代のサービスは複数のサーバーで稼働しているため、例えば一部のサーバーが落ちていた場合はどうするかなど判断が難しくなる。そこで、全体の操作数のうち良い操作の数として可用性を定義することもできる。いずれにしても計測することが重要となる。

1台の場合の信頼性の計測方法
複数台からなる場合の信頼性の計測方法

 信頼性の指標を定義したら、次に目標値(SLO)が重要になる。例えば可用性を99.99%にしてしまうと、非信頼性の許容範囲が年間で4.32分となり、対応を自動化しないと不可能であるなど、目標値にあわせてどういうシステムにするかが変わる。

 ここで山口氏はGoogleのBenjamin Treynor Sloss氏による「信頼性100%は間違った目標設定」という言葉を引用した。

非信頼性の許容範囲によってシステムも変わる
「信頼性100%は間違った目標設定」

 ここからエラーバジェット(非信頼性予算)の概念が出てくる。100%から可用性(ユーザーが許容できない障害の長さあるいは量)目標を引いた残りのことだ。モニタリングで実際の稼働時間を計測することで、どれぐらいエラーバジェットが残っているかがわかる。

 エラーバジェットが残っていれば、新しい機能のリリース、新しいデプロイ方法の実験など、安定性を損なう可能性のある新しいことができる。反対に、超えてしまったら安定性を重視する。「ユーザーから見た障害を測定することで、開発と運用が合意できる指標ができた」と山口氏は説明した。

 そのSLOの定義方法について、山口氏は、極力シンプルなSLOから始めて、運用しながら、設定したSLOが厳しすぎるのか、ゆるすぎるのか、あるいは別の指標(SLI)にもとづいた目標値が良いのか、など、定期的に振り返りを行いながら調整していくことになると説明した。

 そのほかSREにはさまざまなプラクティスがあり、例えば緊急対応において、どういう方法でエンジニアを呼び出すかのオンコールや、ポストモーテムの振り返りなどもあると山口氏は例を挙げた。

エラーバジェットとは
エラーバジェットの利点
SLOの定義と計測
その他のSREプラクティス

JCBのSREチームの設立と活動の事例を紹介

 JCBのSREチームとその活動については、株式会社ジェーシービー システム本部 デジタルソリューション開発部 DXテックグループ 主査の笹野真平氏が解説した。なお、こちらは文章のみでの紹介となる。

株式会社ジェーシービー システム本部 デジタルソリューション開発部 DXテックグループ 主査 笹野真平氏

社内に出島チームを作って新しいプラットフォームを開発運用

 背景としては、不確実性が高く、どのようなサービスが求められるか見極めるのが難しい時代であることから、スピードを高める必要があったという。

 そこで、既存のJCBの仕組みとは切り離されたゼロベースのところで新しいプラットフォームを開発。開発のプロセス、リスク管理、チーム体制、クラウドのプラットフォーム、マイクロサービスなどのアーキテクチャ、ツールなどを独自のもので進める出島方式で開発した。

 こうしてGCP上にできあがった新しいプラットフォームが、JDEP(JCB Digital Enablement Platform)だ。GKEによるKubernetesベースのプラットフォームで、信頼性確保のために東京リージョンと大阪リージョンで両現用運用されている。

 この組織は2年半前の発足当初は約30名だったものが、今では合計20チーム350名を超えるという。これは、サービスが横に増えていることと、共通に支えるメンバーも必要になっていることからだと笹野氏は説明した。

 組織は大きくアプリケーションチームとプラットフォームチームに分かれる。そして、プラットフォームチームが、基盤の払い出しやネットワーク管理などの「commonPF(platform)」、開発の申請フロー、自動化やツールの導入管理などの「SysAdmin」、新技術の検討などの「Architecture」、そして「SRE」の4チームに分かれる。なお、笹野氏はSREとSysAdminのプロダクトオーナーを務める。

SLI/SLOをビジネス部門とシステム部門の合同で策定

 SREを導入した理由については、適切な信頼性を設定できるようにすることと、その適切な信頼性を提供することで顧客の満足度を維持することの2つを笹野氏は挙げた。

 まず、適切な信頼性の設定。「障害は起こしてはいけないが、SLA/SLOをひたすら高くすることを前提にするのではなく、本当に必要なお客さまの行動を考えて設定する」という考えから、ビジネス部門とシステム部門がいっしょになってSLI/SLOを策定した。さらにダッシュボードで見える化して、ビジネス部門とシステム部門の両方で確認できるようにした。

 笹野氏は、現在できるようになったこととして、そもそもSREの考え方について、Googleの協力を得てワークショップなども開催し、理解をはかったことを挙げた。また、SLI/SLOの策定や、見える化なども挙げた。

 今後については、SLI/SLO策定についてGoogleの支援なしに自分たちでやりきれるようにするのが課題だという。これについてはノウハウがたまることが重要で、例えばAPIについてはノウハウがたまってきたが、バッチについてはまだだと笹野氏は語った。

SREをアプリに近いチームと全体のルールを作成するチームに分ける

 続いて、適切な信頼性の提供。JCBでの取り組みの内容を笹野氏は紹介した。

 まず取り組んだことは、ポリシーの策定。インシデントが発生したときに即時に動けるように、どうするかのあいまいさをなくすために、ポリシーとして明確化した。これについては、Googleの提唱するやりかたに加えて、人数の少なさなどJCBの事情にあわせて、泥臭いところも含めてアレンジしたという。

 SREチームとしては、各アプリに近いところでSRE業務を支援・注入する「Diplomat」と、その背後で全体のルール作成・運用を規定する「Sheriff」の2チームに分ける体制をとっているという。以前は1チームだったが、アプリチームの対応に時間がとられ、横串のタスクにリソースが足りなくなったことから、2チームに分けたと笹野氏は説明した。

 より具体的には、Sheriffは、リリース方式策定・導入や、障害訓練の企画・遂行、ワークロードの脆弱性検知などを担当。一方のDiplomatは、ダッシュボード構築や、SLI/SLOの管理・更新、CI/CD設計・構築などを担当する。

各チームへのSREの注入などが今後の課題

 笹野氏は、現在できるようになったこととして、ポリシーをふまえたSREチーム運用や、アプリチームへのフォロー体制の構築、障害訓練実施、Playbook(手順書)の拡充を挙げた。

 今後については、人が少ないオンコール体制の拡充や、各チームがSREの考え方を持つよう各チームへのSREの注入、高度なスキルセットが求められるSREの教育カリキュラム拡充を挙げた。

 最後に笹野氏は、SREの導入を通じた変化を紹介。現実的なSLAを前提とした信頼性の策定や、インシデント発生時の初動対応時間の短縮、週次(チームによっては日次)でのSLO確認プロセスの定着化を挙げた。