高可用性システムの信頼性向上

U 社は，一般のインターネット利用者に動画配信サービス（以下，T サービスという）を 24 時間 365 日提供している。T サービスは，W 社のパブリッククラウドサービスを使った T システムによって実現されている。稼働環境と試験環境が存在し，稼働環境では高い可用性が求められている。T サービスは，現在 T1 から T5 の五つのマイクロサービス（以下，T1～T5 サービスという）で構成されている。

U 社情報システム部は，開発課と運用課で構成され，開発課は開発課長の下で T サービスの開発を，運用課は運用課長の下で T サービスの運用を担当している。情報システム部では，スクラムによるアジャイル開発を採用し，開発課と運用課が連携してリリースサイクルを短縮することを目的に DevOps を推進してきた。スクラム開発によってリリース頻度が高まる一方で，運用課の受入準備が追い付かないといった事象が度々発生するようになった。また，停止時間は僅かではあるがサービス停止の事象も何回か発生しており，システムの信頼性が確保された安定した運用が求められている。
そこで，情報システム部の X 部長は，SRE（Site Reliability Engineering）の考え方を取り入れ，開発から運用までのライフサイクルに関わり，稼働する T サービスの信頼性に責任をもつ組織を作る必要があると考えた。X 部長は，U 社の経営層から了承を得て，暫定的な SRE チーム（以下，S チームという）を作り，3 か月後に正式なサービス開始を予定している T サービスの一つのマイクロサービス（以下，T6 サービスという）を対象として，検証を行うことにした。検証期間の間，情報システム部は，開発課，運用課及び S チームの三つの組織構成とし，S チームは X 部長が直轄する。
T6 サービスは，今後も反復アプローチに基づいた開発が継続する状況にあり，開発課は機能追加の開発に専念する必要がある。X 部長は，チームの編成に当たって，開発課長及び運用課長と調整を行い，開発課と運用課から（ア）開発経験と運用経験をともに有する要員を S チームに参画させることにし，T6 サービスを含む T サービスに関する役割分担を表 1 に整理した。 サービスの信頼性には，スループットや可用性などが該当し，サービスの信頼性を示す指標には，SLI（Service Level Indicator：サービスレベル指標）と SLO（Service Level Objective：サービスレベル目標）がある。SLI は，信頼性の目標が守られているかどうかを評価するために使うサービスレベルの計測値のことである。SLO は，SLI で計測されるサービスレベルの目標値のことである。
S チームは，T6 サービスにおける SLI と SLO について検討を行った。その結果を表 2 に示す。ここで，稼働率は算出式に基づいて毎日算出することにし，対象期間は対象日を含む過去 30 日間とする。

また，S チームは，エラーバジェット（以下，EB という）の運用を採用することにした。EB とは，サービスの信頼性が一定程度損なわれても許容できる時間を示す指標のことであり，定期リリースや緊急リリースの展開に伴って発生する稼働停止の時間及びエラー対処に要した時間を EB から消費させていく運用を行う。T6 サービスの EB は SLO が未達状態とならないサービス停止時間の最大値とする。具体的には，SLO が表 2 の場合，対象日を含む過去 30 日間の対象期間の中で 15 分を EB の最大値とし，その範囲でのサービス停止を許容した上でサービスを運用する。
EB の消費がひっ迫した場合は，開発課と協議を行い，更なる信頼性低下のリスクを抑えるためにリリース作業と機能追加開発作業を凍結し，サービスの安定性を重視した信頼性回復のための作業を優先して行うことにする。EB の消費ひっ迫を EB が 3 分以下（EB を 12 分消費）となった場合と定め，信頼性回復作業は S チームと開発課が主体的に取り組む。S チームで検討した EB の運用ルール案を表 3 に示す。

S チームは，X 部長に運用ルール案を報告したところ，項番 2 について（イ）リリース作業の凍結については，例外規定を設けることを検討するように指示を受けた。
S チームは，検討した結果を X 部長に提案し，X 部長は提案内容を含めて運用ルール案を承認し，試行運用を開始するように S チームに指示した。

S チームは，4 月 1 日から EB の試行運用を開始した。T6 サービスは，2 月 1 日からサービス開始に向けた準備を進めて稼働環境で稼働しており，3 月はリリース作業などによるサービス停止の停止時間は発生していない。したがって，4 月 1 日開始時点での SLI の稼働率は，対象日を含む過去 30 日間のサービス稼働予定時間である 43,200 分から算出された 100％となり，EB は 15 分である。試行運用開始後の結果を表 4 に示す。ここで，EB は，次の計算式に基づいて計算される。

当日の EB ＝ 前日の EB － 当日の EB の消費 ＋ 当日の EB の回復

当日の EB の消費とは “当日発生したサービス停止時間のこと” であり，当日の EB の回復とは “過去に発生したサービス停止事象が対象日（当日）を含む過去 30 日間から外れたので，EB に追加する当該事象のサービス停止時間のこと” である。例えば，4 月 2 日の EB の計算では，前日の EB が 15 分，当日の EB の消費が 1 分，当日の EB の回復が 0 分であり，計算結果は 14 分となる。

また，S チームは，（ウ）4 月 26 日に信頼性回復のための改善活動を開始した。改善活動を開始するに当たって，S チームは，開発課と，EB の推移を示して議論を行い，T6 サービスの信頼性についての認識を合わせた。改善活動の候補を議論したところ，稼働環境へのリリース方法について，（エ）T6 サービスを停止することなくリリース作業が可能となる方式が実現できないかどうかの検討に取り組むことにした。

X 部長は，試行運用の振り返りと今後の本格運用に向けた改善点などについて，S チームにヒアリングを行ったところ，次の意見が出された。

• 開発課と b の実施判断について，EB を使って効果的な議論を行い，T6 サービスの信頼性低下のリスクを抑えることができた。
• 4 月 11 日は，“数名の利用者が，問合せリクエストへの応答がないので再度リクエスト入力したという報告” を受けた対策をしている。調査したところ，プログラムでエラーが発生していて，リクエストが失敗となっていた。稼働時間を基に算出する稼働率の SLI だけでは，十分でないように感じる。そこで，サービス利用客からの客観的な評価を反映したサービスの信頼性指標として “T6 サービスが受け付けた総リクエスト数に対する c の割合” を SLI に追加した方がよい。

X 部長は，今後の本格運用に向けて，改善計画を策定することにした。