SUS02-BP02 SLA を持続可能性の目標に合わせる - 持続可能性の柱
実装のガイダンスリソース

SUS02-BP02 SLA を持続可能性の目標に合わせる

持続可能性の目標に基づいてワークロードのサービスレベルアグリーメント (SLA) をレビュー、最適化して、ビジネスニーズを満たしながらワークロードをサポートするために必要なリソースを最小化します。

一般的なアンチパターン:

  • ワークロード SLA がわからない、またはあいまいである。

  • SLA を可用性とパフォーマンスのためにのみ定義している。

  • すべてのワークロードに同じ設計パターン (マルチ AZ アーキテクチャなど) を使用している。

このベストプラクティスを活用するメリット: SLA を持続可能性の目標と整合すると、ビジネスニーズを満たすと同時にリソース使用を最適化できます。

このベストプラクティスを活用しない場合のリスクレベル: 低

実装のガイダンス

SLA は、クラウドワークロードで期待できるサービスのレベルを定義します。応答時間、可用性、データ保持などです。アーキテクチャ、リソース使用量、クラウドワークロードの環境への影響にかかわります。定期的に SLA をレビューして、リソースの使用量を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。

実装手順

  • 持続可能性の目標を理解する: 炭素削減やリソース使用率の向上など、組織内の持続可能性の目標を特定します。

  • SLA の確認: SLA を評価して、ビジネス要件をサポートしているかどうかを評価します。SLA を超えている場合は、さらに見直しを行います。

  • トレードオフを理解する: ワークロードの複雑さ (大量の同時接続ユーザーなど)、パフォーマンス (レイテンシーなど)、持続可能性への影響 (必要なリソースなど) のトレードオフを理解します。通常、2 つの要素に優先順位を付けると、3 つ目の要素が犠牲になります。

  • SLA を調整する: 持続可能性への影響を大幅に削減できる事項と、サービスレベルの許容できる範囲での低下をトレードオフします。

    • 持続可能性と信頼性: 可用性の高いワークロードは、より多くのリソースを消費する傾向があります。

    • 持続可能性とパフォーマンス: より多くのリソースを使用してパフォーマンスを向上させると、環境への影響が大きくなる可能性があります。

    • 持続可能性とセキュリティ: ワークロードが過度に安全であれば、環境への影響が大きくなる可能性があります。

  • 可能であれば持続可能性 SLA を定義する: ワークロードに持続可能性 SLA を含めます。例えば、コンピューティングインスタンスの持続可能性に関する SLA として最小の使用率レベルを定義します。

  • 効率的な設計パターンを使用する: ビジネスクリティカルな機能を優先し、クリティカルでない機能にはサービスレベル (応答時間や回復時間目標など) を引き下げる AWS 上のマイクロサービスなどの設計パターンを使用します。

  • 説明責任を伝達して確立する: 開発チームや顧客を含む関連するすべての関係者と SLA を共有します。レポートを使用して SLA を追跡およびモニタリングします。SLA の持続可能性目標を達成するための説明責任を割り当てます。

  • インセンティブと報酬を使用する: インセンティブと報酬を使用して、持続可能性の目標に沿った SLA を達成または超過します。

  • 見直しと反復: SLA を定期的に見直して調整し、進化する持続可能性とパフォーマンスの目標に合致していることを確認します。

リソース

関連ドキュメント:

関連動画: