# REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する
<a name="rel_withstand_component_failures_avoid_control_plane"></a>

 コントロールプレーンはリソースの作成、読み取り、記述、更新、削除、一覧表示 (CRUDL) に使用される管理 API を提供し、データプレーンは日々のサービストラフィックを処理します。回復力に影響を与える可能性のあるイベントへの回復または軽減対応を実装するときは、サービスの回復、再スケーリング、復元、修復、またはフェイルオーバーに最小限のコントロールプレーンのオペレーションを使用することに焦点を当ててください。これらのパフォーマンスの低下イベント中は、データプレーンのアクションがどのアクティビティよりも優先されるはずです。 

 たとえば、新しいコンピューティングインスタンスの起動、ブロックストレージの起動、キューサービスの記述などは、すべてコントロールプレーンのアクションです。コンピューティングインスタンスを起動後、コントロールプレーンは、容量のある物理ホストの検索、ネットワークインターフェースの割り当て、ローカルブロックストレージボリュームの準備、認証情報の生成、セキュリティルールの追加など、複数のタスクを実行する必要があります。コントロールプレーンは複雑なオーケストレーションになりがちです。 

 **期待される成果:** リソースに障害が発生すると、システムは、トラフィックを障害のあるリソースから正常なリソースに移行することで、自動または手動で回復できます。 

 **一般的なアンチパターン:** 
+  トラフィックを再ルーティングするための DNS レコードの変更への依存。 
+  リソースのプロビジョニングが不十分なため、障害が発生したコンポーネントの交換をコントロールプレーンのスケーリング操作に依存。 
+  あらゆるカテゴリの障害を修復するために、広範囲にわたるマルチサービス、マルチ API コントロールプレーンアクションに依存。 

 **このベストプラクティスを活用するメリット:** 自動修復の成功率が高くなると、平均復旧時間が短縮され、ワークロードの可用性が向上します。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 中程度: 特定の種類のサービス低下では、コントロールプレーンが影響を受けます。コントロールプレーンを広範囲に使用して修復すると、復旧時間 (RTO) と平均復旧時間 (MTTR) が長くなる可能性があります。 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 データプレーンのアクションを制限するには、サービスの復元に必要なアクションについて各サービスを評価します。 

 Amazon Application Recovery Controller (ARC) を活用して DNS トラフィックをシフトします。これらの機能により、障害から回復するアプリケーションの機能を継続的にモニタリングし、複数の 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 グループ (ASG) を使用してスケールアップすることが含まれます。回復性を最大限に高めるには、フェイルオーバーに使用するクラスターに十分な容量をプロビジョニングしてください。この容量のしきい値を制限する必要がある場合は、エンドツーエンドのシステム全体にスロットルを設定して、限られたリソースに到達するトラフィックの合計を安全に制限してください。 

 Amazon DynamoDB、Amazon API Gateway、ロードバランサー、AWS Lambda サーバーレスなどのサービスでは、これらのサービスを使用するとデータプレーンを活用できます。ただし、新しい関数、ロードバランサー、API ゲートウェイ、またはDynamoDB テーブルの作成はコントロールプレーンのアクションであり、イベントの準備やフェイルオーバーアクションのリハーサルとして、パフォーマンス低下の前に完了しておく必要があります。Amazon RDS では、データプレーンのアクションはデータへのアクセスを可能にします。 

 データプレーン、コントロールプレーン、および AWS が高可用性目標を満たすためにサービスを構築する方法の詳細については、 [アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)を参照してください。 

 データプレーンでの運用と、コントロールプレーンでの運用を理解します。 

### 実装手順
<a name="implementation-steps"></a>

 パフォーマンス低下のイベント後に復元する必要のある各ワークロードについて、フェイルオーバーランブック、高可用性設計、自動修復設計、または HA リソース復元プランを評価します。コントロールプレーンのアクションと見なされる可能性のある各アクションを特定します。 

 コントロールアクションをデータプレーンアクションに変更することを検討します。 
+  Auto Scaling (コントロールプレーン) と事前にスケーリングされた Amazon EC2 リソース (データプレーン) の比較 
+  Lambda およびそのスケーリング方法 (データプレーン) または Amazon EC2 および ASG (コントロールプレーン) への移行 
+  Kubernetes を使用するあらゆる設計とコントロールプレーンのアクションの性質を評価します。ポッドの追加は Kubernetes のデータプレーンのアクションです。アクションはノードの追加ではなく、ポッドの追加に限定する必要があります。 [オーバープロビジョニングされたノード](https://www.eksworkshop.com/docs/autoscaling/compute/cluster-autoscaler/overprovisioning/) を使用することが、コントロールプレーンのアクションを制限するための推奨方法です 

 データプレーンのアクションが同じ修復に影響を与えられる代替アプローチを検討してください。 
+  Route 53 のレコード変更 (コントロールプレーン) または ARC (データプレーン) 
+ [ より自動化されたアップデートのための 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 を比較し、セカンダリリージョンにトラフィックをルーティングする (コントロールプレーンのアクション) 
+  セカンダリプライマリでリードレプリカを作成するか、プライマリリージョンで同じアクションを試みる (コントロールプレーンのアクション) 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [可用性の定義](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 パートナー: 耐障害性のオートメーションを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=automation) 
+  [AWS Marketplace: 耐障害性に関して活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance) 
+  [The 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 データプレーン](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html) 
+  [Amazon Route 53 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 Route 53 を使用した回復力の高いアプリケーションの構築、パート 1: シングルリージョンスタック](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 を使用したディザスタリカバリメカニズムの作成](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/) 
+  [Route 53 Application Recovery Controller とは](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+ [ Kubernetes コントロールプレーンとデータプレーン ](https://aws.amazon.com/blogs/containers/managing-kubernetes-control-plane-events-in-amazon-eks/)

 **関連動画:** 
+ [ 基本に戻る - 静的安定性の使用 ](https://www.youtube.com/watch?v=gy1RITZ7N7s)
+ [AWS グローバルサービスを使用して回復力のあるマルチサイトワークロードを構築 ](https://www.youtube.com/watch?v=62ZQHTruBnk)

 **関連する例:** 
+  [Amazon Route 53 Application Recovery Controller の概要](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/) 
+ [ The Amazon Builders' Library: より小規模なサービスを管理して、分散システムの過負荷を回避する ](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [ Amazon Route 53 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 Route 53 を使用した回復力の高いアプリケーションの構築、パート 1: シングルリージョンスタック ](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)