翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 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 以前の既知の問題 [\#24136](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/) にお問い合わせください。