信頼性ターゲットを定義するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

RE:04 コンポーネント、フロー、およびソリューション全体の信頼性と回復のターゲットを定義します。 目標を視覚化して、ネゴシエートし、合意を得て、期待を設定し、理想的な状態を達成するためのアクションを推進します。 定義されたターゲットを使用して正常性モデルを構築します。 正常性モデルでは、正常な状態、低下状態、異常な状態を定義します。

このガイドでは、重要なワークロードとフローの可用性と復旧ターゲットのメトリックを定義するための推奨事項について説明します。 信頼性目標は、ビジネス利害関係者とのワークショップ演習を通じて派生します。 ターゲットは、監視とテストによって絞り込まれます。

内部の利害関係者と共に、ワークロードの信頼性に対する現実的な期待を設定して、利害関係者が契約契約を通じて顧客にそれらの期待を伝えるようにします。 現実的な期待は、利害関係者がアーキテクチャ設計の決定を理解してサポートし、合意した目標を最適に満たすように設計していることを認識するのにも役立ちます。

次のメトリックを使用して、ビジネス要件を定量化することを検討してください。

期間 定義
サービス レベルの目標 (SLO) コンポーネントの正常性と信頼性レベルを表すパーセンテージターゲット。 レベルが高いほど、コンポーネントの信頼性が高くなります。 複合 SLO は、ワークロード全体の集計ターゲットを表し、コンポーネント SLO のアカウントを表します。
サービス レベル インジケーター (SLI) サービスによって出力されるメトリック。 SLI メトリックは、SLO 値を定量化するために集計されます。
サービス レベル アグリーメント (SLA) サービス プロバイダーとサービス顧客の間の契約契約。 契約によって SLO が定義されます。 契約を満たしないと、サービス プロバイダーに財務上の影響が生じる可能性があります。
平均復旧時間 (MTTR) 障害が検出された後にコンポーネントを復元するのにかかった時間。
平均故障間隔 (MTBF) ワークロードが失敗するまで、中断することなく予想される関数を実行できる期間。
目標復旧時間 (RTO) インシデントの発生後にアプリケーションを使用不可状態にできる最大許容時間。
目標復旧時点 (RPO) インシデント中のデータ損失の許容される最大期間。

ユーザー フローとシステム フローのコンテキストで、これらのメトリックのワークロードのターゲット値を定義します。 これらのフローが要件にどれだけ重要であるかを特定し、スコア付 けします。 値を使用して、アーキテクチャ、レビュー、テスト、インシデント管理操作の観点からワークロードの設計を推進します。 目標を達成できなかった場合、許容範囲を超えるビジネスに影響します。

主要な設計戦略

技術的なディスカッションでは、重要なフローの信頼性ターゲットを定義する方法を推進することはできません。 代わりに、ビジネス利害関係者は、ワークロードの要件を定義する際に顧客に焦点を当てる必要があります。 技術専門家は、利害関係者がそれらの要件に関連する現実的な数値を割り当てるのに役立ちます。 知識を共有する中で、技術専門家は現実的なSLOに関する交渉と相互合意を可能にします。

測定可能な数値に要件をマップする方法の例を考えてみましょう。 利害関係者は、重要なユーザー フローの場合、通常の営業時間中に 1 時間のダウンタイムが発生すると、毎月の収益で X ドルが失われると見積もっています。 この金額は、可用性 SLO が 99.9% ではなく 99.95% のフローを設計する場合の推定コストと比較されます。 意思決定者は、その収益損失のリスクが、それに対する保護に必要な追加コストと管理負担を上回るかどうかを議論する必要があります。 フローを調べてターゲットの完全な一覧を作成するときは、このパターンに従います。

信頼性ターゲットは、パフォーマンス ターゲットとは異なる点に注意してください。 信頼性のターゲットは、可用性と回復に重点を置きます。 信頼性の目標を設定するには、まず最も広範な要件を定義してから、高レベルの要件を満たすようにより具体的なメトリックを定義します。

最も高いレベルの信頼性と回復の要件と相関メトリックには、たとえば、すべてのリージョンでアプリケーションの可用性が 99.9%、南北アメリカリージョンの場合は 5 時間のターゲット RTO が含まれる場合があります。 これらの種類のターゲットを定義すると、それらのターゲットに関係する重要なフローを特定するのに役立ちます。 その後、コンポーネント レベルのターゲットを検討できます。

トレードオフ: ワークロードのコンポーネントの技術的な制限と、ビジネスにとって何を意味するか (たとえば、メガビット/秒のスループットと 1 秒あたりのトランザクション数) の間には、概念上のギャップが存在する可能性があります。 これら 2 つのビュー間でモデルを作成するのは困難な場合があります。 ソリューションを過剰に設計するのではなく、経済的で意味のある方法でアプローチしてみてください。

可用性のメトリック

SLA と SLA

可用性メトリックは、SLA の定義に使用する SLO に関連付けます。 ワークロード SLO は、特定の期間 (たとえば、1 か月あたり 1 時間未満) に許容されるダウンタイムの量を決定します。 SLO ターゲットを満たすことができるかどうかを確認するには、各コンポーネントの Microsoft SLA を確認します。 高い SLA を満たすために必要な冗長性に注意してください。 たとえば、Microsoft では、Azure Cosmos DB の複数リージョンデプロイに対して、単一リージョンのデプロイよりも高い SLA が保証されます。

注意

Azure SLA は、常にサービスのすべての側面をカバーするとは限りません。 たとえば、Azure Application Gatewayには可用性 SLA がありますが、Azure Web Application Firewall機能では、悪意のあるトラフィックの通過を停止する保証はありません。 SLA と SLO を開発する場合は、この制限を考慮してください。

個々のワークロード コンポーネントの SLA を収集したら、複合 SLA を計算します。 複合 SLA は、ワークロードのターゲット SLO と一致する必要があります。 複合 SLA の計算には、アーキテクチャの設計に応じて、いくつかの要因が含まれます。 次の例を考えてみます。

注意

次の例の SLA 値は仮定であり、デモンストレーションのみを目的としています。これらは、Microsoft でサポートされている現在の値を表すことを意図したものではありません。

複合 SLA には、異なるレベルの可用性を持つアプリケーションをサポートする複数のサービスが含まれます。 たとえば、Azure SQL Database に書き込むAzure App Service Web アプリがあるとします。 仮定すると、これらの SLA は次のようになります。

  • App Service Web アプリ = 99.95%
  • SQL Database = 99.99%

このアプリケーションで予想できる最大ダウンタイムは何ですか? いずれかのサービスで障害が発生すると、アプリケーション全体で障害が発生します。 各サービスが失敗する確率は独立しているため、このアプリケーションの複合 SLA は 99.99% × 99.99% = 99.94% です。 この値は、個々の SLA よりも低くなります。 この結論は、複数のサービスに依存するアプリケーションの潜在的な障害ポイントが多いため、驚くべきことではありません。

複合 SLA を改善するには、独立したフォールバック パスを作成する方法があります。 たとえば、SQL Database が使用できない場合は、後で処理できるようにトランザクションをキューに格納します。

フォールバック パスを示す図。Web アプリ ボックスには、SQL Databaseまたはキューに分岐する矢印が表示されます。

この設計では、アプリケーションはデータベースに接続できない場合でも引き続き使用できます。 ただし、データベースとキューが同時に失敗すると失敗します。 同時障害の予想時間の割合は 0.0001 × 0.001 であるため、この結合パスの複合 SLA を次に示します。

データベースまたはキュー = 1.0 − (0.0001 × 0.001) = 99.99999%

複合 SLA の合計:

Web アプリと (データベースまたはキュー) = 99.95% × 99.99999% = ~99.95%

このアプローチはトレードオフを引き起します。

  • アプリケーション ロジックの方が複雑です。
  • キューの料金を支払います。
  • データの整合性の問題を考慮する必要があります。

マルチリージョンデプロイの場合、複合 SLA は次のように計算されます。

  • N は、1 つのリージョンにデプロイされているアプリケーションの複合 SLA です。

  • R は、アプリケーションがデプロイされているリージョンの数です。

すべてのリージョンでアプリケーションが同時に失敗する可能性は ((1 − N) ^ R) です。 たとえば、仮定の単一リージョン SLA が 99.95% の場合は、次のようになります。

  • 2 つのリージョンの組み合わせ SLA = (1 - (1 - 0.9995) ^ 2) = 99.999975%

  • 4 つのリージョンの組み合わせ SLA = (1 - (1 - 0.9995) ^ 4) = 99.999999%

適切な SLO を定義するには、時間と慎重な考慮事項が必要です。 ビジネス関係者は、主要な顧客がアプリを使用する方法を理解する必要があります。 また、信頼性の許容範囲も理解している必要があります。 このフィードバックは、ターゲットに通知する必要があります。

SLA 値

次の表では、一般的な SLA 値を定義します。

SLA 週あたりのダウンタイム 月あたりのダウンタイム 年あたりのダウンタイム
99% 1.68 時間 7.2 時間 3.65 日
99.9% 10.1 分 43.2 分 8.76 時間
99.95% 5 分 21.6 分 4.38 時間
99.99% 1.01 分 4.32 分 52.56 分
99.999% 6 秒 25.9 秒 5.26 分

フローのコンテキストで複合 SLA について考える場合は、フローごとに重要度の定義が異なっていることに注意してください。 複合 SLA を構築する場合は、これらの違いを考慮してください。 重要でないフローには、一時的に使用できない場合はカスタマー エクスペリエンスに影響しないため、計算から省略する必要があるコンポーネントがある場合があります。

注意

顧客向けのワークロードと内部使用ワークロードでは、SLO が異なります。 通常、内部使用ワークロードは、顧客向けのワークロードよりもはるかに制限の厳しい可用性 SLO を持つことができます。

SLI

SLI は、SLO に寄与するコンポーネント レベルのメトリックと考えてください。 最も重要な SLI は、顧客の観点から重要なフローに影響を与えるものです。 多くのフローでは、SLI には待機時間、スループット、エラー率、可用性が含まれます。 優れた SLI は、SLO が侵害されるリスクがあるタイミングを特定するのに役立ちます。 可能であれば、SLI を特定の顧客に関連付けます。

役に立たないメトリックを収集しないようにするには、フローごとに SLA の数を制限します。 可能であれば、フローごとに 3 つの SLI を目指します。

回復のメトリック

復旧ターゲットは、RTO、RPO、MTTR、および MTBF メトリックに対応します。 可用性ターゲットとは対照的に、これらの測定の復旧ターゲットは Microsoft SLA に大きく依存しません。 Microsoft では、SQL Databaseなどの一部の製品に対してのみ RTO と RPO の保証を公開しています。

現実的な復旧ターゲットの定義は、 障害モードの分析 と、ビジネス継続性と ディザスター リカバリーの計画とテストに依存します。 この作業を完了する前に、利害関係者と願望的なターゲットについて話し合い、アーキテクチャの設計で復旧ターゲットが理解できる限りサポートされていることを確認します。 復旧メトリックについて十分にテストされていないフローまたはワークロード全体に SLA が保証されていないことを関係者に明確に伝えます。 ワークロードが更新されると、復旧ターゲットが時間の経過と同時に変化する可能性があることを関係者が理解していることを確認します。 顧客が追加されたり、新しいテクノロジを採用してカスタマー エクスペリエンスを向上させたりすると、ワークロードが複雑になる可能性があります。 これらの変更により、復旧メトリックが増減する可能性があります。

注意

MTBF の定義と保証は困難な場合があります。 サービスとしてのプラットフォーム (PaaS) またはサービスとしてのソフトウェア (SaaS) は、クラウド プロバイダーからの通知なしに失敗して回復する可能性があり、プロセスはユーザーまたは顧客に対して完全に透過的にすることができます。 このメトリックのターゲットを定義する場合は、制御下にあるコンポーネントのみを対象とします。

復旧ターゲットを定義するときに、回復を開始するためのしきい値を定義します。 たとえば、Web ノードが 5 分を超えて使用できない場合、新しいノードがプールに自動的に追加されます。 他のコンポーネントや依存関係への影響など、特定のコンポーネントの回復に関連するものを考慮して、すべてのコンポーネントのしきい値を定義します。 また、一 時的な障害 についてもしきい値を考慮して、回復アクションを迅速に開始しないようにする必要があります。 顧客のデータ損失やセッションの中断など、回復操作の潜在的なリスクを利害関係者に文書化して共有します。

正常性モデルの構築

信頼性ターゲット用に収集したデータを使用して、ワークロードと関連する重要なフローごとに正常性モデルを構築します。 正常性モデルは、フローとワークロードの 正常、 低下、異常 な 状態を定義します。 状態により、運用上の適切な優先順位付けが保証されます。 このモデルは、 信号機モデルとも呼ばれます。 モデルでは、正常な場合は緑、劣化した場合は黄色、異常な場合は赤が割り当てられます。 正常性モデルを使用すると、フローの状態が正常から低下または異常に変化するタイミングを把握できます。

正常、低下、異常な状態を定義する方法は、信頼性のターゲットによって異なります。 状態を定義する方法の例をいくつか次に示します。

  • 緑色または正常な状態は、主要な非機能要件とターゲットが完全に満たされていること、およびリソースが最適に使用されることを示します。 たとえば、要求の 95% は =500 ミリ秒で<処理され、Azure Kubernetes Service (AKS) ノードでは X% で使用されます。

  • 黄色または低下状態は、フローの 1 つ以上のコンポーネントが定義されたしきい値に対してアラートを生成しているが、フローは動作可能であることを示します。 たとえば、ストレージの調整が検出されました。

  • 赤または異常の状態は、信頼性ターゲットによって低下が許容されるよりも長く持続しているか、フローが使用できなくなったことを示します。

注意

正常性モデルでは、すべてのエラーを同じように扱うべきではありません。 正常性モデルでは、 一時的 な障害と 非一時的な 障害を区別する必要があります。 予期される一時的な障害と回復可能なエラーを明確に区別する必要があります。

このモデルは、継続的な改善の原則に基づいて開発および運用されている監視およびアラート戦略を使用して機能します。 ワークロードが進化するにつれて、正常性モデルはそれらと共に進化する必要があります。

階層化されたアプリケーション正常性モデルの設計に関する詳細な考慮事項と推奨事項については、ミッション クリティカルなワークロード設計領域にある 正常性モデリング ガイダンス を参照してください。 監視とアラートの構成に関する詳細なガイダンスについては、 正常性の監視 ガイドを参照してください。

グラフ

運用チームとワークロードの利害関係者に、ワークロード正常性モデルのリアルタイムの状態と全体的な傾向に関する情報を保持するには、監視ソリューションで ダッシュボード を作成することを検討してください。 利害関係者と視覚化ソリューションについて話し合い、価値のある情報を簡単に提供できるようにします。 また、生成されたレポートを毎週、毎月、または四半期ごとに表示することもできます。

Azure ファシリテーション

Azure SLA は、アップタイムと接続に関する Microsoft のコミットメントを提供します。 サービスごとに SLA が異なり、サービス内の SKU の SLA が異なる場合があります。 詳細については、「オンライン サービスのサービス レベル アグリーメント」を参照してください。

Azure SLA には、SLA が満たされていない場合にサービス クレジットを取得するための手順と、各サービスの可用性の定義が含まれます。 SLA のこの側面は、強制ポリシーとして機能します。

組織の配置

クラウド導入フレームワークでは、organization全体の監視に関連する SLO と SLI の推奨事項に関するガイダンスを提供します。

詳細については、「 クラウド監視 SLO」を参照してください。

信頼性チェックリスト

推奨事項の完全なセットを参照してください。

信頼性チェックリスト