翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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)」を参照してください。
この章では、トラブルシューティングのベストプラクティスと App Mesh の使用時に発生する可能性のある一般的な問題について説明します。次の領域のいずれかを選択して、その領域のベストプラクティスと一般的な問題を確認します。
**Topics**
+ [App Mesh のトラブルシューティングのベストプラクティス](troubleshooting-best-practices.md)
+ [App Mesh 設定のトラブルシューティング](troubleshooting-setup.md)
+ [App Mesh 接続のトラブルシューティング](troubleshooting-connectivity.md)
+ [App Mesh スケーリング](troubleshooting-scaling.md)
+ [App Mesh の可観測性](troubleshooting-observability.md)
+ [App Mesh セキュリティのトラブルシューティング](troubleshooting-security.md)
+ [App Mesh Kubernetes のトラブルシューティング](troubleshooting-kubernetes.md)
# 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)」を参照してください。
このトピックのベストプラクティスに従って、App Mesh を使用する際の問題をトラブルシューティングするようお勧めします。
## Envoy プロキシ管理インターフェイスを有効にする
Envoy プロキシには、設定と統計の検出、および Connection Draining などのその他の管理機能を実行するために使用できる管理インターフェイスが付属しています。詳細については、Envoy ドキュメント「[管理インターフェイス](https://www.envoyproxy.io/docs/envoy/latest/operations/admin)」を参照してください。
マネージド [Envoy イメージ](envoy.md) を使用する場合、管理エンドポイントは、デフォルトでポート 9901 が有効化されています。[App Mesh 設定のトラブルシューティング](troubleshooting-setup.md) の例では、管理エンドポイント URL は、`http://my-app.default.svc.cluster.local:9901/` のように表示されます。
**注記**
管理エンドポイントは、パブリックインターネットに公開されることはありません。さらに、`ENVOY_ADMIN_ACCESS_LOG_FILE` 環境変数によって、デフォルトで `/tmp/envoy_admin_access.log` に設定されている管理エンドポイントログをモニタリングするようお勧めします
## メトリクスオフロードの Envoy dogStatsD 統合を有効にする
Envoy プロキシは、OSI レイヤー 4 およびレイヤー 7 のトラフィックおよび内部プロセスのヘルスの統計情報をオフロードするように設定できます。このトピックでは、CloudWatch メトリクスや Prometheus などのシンクにメトリクスをオフロードせずにこれらの統計を使用する方法を説明します。これらの統計をすべてのアプリケーションの一元管理された場所に配置すると、問題の診断と動作の迅速な確認に役立ちます。詳細については、「[Amazon CloudWatch メトリクスの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)」と [Prometheus ドキュメント](https://prometheus.io/docs/introduction/overview/)を参照してください。
DogStatsD メトリクスの設定は、[dogStatsD 変数](envoy-config.md#envoy-dogstatsd-config) で定義されているパラメータを設定することで実行できます。DogStatsD の詳細については、[DogStatSD](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) ドキュメントを参照してください。 AWS CloudWatch メトリクスへのメトリクスオフロードのデモンストレーションは、GitHub の [App Mesh with Amazon ECS の基本ウォークスルー](https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics)で確認できます。
## アクセスログの有効化
[仮想ノード](virtual_nodes.md) と [仮想ゲートウェイ](virtual_gateways.md) でアクセスログを有効にして、アプリケーション間のトラフィックの推移の詳細を確認するようお勧めします。詳細については、Envoy ドキュメントに記載の「[アクセスログ](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging)」を参照してください。ログには、OSI レイヤー 4 およびレイヤー 7 のトラフィック動作に関する詳細情報が表示されます。Envoy のデフォルトのフォーマットを使用すると、[CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)で、アクセスログを分析できます。次の構文解析ステートメントを使用します。
```
parse @message "[*] \"* * *\" * * * * * * * * * * *" as StartTime, Method, Path, Protocol, ResponseCode, ResponseFlags, BytesReceived, BytesSent, DurationMillis, UpstreamServiceTimeMillis, ForwardedFor, UserAgent, RequestId, Authority, UpstreamHost
```
## 本番稼働前の環境で、Envoy デバッグログを有効にする
本番稼働前の環境では、Envoy プロキシのログレベルを `debug` に設定するようお勧めします。デバッグログは、関連する App Mesh 設定を本番稼働環境に移行する前に、問題を特定する役に立ちます。
[Envoy イメージ](envoy.md)使用している場合、ログレベルを `ENVOY_LOG_LEVEL` 環境変数で `debug` に設定できます。
**注記**
本番稼働環境での `debug` レベルの使用はお勧めしていません。レベルを `debug` に設定すると、ログが増加し、[CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) などのソリューションにオフロードされるログのパフォーマンスと全体的なコストに影響を与える可能性があります。
Envoys のデフォルトのフォーマットを使用すると、[CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) でプロセスログを、次の解析ステートメントを使用して分析できます。
```
parse @message "[*][*][*][*] [*] *" as Time, Thread, Level, Name, Source, Message
```
## App Mesh コントロールプレーンで Envoy プロキシ接続を監視する
Envoy メトリクス `control_plane.connected_state` を監視し、Envoy プロキシが App Mesh コントロールプレーンと通信して動的設定リソースを取得しているかを確認することをお勧めします。詳細については、「[Management Server](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/mgmt_server.html)」を参照してください。
# 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)」を参照してください。
このトピックでは、App Mesh 設定で発生する可能性のある一般的な問題の詳細を説明します。
## Envoy コンテナイメージをプルできない
**症状**
Amazon ECS タスクで、次のエラーメッセージが表示されます。次のメッセージの Amazon ECR *アカウント ID* と*リージョン*は、コンテナイメージを取得した Amazon ECR リポジトリによって異なる場合があります。
```
CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'
```
**解決策**
このエラーは、使用されているタスク実行ロールに Amazon ECR と通信するアクセス許可がなく、リポジトリから Envoy コンテナイメージをプルできないことを示しています。Amazon ECS タスクに割り当てられたタスク実行ロールには、次のステートメントを含む IAM ポリシーが必要です。
```
{
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage"
],
"Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
"Effect": "Allow"
},
{
"Action": "ecr:GetAuthorizationToken",
"Resource": "*",
"Effect": "Allow"
}
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## App Mesh Envoy 管理サービスに接続できない
**症状**
Envoy プロキシが App Mesh Envoy 管理サービスに接続できません。次が表示されます：
+ 接続がエラーを拒否しました
+ 接続タイムアウトしました
+ App Mesh Envoy 管理サービスエンドポイントの解決中にエラーが発生しました
+ gRPC エラー
**解決策**
Envoy プロキシがインターネットまたはプライベート[VPC エンドポイント](vpc-endpoints.md)にアクセスできること、および[セキュリティグループ](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html)がポート 443 でのアウトバウンドトラフィックを許可していることを確認してください。App Mesh の公開 Envoy 管理サービスのエンドポイントは、完全修飾ドメイン名 (FQDN、Fully Qualified Domain Name) フォーマットに従います。
```
# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com
# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com
```
次のコマンドを使用して、EMS への接続をデバッグできます。これにより、有効だが空の gRPC 要求が Envoy 管理サービスに送信されます。
```
curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources
```
これらのメッセージを受け取った場合、Envoy Management Service への接続は機能しています。gRPC 関連のエラーのデバッグについては、「[Envoy が エラーテキストで App Mesh Envoy 管理サービスから切断されました](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes)」を参照してください。
```
grpc-status: 16
grpc-message: Missing Authentication Token
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するするか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました
**症状**
Envoy プロキシは、App Mesh Envoy 管理サービスへの接続して設定を受信することができません。Envoy プロキシログには、次のようなログエントリが含まれています。
```
gRPC config stream closed: gRPC status code, message
```
**解決策**
ほとんどの場合、ログのメッセージ部分は問題を示しているはずです。次の表に、表示される可能性のある最も一般的な gRPC ステータスコード、その原因、および解決策を示します。
| gRPC ステータスコード | 原因 | 解決策 |
| --- | --- | --- |
| 0 | Envoy 管理サービスから正常に切断します。 | 問題はありません。App Mesh は、このステータスコードで Envoy プロキシを切断することがあります。Envoy は再接続し、更新を受信し続けます。 |
| 3 | メッシュエンドポイント (仮想ノードまたは仮想ゲートウェイ) 、または関連するリソースの 1 つが見つかりませんでした。 | Envoy 設定を再チェックして、それが表す App Mesh リソースの適切な名前があることをチェックします。App Mesh リソースが AWS Cloud Map 名前空間や ACM 証明書などの他の AWS リソースと統合されている場合は、それらのリソースが存在することを確認してください。 |
| 7 | Envoy プロキシは、Envoy 管理サービスへの接続や関連リソースの取得などのアクションの実行を許可されていません。 | App Mesh やその他のサービスに適切なポリシーステートメントを持つ[IAMポリシーを作成](proxy-authorization.md#create-iam-policy)し、Envoy プロキシが Envoy 管理サービスに接続するために使用している IAM ユーザーまたはロールに、そのポリシーをアタッチしていることを確認してください。 |
| 8 | 特定の App Mesh リソースの Envoy プロキシの数がアカウントレベルのサービスクォータを超えています。 | デフォルトのアカウントクォータの詳細および引き上げをリクエストする方法については、「[App Mesh Service Quotas](service-quotas.md)」を参照してください。 |
| 16 | Envoy プロキシには、 AWSの有効な認証資格情報がありません。 | Envoy に接続する適切な資格情報があることを確認します AWS IAM ユーザーまたはロールを介したサービス。Envoy のバージョン v1.24 以前の既知の問題 [\$124136](https://github.com/envoyproxy/envoy/issues/24136) では、Envoy プロセスが 1024 個を超えるファイル記述子を使用すると認証情報の取得に失敗します。これは Envoy が大量のトラフィックを処理している場合に発生します。デバッグレベルで Envoy ログのテキスト「A libcurl function was given a bad argument」を確認することで、この問題を確認できます。この問題を軽減するには、Envoy バージョン v1.25.1.0-prod 以降にアップグレードしてください。 |
Envoy プロキシからのステータスコードやメッセージは、次のクエリを使用して、[Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)で監視できます。
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
表示されたエラーメッセージが役に立たなかったり、問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討してください。
## Envoy コンテナのヘルスチェック、準備状態プローブ、またはライブネスプローブの失敗
**症状**
Envoy プロキシが Amazon ECS タスク、Amazon EC2 インスタンス、Kubernetes ポッドでヘルスチェックに失敗しています。例えば、次のコマンドを使用して Envoy 管理インターフェースをクエリし、`LIVE` 以外のステータスを受け取ります。
```
curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'
```
**解決策**
Envoy プロキシによって返されるステータスに応じた修復手順の一覧を次に示します。
+ `PRE_INITIALIZING` または `INITIALIZING` — Envoy プロキシがまだ設定を受信していないか、まだ接続できないため App Mesh Envoy 管理サービスから設定を取得できない。Envoy 管理サービスから接続しようとしたときに、 Envoy がエラーを受信している可能性があります。詳細については、「[Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました](#ts-setup-grpc-error-codes)」を参照してください。
+ `DRAINING` — Envoy プロキシは、Envoy 管理インターフェースの `/healthcheck/fail` または `/drain_listeners` リクエストに応答して接続のドレインを開始しました。Amazon ECS タスク、Amazon EC2 インスタンス、または Kubernetes ポッドを終了する場合を除き、管理インターフェイスでこれらのパスを呼び出すことはお勧めしません。
それでも問題が解決しない場合は、「[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)」を参照するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## ロードバランサーからメッシュエンドポイントへのヘルスチェックが失敗している
**症状**
メッシュエンドポイントは、コンテナヘルスチェックまたは準備プローブによって正常と見なされますが、ロードバランサーからメッシュエンドポイントへのヘルスチェックが失敗しています。
**解決策**
この問題を解決するには、次のタスクを完了します。
+ メッシュエンドポイントに関連する[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)が、ヘルスチェック用に設定したポートのインバウンドトラフィックを受け入れていることを確認してください。
+ 手動で要求された場合、ヘルスチェックが一貫して成功していることを確認します。例えば、[VPC 内の踏み台ホスト](https://aws.amazon.com/quickstart/architecture/linux-bastion/)です。
+ 仮想ノードのヘルスチェックを設定する場合は、アプリケーションにヘルスチェックエンドポイントを実装することをお勧めします。例えば、HTTP の場合は /ping などです。これにより、Envoy プロキシとアプリケーションの両方がロードバランサーからルーティング可能になります。
+ 必要な機能に応じて、仮想ノードには任意の Elastic Load Balancer タイプを使用できます。詳細については、「[Elastic Load Balancing の機能](https://aws.amazon.com/elasticloadbalancing/features/#compare)」を参照してください。
+ [仮想ゲートウェイ](virtual_gateways.md)のヘルスチェックを設定する場合は、仮想ゲートウェイのリスナーポートに TCP または TLS ヘルスチェックを備えた[ネットワークロードバランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html)を使用することをお勧めします。これにより、仮想ゲートウェイリスナーがブートストラップされ、接続を受け入れる準備ができていることが保証されます。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 仮想ゲートウェイがポート 1024 以下のトラフィックを受け入れない
**症状**
仮想ゲートウェイは、ポート 1024 以下のトラフィックを受け入れませんが、1024 より大きいポート番号のトラフィックを受け入れます。例えば、次のコマンドを使用して Envoy 統計をクエリし、ゼロ以外の値を受け取ります。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"
```
特権ポートへのバインド障害を示す、次のテキストのようなテキストがログに、表示される場合があります。
```
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_: cannot bind '0.0.0.0:': Permission denied
```
**解決策**
この問題を解決するには、ゲートウェイに指定したユーザーに linux 機能 `CAP_NET_BIND_SERVICE` が必要です。詳細については、「Linux プログラマーズマニュアル」の「[機能](https://www.man7.org/linux/man-pages/man7/capabilities.7.html)」、「ECS タスク定義パラメータ」の「[Linux パラメータ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_linuxparameters)」、および Kubernetes ドキュメントの「[コンテナの機能の設定](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)」を参照してください。
**重要**
Fargate は 1024 より大きいポート値を使用する必要があります。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
# 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)」を参照してください。
このトピックでは、App Mesh 接続で発生する可能性のある一般的な問題の詳細を説明します。
## 仮想サービスの DNS 名を解決できません
**症状**
アプリケーションは、接続しようとしている仮想サービスの DNS 名を解決できません。
**解決策**
これは既知の問題です。詳細については、GitHub issue の「[VirtualServices に任意のホスト名または FQDN で名前を付ける](https://github.com/aws/aws-app-mesh-roadmap/issues/65)」を参照してください。App Mesh の仮想サービスには任意の名前を付けることができます。仮想サービス名のDNS `A` レコードがあり、アプリケーションが仮想サービス名を解決できる限り、リクエストは Envoy によってプロキシされ、適切な宛先にルーティングされます。この問題を解決するには、仮想サービス名の `10.10.10.10` などの非ループバック IP アドレスにDNS `A` レコードを追加します。DNS `A` レコードは、次の条件で使用できます。
+ プライベートホストゾーン名の末尾に名前が付いている場合には、Amazon Route 53 内
+ アプリケーションコンテナの `/etc/hosts` ファイル内
+ 管理するサードパーティー DNS サーバー内
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 仮想サービスのバックエンドに接続できない
**症状**
アプリケーションは、仮想ノードのバックエンドとして定義された仮想サービスへの接続を確立できません。接続を確立しようとすると、接続が完全に失敗したり、アプリケーションの観点から見たリクエストが `HTTP 503` レスポンスコードで失敗する可能性があります。
**解決策**
アプリケーションがまったく接続に失敗した場合 (`HTTP 503` レスポンスコードが返されない場合) は、次の手順を実行します。
+ コンピューティング環境が App Mesh で動作するように設定されていることを確認してください。
+ Amazon ECS の場合は、適切な[プロキシ設定](proxy-authorization.md)が有効になっていることを確認してください。エンドツーエンドのチュートリアルについては、「[App Mesh と Amazon ECS の使用を開始する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/appmesh-getting-started.html)」を参照してください。
+ Amazon EKS を含む Kubernetes については、Helm を介して最新のApp Mesh コントローラーがインストールされていることを確認してください。詳細については、Helm Hub の「[App Mesh コントローラー](https://hub.helm.sh/charts/aws/appmesh-controller)」または「[チュートリアル: Kubernetes とのApp Mesh 統合を設定する](https://docs.aws.amazon.com/app-mesh/latest/userguide/mesh-k8s-integration.html)」を参照してください。
+ Amazon EC2 の場合は、App Mesh トラフィックをプロキシするための Amazon EC2 インスタンスを設定していることを確認してください。詳細については、「[サービスの更新](https://docs.aws.amazon.com/app-mesh/latest/userguide/appmesh-getting-started.html#update-services)」を参照してください。
+ コンピューティングサービスで実行されている Envoy コンテナが App Mesh Envoy 管理サービスに正常に接続されていることを確認してください。Envoy 統計情報の `control_plane.connected_state` フィールドを確認することで、この問題を確認できます。`control_plane.connected_state` の詳細については、「**トラブルシューティングのベストプラクティス**」の「[Envoy プロキシ接続を監視する](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-best-practices.html#ts-bp-enable-envoy-control-plane-connected-state)」を参照してください。
Envoy が最初は接続を確立できたが、その後切断され再接続されなかった場合は、「[Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました](https://docs.aws.amazon.com/app-mesh/latest/userguide/troubleshooting-setup.html#ts-setup-grpc-error-codes)」を参照して、接続が切断された理由を確認してください。
アプリケーションが接続してもリクエストが `HTTP 503` レスポンスコードで失敗する場合は、次のことを試してください。
+ 接続する仮想サービスがメッシュに存在することを確認してください。
+ 仮想サービスにプロバイダー (仮想ルーターまたは仮想ノード) があることを確認してください。
+ Envoy を HTTP プロキシとして使用しているときに、Envoy の統計情報で、正しい宛先ではなく `cluster.cds_egress_*_mesh-allow-all` への出力トラフィックが見られる場合は、Envoy が `filter_chains` 経由でリクエストを適切にルーティングしていない可能性があります。これは、修飾されていない仮想サービス名を使用したことが原因である可能性があります。Envoy プロキシは他の仮想サービスと名前で通信するため、実際のサービスのサービス検出名を仮想サービス名として使用することをお勧めします。
詳細については、「[仮想サービス](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_services.html)」を参照してください。
+ Envoy プロキシログで、次のエラーメッセージがないか調べます。
+ `No healthy upstream` — Envoy プロキシがルートしようとしている仮想ノードに、解決済みのエンドポイントがないか、正常なエンドポイントがありません。ターゲット仮想ノードに正しいサービスディスカバリとヘルスチェック設定があることを確認してください。
バックエンド仮想サービスのデプロイまたはスケーリング中にサービスへのリクエストが失敗した場合は、[仮想サービスに仮想ノードプロバイダーがある場合、一部のリクエストが失敗して、 HTTP ステータスコード `503` を表示する](#ts-connectivity-virtual-node-provider) のガイダンスに従ってください。
+ `No cluster match for URL` — これは、リクエストが、仮想ルーター)プロバイダで定義されたどのルートで定義されている基準にも一致しない、仮想サービスに送信された場合に発生する可能性が多々あります。パスと HTTP リクエストヘッダーが正しいことを確認して、アプリケーションからのリクエストがサポートされているルートに送信されていることを確認してください。
+ `No matching filter chain found` — これは、リクエストが無効なポート上の仮想サービスに送信された場合に発生する可能性が多々あります。アプリケーションからの要求が、仮想ルーターで指定された同じポートを使用していることを確認してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 外部サービスに接続できない
**症状**
アプリケーションがメッシュ外のサービスに接続できません。例えば、`amazon.com`。
**解決策**
デフォルトでは、App Mesh は、メッシュ内のアプリケーションからメッシュ外の宛先へのアウトバウンドトラフィックを許可しません。外部サービスとの通信を有効にするには、次の 2 つのオプションがあります。
+ メッシュリソースの[アウトバウンドフィルター](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html)を`ALLOW_ALL` に設定します。この設定により、メッシュ内のすべてのアプリケーションは、メッシュの内外にあるすべての宛先 IP アドレスと通信を許可されます。
+ 仮想サービス、仮想ルーター、ルート、および仮想ノードを使用して、メッシュ内の外部サービスをモデル化します。例えば、外部サービス `example.com` をモデル化するには、仮想ルーターとルートを使用して `example.com` という名前の仮想サービスを作成し、DNS サービスディスカバリホスト名が `example.com` の仮想ノードに、すべてのトラフィックを送信します。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## MySQL または SMTP サーバーに接続できない
**症状**
SMTP サーバーや仮想ノード定義を使用する MySQL データベースなど、すべての宛先 (メッシュ `EgressFilter type`=`ALLOW_ALL`) へのアウトバウンドトラフィックを許可すると、アプリケーションからの接続が失敗します。例として、MySQL サーバーへの接続を試みたときのエラーメッセージを次に示します。
```
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0
```
**解決策**
この問題は既知の問題であり、App Meshのイメージバージョン1.15.0以降を使用することで解決します。詳細については、GitHub issue の「[App Mesh で MySQL に接続できない](https://github.com/aws/aws-app-mesh-roadmap/issues/62)」を参照してください。このエラーは、App Mesh で設定したEnvoy の送信リスナーが Envoy TLS Inspector のリスナーフィルターを追加するため発生します。詳細については、Envoy ドキュメントの「[TLS Inspector](https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listener_filters/tls_inspector#config-listener-filters-tls-inspector)」を参照してください。を参照してください。このフィルターは、クライアントから送信された最初のパケットを調べて、接続が TLS を使用しているかどうかを評価します。ただし、MySQL と SMTP では、サーバーは接続後に最初のパケットを送信します。MySQL の詳細については、MySQL ドキュメントの「[初期ハンドシェイク](https://dev.mysql.com/doc/internals/en/initial-handshake.html)」を参照してください。サーバーが最初のパケットを送信するため、フィルターでの検査は失敗します。
**Envoy のバージョンに応じて、この問題を回避するには:**
+ App Mesh イメージ Envoy のバージョンが 1.15.0 以降の場合は、**MySQL**、**SMTP**、**MSSQL**などの外部サービスをアプリケーションの仮想ノードのバックエンドとしてモデル化しないでください。
+ App Mesh イメージの Envoy のバージョンが 1.15.0 以前の場合は、**MySQL** のサービスの `APPMESH_EGRESS_IGNORED_PORTS` の値リストに、**STMP** に使用しているポートとして、ポート `3306` を追加します。
**重要**
デフォルトの SMTP ポートは `25`、`587`、`465` ですが、使用しているポートのみを `APPMESH_EGRESS_IGNORED_PORTS` にに追加する必要があり、3つすべてを追加する必要はありません。
詳細については、Kubernetes の「[更新サービス](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-kubernetes.html#create-update-services)」、Amazon ECS の「[更新サービス](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ecs.html#update-services)」、または Amazon EC2 の「[更新サービス](https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html#update-services)」を参照してください。
それでも問題が解決しない場合は、既存の [GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/62) を使用してその問題の詳細をお知らせいただくか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## App Mesh で TCP 仮想ノードまたは仮想ルーターとしてモデル化されたサービスに接続できない
**症状**
アプリケーションは、App Mesh [PortMapping](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_PortMapping.html) 定義の TCP プロトコル設定を使用するバックエンドに接続できません。
**解決策**
これは既知の問題です。詳細については、GitHub の「[同じポート上の複数の TCP 宛先へのルーティング](https://github.com/aws/aws-app-mesh-roadmap/issues/195)」を参照してください。現在、App Mesh では、OSI レイヤー 4 で Envoy プロキシに提供される情報の制限により、TCP としてモデル化された複数のバックエンド宛先を同じポートを共有することは許可されていません。TCP トラフィックがすべてのバックエンド送信先で適切にルーティングされるようにするには、次の手順を実行します。
+ すべての宛先が一意のポートを使用していることを確認してください。バックエンド仮想サービスに仮想ルータープロバイダーを使用している場合は、ルーティング先の仮想ノードのポートを変更せずに、仮想ルーターポートを変更できます。これにより、Envoy プロキシが仮想ノードで定義されたポートを引き続き使用する間、アプリケーションは仮想ルーターのポートで接続を開くことができます。
+ TCP としてモデル化された送信先が MySQL サーバー、または接続後にサーバが最初のパケットを送信するその他の TCP ベースのプロトコルである場合は、「[MySQL または SMTP サーバーに接続できない](#ts-connectivity-troubleshooting-mysql-and-smtp)」を参照してください。
それでも問題が解決しない場合は、既存の [GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/195) を使用してその問題の詳細をお知らせいただくか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 仮想ノードの仮想サービスバックエンドとしてリストされていないサービスへの接続に成功する
**症状**
アプリケーションは、仮想ノードの仮想サービスバックエンドとして指定されていない送信先に接続してトラフィックを送信できます。
**解決策**
App Mesh API でモデル化されていない送信先へのリクエストが成功した場合、メッシュの[アウトバウンドフィルター](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html)タイプが `ALLOW_ALL` に設定されていることが最も可能性の高い原因となります。アウトバウンドフィルターが `ALLOW_ALL` に設定されている場合、アプリケーションからのアウトバウンドリクエストのうち、モデル化された送信先 (バックエンド) に一致しないものは、アプリケーションが設定した送信先 IP アドレスに送信されることになります。
メッシュでモデル化されていない宛先へのトラフィックを許可しない場合は、アウトバウンドフィルターの値を`DROP_ALL` に設定することを検討してください。。
**注記**
メッシュアウトバウンドフィルター値を設定すると、メッシュ内のすべての仮想ノードに影響します。
を `egress_filter` として設定`DROP_ALL`し、TLS を有効にすることは、 AWS ドメインにないアウトバウンドトラフィックでは使用できません。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 仮想サービスに仮想ノードプロバイダーがある場合、一部のリクエストが失敗して、 HTTP ステータスコード `503` を表示する
**症状**
アプリケーションのリクエストの一部は、仮想ルータープロバイダーではなく仮想ノードプロバイダーを使用している仮想サービスバックエンドで失敗します。仮想サービスに仮想ルータープロバイダーを使用する場合、リクエストは失敗しません。
**解決策**
これは既知の問題です。詳細については、GitHub の「[仮想サービスの仮想ノードプロバイダーのポリシーを再試行](https://github.com/aws/aws-app-mesh-roadmap/issues/194)」を参照してください。仮想ノードを仮想サービスのプロバイダーとして使用する場合、仮想サービスのクライアントが使用するデフォルトの再試行ポリシーを指定することはできません。これに対し、仮想ルーターのプロバイダーでは、リトライポリシーは子ルートリソースのプロパティであるため、指定することが可能です。
仮想ノードプロバイダーへのリクエストの失敗を減らすには、代わりに仮想ルーターのプロバイダーを使用し、そのルートで再試行ポリシーを指定します。アプリケーションへのリクエストの失敗を減らすその他の方法については、「[App Mesh のベストプラクティス](best-practices.md)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## Amazon EFS ファイルシステムに接続できない
**症状**
Amazon EFS ファイルシステムをボリュームとして Amazon ECS タスクを設定すると、次のエラーでタスクは失敗し始めます。
```
ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: mount.nfs4: Connection refused : unsuccessful EFS utils command execution; code: 32
```
**解決策**
これは既知の問題です。このエラーは、タスク内のコンテナが開始される前に Amazon EFS への NFS 接続が発生するために発生します。このトラフィックは、プロキシ設定によって Envoy にルーティングされますが、この時点では実行されません。スタートアップの順序が原因で、NFS クライアントは Amazon EFS ファイルシステムへの接続に失敗し、タスクの起動に失敗します。この問題を解決するには、Amazon ECS タスク定義のプロキシ設定の `EgressIgnoredPorts` 設定値リストにポート `2049` を追加します。詳細については、「[プロキシ設定ファイル](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#proxyConfiguration)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 接続は正常にサービスされるが、受信リクエストが Envoy のアクセスログ、トレース、またはメトリクスに表示されない
**症状**
アプリケーションが別のアプリケーションに接続してリクエストを送信できる場合でも、アクセスログまたは Envoy プロキシのトレース情報で受信リクエストを表示できません。
**解決策**
これは既知の問題です。詳細については、GitHub issue の「[iptables ルールのセットアップ](https://github.com/aws/aws-app-mesh-roadmap/issues/166)」を参照してください。Envoy プロキシは、対応する仮想ノードがリッスンしているポートへのインバウンドトラフィックのみをインターセプトします。他のポートへのリクエストは、Envoy プロキシをバイパスし、その背後にあるサービスに直接到達します。Envoy プロキシがサービスのインバウンドトラフィックをインターセプトできるようにするには、仮想ノードとサービスを同じポートでリッスンするように設定する必要があります。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## コンテナレベルで 設定方法 `HTTP_PROXY` / `HTTPS_PROXY` 環境変数を設定すると、期待どおりに動作しません。
**症状**
HTTP\$1PROXY / HTTPS\$1PROXY が次の環境変数として設定されている場合：
+ App Mesh が有効になっているタスク定義のアプリケーションのコンテナでは、App Mesh サービスの名前空間に送信されるリクエストは、Envoy サイドカーから `HTTP 500` エラーレスポンスを受け取ります。
+ App Mesh が有効になっているタスク定義の Envoy コンテナでは、Envoy サイドカーから出るリクエストが `HTTP` / `HTTPS` プロキシサーバーを通らず、環境変数が動作しなくなります。
**解決策**
アプリケーションコンテナの場合:
App Mesh は、タスク内のトラフィックが Envoy プロキシを通過することによって機能します。`HTTP_PROXY`/`HTTPS_PROXY`設定は、コンテナのトラフィックが別の外部プロキシを通過するように設定することで、この動作を上書きします。トラフィックは、引き続き Envoy によってインターセプトされますが、外部プロキシを使用したメッシュトラフィックのプロキシはサポートされません。
メッシュ以外のすべてのトラフィックをプロキシする場合は、次の例のように、メッシュの CIDR /名前空間、ローカルホスト、および認証情報のエンドポイントを含めるように `NO_PROXY` を設定してください。
```
NO_PROXY=localhost,127.0.0.1,169.254.169.254,169.254.170.2,10.0.0.0/16
```
Envoy コンテナの場合:
Envoy では汎用プロキシはサポートされていません。これらの変数を設定することはお勧めしません。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## ルートのタイムアウトを設定した後でも、アップストリームのリクエストがタイムアウトします。
**症状**
次のタイムアウトを定義しました。
+ ルートですが、アップストリームリクエストのタイムアウトエラーがまだ発生しています。
+ 仮想ノードリスナーとタイムアウト、およびルートの再試行タイムアウトですが、アップストリームリクエストのタイムアウトエラーが発生しています。
**解決策**
15 秒を超える高レイテンシーのリクエストが正常に完了するには、ルートと仮想ノードのリスナーレベルの両方でタイムアウトを指定する必要があります。
デフォルトの 15 秒より大きいルートのタイムアウトを指定する場合は、すべての参加仮想ノードのリスナーにもタイムアウトが指定されていることを確認してください。ただし、タイムアウトをデフォルトより低い値に減らすと、仮想ノードのタイムアウトを更新することはオプションとなります。仮想ノードとルートを設定するときのオプションの詳細については、「[仮想ノード](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html)」と「[ルート](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html)」を参照してください。
**再試行ポリシー**を指定した場合、リクエストタイムアウトに指定する時間は、常に*再試行タイムアウト*に**再試行ポリシー**で定義した*最大再試行回数*を掛けた値以上である必要があります。これにより、すべての再試行でのリクエストが正常に完了します。詳細については、「[ルート](https://docs.aws.amazon.com/app-mesh/latest/userguide/routes.html)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## Envoy が HTTP Bad request で応答する。
**症状**
Envoy は、Network Load Balancer (NLB) を介して送信されたすべてのリクエストに対して **HTTP 400 Bad request** で応答します。Envoy のログを確認すると、次のことがわかります。
+ デバッグログ:
```
dispatch error: http/1.1 protocol error: HPE_INVALID_METHOD
```
+ アクセスログ:
```
"- - HTTP/1.1" 400 DPE 0 11 0 - "-" "-" "-" "-" "-"
```
**解決策**
解決策は、NLB の[ターゲットグループ属性](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#target-group-attributes)でプロキシプロトコルバージョン 2 (PPv2) を無効にすることです。
現在のところ、PPv2は、App Mesh コントロールプレーンを使用して実行される仮想ゲートウェイと仮想ノード Envoy ではサポートされていません。Kubernetes で AWS ロードバランサーコントローラーを使用して NLB をデプロイする場合は、次の属性を に設定して PPv2 を無効にします`false`。
```
service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: proxy_protocol_v2.enabled
```
NLB リソース属性の詳細については、「[AWS Load Balancer Controller のアノテーション](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## タイムアウトを適切に設定できない。
**症状**
仮想ノードリスナーのタイムアウトと、仮想ノードバックエンドへのルートのタイムアウトを設定した後でも、リクエストは 15 秒以内にタイムアウトします。
**解決策**
バックエンドリストに正しい仮想サービスが含まれていることを確認してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
# 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)」を参照してください。
このトピックでは、App Mesh のスケーリングで発生する可能性のある一般的な問題を詳細に説明します。
## 仮想ノード/仮想ゲートウェイの 50 レプリカを超えてスケーリングすると、接続が失敗し、コンテナのヘルスチェックが失敗する
**症状**
仮想ノード/仮想ゲートウェイの Amazon ECS タスク、Kubernetes ポッド、Amazon EC2 インスタンスなどのレプリカの数を 50 個を超えてスケールすると、新規および現在実行中の Envoy の Envoy コンテナヘルスチェックが失敗し始めます。仮想ノード/仮想ゲートウェイにトラフィックを送信するダウンストリームアプリケーションは、HTTP ステータスコード `503` でリクエストの失敗を確認し始めます。
**解決策**
仮想ノード/仮想ゲートウェイあたりのエンボイ数に対する App Mesh のデフォルトのクォータは 50 です。実行中の Envoys の数がこのクォータを超えると、新規で現在実行中の Envoy は、gRPC ステータスコード `8` (`RESOURCE_EXHAUSTED`)を使用して App Mesh の Envoy 管理サービスに接続できません。このクォータは、引き上げることができます。詳細については、「[App Mesh Service Quotas](service-quotas.md)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## 仮想サービスバックエンドが水平方向にスケールアウトまたはスケールインする場合、リクエストが `503` で失敗する
**症状**
バックエンド仮想サービスが水平方向にスケールアウトまたはスケールインされると、ダウンストリームアプリケーションからのリクエストは失敗し、`HTTP 503` ステータスコードを表示します。
**解決策**
App Mesh では、アプリケーションを水平方向にスケーリングしながら、障害発生を緩和するためのいくつかのアプローチを推奨しています。これらの障害を防ぐ方法の詳細については、「[App Mesh のベストプラクティス](best-practices.md)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## ロードが増加すると、Envoy コンテナがセグメンテーション違反でクラッシュする
**症状**
トラフィックのロードが高い場合、セグメンテーション違反 (Linux 終了コード `139`) により Envoy プロキシがクラッシュします。Envoy プロセスログには、次のようなステートメントが含まれています。
```
Caught Segmentation fault, suspect faulting address 0x0"
```
**解決策**
Envoy プロキシは、オペレーティングシステムのデフォルトの nofile ulimit に違反している可能性があります。これは、プロセスが一度に開くことができるファイル数の制限です。この違反は、トラフィックがより多くの接続を引き起こし、追加のオペレーティングシステムソケットを消費することが原因です。この問題を解決するには、ホストオペレーティングシステムで ulimit nofile 値を増やします。Amazon ECS を使用している場合は、この制限は、タスク定義の[リソース制限設定](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits)の[Ulimit設定](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Ulimit.html)を介して変更できます。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## デフォルトリソースの増加がサービスの制限に反映されない
**症状**
App Mesh リソースのデフォルト制限を増やした後、サービスの制限を確認しても新しい値は反映されません。
**解決策**
新しい制限は、現在表示されていませんが、お客様は引き続きそれらを行使できます。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にへお問い合わせください。
## 大量のヘルスチェックコールが原因でアプリケーションがクラッシュする
**症状**
仮想ノードのアクティブなヘルスチェックを有効にすると、ヘルスチェックのコール数が増加します。アプリケーションに対して行われるヘルスチェックコールのボリュームが大幅に増加したため、アプリケーションがクラッシュします。
**解決策**
アクティブなヘルスチェックが有効な場合、ダウンストリーム (クライアント) の各 Envoy エンドポイントは、ルーティングを決定するために、アップストリームのクラスター (サーバー) の各エンドポイントにヘルスリクエストを送信します。その結果、ヘルスチェックのリクエストの総数は、`number of client Envoys` \$1 `number of server Envoys` \$1 `active health check frequency` になります。
この問題を解決するには、ヘルスチェックのプローブの頻度を変更します。これにより、ヘルスチェックプローブの総ボリュームが減少します。App Mesh では、アクティブなヘルスチェックに加えて、パッシブヘルスチェックの手段として[外れ値の検出](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_OutlierDetection.html)を設定できます。外れ値検出を使用して、連続した `5xx` レスポンスに基づいて特定のホストを削除するタイミングを設定します。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
# 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)」を参照してください。
このトピックでは、App Mesh の観測性で発生する可能性のある一般的な問題を詳細に説明します。
## アプリケーションの AWS X-Ray トレースを表示できない
**症状**
App Mesh のアプリケーションが X-Ray コンソールまたは API に X-Ray トレース情報を表示していません。
**解決策**
App Mesh で X-Ray を使用するには、アプリケーション、サイドカーコンテナ、および X-Ray サービス間の通信を有効にするようにコンポーネントを正しく設定する必要があります。次の手順を実行して、X-Ray が正しく設定されていることを確認します。
+ App Mesh 仮想ノードリスナーのプロトコルが `TCP` に設定されていないことを確認します。
+ アプリケーションとともにデプロイされた X-Ray コンテナが UDP ポート `2000` を公開し、ユーザー `1337` として実行されることを確認します。詳細については、GitHub の「[Amazon ECS X-Ray の例](https://github.com/aws/aws-app-mesh-examples/blob/main/walkthroughs/howto-ecs-basics/deploy/2-meshify.yaml#L374-L386)」を参照してください。
+ Envoy コンテナでトレースが有効になっていることを確認します。[App Mesh Envoy イメージ](envoy.md)を使用している場合、`ENABLE_ENVOY_XRAY_TRACING` 環境変数を `1` の値に設定し、`XRAY_DAEMON_PORT` 環境変数を `2000` に設定することで、X-Ray を有効にできます。
+ [言語固有の SDK](https://docs.aws.amazon.com/xray/index.html) の1つを使用してアプリケーションコードに X-Ray を実装した場合は、言語のガイドに従って、正しく設定されていることを確認してください。
+ 前の項目がすべて正しく設定されている場合は、X-Ray コンテナのログでエラーがないか確認し、[AWS X-Rayのトラブルシューティング](https://docs.aws.amazon.com/xray/latest/devguide/xray-troubleshooting.html)のガイダンスに従ってください。App Mesh での X-Ray 統合に関するより詳細な説明は、「[X-Ray と App Mesh 統合](https://aws.amazon.com/blogs/compute/integrating-aws-x-ray-with-aws-app-mesh/)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## Amazon CloudWatch メトリクスでは、自分のアプリケーションの Envoy メトリクスを表示できません
**症状**
App Mesh 内のアプリケーションは、Envoy プロキシによって生成されたメトリクスを CloudWatch メトリクスに送信していません。
**解決策**
App Mesh で CloudWatch メトリクスを使用する場合は、Envoy プロキシ、CloudWatch エージェントのサイドカー、CloudWatch メトリクスサービス間の通信を有効にするために、いくつかのコンポーネントを正しく設定する必要があります。次の手順を実行して、Envoy プロキシの CloudWatch メトリクスが正しく設定されていることを確認してください。
+ App Mesh に CloudWatch エージェントイメージを使用していることを確認てください。詳細については、GitHub の「[App Mesh CloudWatch エージェント](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent)」を参照してください。
+ プラットフォーム固有の使用手順に従って、CloudWatch エージェントが App Mesh 用に適切に設定されていることを確認してください。詳細については、GitHub の「[App Mesh CloudWatch エージェント](https://github.com/aws-samples/aws-app-mesh-cloudwatch-agent#usage)」を参照してください。
+ 前の項目がすべて正しく設定されている場合は、CloudWatch エージェントのコンテナログでエラーがないか確認し、「[CloudWatch エージェントのトラブルシューティング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html)」に記載されているガイダンスに従ってください。。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## AWS X-Ray トレースのカスタムサンプリングルールを設定できない
**症状**
アプリケーションで X-Ray トレースを使用していますが、トレースのサンプリングルールを設定できません。
**解決策**
App Mesh Envoy では、現在、**X-Ray の動的サンプリングの設定**がサポートされていないため、次の回避策を利用できます。
Envoy のバージョンが `1.19.1` 以降の場合は、次のオプションがあります。
+ サンプリングレートのみを設定するには、Envoy コンテナで `XRAY_SAMPLING_RATE` 環境変数を使用します。値は、 `0` と `1.00` (100％) の間の10進数で指定する必要があります。詳細については、「[AWS X-Ray 変数](envoy-config.md#envoy-xray-config)」を参照してください。
+ X-Ray トレーサのローカライズされたカスタムサンプリングルールを設定するには、`XRAY_SAMPLING_RULE_MANIFEST` 環境変数を使用して、Envoy コンテナファイルシステムのファイルパスを指定します。詳細については、「*AWS X-Ray デベロッパーガイド*」の「[サンプリングルール](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling)」を参照してください。
Envoyのバージョンが `1.19.1` 以前の場合は、次を実行します。
+ `ENVOY_TRACING_CFG_FILE` 環境変数を使用して、サンプリングレートを変更します。詳細については、「[Envoy 設定変数](envoy-config.md)」を参照してください。カスタムトレース設定を指定し、ローカルサンプリングルールを定義します。詳細については、「[Envoy X-Ray Config](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/trace/v3/xray.proto.html#config-trace-v3-xrayconfig)」を参照してください。
+ `ENVOY_TRACING_CFG_FILE` 環境変数のカスタムトレース設定の例：
```
tracing:
http:
name: envoy.tracers.xray
typedConfig:
"@type": type.googleapis.com/envoy.config.trace.v3.XRayConfig
segmentName: foo/bar
segmentFields:
origin: AWS::AppMesh::Proxy
aws:
app_mesh:
mesh_name: foo
virtual_node_name: bar
daemonEndpoint:
protocol: UDP
address: 127.0.0.1
portValue: 2000
samplingRuleManifest:
filename: /tmp/sampling-rules.json
```
+ `samplingRuleManifest`プロパティのサンプリングルールのマニフェスト設定の詳細については、「[X-Ray SDK for Go の設定](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
# 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)」を参照してください。
このトピックでは、App Mesh セキュリティで発生する可能性のある一般的な問題を詳細に説明します。
## TLS クライアントのポリシーを使用してバックエンド仮想サービスに接続できない
**症状**
TLS クライアントのポリシーを仮想ノードの仮想サービスバックエンドに追加すると、そのバックエンドへの接続が失敗します。バックエンドサービスにトラフィックを送信しようとすると、リクエストは`HTTP 503` レスポンスコードとエラーメッセージ:`upstream connect error or disconnect/reset before headers. reset reason: connection failure` で失敗します。
**解決策**
問題の根本原因を特定するには、問題の診断に役立つ Envoy プロキシプロセスログを使用することをお勧めします。詳細については、「[本番稼働前の環境で、Envoy デバッグログを有効にする](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging)」を参照してください。次のリストを使用して、接続障害の原因を特定します。
+ [仮想サービスのバックエンドに接続できない](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend) で説明されているエラーを除外して、バックエンドへの接続が成功していることを確認します。
+ Envoy プロセスログで、次のエラー (デバッグレベルで記録される) を探します。
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
次の問題のいずれかが原因で、このエラーが発生します。
+ 証明書は、TLS クライアントのポリシーの信頼バンドルで定義されている認証局の 1 つによって署名されていませんでした。
+ 証明書は無効です(期限切れ)。
+ サブジェクト別名 (SAN) がリクエストされた DNS ホスト名と一致しません。
+ バックエンドサービスによって提供される証明書が有効であること、TLS クライアントポリシーの信頼バンドル内のいずれかの認証局によって署名されていること、および [Transport Layer Security (TLS)](tls.md) で定義されている基準を満たしていることを確認します。
+ 次のようなエラーが表示される場合は、リクエストが Envoy プロキシをバイパスしてアプリケーションに直接到達していることを意味します。トラフィックを送信しても、Envoy の統計は変化せず、Envoy がトラフィックを復号する経路上にいないことがわかります。仮想ノードのプロキシ設定で、`AppPorts` にアプリケーションがリッスンしている正しい値が含まれていることを確認してください。
```
upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
## アプリケーションが TLS を発信しているときにバックエンド仮想サービスに接続できない
**症状**
Envoy プロキシからではなく、アプリケーションから TLS セッションを開始すると、バックエンド仮想サービスへの接続が失敗します。
**解決策**
これは既知の問題です。詳細については、GitHub issue の「[機能リクエスト: ダウンストリームアプリケーションとアップストリームプロキシ間の TLS ネゴシエーション](https://github.com/aws/aws-app-mesh-roadmap/issues/162)」を参照してください。App Mesh では、TLS 発信は、現在 Envoy プロキシからサポートされていますが、アプリケーションからはサポートされていません。Envoy で TLS 発信 Support を使用するには、アプリケーションでの TLS 発信を無効にします。これにより、Envoy はアウトバウンドリクエストヘッダーを読み取り、TLS のセッションを介してリクエストを適切な宛先に転送できます。詳細については、「[Transport Layer Security (TLS)](tls.md)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
## Envoy プロキシ間の接続が TLS を使用していることをアサートできません
**症状**
アプリケーションが仮想ノードまたは仮想ゲートウェイのリスナーで TLS 終了、またはバックエンド TLS クライアントのポリシーで TLS 発信を有効にしていますが、TLS ネゴシエートされたセッションで Envoy プロキシ間の接続が発生していることをアサートできません。
**解決策**
この解決法で定義されているステップは、Envoy 管理インターフェイスと Envoy 統計を使用します。これらの設定については、「[Envoy プロキシ管理インターフェイスを有効にする](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface)」と「[メトリクスオフロードの Envoy dogStatsD 統合を有効にする](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration)」を参照してください。次の統計例では、簡単にするために管理インターフェイスを使用しています。
+ TLS 終了を実行する Envoy プロキシの場合:
+ 次のコマンドを使用して、TLS 証明書が Envoy 設定でブートストラップされていることを確認してください。
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
返される出力には、TLSターミネーションで使用される証明書の `certificates[].cert_chain` の下に少なくとも1つのエントリが表示されます。
+ 次のコマンドと出力の例に示すように、プロキシのリスナーへの正常なインバウンド接続の数が、SSL ハンドシェイクの数に再利用された SSL セッションの数を加えたものと正確に同じであることを確認してください。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total
listener.0.0.0.0_15000.downstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error
listener.0.0.0.0_15000.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake
listener.0.0.0.0_15000.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused
listener.0.0.0.0_15000.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
+ TLS 発信を実行する Envoy プロキシの場合:
+ 次のコマンドを使用して、TLS 信頼ストアが Envoy 設定でブートストラップされていることを確認してください。
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
TLS の発信中にバックエンドの証明書を検証する際に使用される証明書について、`certificates[].ca_certs` の下に少なくとも1つのエントリが表示されます。
+ 次のコマンドと出力の例に示すように、バックエンドのクラスターへの正常なアウトバウンド接続の数が、SSL ハンドシェイクの数に再利用された SSL セッションの数を加えたものと正確に同じであることを確認してください。
```
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9
curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused
cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1
# Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
## Elastic Load Balancing を使用した TLS のトラブルシューティング
**症状**
仮想ノードへのトラフィックを暗号化するように Application Load Balancer または Network Load Balancer を設定しようとすると、接続とロードバランサーのヘルスチェックが失敗することがあります。
**解決策**
問題の根本原因を特定するには、次の点をチェックする必要があります。
+ TLS 終了を実行する Envoy プロキシでは、設定ミスを除外する必要があります。上記の「[TLS クライアントのポリシーを使用してバックエンド仮想サービスに接続できない](#ts-security-tls-client-policy)」の手順に従います。
+ ロードバランサーの場合は、`TargetGroup:` 設定を確認する必要がある
+ `TargetGroup` ポートが仮想ノードの定義済みリスナーポートと一致していることを確認してください。
+ HTTP を介してサービスへの TLS 接続を発信しているアプリケーションロードバランサーの場合、`TargetGroup` プロトコルが `HTTPS` に設定されていることを確認してください。ヘルスチェックを利用している場合は、`HealthCheckProtocol` が `HTTPS` に設定されていることを確認してください。
+ TCP を介してサービスへの TLS 接続を発信しているネットワークロードバランサーの場合、`TargetGroup` プロトコルが `TLS` に設定されていることを確認してください。ヘルスチェックを利用している場合は、`HealthCheckProtocol` が `TCP` に設定されていることを確認してください。
**注記**
`TargetGroup` へのすべての更新では、`TargetGroup` 名を変更する必要があります。
これが適切に設定されている場合、ロードバランサーは、Envoy プロキシに提供された証明書を使用して、サービスへの安全な接続を提供する必要があります。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。セキュリティの脆弱性が見つかったと思われる場合、または App Mesh のセキュリティについて質問がある場合は、「[AWS 脆弱性レポートガイドライン](https://aws.amazon.com/security/vulnerability-reporting/)」を参照してください。
# App Mesh Kubernetes のトラブルシューティング
**重要**
サポート終了通知: 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)」を参照してください。
このトピックでは、Kubernetes で App Mesh を使用するときに発生する可能性のある一般的な問題を詳細に説明します。
## Kubernetes で作成されたアプリケーションメッシュリソースが App Mesh 内で見つからない
**症状**
Kubernetes カスタムリソース定義 (CRD) を使用して App Mesh リソースを作成しましたが、 AWS マネジメントコンソール または APIs を使用する場合、作成したリソースは App Mesh に表示されません。
**解決策**
考えられる原因は、App Mesh の Kubernetes コントローラーのエラーです。詳細については、GitHub の「[トラブルシューティング](https://github.com/aws/aws-app-mesh-controller-for-k8s/blob/master/docs/guide/troubleshooting.md)」を参照してください。コントローラーのログで、コントローラーがリソースを作成できなかったことを示すエラーまたは警告がないかどうかをチェックしてください。
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller)
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## Envoy サイドカーが挿入された後、準備状態とライブネスのチェックに失敗する
**症状**
アプリケーションのポッドは、以前正常に実行されていましたが、Envoy サイドカーがポッドに挿入された後、準備状態とライブネスのチェックに失敗し始めました。
**解決策**
ポッドに挿入された Envoy コンテナが App Mesh の Envoy 管理サービスでブートストラップされていることを確認します。エラーを確認するには、[Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました](troubleshooting-setup.md#ts-setup-grpc-error-codes) でエラーコードを参照します。次のコマンドを使用して、関連するポッドの Envoy ログを調べることができます。
```
kubectl logs -n appmesh-system -f \
$(kubectl get pods -n appmesh-system -o name | grep controller) \
| grep "gRPC config stream closed"
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## ポッドが AWS Cloud Map インスタンスとして登録または登録解除していない
**症状**
Kubernetes ポッドは、ライフサイクル AWS Cloud Map の一環として に登録されていないか、 から登録解除されていません。ポッドが正常にスタートし、トラフィックを処理する準備ができていても、受信できない場合があります。ポッドが終了しても、クライアントはその IP アドレスを保持し、トラフィックを送信しようとする可能性があり、失敗します。
**解決策**
これは既知の問題です。詳細については、GitHub issue の「[AWS Cloud Mapでポッドが Kubernetes にメンバー登録/メンバー登録解除されない](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159)」を参照してください。ポッド、App Mesh 仮想ノード、 AWS Cloud Map リソース間の関係により、[Kubernetes 用 App Mesh コントローラー](https://github.com/aws/aws-app-mesh-controller-for-k8s)が非同期になり、リソースが失われる可能性があります。例えば、これは、関連するポッドを終了する前に仮想ノードリソースが Kubernetes から削除された場合に発生する可能性があります。
この問題を軽減するには、次の手順を実行します。
+ Kubernetes 用の App Mesh コントローラーの最新バージョンを実行していることを確認してください。
+ 仮想ノード定義で と `serviceName`が正しいことを確認します AWS Cloud Map `namespaceName`。
+ 仮想ノード定義を削除する前に、関連するポッドをすべて削除してください。仮想ノードに関連付けられているポッドを特定するための助けが必要な場合は、「[App Mesh リソースのポッドが実行されている場所を特定できない](#ts-kubernetes-where-pod-running)」を参照してください。
+ 問題が解決しない場合は、次のコマンドを実行して、根本的な問題を明らかにするのに役立つ可能性のあるエラーがないかコントローラーログを調べます。
```
kubectl logs -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
+ 次のコマンドを使用してコントローラーのポッド を再起動することを検討してください。これにより、同期の問題が修正される可能性があります。
```
kubectl delete -n appmesh-system \
$(kubectl get pods -n appmesh-system -o name | grep appmesh-controller)
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## App Mesh リソースのポッドが実行されている場所を特定できない
**症状**
Kubernetes クラスターで App Mesh を実行すると、オペレータは、特定の App Mesh リソースに対してワークロードまたはポッドが実行されている場所を特定できません。
**解決策**
Kubernetes ポッドのリソースは、関連付けられているメッシュと仮想ノードで注釈が付けられます。次のコマンドを使用して、特定の仮想ノード名に対して実行されているポッドをクエリできます。
```
kubectl get pods --all-namespaces -o json | \
jq '.items[] | { metadata } | select(.metadata.annotations."appmesh.k8s.aws/virtualNode" == "virtual-node-name")'
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## ポッドが実行されている App Mesh リソースを特定できない
**症状**
Kubernetes クラスターで App Mesh を実行している場合、オペレータは、特定のポッドが実行されている App Mesh リソースを特定できません。
**解決策**
Kubernetes ポッドのリソースには、関連付けられているメッシュと仮想ノードの注釈が付けられます。次のコマンドを使用して、 ポッドに直接クエリを実行することで、メッシュおよび仮想ノード名を出力できます。
```
kubectl get pod pod-name -n namespace -o json | \
jq '{ "mesh": .metadata.annotations."appmesh.k8s.aws/mesh", "virtualNode": .metadata.annotations."appmesh.k8s.aws/virtualNode" }'
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## クライアント Envoy は、IMDSv1 が無効になっていると App Mesh Envoy Management Service と通信できません
**症状**
`IMDSv1` を無効にすると、クライアントの Envoy は App Mesh コントロールプレーン (Envoy Management Service) と通信できなくなります。`v1.24.0.0-prod` 以前のバージョンの App Mesh Envoy では `IMDSv2` はサポートされていません。
**解決策**
この問題を解決するには、次の 3 つのいずれかを実行します。
+ `IMDSv2` がサポートされている App Mesh Envoy バージョン `v1.24.0.0-prod` 以降にアップグレードします。
+ Envoy が実行されているインスタンスで再度 `IMDSv1` を有効にします。`IMDSv1` の復元方法については、「[インスタンスメタデータオプションの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html)」を参照してください。
+ サービスが Amazon EKS で実行されている場合、認証情報の取得にはサービスアカウントの IAM ロール (IRSA) を使用することをお勧めします。IRSA を有効にする方法については、「[サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)」を参照してください。
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。
## App Mesh が有効で、Envoy が挿入されている場合、IRSA はアプリケーションコンテナで動作しません
**症状**
Amazon EKS 用のApp Mesh コントローラーを利用して Amazon EKS クラスターで App Mesh を有効にした場合、Envoy と `proxyinit` コンテナがアプリケーションポッドに挿入されます。アプリケーションは `IRSA` を引き受けることができず、代わりに `node role` を引き受けます。ポッドの詳細を確認すると、`AWS_WEB_IDENTITY_TOKEN_FILE` または `AWS_ROLE_ARN` 環境変数のいずれかがアプリケーションコンテナに含まれていないことがわかります。
**解決策**
`AWS_WEB_IDENTITY_TOKEN_FILE` または `AWS_ROLE_ARN` 環境変数が定義されている場合、ウェブフックはポッドをスキップします。これらの変数はいずれも指定しないでください。ウェブフックによってこれらの環境変数は自動的に挿入されます。
```
reservedKeys := map[string]string{
"AWS_ROLE_ARN": "",
"AWS_WEB_IDENTITY_TOKEN_FILE": "",
}
...
for _, env := range container.Env {
if _, ok := reservedKeys[env.Name]; ok {
reservedKeysDefined = true
}
```
それでも問題が解決しない場合は、[GitHub issue](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)のオープンを検討するか、[AWS Support](https://aws.amazon.com/premiumsupport/) にお問い合わせください。