信頼性目標を定義するための推奨事項
この Power Platform Well-Architected Reliabilityチェックリストの推奨事項に適用されます:
| RE:04 | コンポーネント、フロー、および全体的なソリューションについて信頼性と回復の目標を定義します。 ターゲットを視覚化して、交渉し、合意を得て、期待を設定し、行動を促すことで、理想的な状態を実現します。 定義されたターゲットを使用して正常性モデルをビルドします。 正常性モデルは、正常な状態、劣化した状態、および異常な状態がどのようなものであるかを定義します。 |
|---|
このガイドでは、重要なワークロードの可用性と回復ターゲットのメトリックを定義するための推奨事項について説明します。 信頼性の目標は、ビジネス関係者とのワークショップ演習を通じて導き出されます。
監視とテストを通じて目標が改善されます。 社内の関係者と協力して、信頼性に対する現実的な期待を確立します。 この演習はまた、関係者が皆さんのアーキテクチャ設計の選択を支持し、あなたが合意した目標を達成するために最適な設計を行っていることを理解する際にも役立ちます。
Microsoft Power Platform は、インフラレベル の可用性と信頼性に関するほとんどの問題を処理します。 ただし、構築するワークロードの可用性は共有責任となります。 Microsoftの 高可用性への取り組みがあっても、システムのダウンタイムのリスクがゼロになることはないことを理解することが重要です。
ビジネス要件を定量化するには、次のメトリックの使用を検討してください。
| 任期 | Definition |
|---|---|
| サービス レベル目標 (SLO) | コンポーネントの健全性と信頼性層を表す目標のパーセンテージです。 階層が高いほど、コンポーネントの信頼性が高くなります。 複合SLO は、ワークロード全体の集計ターゲットを表し、コンポーネントSLOを考慮します。 |
| サービス レベル インジケーター (SLI) | サービスが発行するメトリックです。 SLI メトリクスは、SLO 値を定量化するために集計されます。 |
| サービス レベル アグリーメント (SLA) | サービス プロバイダーとサービス顧客の間の契約上の合意です。 この契約では SLO を定義します。 契約を遵守できない場合、サービス プロバイダーに経済的影響が及ぶ可能性があります。 |
| 平均回復時間 (MTTR) | 障害が検出されてからコンポーネントを復元するのにかかる時間です。 |
| 平均故障間隔 (MTBF) | ワークロードが障害が発生するまで、中断することなく期待された機能を実行できる期間です。 |
| 復旧時間目標 (RTO) | インシデント発生後にアプリケーションが利用できなくなる最大許容時間です。 |
| 目標復旧地点 (RPO) | インシデント発生時のデータ損失の最大許容期間です。 |
ユーザー フローとシステム フローのコンテキストで、これらのメトリックのワークロードのターゲット値を定義します。 要件に対する重要度に応じて、それらのフローを特定し、スコアを付けます。 これらの値を使用して、アーキテクチャ、レビュー、テスト、インシデント管理操作の観点からワークロードの設計を推進します。 目標を達成できない場合、許容範囲を超えてビジネスに影響が及びます。
主要な設計戦略
重要なフローの信頼性目標の定義方法は、技術的な議論によって決まるべきではありません。 代わりに、ビジネス関係者は、自らの要件とワークロードのエンドユーザーの期待に重点を置く必要があります。 技術専門家は、関係者がこれらの要件を満たす現実的な数値を割り当てるのを支援します。 技術専門家が情報を交換することで、実現可能な SLO についての議論と合意が可能になります。
要件を測定可能な数値にマッピングする方法の例を考えてみましょう。 関係者の試算によると、重要なユーザー フローでは、通常の営業時間中に 1 時間のダウンタイムが発生すると、月収で X ドルの損失が発生します。 この金額は、可用性 SLO が 99.9％ ではなく 99.95％ になるようなフローを設計した場合の推定コストと比較されます。 意思決定者は、収益損失のリスクが、それを防ぐために必要な追加コストや管理負担を上回るかどうかを議論する必要があります。
フローを調べてターゲットの完全なリストを作成する際は、このパターンに従ってください。
信頼性の目標はパフォーマンスの目標とは異なることに注意してください。 信頼性の目標は、可用性と回復に重点を置いています。 信頼性の目標を設定するには、まず最も広範な要件を定義し、次に高レベルの要件を満たすためのより具体的なメトリクスを定義します。
最高レベルの信頼性と回復要件、および関連する指標には、たとえば、すべての地域で 99.9% のアプリケーション可用性や、南北アメリカ地域で 5 時間の目標 RTO が含まれる場合があります。 これらのタイプのターゲットを定義すると、それらのターゲットに関係する重要なフローを特定するのに役立ちます。 次に、コンポーネント レベルのターゲットを検討できます。
可用性メトリクス
可用性ターゲットは、SLO、SLA、SLI メトリックに対応します。
SLO と SLA
可用性メトリックは、SLA を定義するために使用する SLO と相関します。 ワークロード SLO は、特定の期間に許容されるダウンタイムの量を決定します (たとえば、1 か月あたり 1 時間未満)。 SLOターゲットを確実に満たすには、各コンポーネントのSLAを確認してください。 Microsoft
SLOを 確立するには、次の点を考慮してください:
今後 1 ～ 2 年間のワークロードの非機能要件 (ピーク要求率、同時ユーザーなど)。
特定の期間にわたって何を測定できるかに関する利用可能な指標です。 このデータは、どの SLI を指定するかを示します。
個々のワークロード コンポーネントの SLA を収集した後、複合 SLA を計算します。 複合 SLA は、ワークロードのターゲット SLO と一致する必要があります。 複合 SLA の計算には、アーキテクチャ設計に応じていくつかの要素が関係します。
適切な SLO を定義するには、時間と慎重な検討が必要です。 ビジネス関係者は信頼性の許容範囲を理解する必要があります。 このフィードバックはターゲットに通知される必要があります。
SLA 値
次の表では、共通の SLA 値を定義します。
| SLA | 週あたりのダウンタイム | 1 か月あたりのダウンタイム | 年あたりのダウンタイム |
|---|---|---|---|
| 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 を構築する際は、これらの違いを考慮してください。 重要度の低いフローには、一時的に利用できなくなっても顧客エクスペリエンスに影響しないため、計算から除外する必要があるコンポーネントが含まれている場合があります。
SLI
SLI は、SLO に寄与するコンポーネント レベルの指標であると考えてください。 最も重要な SLI は、顧客の観点から重要なフローに影響を与えるものです。 多くのフローでは、SLI にはレイテンシー、スループット、エラー率、可用性が含まれます。 適切な SLI は、SLO に違反するリスクがあるかどうかを特定するのに役立ちます。 可能であれば、SLI を特定の顧客に関連付けます。
無駄なメトリックの収集を避けるには、フローごとに SLI の数を制限します。 可能であれば、フローごとに 3 つの SLI を目指します。
回復メトリック
回復ターゲットは、RTO、RPO、MTTR、MTBF メトリックに対応します。 可用性目標とは対照的に、これらの測定の回復目標はSLAに大きく依存しません。 Microsoft Microsoft RTOおよびRPO保証は、 SQL Database などの一部の製品に対してのみ公開されます。
現実的なリカバリ目標の定義は、故障モード分析、事業継続とディザスター リカバリーの計画とテストに依存します。 この作業を終了する前に、関係者と目標について話し合い、理解できる限りアーキテクチャ設計が復旧目標をサポートするようにしてください。 回復メトリックについて徹底的にテストされていないワークロードの部分には SLA を保証する必要がないことを関係者に明確に伝えます。 ワークロードの更新に伴い、リカバリ ターゲットが時間の経過とともに変更される可能性があることを、関係者に理解してもらうようにします。 ユーザー エクスペリエンスを向上させるために新しいテクノロジーを採用すると、ワークロードがより複雑になる可能性があります。 これらの変更により、回復メトリックが増加または減少する可能性があります。
注意
MTBF を定義して保証するのは難しい場合があります。 サービスとしてのプラットフォーム (PaaS) またはサービスとしてのソフトウェア (SaaS) は、クラウド プロバイダーからの通知なしに障害が発生したり回復したりする可能性があり、そのプロセスはユーザーに対して完全に透過的です。 このメトリクスのターゲットを定義する場合は、管理下にあるコンポーネントのみを対象とします。
正常性モデルの作成
信頼性のターゲットのために収集したデータを使用して、各ワークロードと関連する重要なフローの正常性モデルを構築します。 正常性モデルは、フローとワークロードの 正常性、 劣化、および異常* な状態を定義します。 それぞれの状態は適切な運用優先順位付けを保証します。 このモデルは、信号機モデル とも呼ばれます。 モデルは、健全な場合は緑、劣化した場合は黄色、不健全な場合は赤を割り当てます。 正常性モデルを使用すると、フローの状態が正常から劣化または不健全に変化したタイミングを把握できます。
正常、劣化、異常な状態をどのように定義するかは、信頼性の目標によって異なります。 状態を定義する方法の例をいくつか示します。
グリーンまたは正常 な状態は、主要な非機能要件と目標が完全に満たされており、リソースが最適に使用されていることを示します。
黄色または劣化 状態は、フローのひとつ以上のコンポーネントが定義されたしきい値に対して警告を発しているが、フローは動作していることを示します。 たとえば、ストレージのスロットルが検出されたとします。
赤または不健全な 状態は、信頼性の目標で許容される期間よりも長い間、劣化が続いているか、フローが利用できなくなったことを示します。
注意
正常性モデルでは、すべてのエラーを同じように扱うべきではありません。 ヘルス モデルでは、 一時的なエラー と 非一時的なエラー を区別する必要があります。 予想される一過性だが復旧可能な故障と、真の災害状態を明確に区別する必要があります。
このモデルは、継続的改善の原則に基づいて開発、運用される監視と警告戦略を使用して機能します。 ワークロードが進化するにつれて、正常性モデルもそれに応じて進化する必要があります。
監視とアラート設定に関する詳細なガイダンスについては、正常性監視 ガイドを参照してください。
ビジュアル化
運用チームとワークロード関係者にワークロード健全性モデルのリアルタイムのステータスと全体的な傾向を常に周知するために、監視ソリューションに ダッシュボード を作成することを検討してください。 関係者と視覚化ソリューションについて話し合い、関係者が評価し、利用しやすい情報を確実に提供できるようにします。 また、生成されたレポートを毎週、毎月、四半期ごとに確認したい場合もあります。
Power Platform の促進
Power Platform SLAは、稼働時間と接続性に関するコミットメントを提供します。 Microsoft サービスごとに SLA が異なり、サービス内の SKU ごとに SLA が異なる場合もあります。 詳細については、オンライン サービスのサービス レベル アグリーメント を参照してください。
Power Platform SLA には、SLA が満たされていない場合にサービス クレジットを取得する手順と、各サービスの可用性の定義が含まれています。 SLA のその側面は、強制ポリシーとして機能します。
Microsoft ビジネス アプリケーションは、Dynamics 365およびSaaSアプリケーションのすべての 運用タイプ 環境にビジネス継続性と災害復旧 (BCDR) 機能を提供します。 Power Platform Microsoft の地域的な停止時に運用環境データの耐エラー性能を確保する方法について学習します。
組織の整合性
クラウド導入フレームワークは、組織全体の監視に関連する SLO と SLI の推奨事項に関するガイダンスを提供します。
詳細については、クラウド監視 SLO を参照してください。
信頼性チェックリスト
完全なレコメンデーションのセットを参照してください。