サイトリライアビリティエンジニアリングとは、運用をソフトウェアの問題として扱ったときに得られるものだ。本番サービスの信頼性を自分たちのものとして担い、それをユーザー側から測定し、時間の少なくとも半分を、運用作業を手でこなすのではなく運用作業そのものを取り除くコードを書くことに使うエンジニアのチームである。SREは名前を変えただけのシステム管理者でも、ページャーを持たされたDevOpsエンジニアでもない。この役割には定義された責任範囲、定義された監視対象、そして開発者との定義された関係がある。この記事はその3つすべてを扱う。

これは Budget for Failure の第1回だ。サイトリライアビリティエンジニアリングとは何か、どう実践するかを扱う全4回のシリーズである。第1回と第2回は101レベル: 役割、そしてそれを動かす数字(SLI、SLO、SLA、エラーバジェット)。第3回と第4回は201レベル: SREがコードベースで使いこなすべきもの、そしてプロバイダー側で確認すべきこと。それがクラウドであれ自前のデータセンターであれ、だ。例はAWSだが、プラクティス自体はAWS固有のものではない。

この役割はどこから来たか

この用語はGoogleに由来する。Ben Treynor Slossが2003年に最初のチームを作り、後にSRE本で一行にまとめた。SREとは、ソフトウェアエンジニアに運用チームの設計を頼んだときに起きることだ、と。成長するサービスに対するそのエンジニアの答えは、トラフィックに比例してオペレーターを雇うことではなかった。オペレーターの仕事を自動化し、チームが受け入れてよい手作業の量に厳格な上限を設けることだった。

DevOpsとの関係は、これもGoogleの言葉だが、"class SRE implements interface DevOps" と要約されるのが常だ。DevOpsは原則の集合である。共有された責任、小さな変更、自動化、計測。SREはそれらの原則の具体的な実装のひとつで、意見が付いてくる。信頼性を正確にどう測るか、そして測定値がサービスは十分に信頼できないと告げたとき正確に何が起きるか、といった意見だ。

SREは何に責任を持つか

SRE本はその範囲を一文で列挙している。SREチームは、担当サービスの可用性、レイテンシ、パフォーマンス、効率、変更管理、監視、緊急対応、キャパシティプランニングに責任を持つ。これを実際の一週間で何を意味するかに展開すると:

  • 可用性とレイテンシ。 ユーザーにとって「動いている」とは何かを数字として定義し、測定し、守ること。第2回はまるごとこの話だ。
  • 変更管理。 障害の大半は変更が原因で起きる。SREは変更を安全にする仕組みを担う。段階的ロールアウト、自動ロールバック、そしてリリースが健全であることの証拠だ。
  • 監視とアラート。 どのシグナルが午前3時に人間を起こすに値し、どれがダッシュボードに置くべきものかを決めること。対応の必要がないページはアラートの欠陥であり、SREは他の欠陥と同じようにそれを修正する。
  • 緊急対応。 オンコールに就き、明確な指揮系統でインシデントを運営し、まずサービスを復旧させ、診断は後にすること。
  • ポストモーテム。 インシデントの後に、何が起きたか、どのシステム的な修正がその種類の障害を防ぐかを、書面で、非難なしに分析すること。非難なし(blameless)は技術的な要件だ。罰を予期する人は、自分が見たものを報告しなくなる。
  • キャパシティプランニング。 どれだけの余裕があり、需要がどう伸びていて、新しいキャパシティが届くまでどれだけかかるかを知ること。クラウドなら分単位、オンプレミスなら月単位だ。
  • 効率とパフォーマンス。 無制限の予備キャパシティで買った信頼性はエンジニアリングではない。リクエストあたりのコストもSREの数字だ。
  • トイルの排除。 後述する。残りすべてを可能にする部分だからだ。

SREは何を見るか

インフラ出身のDevOpsエンジニアはリソースを見がちだ。CPU、メモリ、ディスク、ノード数。SREは一段上の、ユーザーが体験したものから始め、リソースのメトリクスはそれを説明するためにだけ使う。標準的な出発点は、SRE本の監視の章にある4つのゴールデンシグナルだ:

シグナル答える問いAWSでの所在
レイテンシリクエストにどれだけ時間がかかるか、成功と失敗で分けてALB TargetResponseTimeのパーセンタイル、API GatewayのLatency、アプリケーショントレース
トラフィックシステムにどれだけの需要がかかっているかALB RequestCount、SQSの送信メッセージ数、Lambda Invocations
エラーリクエストのどれだけの割合が失敗しているかALB HTTPCode_Target_5XX_CountとHTTPCode_ELB_5XX_Count、Lambda Errors
飽和最も制約の厳しいリソースがどれだけ埋まっているかmax_connectionsに対するRDS接続数、キューの滞留時間、ECSのCPU予約、サービスクォータの使用量

これらをSRE流に読むことと漫然と読むことを分ける細部が2つある。レイテンシは分布として読み、決して平均では読まない。不満を抱えたユーザーがいるのは99パーセンタイルの側だ。そして飽和は、実際に最初に当たる上限に対して読む。それがCPUであることは稀だ。データベースの接続プール、NATゲートウェイのポート割り当て、アカウントレベルのLambda同時実行数、EBSボリュームのIOPS予算といったものだ。

4つのシグナルの先で、SREは来月のインシデントを予告するものを見る。変更の頻度と失敗率、パッチ未適用の最も古い依存関係の経過日数、先週のうちどれだけが手作業に費やされたか、オンコール担当者が受けたページの数だ。

50パーセントルールとトイル

SREを、肩書きだけ立派な運用チームと分けている特徴は、上限だ。Googleのモデルでは、SREは数四半期の平均で時間の少なくとも50パーセントをエンジニアリング作業に使う。残りは運用作業、つまりチケット、オンコール、手作業に充ててよい。

手作業の部分にはトイル(toil)という名前と、正確な定義がある。本番サービスの運用に結びついた作業のうち、手動で、反復的で、自動化可能で、戦術的で、永続的な価値を持たず、サービスの成長に比例して増える傾向のあるものだ。固まったワーカーの再起動、証明書の手動ローテーション、クォータ申請の承認、開発者のためのデータベースのコピー。ひとつひとつは小さい。合わせると、5人のチームが一切エンジニアリングをできなくなる理由になる。

この上限が、SREにノーと言う立場を与える。トイルがチームの時間の半分を超えたとき、取るべき対応は英雄的行為ではない。最大の発生源を自動化するか、運用負荷を減るまでそれを生み出しているチームに返すことだ。オンコールも同じ論理に従う。SRE本は持続可能な負荷をオンコールシフトあたりおよそ2件のインシデントとしている。各インシデントにはフォローアップとポストモーテムが必要で、一晩に5回ページされる人はどちらもやらないからだ。

SREは開発者をどう助けるか

この役割の最悪の形はゲートだ。開発者が壁越しにリリースを投げ、信頼性チームが通してよいかを決める。有用な形は、開発者を顧客として、信頼性をSREが彼らのために作るプロダクトとして扱う。具体的な形を4つ:

舗装された道(paved road)。 構造化ログ、メトリクス、トレーシング、ヘルスチェック、カナリアとロールバック付きのデプロイパイプライン、まともなアラームがすでに配線された状態で届くサービステンプレートだ。デフォルトを選んだ開発者は、ランブックを読まずに信頼できるサービスを手に入れる。これはSREチームが出荷するもののなかで最も価値が高い。

本番準備レビュー(production readiness review)。 新しいサービスが本物のトラフィックを受ける前に、SREが開発者と一緒に順に確認する。何に依存しているか、各依存先が遅くなったら何が起きるか、タイムアウトはいくつか、どうロールバックするか、誰がページされるか。設計のレビューであり、設計を変えられるだけ早い段階で行う。第3回で何を見るべきかを扱う。

エラーバジェット。 速く出荷して安全なときと減速すべきときを両側に告げる、事前に合意された共有の数字だ。リリースが「リスクが高すぎる」かどうかの議論を、ひとつの読み取り値で置き換える。第2回で組み立てる。

オンコールの共有。 自分のサービスのページャーを持つ開発者は、違うコードを書く。多くの組織では、サービスをまず開発者のローテーションで始め、信頼性の基準を満たしてからSREに移し、下回れば返す。SREの仕事は、良いアラートと良いランブックでそのローテーションを人間的なものにすることであって、上流の誰も痛みを感じないように自分が吸収することではない。

SREとDevOps: 仕事はどこが違うか

パイプライン、Terraform、Kubernetesを生業にしているなら、ツールの大半はそのまま持ち越せる。変わるのは、各ツールが答えている問いだ。

DevOpsエンジニアとしてのあなたはSREとしてのあなたはさらに
CI/CDパイプラインを構築するどの証拠がロールアウトを自動的に止めるかを決め、各リリースがどれだけの信頼性を消費したかを測る
CPU、メモリ、ディスクにアラームを設定するユーザーに見える症状でだけページし、リソースのメトリクスは診断用に取っておく
インフラをコードとしてプロビジョニングするその障害ドメイン、クォータ、そしてプロバイダーのコントロールプレーンが落ちたときに何が起きるかを知っている
インシデントを直すインシデントを運営し、ポストモーテムを書き、その種類の障害を取り除く修正を出荷する
頼まれればタスクを自動化するトイルを数字として追跡し、チームの時間の半分を超えることを拒む
アプリケーションコードは開発者の領分として扱うそれを読み、タイムアウトとリトライをレビューし、プルリクエストを送る

最後の行が、インフラエンジニアの多くが最も過小評価するものだ。サービスのコードを読めないSREは、障害を外側から観察することしかできない。信頼性は、ある関数が遅い依存先をどう扱うかで決まり、それはクラスターではなくリポジトリの中にある。

障害モードと注視すべきこと

改名。 SREという肩書きと同じチケットキューを与えられた運用チームは、何も変わっていない。トイルの上限とそれに伴う権限がなければエンジニアリングの時間はなく、肩書きは願望を表すだけだ。

門番。 リリースを承認する信頼性チームは、組織が迂回するボトルネックになる。影響力は舗装された道とデータから来るのであって、拒否権からではない。

英雄。 すべてのシステムを知り、すべての障害を直すひとりのエンジニアは、給料をもらっている単一障害点だ。「Samが20分で直した」で終わるインシデントに必要なのは拍手ではなくランブックだ。

数字のない信頼性。 「可能な限り信頼できるように」は計画も人員配置もできず、機能と天秤にかけることもできない。この記事のすべては、サービスがどれだけ信頼できるべきで、いま現在そうであるかを言えることに依存している。それがSLI、SLO、エラーバジェットという語彙であり、第2回の内容だ。

次に読む

AWS、クラウドアーキテクチャ、SREプラクティス、CI/CDパイプライン、Linuxなどのコンサルティングは、ercanermis.comからどうぞ。

参考資料