「Googleのような信頼性と信頼性」-だけでなく、記事「サービスの信頼性の計算」の翻訳

商用（および非商用）サービスの主なタスクは、常にユーザーが利用できるようにすることです。 全員がクラッシュしますが、問題はITチームがそれらを最小化するために何をするかです。 Ben Treynor、Mike Dahlin、Vivek Rau、Betsy Beyerの記事「サービスの信頼性の計算」を翻訳しました。たとえば、Googleなど、信頼性指標の100％が間違ったガイドである理由、「フォーナインのルール」、実際には、サービスおよび/またはその重要なコンポーネントの大規模および小規模の停止の実現可能性を数学的に予測する方法-予想されるダウンタイム量、障害の検出に要する時間、およびサービスの復元時間

サービスの信頼性の計算

システムはそのコンポーネントと同じくらい信頼性が高い

ベン・トレーナー、マイク・ダリン、ビベック・ラウ、ベッツィー・ベイヤー

本「 サイト信頼性エンジニアリング：Googleのような信頼性と信頼性 」（以下SRE本と呼ぶ）で説明されているように、Google製品とサービスの開発は、積極的なSLO（サービスレベル目標、サービスレベル目標）を維持しながら、新しい機能の高速リリースを実現できます）高い信頼性と迅速な対応を保証します。 SLOでは、サービスがほぼ常に良好な状態にあり、ほぼ常に高速であることが必要です。 さらに、SLOは、特定のサービスのこの「ほぼ常に」の正確な値も示します。 SLOは次の観察に基づいています。

一般的な場合、ソフトウェアサービスまたはシステムでは、100％と99,999％の可用性の違いにユーザーが気付かないため、100％は信頼性インジケーターの誤った参照ポイントです。 ユーザーとサービスの間には、他の多くのシステム（ラップトップ、ホームWi-Fi、プロバイダー、電源など）があり、これらのシステムは全部で99.999％のケースでは利用できませんが、それほど頻繁ではありません。 したがって、99.999％と100％の差は、他のシステムのアクセス不能に起因するランダムな要因により失われます。ユーザーは、システム可用性の最後の数分の1を達成するために多大な労力を費やしたという事実から利益を得ません。 この規則の重大な例外は、アンチロックブレーキとペースメーカーです！

SLOとSLI（サービスレベルインジケータ）およびSLA（サービスレベル契約）との関係の詳細については、SREターゲットサービスレベルの章を参照してください。 この章では、特定のサービスまたはシステムに関連するメトリックを選択する方法についても詳細に説明します。これにより、そのサービスまたはシステムに適したSLOの選択が決定されます。

この記事では、SLOトピックを拡張して、サービスコンポーネントに焦点を当てます。 特に、重要なコンポーネントの信頼性がサービスの信頼性にどのように影響するか、および影響を緩和するか、重要なコンポーネントの数を減らすシステムを設計する方法を調べます。

Googleが提供するサービスのほとんどは、ユーザーに99.99パーセント（「フォーナイン」とも呼ばれる）アクセシビリティを提供することを目的としています。 一部のサービスでは、ユーザー同意書に低い数値が示されていますが、目標の99.99％は社内に保存されています。 SREチームNo. 1の目標はユーザーにサービスを満足させることであるため、この高いバーは、契約条件に違反するかなり前にユーザーがサービスのパフォーマンスについて不満を言う状況で有利になります。 多くのサービスで、99.99％の内部目標は、コスト、複雑さ、および信頼性のバランスをとる中間点を表しています。 他の一部、特にグローバルクラウドサービスの場合、内部ターゲットは99.999％です。

信頼性99.99％：観察と結論

99.99％の信頼性を備えたサービスの設計と運用に関するいくつかの重要な観察と結論を見てから、実践に移りましょう。

観察＃1：失敗の原因

障害は、主に2つの理由で発生します。サービス自体の問題と、サービスの重要なコンポーネントの問題です。 重要なコンポーネントとは、障害が発生した場合にサービス全体の動作に対応する障害を引き起こすコンポーネントです。

観察番号2：信頼性の数学

信頼性は、ダウンタイムの頻度と期間に依存します。 以下によって測定されます。

• アイドル周波数、またはその逆：MTTF（平均故障時間）。
• ダウンタイム、MTTR（平均修理時間）。 ダウンタイムは、ユーザーの時間によって決まります：誤動作の開始からサービスの通常動作の再開まで。
  
  したがって、適切なユニットを使用して、信頼性は数学的にMTTF /（MTTF + MTTR）として定義されます。

結論＃1：エクストラナインのルール

サービスは、そのすべての重要なコンポーネントを組み合わせた場合よりも信頼性が高くなりません。 サービスが99.99％で可用性を確保しようとする場合、すべての重要なコンポーネントが99.99％をはるかに超える時間で使用可能でなければなりません。

Googleの内部では、次の経験則を使用します：重要なコンポーネントは、サービスの宣言された信頼性と比較して追加の9を提供する必要があります-上記の例では99.999％の可用性-サービスにはいくつかの重要なコンポーネントと固有の問題があるためです。 これは「エクストラナインのルール」と呼ばれます。

十分な9を提供しない重要なコンポーネント（比較的一般的な問題！）がある場合、マイナスの結果を最小限に抑える必要があります。

結論その2：頻度、検出時間、回復時間の数学

サービスは、インシデントの頻度と検出および復旧の時間の積よりも信頼性が高くなりません。 たとえば、1年に20分の合計3回のシャットダウンにより、合計60分のダウンタイムが発生します。 サービスが年の残りの期間で完全に機能したとしても、99.99％の信頼性（1年あたり53分以内のダウンタイム）は不可能です。

これは単純な数学的観察ですが、しばしば見落とされます。

結論1と2からの結論

サービスが依存する信頼性のレベルを達成できない場合は、上記のように、サービスの可用性を高めるか、悪影響を最小限に抑えることにより、状況を修正する努力をする必要があります。 期待値を下げる（つまり、信頼性を宣言する）ことも選択肢であり、多くの場合最も真実です：サービスの信頼性のエラーを補うためにシステムを再構築するか、サービスレベルの目標を下げる必要があることを、あなたに依存するサービスに対して明確にします。 あなた自身が矛盾を排除しない場合、システムの十分に長い障害は、必然的に調整を必要とします。

実用化

ターゲットの信頼性が99.99％のサービスの例を見て、コンポーネントと障害の両方の要件を調べてみましょう。

フィギュア

利用可能な99.99パーセントのサービスに次の特性があると仮定します。

• 1年に1回の大きな停止と3回の小さな停止。 これは恐ろしいことのように思えますが、99.99％の信頼レベルは、1年に20〜30分の大規模なダウンタイムが1回と数回の短い部分的なシャットダウンを意味することに注意してください。 （数学では、a）1つのセグメントの障害はSLOの観点からシステム全体の障害とは見なされず、b）全体の信頼性はセグメントの信頼性の合計によって計算されます。
• 99.999％の信頼性を備えた、他の独立したサービスという5つの重要なコンポーネント。
• 次々に失敗することのない5つの独立したセグメント。
• すべての変更は、一度に1セグメントずつ徐々に実行されます。

信頼性の数学的計算は次のとおりです。

コンポーネント要件

• 1年間の合計エラー制限は、年間525,600分のうち0.01％、または53分（最悪の場合のシナリオでは365日に基づいて）です。
• 重要なコンポーネントのシャットダウンに割り当てられる制限は、5つの独立した重要なコンポーネントで、それぞれ0.001％の制限= 0.005％です。 年間525,600分の0.005％、つまり26分。
• サービスの残りのエラー制限は53-26 = 27分です。

シャットダウン応答の要件

• 予想されるダウンタイム：4（1つの完全シャットダウンと1つのセグメントのみに影響する3つのシャットダウン）
• 予想される停止の累積効果：（1×100％）+（3×20％）= 1.6
• 障害の検出とその後の復旧：27 / 1.6 = 17分
• 障害を検出して通知するために監視に割り当てられた時間：2分
• アラートの分析を開始するために勤務中のスペシャリストに与えられる時間：5分。 （監視システムは、システムの誤動作が発生するたびにSLO違反を追跡し、勤務中にポケットベルに信号を送信する必要があります。多くのGoogleサービスは、緊急の質問に答えるシフトシフトSRエンジニアによってサポートされます。）
• 悪影響を効果的に最小化するための残り時間：10分

結論：サービスの信頼性を高めるために活用する

基本的なポイントを強調しているため、表示されている数値を注意深く見る価値があります。サービスの信頼性を高めるための3つの主要な手段があります。

• リリースポリシー、テスト、プロジェクト構造の定期的な評価などを通じて、停止の頻度を減らします。
• セグメント化、地理的分離、段階的な低下、または顧客の分離により、平均ダウンタイムを削減します。
• 復旧時間の短縮-監視、ワンボタンのレスキュー操作（たとえば、以前の状態へのロールバックやスタンバイ電源の追加）、運用準備プラクティスなど
  
  これら3つの方法のバランスをとり、フォールトトレランスの実装を簡素化できます。 たとえば、17分間のMTTRを達成するのが難しい場合は、平均ダウンタイムの短縮に焦点を合わせます。 マイナスの影響を最小限に抑え、重要なコンポーネントの影響を緩和するための戦略については、この記事の後半で詳しく説明します。

ネストされたコンポーネントの「追加の9の規則」の明確化

ランダムリーダーは、依存関係チェーンの追加リンクごとに追加の9が必要であると結論付けることができるため、2次の依存関係には2つの追加9、3次の依存関係には3つの追加9などが必要です。

これは間違った結論です。 これは、各レベルで一定の分岐を持つツリー形式のコンポーネントの階層の単純なモデルに基づいています。 このようなモデルでは、図 1、10個の一意の1次コンポーネント、100個の一意の2次コンポーネント、1,000個の一意の3次コンポーネントなどがあるため、アーキテクチャが4層に制限されている場合でも、合計1​​,111個の一意のサービスになります。 非常に多くの独立した重要なコンポーネントを備えた信頼性の高いサービスのエコシステムは、明らかに非現実的です。

図 1-コンポーネント階層：無効なモデル

重要なコンポーネント自体は、依存関係ツリーのどこにあるかに関係なく、サービス全体（またはサービスセグメント）の障害を引き起こす可能性があります。 したがって、Xの特定のコンポーネントが複数の1次コンポーネントの依存関係として表示される場合、Xの障害は最終的にサービス障害につながるため、影響を受ける中間サービスの数に関係なく、Xは1回だけカウントする必要があります。

ルールの正しい読み方は次のとおりです。

• サービスにN個の固有の重要なコンポーネントがある場合、コンポーネントの階層内の低さに関係なく、各コンポーネントはこのコンポーネントによって引き起こされるサービス全体の信頼性の1 / Nに寄与します。
• 各コンポーネントは、コンポーネント階層に複数回出現する場合でも（つまり、一意のコンポーネントのみがカウントされる場合でも）1回だけカウントする必要があります。 たとえば、図1のサービスAのコンポーネントを計算する場合 2、サービスBは1回だけ検討する必要があります。

図 2-階層内のコンポーネント

たとえば、0.01％のエラー制限がある仮想サービスAを考えてみましょう。 サービス所有者は、この制限の半分を自分のミスと損失に、残りの半分を重要なコンポーネントに費やす準備ができています。 サービスにこのようなコンポーネントがN個ある場合、各コンポーネントは残りの1 / Nのエラー制限を受け取ります。 通常、サービスには5〜10個の重要なコンポーネントがあるため、各サービスはサービスAのエラー制限の10分の1または20分の1しか拒否できません。したがって、原則として、サービスの重要な部分にはさらに9つの信頼性が必要です。

エラー制限

エラー制限の概念については、本SREで詳細に説明していますが、ここで言及する必要があります。 Google SRのエンジニアは、エラー制限を使用して、更新の信頼性とペースのバランスを取ります。 この制限により、一定期間（通常は1か月間）のサービスの許容可能な障害レベルが決まります。 エラー制限は、1からサービスのSLOを差し引いたものであるため、前述の利用可能な99.99パーセントのサービスには、信頼性に関する0.01％の「制限」があります。 サービスが1か月以内にエラー制限を使い切るまで、開発チームは（理由の範囲内で）新しい機能や更新などを自由に起動できます。

エラー制限が使い果たされた場合、サービスがエラー制限の予約を補充するか、月が変更されるまで、サービスへの変更は（緊急のセキュリティ修正および違反を最初に引き起こすことを目的とした変更を除く）中断されます。 Googleの多くのサービスでは、SLOにスライディングウィンドウ方式を使用しているため、エラー制限は徐々に復元されます。 SLOが99.99％を超える深刻なサービスの場合、許容されるダウンタイムの数が少ないため、毎月のゼロリセットではなく、四半期ごとの使用をお勧めします。

エラー制限により、SRエンジニアと製品開発者の間で発生する可能性のある部門間の緊張が解消され、製品を起動するための共通のデータベースベースのリスク評価ツールが提供されます。 また、SRエンジニアおよび開発チームは、「予算を膨らませる」ことなく、より速く革新し、製品を発売できる方法と技術を開発するという共通の目標を与えます。

重要なコンポーネントの削減と軽減の戦略

この時点で、この記事では、 「コンポーネントの信頼性に関するゴールデンルール」と呼ばれるものを確立しました。 これは、重要なコンポーネントの信頼性がシステム全体の信頼性の目標レベルよりも10倍高くなければならないことを意味します。その結果、システムの信頼性への寄与はエラーのレベルのままになります。 理想的には、タスクはできるだけ多くのコンポーネントを非クリティカルにすることです。 これは、コンポーネントがより低いレベルの信頼性を順守できることを意味し、開発者が革新し、リスクを取る機会を与えます。

重要な依存関係を減らすための最も簡単で明白な戦略は、可能な限り単一障害点を排除することです。 大規模なシステムは、重要な依存関係またはSPOFではない特定のコンポーネントがなくても許容できるように動作できる必要があります。

実際、ほとんどの重要な依存関係を取り除くことはできません。 しかし、信頼性を最適化するために、いくつかのシステム設計ガイドラインに従うことができます。 これは常に可能ではありませんが、システムが機能し実際のユーザーに影響を与えた後ではなく、設計および計画段階で信頼性を設定すると、システムの高い信頼性を達成するのが簡単で効率的です。

プロジェクト構造評価

新しいシステムまたはサービスを計画する場合、または既存のシステムまたはサービスを再設計または改善する場合、アーキテクチャまたはプロジェクトのレビューにより、内部および外部の依存関係だけでなく、共通のインフラストラクチャが明らかになる場合があります。

共有インフラストラクチャ

サービスが共有インフラストラクチャ（たとえば、ユーザーが利用できる複数の製品で使用されるメインデータベースサービス）を使用する場合、このインフラストラクチャが正しく使用されているかどうかを検討してください。 共有インフラストラクチャの所有者を追加のプロジェクト参加者として明確に識別します。 また、コンポーネントのオーバーロードに注意してください-これを行うには、これらのコンポーネントの所有者と起動プロセスを慎重に調整してください。

内部および外部の依存関係

製品またはサービスは、会社の制御が及ばない要因に依存する場合があります。たとえば、ソフトウェアライブラリまたはサービス、サードパーティからのデータなどです。 これらの要因を特定することで、それらの使用の予測不可能な結果を​​最小限に抑えることができます。

システムを慎重に計画および設計する

システムを設計するときは、次の原則に注意してください。

冗長性と分離

重要なコンポーネントのいくつかの独立したインスタンスを作成することにより、重要なコンポーネントの影響を軽減しようとすることができます。 たとえば、1つのインスタンスにデータを格納すると、このデータの99.9％の可用性が確保される場合、3つのコピーを3つの広く分散したコピーに格納すると、理論上、インスタンスの障害がゼロ相関で独立している場合、可用性レベル1-0.013またはナインナインを提供します。

現実の世界では、相関関係がゼロになることはありません（同時に多くのセルに影響を与えるバックボーンネットワークの障害を見てください）。したがって、実際の信頼性は9ナインに近づきませんが、3ナインをはるかに超えます。

同様に、RPC（リモートプロシージャコール）を同じクラスター内の1つのサーバープールに送信すると、結果の99％の可用性が得られますが、3つの同時RPCを3つの異なるサーバープールに送信し、最初の応答を受け入れると可用性レベルに到達できますスリーナインより高い（上記参照）。 この戦略は、サーバープールがRPC送信者から等距離にある場合、応答時間遅延のテールを短縮することもできます。 （3つのRPCを同時に送信するコストが高いため、Googleはこれらの呼び出しに時間を戦略的に割り当てることがよくあります：ほとんどのシステムは、2番目のRPCを送信する前に割り当てられた時間の一部を、3番目のRPCを送信する前にもう少し時間を必要とします）

リザーブとその適用

ソフトウェアの起動と移植をセットアップして、個々の部品に障害が発生してもシステムが動作し続け（フェールセーフ）、問題が発生したときにシステムが分離されるようにします。 ここでの基本原則は、人を接続してリザーブをオンにするまでに、おそらくすでにエラー制限を超えていることです。

非同期性

コンポーネントがクリティカルになるのを防ぐために、可能な限り非同期に設計します。 サービスが、重要ではない部分の1つからRPC応答を予期している場合、応答時間が急激に遅くなり、この低速化により、親サービスのパフォーマンスが不必要に低下します。 重要ではないコンポーネントのRPCを非同期モードに設定すると、親サービスの応答時間がこのコンポーネントのパフォーマンスに縛られることがなくなります。 非同期性はコードとサービスのインフラストラクチャを複雑にする可能性がありますが、この妥協はそれだけの価値があります。

資源計画

すべてのコンポーネントに必要なものがすべて揃っていることを確認してください。 疑わしい場合は、過剰な準備金を提供する方が良いですが、コストは増加しません。

構成

可能であれば、コンポーネントの構成を標準化して、サブシステム間の差異を最小限に抑え、1回限りの障害/エラー処理モードを回避します。

検出とトラブルシューティング

トラブルシューティング、トラブルシューティング、およびトラブルシューティングをできるだけ簡単にします。 効果的な監視は、問題をタイムリーに特定するための重要な要素です。 深く埋め込まれたコンポーネントを持つシステムの診断は非常に困難です。 常に、職務官による詳細な介入を必要としない間違いを平準化する方法に備えてください。

前の状態への高速で信頼性の高いロールバック

障害の結果を排除する計画に勤務中の人の手作業を含めると、SLOの厳しい目標を達成する能力が大幅に低下します。 簡単、迅速、シームレスに以前の状態に戻ることができるシステムを構築します。 システムが改善し、監視方法に対する信頼が高まるにつれて、安全なロールバックを自動的に起動するシステムを開発することにより、MTTRを削減できます。

考えられるすべての障害モードを体系的に確認します。

各コンポーネントを調べ、その動作の障害がシステム全体にどのように影響するかを判断します。 次の質問を自問してください。

• システムのいずれかが失敗した場合、システムは機能制限モードで動作し続けることができますか？ 言い換えれば、徐々に劣化する可能性を設計します。
• さまざまな状況でコンポーネントにアクセスできないという問題をどのように解決しますか？ サービスを開始するとき？ サービス操作中ですか？

厳格なテストを実施する

各コンポーネントが、環境の他のコンポーネントによってこのコンポーネントを使用するための主要なシナリオを含むテストでカバーされることを保証する開発されたテスト環境を開発および実装します。 そのようなテストのための推奨される戦略は次のとおりです。

• 統合テストを使用して障害をテストします-システムがコンポーネントの障害に耐えられることを確認します。
• 緊急テストを実施して、弱点または隠れた/計画外の依存関係を特定します。 特定された欠陥を修正する手順を修正します。
• 通常の負荷をテストしないでください。 システムを意図的に再起動して、機能がどのように低下​​するかを確認します。 何らかの方法で、システムの過負荷に対する反応が判明します。 ただし、負荷テストをユーザーに任せるのではなく、事前にシステムを自分でテストすることをお勧めします。

今後の計画

スケール関連の変更を期待する：1台のコンピューターで比較的単純なバイナリとして開始されるサービスは、大規模に展開すると、多くの明らかな依存関係と依存関係を持つことがあります。 各スケールの順序は、サービスだけでなく依存関係にも新しい制約を明らかにします。 依存関係が必要な速度で拡張できない場合はどうなるかを考えてください。

また、システムの依存関係は時間とともに進化し、依存関係のリストは時間とともに増加する可能性があることに注意してください。 インフラストラクチャに関しては、一般的なGoogleの推奨事項は、アーキテクチャを大幅に変更することなく、初期ターゲットロードの10倍まで拡張できるシステムを作成することです。

おわりに

読者はおそらくこの記事で説明されている概念のいくつかまたは多くに精通しているでしょうが、その使用の特定の例は、彼らの本質をよりよく理解し、この知識を他の人に伝えるのに役立ちます。 推奨事項は単純ではありませんが、達成不可能ではありません。 多くのGoogleサービスは、超人的な努力や知性によるものではなく、長年にわたって開発された原則とベストプラクティスの思慮深い適用により、フォーナインを超える信頼性を繰り返し実証しています（SRE、付録B：産業運用におけるサービスの実践的なガイドラインを参照）。