# REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する
コントロールプレーンはリソースの作成、読み取り、記述、更新、削除、一覧表示 (CRUDL) に使用される管理 API を提供し、データプレーンは日々のサービストラフィックを処理します。回復力に影響を与える可能性のあるイベントへの回復または軽減対応を実装するときは、サービスの回復、再スケーリング、復元、修復、またはフェイルオーバーに最小限のコントロールプレーンのオペレーションを使用することに焦点を当ててください。これらのパフォーマンスの低下イベント中は、データプレーンのアクションがどのアクティビティよりも優先されるはずです。
例えば、新しいコンピューティングインスタンスの起動、ブロックストレージの起動、キューサービスの記述などは、すべてコントロールプレーンのアクションです。コンピューティングインスタンスを起動後、コントロールプレーンは、容量のある物理ホストの検索、ネットワークインターフェイスの割り当て、ローカルブロックストレージボリュームの準備、認証情報の生成、セキュリティルールの追加など、複数のタスクを実行する必要があります。コントロールプレーンは複雑なオーケストレーションになりがちです。
**期待される成果:** リソースに障害が発生すると、システムは、トラフィックを障害のあるリソースから正常なリソースに移行することで、自動または手動で回復できます。
**一般的なアンチパターン:**
+ トラフィックを再ルーティングするための DNS レコードの変更への依存。
+ リソースのプロビジョニングが不十分なため、障害が発生したコンポーネントの交換をコントロールプレーンのスケーリング操作に依存。
+ あらゆるカテゴリの障害を修復するために、広範囲にわたるマルチサービス、マルチ API コントロールプレーンアクションに依存。
**このベストプラクティスを活用するメリット:** 自動修復の成功率が高くなると、平均復旧時間が短縮され、ワークロードの可用性が向上します。
**このベストプラクティスを活用しない場合のリスクレベル: 中**。特定の種類のサービス低下の場合、コントロールプレーンが影響を受けます。コントロールプレーンを広範囲に使用して修復すると、復旧時間 (RTO) と平均復旧時間 (MTTR) が長くなる可能性があります。
## 実装のガイダンス
データプレーンのアクションを制限するには、サービスの復元に必要なアクションについて各サービスを評価します。
DNS トラフィックをシフトするときは Amazon Application Recovery Controller を活用します。これらの機能により、障害から回復するアプリケーションの機能を継続的にモニタリングし、複数の AWS リージョン、アベイラビリティーゾーン、およびオンプレミスにまたがってアプリケーションの回復を管理できます。
Route 53 ルーティングポリシーにコントロールプレーンが使用されているため、復旧の際にコントロールプレーンに依存しないようにします。Route 53 データプレーンは、DNS クエリに応答し、ヘルスチェックを実行し、評価します。これらはグローバルに配布され、[「100% 利用可能」のサービスレベルアグリーメント (SLA)](https://aws.amazon.com/route53/sla/) 向けに設計されています。
Route 53 のリソースを作成、更新、削除する Route 53 管理 API およびコンソールは、コントロールプレーンで実行します。コントロールプレーンは、DNS の管理に必要な強力な一貫性と耐久性を重視するように設計されています。これを達成するために、コントロールプレーンは単一のリージョン、米国東部 (バージニア北部) に配置されています。どちらのシステムも非常に高い信頼性で構築されていますが、コントロールプレーンは SLA には含まれません。まれに、データプレーンの回復力設計によって可用性を維持できるときでも、コントロールプレーンでは維持でない場合があります。ディザスタリカバリおよびフェイルオーバーメカニズムについては、データプレーンの機能を使用して、可能な限り最善の信頼性を提供してください。
コンピューティングインフラストラクチャは静的に安定するように設計して、インシデント中にコントロールプレーンを使用しないようにします。例えば、Amazon EC2 インスタンスを使用している場合は、新しいインスタンスを手動でプロビジョニングしたり、Auto Scaling グループにインスタンスの追加を指示したりすることは避けてください。回復性を最大限に高めるには、フェイルオーバーに使用するクラスターに十分な容量をプロビジョニングしてください。この容量のしきい値を制限する必要がある場合は、エンドツーエンドのシステム全体にスロットルを設定して、限られたリソースに到達するトラフィックの合計を安全に制限してください。
Amazon DynamoDB、Amazon API Gateway、ロードバランサー、AWS Lambda サーバーレスなどのサービスでは、これらのサービスを使用するとデータプレーンを活用できます。ただし、新しい関数、ロードバランサー、API ゲートウェイ、または DynamoDB テーブルの作成はコントロールプレーンのアクションであり、イベントの準備やフェイルオーバーアクションのリハーサルとして、パフォーマンス低下の前に完了しておく必要があります。Amazon RDS では、データプレーンのアクションによりデータへのアクセスが可能になります。
データプレーン、コントロールプレーン、および、AWS が高可用性の目標を満たすサービスをいかに構築しているのか、についての詳細は、「[アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)」を参照してください。
データプレーンでの運用と、コントロールプレーンでの運用を理解します。
### 実装手順
パフォーマンス低下のイベント後に復元する必要のある各ワークロードについて、フェイルオーバーランブック、高可用性設計、自動修復設計、または HA リソース復元プランの評価を行います。コントロールプレーンのアクションとみなされる可能性のある各アクションを特定します。
コントロールアクションをデータプレーンアクションに変更することを検討します。
+ 自動スケーリング (コントロールプレーン) を事前スケールされた Amazon EC2 リソース (データプレーン) に変更します。
+ Amazon EC2 インスタンススケーリング (コントロールプレーン) を AWS Lambda スケーリング (データプレーン) に変更します。
+ Kubernetes を使用するあらゆる設計とコントロールプレーンのアクションの性質を評価します。ポッドの追加は Kubernetes のデータプレーンのアクションです。アクションはノードの追加ではなく、ポッドの追加に限定する必要があります [過剰にプロビジョニングされたノード](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/)を使用することは、コントロールプレーンのアクションを制限するための推奨される方法です。
データプレーンのアクションが同じ修復に影響を与えられる代替アプローチを検討してください。
+ Route 53 レコードの変更 (コントロールプレーン) または Amazon Application Recovery Controller (データプレーン)
+ [自動化がさらに進んだアップデート用の Route 53 ヘルスチェック](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
サービスがミッションクリティカルな場合は、影響を受けていないリージョンでより多くのコントロールプレーンとデータプレーンのアクションを実行できるように、セカンダリリージョンのサービスを検討してください。
+ プライマリリージョンの Amazon EC2 Auto Scaling または Amazon EKS と、セカンダリリージョンの Amazon EC2 Auto Scaling または Amazon EKS とを比較し、セカンダリリージョンにトラフィックをルーティングします (コントロールプレーンのアクション)。
+ セカンダリプライマリでリードレプリカを作成するか、プライマリリージョンで同じアクションを試みる (コントロールプレーンのアクション)
## リソース
**関連するベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**関連ドキュメント:**
+ [APN Partner: partners that can help with automation of your fault tolerance](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: products that can be used for fault tolerance](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: 小さなサービスに制御を任せて分散型システムのオーバーヘッドを回避する](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API (コントロールプレーンとデータプレーン)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda の実行](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (コントロールプレーンとデータプレーンに分割)
+ [AWS Elemental MediaStore Data Plane](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 1: 単一リージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 2: マルチリージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Amazon Route 53 を用いたディザスタリカバリ (DR) のメカニズム](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Amazon Application Recovery Controller とは](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Kubernetes Control Plane and data plane](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)
**関連動画:**
+ [Back to Basics - Using Static Stability](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [Building resilient multi-site workloads using AWS global services](https://www.youtube.com/watch?v=62ZQHTruBnk)
**関連する例:**
+ [Amazon Application Recovery Controller の紹介](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
+ [Amazon Builders' Library: 小さなサービスに制御を任せて分散型システムのオーバーヘッドを回避する](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 1: 単一リージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 2: マルチリージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
**関連ツール:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)