希望は戦略ではない：サイト信頼性エンジニアリング（SRE）の7原則

サイト信頼性エンジニアリング（SRE）とは、運用上の課題をソフトウェア上の課題として扱うアプローチです。この概念は、Google社のエンジニアであるBen Treynor Sloss氏によって2003年に名付けられ、定義されました。SREという専門分野は、特定のシステムの可用性、パフォーマンス、効率性を維持することを目的としています。

SREを正確に定義するのは容易ではありません。SREは、具体的なタスクを規定するものではなくアプローチや専門分野であり、組織ごとのニーズに応じてさまざまな形を取ります。幸いなことに、サイト信頼性エンジニアリングには7つの原則があり、SREチームを成功へ導く指針となります。

ソフトウェア開発の多くは創造に重点が置かれており、関連分野ではあるものの異なる領域であるDevOpsもその一例です。DevOpsは、製品のライフサイクル全体により強く関心を持っています。しかし、システムが稼働を開始しても、作業が完了するわけではありません。Google社が提供しているSREガイドの序文では、著者らが「システムの総コストの40〜90％は稼働開始後に発生する」と指摘しています。SREは稼働開始後に起こる事象を対象とし、製品が可能な限り使いやすい状態を維持できるようにすることを目的としています。

SREで最も重要な要素は、システムの信頼性と稼働時間です。世界最高のサービスであっても、稼働していなければ何の役にも立ちません。そのためSREは、ダウンタイムを最小限に抑え、信頼性の高いシステムを構築することに重点を置いています。

SREチームは、ソフトウェアやセキュリティーの更新を適切に管理することで、製品のすべての要素が最新の状態に保たれていることも保証します。標準や規制は変化する可能性があるため、エンジニアリング・チームは継続的なコンプライアンスを確保します。

SREの実践は、コスト削減にもつながります。SREの中核となる原則の多くは効率性に関わるものであり、自動化やリソース管理を通じて、コストや労力の大幅な削減につながります。

サイト信頼性エンジニアリングの7つの原則は次のとおりです。    

• リスクの受け入れ
• サービス・レベル目標
• 反復作業の排除
• モニタリング
• 自動化
• リリース・エンジニアリング
• 簡易性

SREはダウンタイムの管理と抑制を重視していますが、それはサービスの信頼性を完全に100％維持することを目標としているわけではありません。実際、SREの重要な柱の1つは、100％の信頼性は現実的でないだけでなく、必ずしも望ましい結果ではないという考え方です。

SREにおいてリスクは連続的なものとして捉えられており、信頼性が100％に近づくにつれてリスク低減は指数関数的に難しく、コストも増大します。信頼性を80％から99％に高めるよりも、99.99％から99.999％に高める方がはるかに困難です。100％に近づけるために必要となるリソースは、開発チームが新機能やアップデートの開発といった他の作業を行う能力を削いでしまいます。ですから、それを行う代わりに、チームは適切な失敗の許容範囲を示す「エラー・バジェット」を設定します。

直感に反するようですが、完全な信頼性を追求しないもう1つの理由は、ある一定の閾値を超えると、顧客は信頼性の向上に気付かないことが多いという点です。それはコストがかかるだけでなく、得られる成果もほとんどありません。理想的には、目標を設定し、それを達成することが重要であり、目標を大幅に超える必要はありません。

その代わりにSREでは、可用性のメトリクスを用いてダウンタイムのリスクが許容範囲内かどうかを測定します。あるメトリクスによれば、信頼性99.99％の1年間には52.6分のダウンタイムが含まれることになります。より複雑なメトリクスでは、サービスの一部や特定の場所でダウンタイムが発生しても、他の部分は稼働している可能性が考慮されます。

SREチームは各サービスを評価し、受け入れ可能な信頼性の欠如レベルを判断しなければなりません。どの程度のダウンタイムなら許容できますか。異なる根本原因に起因する障害の種類が異なると、ユーザー・エクスペリエンスに影響が及びますか。それを超えるには、労力とコストの両面でどのくらいの負担がかかるのでしょうか。その均衡はどこにあるのでしょうか。

目標を設定し、その目標がどの程度達成されているか、またその理由を測定することは、SREチームにとって不可欠です。サービス・レベル目標（SLO）とは、SREチームが目標として設定する品質レベルを表す、具体的かつ測定可能なターゲットのことです。これらのSLOはさまざまなメトリクスがありますが、一般的には可用性、クエリー率、エラー率、応答時間などがあります。

これらの目標は、レイテンシーのようなパフォーマンスの生データを測定するサービス・レベル・メトリクス（SLI）によって評価されます。この場合、SLIはレイテンシーのメトリクスを指し、SLOはそのメトリクスを特定の閾値以下に維持することを目標とします。SLOはサービス・レベル契約（SLA）の一部となることもあり、SLAはプロバイダーと利用者の間で締結される契約で、SLOと、それを満たせなかった場合の対応内容を定めています。

SLOを選定するのは簡単ではありません。理想的には、SLOはユーザーにとって最も重要な点を中心に構築されるべきです。例えばクラウド・ゲーミング・サービスでは、SLOは低レイテンシーを中心に設定されるかもしれませんが、会計サービスではレイテンシーはそれほど重要ではありません。

理想的には、サイト信頼性エンジニアは比較的少数のSLOに絞り込み、それらの目標達成に集中します。最も重要なのは主要なタスクを正しく実行することです。現実的な目標を設定することも重要です。前述のとおり、完璧さは現実的でも望ましい目標でもありません。

SREの提唱者たちは、「反復作業」を仕事と重なる部分はあるものの同じではない労働のカテゴリーとして定義することを重視しています。反復作業とは、規模に比例して増加する手作業であり、典型的には手動かつ繰り返し行われるタスクで、自動化によって実行可能なものを指すことがよくあります。

繰り返し行わなければならない作業は反復作業として分類されます。望ましくは、個々の作業は1回から2回程度の手順確認だけで済むべきです。製品を改善しない作業も反復作業に含まれます。「タスクを終えた後にサービスが同じ状態のままであれば、そのタスクはおそらく反復作業です」と、GoogleのVivek Rau氏は記しています。バグ修正や機能改善、最適化は反復作業には含まれませんが、メトリクスを手動でダウンロードする作業は反復作業にあたります。エンジニアや運用チーム間での大規模な調整を伴うこともあるインシデント対応は反復作業には含まれません。インシデント管理ポリシーはリリース前に計画しておくべきです。

認知的反復作業も存在します。時々使う基本的なレシピがあるのに、そのたびに材料や分量を調べ直さなければならないことはありませんか。それが認知的反復作業です。何度も学び直さなければならないのは、時間と労力の無駄になります。その代わりに、SREはガイドや標準を整備することを推奨しています。これにより、手法や作業を繰り返し覚え直したり学び直したりする必要がなくなります。

サイト信頼性エンジニアリングで最も重要な要素の一つは監視です。ツールを活用して、コア機能やシステムのパフォーマンスを継続的に測定・分析・改善します。これらのコア機能には、監視における「4つのゴールデン・シグナル」と呼ばれるものが含まれることが多いです。

レイテンシー：基本的には、リクエストの処理にどれくらい時間がかかるかです。これはリクエストが成功したかどうかによって変わります。エラー・メッセージの処理には、場合によってはかなり長い時間がかかることがあります。

トラフィック：サービスにどれだけの負荷や需要がかかっているかを示すメトリクスです。具体的な単位は状況によって異なります。ページビューかもしれませんし、トランザクションかもしれませんし、HTTPリクエストかもしれません。

エラー：通常は発生率が測定されます。エラーには、誤ったデータの取得、SLAで定められたより遅いデータ取得、あるいはデータ取得の失敗などが含まれます。

飽和度：飽和度とは、サービスがどれだけ容量に近づいているかを示すメトリクスです。サービスによっては飽和度が100％に近づくにつれて、障害が発生したり、処理が遅くなったり、エラーが増加したりする場合があるため、飽和度を理解することは重要です。

多くの監視ツールは、データの収集、ベンチマークの設定、デバッグや問題の分析、有用なオブザーバビリティーダッシュボードの提供、そしてSREに潜在的な障害やその他の問題を通知することができます。インシデント解決後には、充実した事後分析レポート（ポスト・モーテム）を提供することも重要です。インシデントの背景、根本原因や引き金、影響、解決方法、そして今後に向けた教訓を説明します。詳細かつ客観的なポスト・モーテムは、同じ過ちを繰り返さないために非常に有益です。

現代の多くのテクノロジー要素と同様に、ワークフローに自動化を組み込む目的は、価値を生まない反復作業にエンジニアが取り組む必要をなくすことです。新たに生まれた自由な時間を使って、エンジニアは自動化では対応できない作業、つまり創造や発想、大規模な指針策定などに取り組むことができます。

自動化は、特に次のような目的において有用です。

一貫性：反復的で手作業によるタスクの欠点は、退屈であることや、より価値の高い作業に割く時間を奪うことだけではありません。ユーザー・アカウントの作成のようなタスクを自動化ツールで実行すれば、ミスや不整合をほぼ排除することができます。新入社員は以前からいる社員とは異なる方法で作業するかもしれませんし、ユーザーが誤って値を間違った欄に入力してしまうこともあります。自動化されたプロセスであれば（一般的に）そのようなことは起こりません。

拡張性： 拡張性は、自動化がもたらす主要な長期的メリットです。先ほどのユーザー・アカウント作成の例で説明します。アカウント作成が指数関数的に増加すると、その設定を担当する人間の作業量も同じように指数関数的に増加し、この社員は他の、より価値の高い可能性のある業務から引き離されてしまいます。自動化されたシステムであれば、この問題は発生しません。

スピード：コード内のバグを見つけて修正するなど、特定の作業は人間が行うと多くの時間を要することがあります。自動化されたソフトウェアシステムは膨大なデータを監視でき、高度なパターン認識やその他のツールを活用して、人間よりも迅速にエラーを検出できる場合があります。修正も同様に迅速に適用でき、多くの場合、人間が関与する必要はありません。

もちろん、自動化プロセスには常に潜在的なリスクも存在します。例えば、次のようなものが含まれます。

初期コスト：自動化は、導入する前に作成しなければなりません。これには多大な時間や労力、さらにはハードウェアのコストがかかる場合があります。自動化の価値は、それを構築するための労力と、稼働後に実際に節約できるリソースとのバランスを考慮しなければなりません。

保守：自動化されたタスクは永遠に動き続けるように見えるかもしれませんが、実際にはそうではないことが多いです。自動化コードは常に最新の状態に保ち、他のコードやシステム更新と同期させておく必要があります。新しい機能が追加された場合、自動化コードも人手によって更新し、新しい処理を組み込んだりエラーを防いだりする必要があるかもしれません。

人工知能（AI）は、特に自動化の分野において、SREに新しく刺激的な可能性をもたらします。初期コストと保守の両方は、理論的には新しいAIモデルによって調整することが可能です。とはいえ、AIにはハルシネーション、セキュリティー、プライバシーといった新たな潜在的課題も伴っており、特にこれらは重要な懸念点です。

リリース・エンジニアリングは、ソフトウェアをリリースするために必要な手順に特化したソフトウェア工学の一分野です。その手順には、バージョニング、リリース・スケジュール、継続的または定期的なビルド、リリース・メトリクスの選定と収集などが含まれます。SREにおいては、リリース・エンジニアリングのタスクが場当たり的に直前で割り当てられるのを避けるため、リリース・エンジニアリングは後付けではなく最初から組み込まれます。

リリース・エンジニアリングという分野には、いくつかの重要な原則が含まれます。例えば、次のようなものが含まれます。

自動化とセルフサービス：理想的には、多くのリリースプロセスは自動化でき、エンジニアによる関与は最小限か、あるいは不要になります。これにより、迅速かつ安定したリリースが実現します。

ベロシティー：リリース・エンジニアリングでは、迅速で頻繁なリリースを重視するポリシーが推奨されます。リリースを素早く展開すれば、例えばローンチ時に1時間ごとに行う場合でも、バージョン間の変更点は少なくなります。このベロシティーによって、テストやトラブルシューティングが容易になります。

エルメティック・ビルド：ビルドプロセスは、ビルドマシン自体に依存せず、広く利用されているコンパイラー、ライブラリー、ツールを使用して完全に独立して行う必要があります。「2人が異なるマシンで、ソースコード・リポジトリー内の同じリビジョン番号で同じ製品をビルドしようとした場合、同一の結果になることが期待されます」と、Google社のDinah McNutt氏は記しています。

標準とポリシー：セキュリティー上の理由から、デプロイ、ソースコードの変更、新しいリリース、ビルド構成の変更など、特定のタスクに対してチェックを行うことが不可欠です。

サイト信頼性エンジニアリングの多くは、シンプルさを実現するためにあります。Google社のMax Luebbe氏は「ソフトウェアは本質的に動的で不安定です」と記しています。それを踏まえると、潜在的な問題を最小化し、その本質的な不安定性を抑制するためには、シンプルさが鍵となります。

この目的のために、サイト信頼性エンジニアリングはプロジェクトを単純化し明確にするさまざまな取り組みを推進しています。

1. どの機能を含めるかを慎重に選定することは有用ですが、製品の有用性に大きく寄与しない機能をすべて削除してしまうことも同様に有効です。機能が増えるということは、複雑さも増すということです。
2. より小規模で頻繁なリリースにより、デバッグやトラブルシューティングがはるかに容易になります。多数の新機能を含む新しいリリースは、追跡が極めて困難なエラーを引き起こす可能性があります。新機能が1つだけのリリースであればどうでしょうか。発生し得る問題は1カ所にしか原因がありません。
3. 同様に、複数のエンドポイントやマイクロサービスなどを用いることで、APIに複雑さを加えたくなることもあるかもしれませんが、これは避けたほうが賢明です。よりシンプルなAPIは、セットアップが速く、必要なドキュメントも少なくて済み、統合にかかる時間とコストを削減します。