REL11-BP02 正常なリソースにフェイルオーバーする - 信頼性の柱
実装のガイダンス リソース

REL11-BP02 正常なリソースにフェイルオーバーする

リソース障害の発生時に、正常なリソースが引き続きリクエストに対応します。ロケーション障害 (アベイラビリティーゾーンや AWS リージョン など) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。

サービスを設計するときは、リソース、アベイラビリティーゾーン、またはリージョンに負荷を分散します。そのため、個々のリソースの障害は、残りの正常なリソースにトラフィックをシフトすることによって緩和できます。障害発生時にサービスがどのように検出され、ルーティングされるかを検討してください。

障害復旧を念頭に置いてサービスを設計します。AWS では、障害からの復旧時間とデータへの影響を最小限に抑えるサービスを設計しています。当社のサービスは主にデータストアを使用しており、リクエストが認識されるのは、リージョン内の複数のレプリカにわたりデータが永続的に保存された後です。これらのサービスは、セル単位の分離とアベイラビリティーゾーンにより提供される障害切り分けを活用するように構成されています。当社は、運用上の手順の多くで自動化を幅広く使用しています。また、中断から迅速に復旧するために、置換と再起動の機能を最適化しています。

フェイルオーバーを可能にするパターンとデザインは、AWS プラットフォームサービスごとに異なります。AWS ネイティブマネージドサービスの多くは、ネイティブに複数のアベイラビリティーゾーン (Lambda や API Gateway など) に対応しています。他の AWS サービス (EC2 や EKS など) では、AZ 間でのリソースまたはデータストレージのフェイルオーバーをサポートするための特定のベストプラクティス設計が必要です。

モニタリングは、フェイルオーバーリソースが正常であることを確認し、リソースのフェイルオーバーの進行状況を追跡して、ビジネスプロセスの復旧をモニタリングするために設定する必要があります。

期待される成果: システムは、新しいリソースを自動または手動で使用してパフォーマンスの低下から復旧できます。

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

  • 障害を想定した計画が、計画と設計の段階に含まれていない。

  • RTO と RPO が確立されていない。

  • モニタリングが不十分で、障害が発生しているリソースを検出できない。

  • 障害ドメインの適切な隔離。

  • マルチリージョンのフェイルオーバーが考慮されていない。

  • フェイルオーバーを決定する際の障害検出の感度が高すぎる、または過剰である。

  • フェイルオーバー設計のテストや検証を行っていない。

  • オートヒーリングのオートメーションを実行したが、ヒーリングが必要とされたことは通知しない。

  • すぐにフェイルバックするのを防ぐための減衰期間を十分に設けていない。

このベストプラクティスを活用するメリット: 適切に機能低下し、迅速に回復することで、障害発生時でも信頼性を維持する耐障害性の高いシステムを構築できます。

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

実装のガイダンス

AWS のサービス ( Elastic Load Balancing および Amazon EC2 Auto Scaling) は、複数のリソースおよびアベイラビリティーゾーンへの負荷分散に役立ちます。そのため、個々のリソース (EC2 インスタンスなど) の障害や、アベイラビリティーゾーンの障害を、残りの正常なリソースにトラフィックをシフトすることによって緩和できます。

マルチリージョンのワークロードの場合、設計はさらに複雑です。たとえば、クロスリージョンリードレプリカを使用すると、データを複数の AWS リージョン にデプロイできます。ただし、リードレプリカをプライマリに昇格させ、トラフィックを新しいエンドポイントに向けるには、やはりフェイルオーバーが必要です。Amazon Route 53、Route 53 Route 53 ARC、CloudFront、AWS Global Accelerator は複数の AWS リージョン へのトラフィックのルーティングに役立ちます。

Amazon S3、Lambda、API Gateway、Amazon SQS、Amazon SNS、Amazon SES、Amazon Pinpoint、Amazon ECR、AWS Certificate Manager、EventBridge、Amazon DynamoDB などの AWS サービスは、AWS によって複数のアベイラビリティーゾーンに自動的にデプロイされます。障害が発生した場合、これらの AWS サービスはトラフィックを正常なロケーションに自動的にルーティングします。データは複数のアベイラビリティーゾーンに冗長的に保存され、使用可能な状態を維持します。

Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon EKS、または Amazon ECS の場合、マルチ AZ は設定オプションです。フェイルオーバーが開始されると、AWS はトラフィックを正常なインスタンスに転送できます。このフェイルオーバーアクションは、AWS が行うことも、必要に応じてお客様が実行することもできます。

Amazon EC2 インスタンス、Amazon Redshift、Amazon ECS タスク、または Amazon EKS ポッドの場合、デプロイ先のアベイラビリティーゾーンを選択します。一部の設計の場合、Elastic Load Balancing は異常なゾーンのインスタンスを検出し、正常なゾーンにトラフィックをルーティングするソリューションを提供します。Elastic Load Balancing は、オンプレミスのデータセンターのコンポーネントにトラフィックをルーティングすることもできます。

マルチリージョントラフィックフェイルオーバーの場合、再ルーティングでは Amazon Route 53、Route 53 ARC、AWS Global Accelerator、Route 53 Private DNS for VPCs、または CloudFront を活用して、インターネットドメインを定義し、ヘルスチェックなどのルーティングポリシーを割り当て、トラフィックを正常なリージョンにルーティングできます。AWS Global Accelerator は、アプリケーションへの固定エントリポイントとして機能する静的 IP アドレスを提供し、インターネットの代わりに AWS グローバルネットワークを使用して任意の AWS リージョン のエンドポイントにルーティングすることで、パフォーマンスと信頼性を向上させます。

実装手順

  • すべての適切なアプリケーションとサービスのフェイルオーバー設計を作成します。各アーキテクチャコンポーネントを分離し、各コンポーネントの RTO と RPO を満たすフェイルオーバー設計を作成します。

  • フェイルオーバープランに必要なすべてのサービスを使用して、下位環境 (開発環境やテスト環境など) を構成します。Infrastructure as Code (IaC) を使用してソリューションをデプロイし、再現性を確保します。

  • フェイルオーバー設計を実装してテストするために、2 つ目のリージョンなどの復旧サイトを設定します。必要に応じて、テスト用のリソースを一時的に設定して、追加コストを抑えることができます。

  • どのフェイルオーバープランを AWS で自動化するか、どのフェイルオーバープランを DevOps プロセスで自動化できるか、どのフェイルオーバープランを手動で行うかを判断します。各サービスの RTO と RPO を文書化して測定します。

  • フェイルオーバープレイブックを作成し、各リソース、アプリケーション、サービスをフェイルオーバーするためのすべての手順を含めます。

  • フェイルバックプレイブックを作成し、各リソース、アプリケーション、サービスをフェイルバックするためのすべての手順を (タイミングとともに) 含めます。

  • プレイブックを開始してリハーサルするための計画を立てます。シミュレーションとカオステストを使用して、プレイブックの手順と自動化をテストします。

  • ロケーション障害 (アベイラビリティーゾーンや AWS リージョン など) に対しては、障害のないロケーションの正常なリソースにフェイルオーバーするシステムを用意します。フェイルオーバーテストの前に、クォータ、自動スケーリングのレベル、実行中のリソースを確認してください。

リソース

関連する Well-Architected のベストプラクティス

関連するドキュメント:

関連する例: