2022年9月6日8:30
Google Cloud は、2022年8月29日にGoogleが提唱する「SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）」に関する記者説明会を開催した。当日は、Google Cloud ソリューションを採用し、SRE チームも発足したジェーシービー（JCB）がSRE の導入と実践の経験について紹介した。
運用は開発の10倍ほどのコストがかかることも
アジャイル開発、DevOpsによる取り組み
当日はまず、グーグル シニア デベロッパーリレーションズ エンジニア 山口能迪氏がSREの概要について紹介した。SREは、Webサイト、あるいは、サービスの信頼性をどのように確保しながら運用していくかという手法だ。山口氏は、「SREを一言で表すと本番システムを信頼性高く開発・運用するための一連のプラクティスと心構え、および職務を指す」とした。
ソフトウェア開発や設計において、実際に多くのコストがかかるのは、開発が終わった後、運用を行う段階だと言われる。実際、総コストの4～9割はローンチ後に発生している。開発の10倍ほどのコストがかかることもあるが、「この事実はあまり語られていません」（山口氏）。開発チームは新しい機能を開発後、次の機能の開発を進める。一方で運用チームは、渡された新機能を運用して、ソフトウェアのスケーラビリティや信頼性メンテナンスの責任を負っている。「開発チームはなるべく早く製品をリリースしようとする一方で、運用チームはリスクを減らすためにスピードを下げようとします。これでは、協調的な働きは難しく、脆い組織構造になりスケールもできません」（山口氏）。こういった開発と運用の壁を取り除くため、アジャイル開発、DevOpsによる取り組みが行われている。これは、グーグル社内でSREが提供されたと同時に広がっていて、世間一般では、開発、運用の間の緊張を緩和するための必要な方法だということで、広く知られていた。
DevOpsにはさまざまな定義があるが、「開発と運用の間のサイロをなくすための一連の実践やガイドライン」と山口氏は定義した。特に、5つの主要領域が重要であるとした。組織の壁は、協調と開発速度の低下をもたらすため、撤廃しなければならない。また、物事は失敗することが当然と認め、それを受け入れられる体制を構築する必要がある。さらに、変化が小さければ開発も少なくて済み、デプロイも簡単だ。また、切り戻しも容易となり、障害発生時も短時間で解消できる。加えて、人間によるミスを減らすため、自動化を活用する必要がある。さらに、継続することで改善や障害の変化を加えることができるとした。
システムを初めから信頼性が高くなるように設計
需要な概念となる「エラーバジェット」
SREを取り入れた運用では、意思決定にデータを使って、運用をソフトウェアリングの問題として扱うとした。そのため、ソフトウェア開発のスキルを持った人々が運用を自動化する必要がある。また、システムを事後ではなく、初めから信頼性が高くなるように設計していかなければならないとした。
つまり、SREは、大規模なシステムをスケーラブルに、信頼性高く、効率的に設計・構築・運用するためのソリューションを開拓する。さらに、人間、哲学とマインドセット、エンジニアリングのシステムのツールの全てが必要になってくる。
SREにはさまざまなプラクティスがあるが、その中で最も重要な概念として「エラーバジェット」があるとした。可用性を例にすると、信頼性を定義して計測したら、その目標値の設定が必要になる。たとえば、どれほどの障害時間を許容できるのかっていうその長さを定義した際、信頼性、可用性が90％でよいとする。10％の障害が発生すると1年間では36.5日となる。一方で99.99％にしてしまうと、年間で1時間を切る。1カ月の間にシステムが障害を計上できる時間は、4分32秒となり、障害発生から解決までの時間が5分も与えられていないため、これ全て手作業で行うのは難しい。
また、ハードダウンによりシステムが全く使えない場合の障害時間として、たとえばその可用性の信頼を99.95％に設定した場合、別の障害の1カ月の許容時間は、21.6分になる。これは、システムが1％の割合で、エラーを発生した場合には、その状態を36時間継続できる。そのため、さまざまな形で障害の許容時間を割り振り、システムを運用することが肝になるとした。実際、同社エンジニアリング VicePresidentのBenjamin Treynor Sloss氏は、「あらゆる場面において、信頼性100％は間違った目標設定」と指摘している。
信頼性の目標値は、実際のユーザーのニーズに合うだけの値を選択する。たとえば、ユーザーが許容できないほどの障害になっていないのが重要であるため、そのニーズに合う目標値を選択する必要がある。山口氏は「そのユーザーが許容できる障害の長さ、あるいはそのエラーの量というのがエラーバジェットになってきます」とした。どのくらいのエラーバジェットが残っているのかが分かれば、新しい機能のリリース、従来と違ったサービスのデプロイ方法の実験など、エラーが発生しうる新しい変更のために使うという選択肢が生まれてくる。これは非常に強力な概念であるとした。
SLI、SLO、SLAとは？
SREは全組織間での合意を得るためのプラクティス
なお、信頼性を継続するための指標として「SLI（サービスレベル指標）」、ユーザーが快適に過ごせるための信頼性の下限値となる「SLO（サービスレベル目標）」がある。中でもSLOは、エラーバジェットと表裏一体となる値だ。また、「SLA（サービスレベル合意）」はSLOよりも広く設定されており、万が一それに違反した場合には、たとえばクーポンを渡したり、返金するなど、保証を行うための合意まで含めたものとなる。まずは、極力シンプルなSLOの目標を設定することからはじめることが大事だとした。また、それに基づいて、運用しながら設定したSLOが厳しすぎるのか、緩すぎるのか。あるいは別の指標に基づいた目標値なのかを定期的に振り返りながら、調整していくことが大切だとした。
山口氏は「SLOは、ビジネス開発、運用など全ての組織における合意を得るための懸け橋となります。また、それをプラクティスとして添えるSREは、全組織間での合意を得るためのプラクティスであり、そのためのさまざまなプラクティスが存在しています」とした。たとえば、メトリクスと監視、キャパシティプランニング、チェンジマネージメント、緊急対応、文化などがあるとした。
SREにより信頼性を適切に設定して導入
顧客行動を考えて適切なSLAを定める
具体的な採用事例としてJCBの取り組みが紹介された。JCBでは、SREのプロジェクトが2年半前にはじまり、ジェーシービー システム本部 デジタルソリューション開発部 DXテックグループ 主査 笹野真平氏はそのタイミングでジョインした。JCBはブランドホルダー、カード募集・発行を行うイシュイング、加盟店募集の契約を行うアクワイアリングの3つの事業を中心に展開している。SREのプロジェクトは、既存のJCBとして管理しているシステムとは別の基盤を作り、各種ルールを新しく戦略的に、スモールスタートして始めている。
開発のプロセス、リスク管理、クラウドのプラットフォーム、マイクロサービスのアーキテクチャ、違ったツール群や端末のスペックをまとめて管理して、プロジェクトを推進している。
同社では、JCDP（JCB Digital Enablement Platform）を構築。Google CloudにGKE（Kubernetes）とAnthos Service Mesh （istio）をコアプロダクトとして構築した。JCBには、東京、大阪のリージョンがあり、可用性の高いサービスを開発・運用していくため、ダブルの構成とした。
チーム体制は30名で基盤となるプラットフォームとアプリで運用を始めたが、2022年8月現在は合計20チーム、350名を超えるような体制に拡大している。その背景として、 開発していくサービスが拡大している点が挙げられる。また、アプリチームがどんどん増えていくと、共通として支えていくメンバーが必要になってくる。そのため、QA、アーキテクチャ、セキュリティ、プラットフォームを見る体制を増やしている。
