# 信頼性
信頼性の柱には、意図した機能を期待どおりに、正しく、一貫して実行するワークロードの能力が含まれます。これには、ワークロードのライフサイクル全体を通じてワークロードを運用およびテストする能力が含まれます。本資料では、AWS に信頼性の高いワークロードを実装するための、詳細なベストプラクティスのガイダンスを提供します。
**Topics**
+ [回復力に関する責任共有モデル](shared-responsibility-model-for-resiliency.md)
+ [設計原則](design-principles.md)
+ [定義](definitions.md)
+ [可用性ニーズを理解する](understanding-availability-needs.md)
# 回復力に関する責任共有モデル
回復力については、AWS とお客様で責任を共有します。ディザスタリカバリ (DR) と可用性が回復力の一環として、この責任共有モデルにおいてどのように運用されるのかを理解することが重要です。
**AWS の責任 - クラウドの回復力**
AWS は、AWS クラウドで提供されるすべてのサービスを実行するインフラストラクチャの回復力について責任を負います。このインフラストラクチャは、 AWS クラウドサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設で構成されています。AWS は、商業的に合理的な努力を払ってこれらの AWS クラウドサービスを利用可能にし、[AWS サービス レベル アグリーメント (SLA)](https://aws.amazon.com/legal/service-level-agreements/) を満たすか、それを超えるサービスの可用性を確保します。
[AWS グローバルクラウドインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)は、お客様が回復力の高いワークロードアーキテクチャを構築できるように設計されています。各 AWS リージョンは完全に分離されており、複数の[アベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones)で構成されています。アベイラビリティーゾーンは、インフラストラクチャの物理的に分離された部分です。アベイラビリティーゾーンは、ワークロードの回復力に影響を及ぼす可能性のある障害を分離し、リージョン内のその他のゾーンへの影響を回避します。ただし、同時に AWS リージョン内のすべてのゾーンは、高帯域幅、低レイテンシーのネットワーキングで相互接続されています。ゾーン間をつなぐのは、高スループット、低レイテンシーのネットワーキングを提供する、完全な冗長性を備えた専用メトロファイバーです。ゾーン間のすべてのトラフィックは暗号化されています。ゾーン間の同期レプリケーションを実行するために、十分なネットワークパフォーマンスが提供されます。アプリケーションを AZ 間でパーティショニングすると、企業は、停電、落雷、竜巻、台風などの問題からよりよく隔離され、保護されます。
**お客様の責任 - クラウドの回復力**
お客様の責任は、選択した AWS クラウドサービスによって異なります。選択したサービスにより、お客様が回復力に関する責任の一環として実行する必要がある、設定作業の量が決まります。例えば、Amazon Elastic Compute Cloud (Amazon EC2) のようなサービスでは、必要となる回復力の設定と管理をすべてお客様が実行する必要があります。Amazon EC2 インスタンスをデプロイするお客様は、[複数の場所 (AWS アベイラビリティーゾーンなど) に Amazon EC2 インスタンスをデプロイ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)し、自動スケーリングなどのサービスを使用して[自己修復を実装](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)し、インスタンスにインストールされたアプリケーションに[回復力のあるワークロードアーキテクチャのベストプラクティス](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)を使用する責任があります。Amazon S3 や Amazon DynamoDB などのマネージドサービスについては、インフラストラクチャレイヤー、オペレーティングシステム、プラットフォームの運用を AWS が行い、お客様はエンドポイントにアクセスしてデータを保存、取得します。お客様は、バックアップ、バージョニング、レプリケーション戦略など、データの回復力を管理する責任があります。
AWS リージョン内の複数のアベイラビリティーゾーンにワークロードをデプロイすることは、問題を単一のアベイラビリティーゾーンに分離することでワークロードを保護するように設計された高可用性戦略の一環です。これにより、その他のアベイラビリティーゾーンの冗長性を使用して、リクエストの処理を継続できます。マルチ AZ アーキテクチャは、ワークロードをより適切に分離し、停電、落雷、竜巻、地震などの問題から保護するように設計された DR 戦略の一環でもあります。DR 戦略として、複数の AWS リージョンを利用することもできます。例えば、アクティブ/パッシブ設定では、アクティブなリージョンがリクエストを処理できなくなった場合に、ワークロードのサービスはアクティブなリージョンから DR リージョンにフェイルオーバーします。
![\[回復力の責任共有モデルを説明するグラフ。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png)
お客様は、AWS サービスを使用して回復力の目標を達成できます。お客様は、システムの以下の側面を管理して、クラウド内の回復力を実現する責任を負います。特定の各サービスの詳細については、「[AWS のドキュメント](https://docs.aws.amazon.com/index.html)」を参照してください。
**ネットワーキング、クォータ、制約**
+ この分野の責任共有モデルのベストプラクティスについては、「[基礎](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html)」で詳しく説明しています。
+ 必要に応じて、含めるサービスの [Service Quotas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html) と制約を把握し、予想される負荷リクエストの増加に基づいて、スケーリングのための十分な余裕を持ってアーキテクチャを計画します。
+ 可用性、冗長性、スケーラビリティに優れた[ネットワークトポロジ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)を設計します。
**変更管理と運用上の回復力**
+ [変更管理](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html)には、環境に変更を導入および管理する方法が含まれます。[変更を実装する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html)には、ランブックを構築し、アプリケーションとインフラストラクチャのデプロイ戦略を最新の状態に保つ必要があります。
+ [ワークロードリソースをモニタリングする](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html)ための回復力のある戦略では、技術メトリクスとビジネスメトリクス、通知、自動化、分析を含むすべてのコンポーネントを考慮します。
+ クラウド内のワークロードは[、使用量の減損や変動に伴う需要のスケーリングの変化に適応する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html)必要があります。
**オブザーバビリティ管理と障害管理**
+ ワークロードが[コンポーネントの障害に耐えられる](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)ようにヒーリングを自動化するには、モニタリングによる障害の監視が必要です。
+ [障害管理](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html)には、[データのバックアップ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html)、ワークロードがコンポーネントの障害に耐えられるようにするためのベストプラクティスの適用、[ディザスタリカバリの計画](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)が必要です。
**ワークロードアーキテクチャ**
+ [ワークロードアーキテクチャ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)には、ビジネスドメインに関するサービスを設計する方法、障害を防ぐために SOA と分散システム設計を適用する方法、スロットリング、再試行、キュー管理、タイムアウト、緊急対策などの機能を組み込む方法が含まれます。
+ ベストプラクティスとジャンプスタートの実装に合わせて、実証済みの [AWS ソリューション](https://aws.amazon.com/solutions/)、[Amazon Builders Library](https://aws.amazon.com/builders-library/)、[サーバーレスパターン](https://serverlessland.com/patterns)を活用します。
+ 継続的な改善を採用すると、システムを分散サービスに分解し、スケーリングとイノベーションを加速できます。[AWS マイクロサービス](https://aws.amazon.com/microservices/)ガイダンスとマネージドサービスオプションを使用して、変更とイノベーションを導入する能力を簡素化し、高速化します。
**重要なインフラストラクチャの継続的テスト**
+ [信頼性のテスト](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html)では、機能レベル、パフォーマンスレベル、カオスレベルでのテストと、インシデント分析とゲームデープラクティスを採用して、十分に把握していない問題を解決するための専門知識を構築します。
+ すべてをクラウドに移行した (オールイン) アプリケーションとハイブリッドアプリケーションの両方で、問題発生時やコンポーネントの停止時にアプリケーションがどのように動作するかを把握しておくと、停止から迅速かつ確実に復旧できます。
+ 繰り返し可能な実験を作成し、文書化して、期待どおりにいかない場合にシステムがどのように動作するかを把握しておきます。このようなテストは、全体的な回復力の有効性を証明するものであり、実際の障害シナリオに直面する前に、運用手順のフィードバックループを提供します。
# 設計原則
クラウドには、信頼性の向上に役立ついくつかの原則があります。ベストプラクティスについてこれから説明しますが、以下の原則を覚えておいてください。
+ **障害から自動的に復旧する:** システムでワークロードの主要業績評価指標 (KPI) をモニタリングすることで、しきい値を超えた場合に自動化を実行できます。この場合の KPI は、サービスの運用の技術的側面ではなく、ビジネス価値に関する指標である必要があります。これにより、障害発生時の自動通知と追跡が可能になり、障害に対処する、または障害を修正するための復旧プロセスを自動化できます。より複雑な自動化を使用すると、障害が発生する前に修正を予期できます。
+ **リカバリ手順をテストする:** オンプレミス環境では、ワークロードが特定のシナリオで動作することを実証するためのテストを行うことがよくあります。復旧戦略を検証するためにテストを実施することはあまりありません。クラウドでは、どのようにワークロードに障害が発生するかをテストし、復旧の手順を検証できます。オートメーションを使用してさまざまな障害をシミュレートすることも、以前に障害が発生したシナリオを再現することもできます。このアプローチでは、実際の障害シナリオが発生する前にテストを行い、修正できる障害経路が公開されるため、リスクが軽減されます。
+ **水平方向にスケールしてワークロード全体の可用性を高める:** 1 つの大規模なリソースを複数の小規模なリソースに置き換えることで、1 つの障害がシステム全体に及ぼす影響を軽減します。リクエストを複数の小規模なリソースに分散することで、一般的な障害点を共有しないようにします。
+ **容量の推測をやめる:** オンプレミスのワークロードにおける障害の一般的な原因はリソースの飽和状態で、ワークロードに対する需要がそのワークロードの容量を超えたときに発生します (サービス妨害攻撃の目標となることがよくあります)。クラウドでは、需要とワークロード使用率をモニタリングし、リソースの追加と削除を自動化することで、プロビジョ二ングが過剰にも過小にもならない、需要を満たす最適なレベルを維持できます。制限はまだありますが、いくつかのクオータは制御可能で、そのほかのクオーターも管理できます (「[Service Quotas と制約の管理](manage-service-quotas-and-constraints.md)」を参照)。
+ **自動化の変更を管理する**: インフラストラクチャに対する変更は、自動化を使用して実行する必要があります。管理する必要がある変更には、自動化に対する変更が含まれており、それを追跡して確認することができます。
# 定義
このホワイトペーパーでは、クラウドの信頼性を対象として、次の 4 つの分野のベストプラクティスについて説明します。
+ 基礎
+ ワークロードアーキテクチャ
+ 変更管理
+ 障害管理
信頼性を実現するには、基盤、つまりワークロードに対して Service Quotas とネットワークトポロジを適応させた環境を作ることから始める必要があります。分散システムにおけるワークロードのアーキテクチャは、障害を防止および軽減するように設計する必要があります。ワークロードは需要または要件の変化に対応する必要があり、障害を検出して自動的に復旧するように設計する必要があります。
**Topics**
+ [回復力、および信頼性のコンポーネント](resiliency-and-the-components-of-reliability.md)
+ [利用可能な状況](availability.md)
+ [ディザスタリカバリ (DR) 目標](disaster-recovery-dr-objectives.md)
# 回復力、および信頼性のコンポーネント
クラウド内のワークロードの信頼性はいくつかの要因に依存しますが、その基本となるのは回復力です。
+ **回復力**は、インフラストラクチャまたはサービスの中断から復旧し、需要に合わせて動的にコンピューティングリソースを取得し、設定ミスや一時的なネットワーク問題のような障害を軽減するワークロードの能力です。
ワークロードの信頼性に影響を与えるその他の要因には、次のようなものがあります。
+ 運用上の優秀性。これには、変更の自動化、障害対応のためのプレイブックの利用、アプリケーションに本番運用の準備ができていることを確認するための運用準備状況レビュー (ORR) が含まれます。
+ セキュリティ。これには、可用性に影響を与える、悪意のある行為によるデータまたはインフラストラクチャへの危害を防止することが含まれます。例えば、データの安全性を確保するには、バックアップを暗号化します。
+ パフォーマンス効率。これには、最大リクエストレートの設計とワークロードに対するレイテンシーの最小化が含まれます。
+ コスト最適化。これには、静的な安定性を達成するために EC2 インスタンスにより多く費用をかけるか、より多くの容量が必要な場合に自動スケーリングに依存するかどうかといったトレードオフが含まれます。
回復力は、このホワイトペーパーにおける最大の焦点です。
他の 4 つの要素も重要であり、[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)のそれぞれの柱によってカバーされています ここに記載されているベストプラクティスの多くは、信頼性の面にも対応しますが、焦点は回復力です。
# 利用可能な状況
可用性 (サービス可用性とも呼ばれます) は、回復力を数量的に測定するためによく使用されるメトリクスであると同時に、的を絞った回復力目標でもあります。
+ **可用性**は、ワークロードが使用可能な時間の割合です。
「使用可能」とは、取り決めた機能を必要なときに正常に実行できることを意味します。
この割合 (%) は、月、年、直近 3 年などの時間単位で計算します。可能な限り厳密に解釈すると、予定された中断や予定外の中断を含め、アプリケーションが正常に動作しないときは、可用性が下がることになります。可用性は次のように定義されます。
![\[\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ 可用性は、一定期間 (通常は 1 か月または 1 年) の稼働時間の割合 (例: 99.9%) です。
+ 一般的には「9 の数」で省略して表現され、例えば、「ファイブナイン」は 99.999% の可用性という意味になります。
+ 一部のお客様は、計画されたサービスのダウンタイム (計画メンテナンスなど) を計算式の合計時間から除外することを選択します。ただし、このような時間にもユーザーがサービスを利用したい可能性があるため、この方法はお勧めしません。
アプリケーションの可用性における一般的な設計目標と、この目標の達成中、1 年以内に中断が発生する可能性のある最大時間を以下の表に示します。この表には、可用性レベルごとによく知られているアプリケーションの種類の例が示されています。このドキュメント全体を通して、これらの可用性の値を参考にします。
| 利用可能な状況 | 最大利用不可能時間 (年間) | アプリケーションのカテゴリ |
| --- | --- | --- |
| 99% | 3 日と 15 時間 | バッチ処理、データの抽出、転送、ロードジョブ |
| 99.9% | 8 時間 45 分 | ナレッジ管理、プロジェクト追跡などの社内ツール |
| 99.95% | 4 時間 22 分 | オンラインコマース、POS |
| 99.99% | 52 分 | 動画配信、ブロードキャストワークロード |
| 99.999% | 5 分 | ATM トランザクション、通信ワークロード |
**リクエストに基づく可用性の測定。**サービスの場合、「使用可能な時間」の代わりに、成功したリクエスト数と失敗したリクエスト数をカウントする方が容易かもしれません。この場合、次の計算を使用できます。
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
これは多くの場合、1 分間または 5 分間で測定されます。次に、これらの期間の平均から、1 か月の稼働時間率 (時間ベースの可用性測定) を計算できます。特定の期間に受信したリクエストがなかった場合、その時間の可用性は 100% になります。
**ハードな依存関係を持つ可用性を計算する。**多くのシステムは他のシステムとハードな依存関係にあり、依存するシステムでサービス停止が起こると、呼び出す側のシステムにも影響します。この反対はソフトな依存関係で、依存関係にあるシステムに障害が起こると、アプリケーションがそれを補完します。ハードな依存関係が存在する場合、呼び出す側のシステムにおける可用性は、依存するシステムの可用性の積になります。例えば、可用性 99.99% を実現するように設計されたシステムが、同様に可用性が 99.99% である他の 2 つのシステムに依存する場合、このワークロードの可用性は、理論的には 99.97% になります。
Availinvok × Avail*dep1* × Avail*dep2* = Availworkload
99.99% × 99.99% × 99.99% = 99.97%
したがって、お客様自身で可用性を計算する場合は、このシステムとの依存関係と、それらの可用性の設計目標を理解することが重要です。
**冗長コンポーネントの可用性を計算する** 独立した、冗長化されたコンポーネント (複数のアベイラビリティーゾーンの冗長リソースなど) をシステムが使用する場合、理論的な可用性は、100% からそのコンポーネントの障害率の積を引いたものになります。例えば、あるシステムが 2 つの独立したコンポーネントを利用し、それぞれ 99.9% の可用性を持つ場合、この依存関係の実効可用性は 99.9999% になります。
![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99.9999% = 100% − (0.1%×0.1%)
*ショートカット計算*: 計算内のすべてのコンポーネントの可用性が 9 のみで構成されている場合は、9 の桁の数を合計するだけで答えが得られます。上記の例では、2 つの独立した、冗長なコンポーネントは 9 が 3 つの可用性を持つため、結果は 9 が 6 つになります。
**依存するシステムの可用性を計算する** 依存関係によっては、多くの AWS のサービスの可用性設計目標など、可用性に関するガイダンスを提供するものもあります。ただし、これを利用できない場合 (メーカーが可用性情報を公開していないコンポーネントなど)、推測する 1 つの方法は、**平均故障間隔 (MTBF)** と**平均復旧時間 (MTTR)** を特定することです。可用性の推測値は、次の方法で計算できます。
![\[\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
例えば、MTBF が 150 日、MTTR が 1 時間なら、可用性の推測値は 99.97% です。
詳細については、可用性の計算に役立つ、「[Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)」を参照してください。
**可用性のコスト** 通常は、アプリケーションの可用性レベルを高く設計すればコストは増大するため、設計に着手する前に可用性の正確なニーズを特定することが重要です。可用性レベルが高いと、網羅的な障害シナリオのもとで、厳しいテスト条件と検証条件が課されることになります。このような場合、あらゆる種類の障害からの回復に自動化が必要になり、システム運用のすべての側面が同様に構築され、同じ基準に基づいてテストされることが必要になります。例えば、容量の追加や削除、更新されたソフトウェアや設定変更のデプロイまたはロールバック、システムデータの移行などが、可用性の設計目標を満たすように実施される必要があります。極めて高いレベルの可用性を前提にソフトウェア開発のコストを積み上げると、システムのデプロイ速度が遅くなるため、イノベーションが難しくなります。このため、これに対するガイダンスは、基準を適用しながら、システム運用におけるライフサイクル全体にわたって適切な可用性の目標を検討することです。
可用性の設計目標が高いシステムにおけるもう一つのコスト増大の原因は、依存関係にあるシステムの選択にあります。目標レベルが高ければ、依存関係を持つソフトウェアまたはサービスの選択肢が狭くなり、前述のようにそれに基づくコストも増大していきます。可用性の設計目標が高くなるほど、リレーショナルデータベースのような多目的のサービスは少なくなり、目的に特化したサービスが多くなります。これは、後者の方が評価、テスト、自動化が容易で、含まれているが使用されていない機能との予期せぬ相互作用の可能性が低いためです。
# ディザスタリカバリ (DR) 目標
可用性の目標に加えて、回復力戦略には、災害イベント時にワークロードを復旧する戦略に基づいた、ディザスタリカバリ (DR) 目標も含める必要があります。ディザスタリカバリは、自然災害、大規模な技術的障害、または攻撃やエラーなどの人為的脅威に対応する、1 回限りの復旧目標に焦点を当てています。これは、コンポーネントの障害、負荷の急増、ソフトウェアのバグに対応して、一定期間の平均回復力を測定する可用性とは異なります。
組織によって定義された**目標復旧時間 (RTO)** RTO とは、サービスが中断してから復旧するまでに経過した時間の、許容される最大値のことです。これにより、サービスが使用不可のときに許容される時間枠が決まります。
組織によって定義された**目標復旧時点 (RPO)** RPO とは、データが最後に復旧した時点を起点とする経過時間の、許容される最大値のことです。これにより、最後の回復時点からサービスが中断されるまでの間に許容できるデータ損失の程度が決まります。
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*RPO（目標復旧時点）、RTO（目標復旧時間）、災害イベントの関係。*
RTO は、停止の開始からワークロード復旧までの時間を測定する点で、MTTR (平均復旧時間) と似ています。ただし、MTTR は、一定期間にわたって複数の可用性に影響を与えるイベントに対して取られる平均値であり、RTO は、可用性に影響を与える*単一*のイベントの目標値、つまり許容される最大値です。
# 可用性ニーズを理解する
最初に、アプリケーションの可用性をアプリケーション全体の単一ターゲットとして考えてしまうケースがよくあります。しかし多くの場合、詳しく分析してみれば、アプリケーションやサービスでは、特定の側面に応じて求められる可用性の要件もさまざまであることに気付くはずです。例えば、システムによっては、既存データを取得するよりも、新規データを受信して保存する機能を優先させる場合があります。また、システムの構成や環境を変更するオペレーションよりも、リアルタイムオペレーションを優先させるシステムもあります。1 日のうち特定の時間帯に極めて高い可用性が要求されるサービスでも、その時間帯以外は長時間の中断を許容できる可能性もあります。これらは、1 つのアプリケーションを分解し、それぞれの構成要素の可用性要件を評価する方法のほんの一例です。この方法のメリットは、システム全体を最も厳格な要件に合わせて設計するのではなく、特定のニーズに応じて可用性に労力 (および費用) をかけられることです。
| 推奨事項 |
| --- |
| 各アプリケーションの固有の側面を厳密に評価し、必要に応じてビジネスニーズを反映して、可用性とディザスタリカバリの設計目標を差別化してください。 |
通常、AWS では、サービスを「データプレーン」と「コントロールプレーン」に分けて考えます。コントロールプレーンで環境を設定しつつ、データプレーンではリアルタイムのサービスを提供します。例えば、Amazon EC2 インスタンス、Amazon RDS データベース、Amazon DynamoDB テーブルの読み取り/書き込みオペレーションは、すべてデータプレーンによる操作です。逆に、EC2 インスタンスや RDS データベースの起動、DynamoDB のテーブルメタデータの追加や変更などは、すべてコントロールプレーンによる操作です。これらすべての機能には高レベルの可用性が重要となりますが、一般的にデータプレーンの可用性設計の目標は、コントロールプレーンより高くなります。したがって、高い可用性要件を持つワークロードでは、コントロールプレーンの操作に対するランタイム依存を避ける必要があります。
AWS のお客様の多くは、類似のアプローチを採用して、アプリケーションを厳密に評価し、さまざまな可用性ニーズを持つサブコンポーネントを特定しています。次に、さまざまな側面に応じた可用性設計目標の調整を行い、システムを設計するための適切な作業を行います。AWS は、99.999% 以上の可用性を持つサービスを含め、広い範囲の可用性設計目標を持つアプリケーションを開発する豊富な経験を有しています。AWSソリューションアーキテクト (SA) は、お客様の可用性目標に対する適切な設計を支援します。設計プロセスの初期段階から AWS を導入することで、当社が可用性目標の達成を支援する能力も高まります。可用性の計画は、実際のワークロードが始動する直前にだけ立てるものではありません。運用上の経験を積み、実際のイベントから学び、さまざまな種類の障害に耐えながら、設計を改良し続けることも必要です。これにより、実装を改善するための適切な作業を行うことができます。
ワークロードに求められる可用性のニーズは、ビジネスのニーズと重要度に合わせる必要があります。まず、RTO、RPO、および可用性を定義し、ビジネスにとって重要なことのフレームワークを明確にすることで、各ワークロードを評価できます。このようなアプローチでは、ワークロードの実装に関与する担当者が、フレームワークと、ワークロードがビジネスニーズに与える影響を理解している必要があります。