アドベントカレンダー5日目：SREを読んでみた「リスクの受容」編① #インフラ

昨日までの回でSREのイントロダクション（1章）を終えました。
今日から3章の内容が始まります。2章はどうした？と突っ込みが入るかもしれないですが、2章の内容は膨大なデータやリクエストを処理するためのGoogleのプロダクション環境に関する説明がされています。3章以降の内容の理解に必要な場合があるかもしれないですが、SREの説明からずれてしまうので、飛ばすことにしました。もし、説明が必要になった際は、その都度、説明する形にしようと思います。

導入

今回はタイトル通りリスクの受容について、見ていきます。
SREにおいてのリスクとは、信頼性が下がることです。しかし、その信頼性を下げてでも、リスクを受け入れることには意味があります。
まず、サービスとユーザーの間には様々なシステムが混在しており、信頼性を100%にしようとする試みは、莫大な労力がかかります。また、仮に99.99%のシステムの信頼性を0.01%上げたとしても、それはユーザーに気づかれないため、UXの向上になりません。
ゆえに、可用性におけるリスク、システム開発の速度、サービス運用の間でバランスをとることがゴールになります。
設定したゴールを達成したら、必要以上に信頼性を高めることはしません。それをすることは、システムへの機能追加、技術的負債の払拭、運用コストの低減などを行う機会を失うからです。
では、リスク管理の為にどのようなアプローチをすべきなのでしょうか？

サービスリスクの計測

サービスリスクの計測ができれば、現状のパフォーマンスの評価やシステムの改善、劣化の追跡ができるようになります。
しかし、サービスの障害は、ユーザーの不満、損害、信頼の喪失、直接的または間接的な売り上げの損失、ブランドや評価へのインパクト、望ましくない報道を含む、さまざまな影響を及ぼす可能性があります。¹
これらを一つの指標で表すのは、難しいので、システムの計画外の停止時間に注目します。

可用性　=　稼働時間 / (稼働時間 + 停止時間) ①

例えば、可用性99.99%のシステムならば、年間の停止時間が52.56分なら、可用性を満たすことになります。
ですが、Googleの場合、サービスが世界中に分散しているので、世界のどこかでは動作している可能性が高いです。
そのため、リクエスト成功率で可用性を算出しています。

可用性　=　成功したリクエスト数 / 総リクエスト数 ②

この場合、可用性99.99%のシステムならは、1日250万リクエスト処理した時、エラーを返すリクエストが250回以下になればいいということになります。
また、②の測定方法は、エンドユーザーへ直接応答しないシステムに関しても、少ない変更で適用できます。

サービスリスクの許容度

サービスリスクの許容度は、そのサービスに応じて、異なります。信頼性を上げることよりも開発へリソースを割きたいサービスもあれば、医療システムのような信頼性が非常に重視されるものもあります。
以下では、信頼性の目標値となるサービスが許容できるリスクの量を適切に設定為の指針を見ていきます。
また、先に述べたようにサービスに応じてリスクの考え方は異なります。今回は、例としてコンシューマサービスの場合を見ていきます。

リスク許容度の明確化

サービスにおけるリスク許容度の評価には、以下のような項目があります。

必要な可用性のレベル。

障害の種類の違いによってサービスへの影響に差はないか。

リスク曲線状にサービスを位置づけるうえで、サービスコストはどのように利用できるか。

考慮すべき重要なサービスメトリクスとして、他にはどのようなものがあるか。¹

可用性のターゲットレベル

サービスの可用性のターゲットレベルは、そのサービスが提供する機能と、市場におけてサービスのどのような位置づけになるかが問われます。。以下は、考慮すべき事項です。

ユーザーが期待するサービスのレベル

サービスが直接的に収入（Googleの収入もしくはGoogleの顧客の収入）につながっているか

サービスは、有料化、あるいは無料か。

市場に競合がある場合、その競合が提供しているサービスのレベル

サービスはコンシューマ向けか、それとも企業向けか。¹

障害の種類

サービスで起こりうる障害の種類がどのようなものであるかについて、理解しておくことも重要です。時々、完全にダウンしてしまうシステムと低い確率で障害が続くこと時、エラーの絶対数が同じであっても、ビジネス的なインパクトは大きく異なるかもしれません。

コスト

サービスの可用性のターゲットを決定するにあたって、以下の指標があります。

可用性を１桁改善するようにスステムの構築と運用を行った場合、収入はどのように増加するか

この追加の収入は、信頼性をそのレベルにまで高めるためのコストに見合うか。¹

メリットとコストの関係をシンプルに表すことは、難しいかもしれませんが、優先度的にも考えるべきことです。

サービスの他のメトリクス

リスク許容度には、可用性以外のメトリクスもあります。
例えば、サービスのレイテンシです。このレイテンシの要求が緩い場合は、プロビジョニングの際のキャパシティプランニングにおいて、トレードオフを行うことができます。

まとめ

今回はリスクを受容することの意味と、リスクを明確にする上で考えるべきことについて、学びました。
次回はリスクを受け入れたことによって、得た機会（＝エラーバジェット）をどのように利用すべきかを見ていきます。

信頼性管理の大部分はリスク管理
リスクを明確化する

雑感

記事の改善

そのアプローチを行う意味は残す。
内容はシャープにまとめる。

引用

Betsy Seyerほか　SRE サイトリライアビリティエンジニアリング　オライリー　27-33