信頼性目標を定義するためのレコメンデーション

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

このガイドでは、重要なワークロードとフローの可用性と復旧目標のメトリックを定義するためのレコメンデーションについて説明します。 信頼性のターゲットは、ビジネス関係者とのワークショップ演習を通じて導き出されます。 ターゲットは、監視とテストを通して調整されます。

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

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

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

主要な設計戦略

技術的な議論では、重要なフローの信頼性目標をどのように定義するかについて議論すべきではありません。 代わりに、ビジネス利害関係者は、ワークロードの要件を定義する顧客に焦点を当てる必要があります。 技術専門家は、利害関係者がそれらの要件に関連する現実的な数値を割り当てるのを支援します。 技術専門家が知識を共有することで、現実的な SLO に関する交渉と相互合意が可能になります。

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

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

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

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

可用性のメトリック

SLO と SLA

SLO は、ワークロードまたはアプリケーションのパフォーマンスと信頼性の尺度です。 SLO は、特定の顧客との対話のために設定される、測定可能な特定のターゲットです。 これは、ユーザーが受け取る必要があるサービスの品質に関してワークロードまたはアプリケーションに設定するターゲットです。

SLO は、可用性、応答時間、スループット、成功率など、さまざまなメトリックの観点から定義できます。 たとえば、Web サービスの SLO は、特定の月の時間の 99.9% をユーザーが利用できる場合や、500 ミリ秒以内に 95% の要求に応答する場合があります。

アプリケーションまたはワークロードの SLA を定義する前に、アプリケーションまたはワークロードがホストされている基になるサービスについて、Microsoft が公開した SLA を確認します。

各サービスの SLA を確認するときは、高い SLA を満たすために必要な冗長性に注意してください。 たとえば、Microsoft では、Azure Cosmos DB のマルチリージョン デプロイでは、単一リージョンのデプロイよりも高い SLA を保証しています。

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

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

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

このアプリケーションで予想される最大ダウンタイムはどのくらいですか? いずれかのサービスで障害が発生すると、アプリケーション全体で障害が発生します。 各サービスで障害が発生する可能性は独立しているため、このアプリケーションの複合 SLA は 99.95% x 99.99% = 99.94% です。 この値は、個々の SLA よりも低くなります。 この結論は、複数のサービスに依存するアプリケーションには潜在的な障害ポイントが多いため、当然です。

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

この設計の場合、データベースに接続できない場合でも、アプリケーションは使用可能な状態です。 ただし、データベースとキューで同時に障害が発生すると、アプリケーションは使用できなくなります。 同時に障害が発生する時間の予測される割合は 0.0001 x 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 について考える場合は、フローによって重要度の定義が異なっていることに注意してください。 複合 SLA をビルドするときは、これらの違いを考慮してください。 重要でないフローには、一時的に使用できなくてもカスタマー エクスペリエンスに影響しないため、計算から省略する必要があるコンポーネントがある場合があります。

SLI

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

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

回復のメトリック

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

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

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

正常性モデルの構築

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

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

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

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

• 赤色つまり異常な状態は、低下した状態が信頼性目標によって許容される時間よりも長く続いているか、フローが使用できなくなったことを示します。

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

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

視覚化

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

Azure ファシリテーション

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

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

関連リンク

• 正常性モデリングのための適切に設計されたフレームワークのミッション クリティカルなガイダンス: Azure でのミッション クリティカルなワークロードの正常性モデリングと監視

信頼性チェックリスト

レコメンデーションの完全なセットを参照してください。