REL11-BP07 可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たす製品を設計する
可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たすように製品を設計します。可用性目標またはアップタイム SLA を公開するか、非公開で同意する場合は、アーキテクチャと運用プロセスが SLA をサポートするように設計されていることを確認します。
期待される成果: 各アプリケーションには、可用性の目標とパフォーマンスメトリクスの SLA が定義されています。これらのメトリクスは、ビジネス上の成果を満たすためにモニタリングおよび管理できます。
一般的なアンチパターン:
-
SLA を設定せずにワークロードを設計およびデプロイする。
-
合理的な理由やビジネス要件なしに SLA メトリクスが高すぎに設定されている。
-
依存関係とその基盤となる SLA を考慮せずに SLA を設定する。
-
回復力の共有責任モデルを考慮せずにアプリケーションが設計される。
このベストプラクティスを活用するメリット: 主要な復元力の目標に基づいてアプリケーションを設計すると、ビジネス目標と顧客の期待を満たすことができます。このような目標は、さまざまなテクノロジーを評価し、さまざまなトレードオフを考慮に入れたアプリケーション設計プロセスの促進につながります。
このベストプラクティスを活用しない場合のリスクレベル: 中
実装のガイダンス
アプリケーションの設計では、ビジネス、オペレーション、財務上の目的に基づくさまざまな要件を考慮する必要があります。運用上の要件の範囲内で、ワークロードを適切にモニタリングおよびサポートできるように、ワークロードには特定の回復性メトリクス目標が必要です。ワークロードのデプロイ後は、回復性メトリクスの設定や派生の作成を行うべきではありません。これは設計段階で定義し、さまざまな決定とトレードオフのガイドとしての役割を果たす必要があります。
-
各ワークロードには、独自の回復性メトリクスセットが必要です。このようなメトリクスは、その他のビジネスアプリケーションとは異なる場合があります。
-
依存関係を減らすと、可用性にプラスの影響を与えることができます。各ワークロードは、独自の依存関係と SLA を考慮に入れる必要があります。通常、ワークロードの目標以上の可用性目標を持つ依存関係を選択します。
-
可能であれば、依存関係が損なわれてもワークロードが正常に動作できるように、疎結合の設計を検討します。
-
コントロールプレーンの依存関係を減らします。特に、復旧時または機能低下時の依存関係を低減します。ミッションクリティカルなワークロードに対して静的安定性がある設計を評価します。リソースを節約して、ワークロード内のこのような依存関係の可用性を向上します。
-
オブザーバビリティと計測は、平均検出時間 (MTTD) と平均修復時間 (MTTR) の短縮と SLA の達成のために重要です。
-
分散システムの可用性を向上させる要素は、障害の頻度が少ない (MTBF が長い)、障害検出時間が短い (MTTD が短い)、修理時間が短い (MTTR が短い) という 3 つです。
-
ワークロードの回復性メトリクスを確立し、それを満たすことは、効果的な設計の基本となります。このような設計では、設計の複雑性、サービスの依存関係、パフォーマンス、スケーリング、コストのトレードオフを考慮する必要があります。
実装手順
-
以下の質問を検討し、ワークロードの設計を確認して、文書化します。
-
コントロールプレーンはワークロードのどの個所で使用されますか。
-
ワークロードはどのように耐障害性を実装しますか。
-
どのようなスケーリング、自動スケーリング、冗長性、高可用性コンポーネントの設計パターンがありますか。
-
どのようなデータ整合性と可用性の要件がありますか。
-
リソース節約またはリソースの静的安定性に関する考慮事項はありますか。
-
どのようなサービスの依存関係がありますか。
-
-
ステークホルダーと協力して、ワークロードアーキテクチャに基づいて SLA メトリクスを定義します。ワークロードで使用されるすべての依存関係の SLA を検討します。
-
SLA 目標の設定後、SLA を満たすようにアーキテクチャを最適化します。
-
SLA を満たす設計が定まったら、運用上の変更、プロセスの自動化、MTTD および MTTR の短縮についても重視するランブックを導入します。
-
デプロイ後、SLA についてモニタリングしてレポートを作成します。
リソース
関連するベストプラクティス:
関連ドキュメント:
関連サービス:
