回復力に関する責任共有モデル - 信頼性の柱

回復力に関する責任共有モデル

回復力については、AWS とお客様で責任を共有します。ディザスタリカバリ (DR) と可用性が回復力の一環として、この責任共有モデルにおいてどのように運用されるのかを理解することが重要です。

AWS の責任 - クラウドの回復力

AWS は、AWS クラウドで提供されるすべてのサービスを実行するインフラストラクチャの回復力について責任を負います。このインフラストラクチャは、 AWS クラウドサービスを実行するハードウェア、ソフトウェア、ネットワーキング、施設で構成されています。AWS は、商業的に合理的な努力を払ってこれらの AWS クラウドサービスを利用可能にし、AWS サービス レベル アグリーメント (SLA) を満たすか、それを超えるサービスの可用性を確保します。

AWS グローバルクラウドインフラストラクチャは、お客様が回復力の高いワークロードアーキテクチャを構築できるように設計されています。各 AWS リージョンは完全に分離されており、複数のアベイラビリティーゾーンで構成されています。アベイラビリティーゾーンは、インフラストラクチャの物理的に分離された部分です。アベイラビリティーゾーンは、ワークロードの回復力に影響を及ぼす可能性のある障害を分離し、リージョン内のその他のゾーンへの影響を回避します。ただし、同時に AWS リージョン内のすべてのゾーンは、高帯域幅、低レイテンシーのネットワーキングで相互接続されています。ゾーン間をつなぐのは、高スループット、低レイテンシーのネットワーキングを提供する、完全な冗長性を備えた専用メトロファイバーです。ゾーン間のすべてのトラフィックは暗号化されています。ゾーン間の同期レプリケーションを実行するために、十分なネットワークパフォーマンスが提供されます。アプリケーションを AZ 間でパーティショニングすると、企業は、停電、落雷、竜巻、台風などの問題からよりよく隔離され、保護されます。

お客様の責任 - クラウドの回復力

お客様の責任は、選択した AWS クラウドサービスによって異なります。選択したサービスにより、お客様が回復力に関する責任の一環として実行する必要がある、設定作業の量が決まります。例えば、Amazon Elastic Compute Cloud (Amazon EC2) のようなサービスでは、必要となる回復力の設定と管理をすべてお客様が実行する必要があります。Amazon EC2 インスタンスをデプロイするお客様は、複数の場所 (AWS アベイラビリティーゾーンなど) に Amazon EC2 インスタンスをデプロイし、自動スケーリングなどのサービスを使用して自己修復を実装し、インスタンスにインストールされたアプリケーションに回復力のあるワークロードアーキテクチャのベストプラクティスを使用する責任があります。Amazon S3 や Amazon DynamoDB などのマネージドサービスについては、インフラストラクチャレイヤー、オペレーティングシステム、プラットフォームの運用を AWS が行い、お客様はエンドポイントにアクセスしてデータを保存、取得します。お客様は、バックアップ、バージョニング、レプリケーション戦略など、データの回復力を管理する責任があります。

AWS リージョン内の複数のアベイラビリティーゾーンにワークロードをデプロイすることは、問題を単一のアベイラビリティーゾーンに分離することでワークロードを保護するように設計された高可用性戦略の一環です。これにより、その他のアベイラビリティーゾーンの冗長性を使用して、リクエストの処理を継続できます。マルチ AZ アーキテクチャは、ワークロードをより適切に分離し、停電、落雷、竜巻、地震などの問題から保護するように設計された DR 戦略の一環でもあります。DR 戦略として、複数の AWS リージョンを利用することもできます。例えば、アクティブ/パッシブ設定では、アクティブなリージョンがリクエストを処理できなくなった場合に、ワークロードのサービスはアクティブなリージョンから DR リージョンにフェイルオーバーします。

回復力の責任共有モデルを説明するグラフ。

お客様と AWS の、クラウド内およびクラウドの回復力に対する責任。

お客様は、AWS サービスを使用して回復力の目標を達成できます。お客様は、システムの以下の側面を管理して、クラウド内の回復力を実現する責任を負います。特定の各サービスの詳細については、「AWS のドキュメント」を参照してください。

ネットワーキング、クォータ、制約

  • この分野の責任共有モデルのベストプラクティスについては、「基礎」で詳しく説明しています。

  • 必要に応じて、含めるサービスの Service Quotas と制約を把握し、予想される負荷リクエストの増加に基づいて、スケーリングのための十分な余裕を持ってアーキテクチャを計画します。

  • 可用性、冗長性、スケーラビリティに優れたネットワークトポロジを設計します。

変更管理と運用上の回復力

オブザーバビリティ管理と障害管理

ワークロードアーキテクチャ

  • ワークロードアーキテクチャには、ビジネスドメインに関するサービスを設計する方法、障害を防ぐために SOA と分散システム設計を適用する方法、スロットリング、再試行、キュー管理、タイムアウト、緊急対策などの機能を組み込む方法が含まれます。

  • ベストプラクティスとジャンプスタートの実装に合わせて、実証済みの AWS ソリューション、Amazon Builders Library、サーバーレスパターンを活用します。

  • 継続的な改善を採用すると、システムを分散サービスに分解し、スケーリングとイノベーションを加速できます。AWS マイクロサービスガイダンスとマネージドサービスオプションを使用して、変更とイノベーションを導入する能力を簡素化し、高速化します。

重要なインフラストラクチャの継続的テスト

  • 信頼性のテストでは、機能レベル、パフォーマンスレベル、カオスレベルでのテストと、インシデント分析とゲームデープラクティスを採用して、十分に把握していない問題を解決するための専門知識を構築します。

  • すべてをクラウドに移行した (オールイン) アプリケーションとハイブリッドアプリケーションの両方で、問題発生時やコンポーネントの停止時にアプリケーションがどのように動作するかを把握しておくと、停止から迅速かつ確実に復旧できます。

  • 繰り返し可能な実験を作成し、文書化して、期待どおりにいかない場合にシステムがどのように動作するかを把握しておきます。このようなテストは、全体的な回復力の有効性を証明するものであり、実際の障害シナリオに直面する前に、運用手順のフィードバックループを提供します。