翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# App Mesh のベストプラクティス
**重要**
サポート終了通知: 2026 年 9 月 30 日、 AWS はサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。
計画されたデプロイ中および一部のホストの予期しない損失時に、失敗したリクエストをゼロにするという目標を達成するために、このトピックのベストプラクティスでは、次の戦略を実装します。
+ 安全なデフォルトの再試行戦略を使用することで、アプリケーションの観点からリクエストが成功する可能性が高くなります。詳細については、「[再試行ですべてのルートを計測する](#route-retries)」を参照してください。
+ 再試行されたリクエストが実際の送信先に送信される可能性を最大化することで、再試行されたリクエストが成功する可能性が高くなります。詳細については[デプロイ速度の調整](#reduce-deployment-velocity)、[スケールインする前にスケールアウトする](#scale-out)、および[コンテナのヘルスチェックを実装する](#health-checks)を参照してください。
障害を大幅に削減または排除するには、次のすべてのプラクティスでレコメンデーションを実装することをお勧めします。
## 再試行ですべてのルートを計測する
すべての仮想サービスが仮想ルーターを使用するように設定し、すべてのルートに対してデフォルトの再試行ポリシーを設定します。これにより、ホストを再選択して新しいリクエストを送信することで、リクエストの失敗が軽減されます。再試行ポリシーでは、「`maxRetries`」に2つ以上の値を指定し、再試行イベントタイプをサポートする各ルートタイプで、再試行イベントタイプごとに次のオプションを指定することを推奨します。
+ **TCP** – `connection-error`
+ **HTTP と HTTP/2** – `stream-error` と `gateway-error`
+ **gRPC** – `cancelled` と `unavailable`
他の再試行イベントは、リクエストが冪等性がない場合など、安全ではない可能性があるため、ケースバイケースで検討する必要があります。リクエストの最大レイテンシー(`maxRetries` \$1 `perRetryTimeout`)と、より多くの再試行により増えた成功率との間の適切なトレードオフを行うために、`maxRetries` と `perRetryTimeout`の値を検討しテストする必要があります。さらに、Envoyが存在しないエンドポイントに接続しようとする場合、そのリクエストが完全に`perRetryTimeout`を消費することを予想する必要があります。再試行ポリシーを設定するには、「[ルートを作成する](routes.md#create-route)」を参照し、次に、ルートしたいプロトコルを選択します。
**注記**
2020年7月29日以降にルートを実装し、再試行ポリシーを指定していない場合、App Meshは、2020年7月29日以降に作成した各ルートに対して、以前のポリシーと同様のデフォルトの再試行ポリシーを自動的に作成している可能性があります。詳細については、「[デフォルトのルート再試行ポリシー](envoy-defaults.md#default-retry-policy)」を参照してください。
## デプロイ速度の調整
ローリングデプロイを使用する場合は、デプロイ全体の速度を下げます。デフォルトでは、Amazon ECSは最低100%の正常なタスクおよび総タスクは200 パーセントのデプロイ戦略を設定します。これによりデプロイでは、2箇所に高いドリフトが発生します。
+ 新しいタスクの100％のフリートサイズが、リクエストを完了する前にEnvoyに表示される場合があります (軽減については「[コンテナのヘルスチェックを実装する](#health-checks)」を参照してください)。
+ 古いタスクの100%フリートサイズは、タスクが終了している間にEnvoyに表示される場合があります。
このデプロイ制約で設定されていると、コンテナのオーケストレータは、古い送信先をすべて同時に非表示にし、新しい送信先をすべて表示できる状態になる場合があります。Envoyデータプレーンは結果整合性があるため、データプレーンに表示される一連の送信先がオーケストレーターの視点とは異なる可能性があります。これを軽減するには、最低でも100%の正常なタスクを維持しながら、総タスクを125%に下げることを推奨します。これにより、発散が減少し、再試行の信頼性が向上します。コンテナのランタイムごとに、次の設定を推奨します。
**Amazon ECS**
サービスに必要な数が2または3の場合は、`maximumPercent`を150パーセントに設定します。それ以外の場合は、「`maximumPercent`」を125パーセントに設定します。
**Kubernetes**
デプロイの `update strategy` を設定し、`maxUnavailable` を 0 パーセント、`maxSurge` を 25 パーセントに設定します。詳細については、Kubernetes ドキュメントの「[Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)」を参照してください。
## スケールインする前にスケールアウトする
スケールアウトとスケールインのどちらも、ある程度の確率でリクエストの再試行に失敗するという結果を招くおそれがあります。スケールアウトを軽減するタスクのレコメンデーションがありますが、スケールインに関する唯一のレコメンデーションは、一度にスケールインするタスクの割合を最小限に抑えることです。古いタスクまたはデプロイをスケーリングインする前に、新しい Amazon ECSタスクまたはKubernetesデプロイをスケールアウトするデプロイ戦略を使用することを推奨します。このスケーリング戦略により、同じ速度を維持しながら、タスクまたはデプロイでのスケーリングの割合を低く抑えることができます。このプラクティスは、Amazon ECSタスクとKubernetesデプロイの両方に適用されます。
## コンテナのヘルスチェックを実装する
スケールアップのシナリオでは、Amazon ECS タスク内のコンテナに故障が発生し、最初は応答しないことがあります。コンテナのランタイムごとに、次の提案を推奨します。
**Amazon ECS**
これを軽減するために、コンテナのヘルスチェックとコンテナの依存関係の順序付けを使用して、送信ネットワーク接続を必要とするコンテナが起動する前に、Envoyが実行されていて正常であることの確認を推奨します。タスク定義でアプリケーションコンテナと Envoy コンテナを正しく設定するには、「[コンテナの依存関係](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html#example_task_definition-containerdependency)」を参照してください。
**Kubernetes**
Kubernetes の[ライブネスプローブと準備状況](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)プローブは、Kubernetes [用 App Mesh コントローラー](https://github.com/aws/aws-app-mesh-controller-for-k8s)の AWS Cloud Map インスタンスの登録と登録解除では考慮されていないため、なし。詳細については、GitHub issue [\$1132](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/132) を参照してください。
## DNS 解決の最適化
サービス検出に DNS を使用している場合は、メッシュを設定するときに DNS 解決を最適化するために、適切な IP プロトコルを選択することが重要です。App Mesh は `IPv4` と の両方をサポートし`IPv6`、選択するとサービスのパフォーマンスと互換性に影響を与える可能性があります。インフラストラクチャが をサポートしていない場合は`IPv6`、デフォルトの`IPv6_PREFERRED`動作に依存するのではなく、インフラストラクチャに合った IP 設定を指定することをお勧めします。デフォルトの`IPv6_PREFERRED`動作では、サービスのパフォーマンスが低下する可能性があります。
+ **IPv6\$1PREFERRED** – これはデフォルト設定です。Envoy は最初に IPv6 アドレスの DNS ルックアップを実行し、`IPv6`アドレスが見つからない`IPv4`場合は にフォールバックします。これは、インフラストラクチャが主に をサポートしている`IPv6`が`IPv4`、互換性が必要な場合に役立ちます。
+ **IPv4\$1PREFERRED** – Envoy はまず`IPv4`アドレスを検索し、使用可能な`IPv4`アドレス`IPv6`がない場合は にフォールバックします。インフラストラクチャが主に をサポートしている`IPv4`が、ある程度`IPv6`の互換性がある場合は、この設定を使用します。
+ **IPv6\$1ONLY** – サービスが`IPv6`トラフィックのみをサポートしている場合は、このオプションを選択します。Envoy は`IPv6`アドレスの DNS ルックアップのみを実行し、すべてのトラフィックが を介してルーティングされるようにします`IPv6`。
+ **IPv4\$1ONLY** – サービスが`IPv4`トラフィックのみをサポートしている場合は、この設定を選択します。Envoy は`IPv4`アドレスの DNS ルックアップのみを実行し、すべてのトラフィックが を介してルーティングされるようにします`IPv4`。
IP バージョン設定は、メッシュレベルと仮想ノードレベルの両方で設定できます。仮想ノード設定はメッシュレベルで上書きされます。
詳細については、[「サービスメッシュ](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html)と[仮想ノード](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html)」を参照してください。