기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# App Mesh 문제 해결
**중요**
지원 종료 공지: 2026년 9월 30일에는에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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 프록시에는 구성 및 통계를 검색하고 연결 드레이닝 등의 기타 관리 기능을 수행하는 데 사용할 수 있는 관리 인터페이스가 함께 제공됩니다. 자세한 내용은 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 변수](envoy-config.md#envoy-dogstatsd-config)에 정의된 파라미터를 설정하여 DogStatd 지표를 구성할 수 있습니다. DogStatsD에 대한 자세한 내용은 [DogStatsD](https://docs.datadoghq.com/developers/dogstatsd/?tab=hostagent) 설명서를 참조하세요. GitHub의 App Mesh with Amazon ECS 기본 안내서에서 AWS CloudWatch 지표로의 지표 오프로드 데모를 찾을 수 있습니다. [https://github.com/aws/aws-app-mesh-examples/tree/main/walkthroughs/howto-ecs-basics](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) 같은 솔루션으로 오프로드되는 로그의 전체 비용에 영향을 미칠 수 있습니다.
Envoy의 기본 형식을 사용하는 경우 다음 구문 분석 문을 사용하여 [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 제어 영역과 통신하여 동적 구성 리소스를 가져오는지 확인하는 것이 좋습니다. 자세한 내용은 [관리 서버](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 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## App Mesh Envoy Management Service에 연결할 수 없음
**증상**
Envoy 프록시가 App Mesh Envoy Management Service에 연결할 수 없습니다. 현재 표시되는 내용은 다음과 같습니다.
+ 연결 거부 오류
+ 연결 시간 초과
+ App Mesh Envoy Management Service 엔드포인트를 확인하는 동안 오류 발생
+ gRPC 오류
**해결 방법**
Envoy 프록시가 인터넷 또는 프라이빗 [VPC 엔드포인트](vpc-endpoints.md)에 액세스할 수 있고 [보안 그룹](https://docs.aws.amazon.com//vpc/latest/userguide/VPC_SecurityGroups.html)이 포트 443에서 아웃바운드 트래픽을 허용하는지 확인합니다. App Mesh의 퍼블릭 Envoy Management Service 엔드포인트는 정규화된 도메인 이름(FQDN) 형식을 따릅니다.
```
# 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 Management Service에 전송됩니다.
```
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 Management Service에서 연결이 끊김](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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## Envoy가 오류 텍스트를 나타내며 App Mesh Envoy Management Service에서 연결이 끊김
**증상**
Envoy 프록시가 App Mesh Envoy Management Service에 연결하여 해당 구성을 받을 수 없습니다. Envoy 프록시 로그에는 다음과 같은 로그 항목이 포함되어 있습니다.
```
gRPC config stream closed: gRPC status code, message
```
**해결 방법**
대부분의 경우 로그의 메시지 부분에 문제가 표시되어야 합니다. 다음 표에는 표시될 수 있는 가장 일반적인 gRPC 상태 코드, 원인 및 해결 방법이 나와 있습니다.
| gRPC 상태 코드 | 원인 | 해결 방법 |
| --- | --- | --- |
| 0 | Envoy Management Service와의 연결을 정상적으로 끊습니다. | 문제가 없습니다. App Mesh는 이 상태 코드를 사용하여 Envoy 프록시의 연결을 끊는 경우가 있습니다. Envoy는 다시 연결하여 업데이트를 계속 받습니다. |
| 3 | 메시 엔드포인트(가상 노드 또는 가상 게이트웨이) 또는 관련 리소스 중 하나를 찾을 수 없습니다. | Envoy 구성을 다시 확인하여 해당 구성이 나타내는 App Mesh 리소스의 적절한 이름이 있는지 확인합니다. App Mesh 리소스가 AWS Cloud Map 네임스페이스 또는 ACM 인증서와 같은 다른 AWS 리소스와 통합된 경우 해당 리소스가 존재하는지 확인합니다. |
| 7 | Envoy 프록시는 Envoy Management Service에 연결하거나 관련 리소스를 검색하는 등의 작업을 수행할 권한이 없습니다. | App Mesh 및 기타 서비스에 대한 적절한 정책 설명이 포함된 [IAM 정책을 생성하고](proxy-authorization.md#create-iam-policy) 해당 정책을 Envoy 프록시가 Envoy Management Service에 연결하는 데 사용하는 IAM 사용자 또는 역할에 연결해야 합니다. |
| 8 | 특정 App Mesh 리소스의 Envoy 프록시 수가 계정 수준 서비스 할당량을 초과합니다. | 기본 계정 할당량과 할당량 증가를 요청하는 방법에 대한 자세한 내용은 [App Mesh 서비스 할당량](service-quotas.md) 섹션을 참조하세요. |
| 16 | Envoy 프록시에는 AWS에 대한 유효한 인증 자격 증명이 없습니다. | Envoy가 IAM 사용자 또는 역할을 통해 AWS 서비스에 연결할 수 있는 적절한 자격 증명을 가지고 있는지 확인합니다. Envoy 프로세스에서 1024 이상의 파일 설명자를 사용하는 경우 버전 v1.24 이하의 Envoy에서 알려진 문제인 [\$124136](https://github.com/envoyproxy/envoy/issues/24136)으로 인해 자격 증명을 가져오지 못합니다. 이 문제는 Envoy가 높은 트래픽 볼륨을 제공할 때 발생합니다. 디버그 수준에서 Envoy 로그의 텍스트 "A libcurl function was given a bad argument“를 확인하여 이 문제를 확인할 수 있습니다. 이 문제를 완화하려면 Envoy 버전 v1.25.1.0-prod 이상으로 업그레이드하세요. |
다음 쿼리를 사용하여 [Amazon CloudWatch Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)에서 Envoy 프록시의 상태 코드 및 메시지를 관찰할 수 있습니다.
```
filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message
```
제공된 오류 메시지가 도움이 되지 않거나 문제가 여전히 해결되지 않은 경우 [GitHub 문제](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 Management Service에 연결하여 구성을 검색할 수 없습니다. 연결을 시도할 때 Envoy는 Envoy Management Service에서 오류를 수신할 수 있습니다. 자세한 내용은 [Envoy가 오류 텍스트를 나타내며 App Mesh Envoy Management Service에서 연결이 끊김](#ts-setup-grpc-error-codes)의 오류를 참조하세요.
+ `DRAINING` - Envoy 프록시는 Envoy 관리 인터페이스의 `/healthcheck/fail` 또는 `/drain_listeners` 요청에 대한 응답으로 연결을 드레이닝하기 시작했습니다. Amazon ECS 태스크, Amazon EC2 인스턴스 또는 Kubernetes 포드를 종료하려는 경우가 아니면 관리 인터페이스에서 이러한 경로를 호출하지 않는 것이 좋습니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 로드 밸런서에서 메시 엔드포인트로의 상태 확인이 실패함
**증상**
컨테이너 상태 확인 또는 준비 상태 프로브에서 메시 엔드포인트가 정상으로 간주되지만 로드 밸런서에서 메시 엔드포인트로의 상태 확인이 실패합니다.
**해결 방법**
이 문제를 해결하려면 다음 태스크를 완료합니다.
+ 메시 엔드포인트와 연결된 [보안 그룹](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)이 상태 확인을 위해 구성한 포트의 인바운드 트래픽을 수락하는지 확인합니다.
+ 수동으로 요청할 경우(예: [VPC 내 Bastion Host](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 상태 확인에 [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html)를 사용하는 것이 좋습니다. 이렇게 하면 가상 게이트웨이 리스너가 부트스트랩되어 연결을 수락할 준비가 됩니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 가상 게이트웨이는 포트 1024 이하에서 트래픽을 허용하지 않음
**증상**
가상 게이트웨이는 포트 1024 이하에서는 트래픽을 허용하지 않지만 1024보다 큰 포트 번호에서는 트래픽을 허용합니다. 예를 들어 다음 명령으로 Envoy 통계를 쿼리하면 0이 아닌 값이 수신됩니다.
```
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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
# App Mesh 연결 문제 해결
**중요**
지원 종료 공지: 2026년 9월 30일에는에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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 이름을 확인할 수 없습니다.
**해결 방법**
이는 알려진 문제입니다. 자세한 내용은 [호스트 이름 또는 FQDN에 따라 가상 서비스 이름 지정](https://github.com/aws/aws-app-mesh-roadmap/issues/65) GitHub 문제를 참조하세요. App Mesh의 가상 서비스에는 어떤 이름도 지정 가능합니다. 가상 서비스 이름에 대한 DNS `A` 레코드가 있고 애플리케이션이 가상 서비스 이름을 확인할 수 있는 한, Envoy에서 요청을 프록시하여 적절한 대상으로 라우팅합니다. 이 문제를 해결하려면 가상 서비스 이름으로 루프백이 아닌 IP 주소(예: `10.10.10.10`)에 DNS `A` 레코드를 추가합니다. 다음 조건에 따라 DNS `A` 레코드를 추가할 수 있습니다.
+ Amazon Route 53에서 이름 뒤에 프라이빗 호스팅 영역 이름이 붙은 경우
+ 애플리케이션 컨테이너의 `/etc/hosts` 파일 내부
+ 관리하는 타사 DNS 서버에서
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](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) 또는 [자습서: App Mesh와의 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 Management Service에 성공적으로 연결되었는지 확인합니다. 필드 `control_plane.connected_state`의 Envoy 통계를 확인하여 이러한 연결을 확인할 수 있습니다. `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 Management Service 간의 연결 끊김](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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 외부 서비스에 연결할 수 없음
**증상**
애플리케이션이 메시 외부의 서비스(예: `amazon.com`)에 연결할 수 없습니다.
**해결 방법**
기본적으로 App Mesh는 메시 내 애플리케이션에서 메시 외부의 대상으로 향하는 아웃바운드 트래픽을 허용하지 않습니다. 외부 서비스와의 통신을 활성화하는 옵션에는 다음 두 가지가 있습니다.
+ 메시 리소스의 [아웃바운드 필터](https://docs.aws.amazon.com/app-mesh/latest/APIReference/API_EgressFilter.html)를 `ALLOW_ALL`로 설정합니다. 이 설정을 사용하면 메시 내의 모든 애플리케이션이 메시 내부 또는 외부의 모든 대상 IP 주소와 통신할 수 있습니다.
+ 가상 서비스, 가상 라우터, 경로 및 가상 노드를 사용하여 메시의 외부 서비스를 모델링합니다. 예를 들어 외부 서비스 `example.com`을 모델링하려면 가상 라우터를 사용하여 이름이 `example.com`인 가상 서비스를 생성하고, DNS 서비스 검색 호스트 이름이 `example.com`인 가상 노드로 모든 트래픽을 보내는 경로를 생성할 수 있습니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## MySQL 또는 SMTP 서버에 연결할 수 없음
**증상**
가상 노드 정의를 사용하여 SMTP 서버 또는 MySQL 데이터베이스와 같은 모든 대상(Mesh `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 이상을 사용하면 해결됩니다. 자세한 내용은 [App Mesh를 사용하여 MySQL에 연결할 수 없음](https://github.com/aws/aws-app-mesh-roadmap/issues/62) GitHub 문제를 참조하세요. 이 오류는 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`의 값 목록에 **SMTP**에 사용하는 포트로서 포트 `3306`을 추가합니다.
**중요**
표준 SMTP 포트는 `25`, `587` 및 `465`이지만 사용 중인 포트만 `APPMESH_EGRESS_IGNORED_PORTS`에 추가해야 하며 세 포트를 모두 추가해서는 안 됩니다.
자세한 내용은 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 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/62)를 사용하면서 발생한 문제에 대한 세부 정보를 제공하거나 [AWS 지원 서비스](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)을 참조하세요. OSI 계층 4에서 Envoy 프록시에 제공되는 정보의 제한으로 인해 App Mesh는 현재 TCP로 모델링된 여러 백엔드 대상이 동일한 포트를 공유하는 것을 허용하지 않습니다. TCP 트래픽이 모든 백엔드 대상에 적절하게 라우팅될 수 있도록 하려면 다음을 수행합니다.
+ 모든 대상이 고유한 포트를 사용하고 있는지 확인합니다. 백엔드 가상 서비스에 가상 라우터 공급자를 사용하는 경우 라우팅되는 가상 노드의 포트를 변경하지 않고도 가상 라우터 포트를 변경할 수 있습니다. 이렇게 하면 Envoy 프록시가 가상 노드에 정의된 포트를 계속 사용하는 동안 애플리케이션이 가상 라우터 포트에서 연결을 열 수 있습니다.
+ TCP로 모델링된 대상이 MySQL 서버이거나, 서버가 연결 후 첫 번째 패킷을 보내는 다른 TCP 기반 프로토콜이 있는 경우 [MySQL 또는 SMTP 서버에 연결할 수 없음](#ts-connectivity-troubleshooting-mysql-and-smtp) 섹션을 참조하세요.
문제가 여전히 해결되지 않은 경우 기존 [GitHub 문제](https://github.com/aws/aws-app-mesh-roadmap/issues/195)를 사용하면서 발생한 문제에 대한 세부 정보를 제공하거나 [AWS 지원 서비스](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`로 설정하는 것이 좋습니다.
**참고**
메시 아웃바운드 필터 값을 설정하면 메시 내의 모든 가상 노드에 영향을 줍니다.
AWS 도메인에 없는 아웃바운드 트래픽에는 `egress_filter`로 구성`DROP_ALL`하고 TLS를 활성화할 수 없습니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 가상 서비스에 가상 노드 공급자가 있는 경우 일부 요청은 HTTP 상태 코드 `503`을 나타내며 실패합니다.
**증상**
가상 라우터 공급자 대신 가상 노드 공급자를 사용하는 가상 서비스 백엔드에 대한 애플리케이션 요청 중 일부가 실패합니다. 가상 서비스에 가상 라우터 공급자를 사용하는 경우 요청은 실패하지 않습니다.
**해결 방법**
이는 알려진 문제입니다. 자세한 내용은 GitHub의 [가상 서비스에 대한 가상 노드 공급자 재시도 정책](https://github.com/aws/aws-app-mesh-roadmap/issues/194)을 참조하세요. 가상 노드를 가상 서비스 공급자로 사용하는 경우 가상 서비스의 클라이언트가 사용할 기본 재시도 정책을 지정할 수 없습니다. 이와 비교할 때 가상 라우터 공급자는 하위 경로 리소스의 속성이므로 재시도 정책을 지정할 수 있습니다.
가상 노드 공급자에 대한 요청 실패를 줄이려면 가상 라우터 공급자를 대신 사용하고, 해당 경로에 재시도 정책을 지정합니다. 애플리케이션에 대한 요청 실패를 줄이는 다른 방법은 [App Mesh 모범 사례](best-practices.md) 섹션을 참조하세요.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 서비스에 성공적으로 연결되지만 수신 요청은 Envoy의 액세스 로그, 추적 또는 지표에 나타나지 않음
**증상**
애플리케이션이 다른 애플리케이션에 연결하여 요청을 보낼 수는 있지만 액세스 로그나 Envoy 프록시의 추적 정보에서 들어오는 요청을 볼 수 없습니다.
**해결 방법**
이는 알려진 문제입니다. 자세한 내용은 Github의 [iptables 규칙 설정](https://github.com/aws/aws-app-mesh-roadmap/issues/166) 문제를 참조하세요. Envoy 프록시는 해당 가상 노드가 수신 중인 포트로 향하는 인바운드 트래픽만 가로챕니다. 다른 포트에 대한 요청은 Envoy 프록시를 우회하여 뒤에 있는 서비스에 직접 도달합니다. Envoy 프록시가 서비스의 인바운드 트래픽을 가로채도록 하려면 가상 노드와 서비스가 동일한 포트에서 수신하도록 설정해야 합니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](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/네임스페이스, localhost 및 자격 증명의 엔드포인트를 포함하도록 `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 문제](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 지원 서비스](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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## Envoy는 HTTP 잘못된 요청으로 응답합니다.
**증상**
Envoy는 Network Load Balancer(NLB)를 통해 전송된 모든 요청에 대해 **HTTP 400 잘못된 요청**으로 응답합니다. 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 로드 밸런서 컨트롤러 주석](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/#resource-attributestrue)을 참조하세요.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 제한 시간을 제대로 구성할 수 없습니다.
**증상**
가상 노드 리스너에서 제한 시간을 구성하고 가상 노드 백엔드로 향하는 경로에서 제한 시간을 구성한 후에도 요청 제한 시간이 15초 이내에 초과됩니다.
**해결 방법**
백엔드 목록에 올바른 가상 서비스가 포함되어 있는지 확인하세요.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
# App Mesh 스케일링 문제 해결
**중요**
지원 종료 공지: 2026년 9월 30일에는에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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`을 나타내는 요청 실패를 확인하기 시작합니다.
**해결 방법**
가상 노드/가상 게이트웨이당 Envoy 수에 대한 App Mesh의 기본 할당량은 50입니다. 실행 중인 Envoy의 수가 이 할당량을 초과하면 현재 실행 중인 새 Envoy가 gRPC 상태 코드 `8`(`RESOURCE_EXHAUSTED`)을 사용하여 App Mesh의 Envoy Management Service에 연결하지 못합니다. 이 할당량을 늘릴 수 있습니다. 자세한 내용은 [App Mesh 서비스 할당량](service-quotas.md) 단원을 참조하십시오.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 가상 서비스 백엔드가 수평적으로 스케일 아웃되거나 스케일 인될 때 `503`을 나타내며 요청이 실패함
**증상**
백엔드 가상 서비스가 수평적으로 스케일 아웃되거나 스케일 인될 경우 다운스트림 애플리케이션의 요청은 `HTTP 503` 상태 코드를 나타내며 실패합니다.
**해결 방법**
App Mesh는 애플리케이션을 수평적으로 스케일링하는 동안 실패 사례를 줄일 수 있는 몇 가지 접근 방식을 권장합니다. 이러한 오류를 방지하는 방법에 대한 자세한 내용은 [App Mesh 모범 사례](best-practices.md) 섹션을 참조하세요.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 로드가 증가하면 Envoy 컨테이너가 segfault를 나타내며 충돌함
**증상**
트래픽 로드가 높으면 세분화 오류(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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 기본 리소스 증가는 서비스 제한에 반영되지 않습니다.
**증상**
App Mesh 리소스의 기본 제한을 늘린 후에는 서비스 제한을 확인할 때 새 값이 반영되지 않습니다.
**해결 방법**
새 제한은 현재 표시되지 않지만 고객은 여전히 해당 제한을 적용할 수 있습니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
# App Mesh 관찰성 문제 해결
**중요**
지원 종료 공지: 2026년 9월 30일에는에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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) 중 하나를 사용하여 애플리케이션 코드에서 X-Ray를 계측한 경우 해당 언어의 가이드에 따라 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 문제](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 지원 서비스](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)를 참조하세요.
+ 플랫폼별 사용 지침에 따라 App Mesh용 CloudWatch 에이전트를 적절하게 구성했는지 확인합니다. 자세한 내용은 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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## AWS X-Ray 트레이스에 대한 사용자 지정 샘플링 규칙을 구성할 수 없음
**증상**
애플리케이션에서 X-추적을 사용하고 있지만 추적에 대한 샘플링 규칙을 구성할 수 없습니다.
**해결 방법**
App Mesh Envoy는 현재 **동적 X-Ray 샘플링 구성**을 지원하지 않으므로 다음과 같은 해결 방법을 사용할 수 있습니다.
Envoy 버전이 `1.19.1` 이상인 경우, 다음 옵션을 사용할 수 있습니다.
+ 샘플링 속도만 설정하려면 Envoy 컨테이너에서 `XRAY_SAMPLING_RATE` 환경 변수를 사용하세요. 값은 `0` \$1 `1.00`(100%) 범위의 십진수로 지정해야 합니다. 자세한 내용은 [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 구성](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` 속성의 샘플링 규칙 매니페스트 구성에 대한 자세한 내용은 [Go용 X-Ray SDK 구성](https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-go-configuration.html#xray-sdk-go-configuration-sampling)을 참조하세요.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
# App Mesh 보안 문제 해결
**중요**
지원 종료 공지: 2026년 9월 30일에는에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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 클라이언트 정책 신뢰 번들에 정의된 인증 기관 중 하나에서 인증서에 서명하지 않았습니다.
+ 인증서가 더 이상 유효하지 않습니다(만료됨).
+ 주체 대체 이름(SAN)이 요청된 DNS 호스트 이름과 일치하지 않습니다.
+ 백엔드 서비스에서 제공하는 인증서가 유효하고, TLS 클라이언트 정책 신뢰 번들에 있는 인증 기관 중 하나에서 서명했으며, [전송 계층 보안(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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요. 보안 취약점을 발견했다고 생각되거나 App Mesh의 보안에 대해 궁금한 점이 있으면 [AWS 취약성 보고 지침](https://aws.amazon.com/security/vulnerability-reporting/)을 참조하세요.
## 애플리케이션에서 TLS를 시작할 때 백엔드 가상 서비스에 연결할 수 없음
**증상**
Envoy 프록시 대신 애플리케이션에서 TLS 세션을 시작하면 백엔드 가상 서비스로의 연결이 실패합니다.
**해결 방법**
이는 알려진 문제입니다. 자세한 내용은 [기능 요청: 다운스트림 애플리케이션과 업스트림 프록시 간의 TLS 협상](https://github.com/aws/aws-app-mesh-roadmap/issues/162) GitHub 문제를 참조하세요. App Mesh에서 TLS 시작이 현재 Envoy 프록시에서는 지원되지만 애플리케이션에서는 지원되지 않습니다. Envoy에서 TLS 시작 지원을 사용하려면 애플리케이션에서 TLS 시작을 비활성화해야 합니다. 이렇게 하면 Envoy가 아웃바운드 요청 헤더를 읽고 TLS 세션을 통해 적절한 대상으로 요청을 전달할 수 있습니다. 자세한 내용은 [전송 계층 보안(TLS)](tls.md) 단원을 참조하십시오.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요. 보안 취약점을 발견했다고 생각되거나 App Mesh의 보안에 대해 궁금한 점이 있으면 [AWS 취약성 보고 지침](https://aws.amazon.com/security/vulnerability-reporting/)을 참조하세요.
## Envoy 프록시 간의 연결이 TLS를 사용하고 있음을 어설션할 수 없음
**증상**
애플리케이션이 가상 노드 또는 가상 게이트웨이 리스너에서 TLS 종료를 활성화하거나 백엔드 TLS 클라이언트 정책에서 TLS 시작을 활성화했지만 Envoy 프록시 간의 연결이 TLS 협상 세션을 통해 발생하고 있음을 어설션할 수 없습니다.
**해결 방법**
이 해결 방법에 정의된 단계는 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 프록시의 경우:
+ 다음 명령을 사용하여 Envoy 구성에서 TLS 인증서가 부트스트랩되었는지 확인합니다.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
반환된 출력에서 TLS 종료에 사용된 인증서에 대한 항목이 `certificates[].cert_chain` 아래에 하나 이상 표시됩니다.
+ 다음 예제 명령 및 출력에서 볼 수 있듯이 프록시 리스너에 대한 성공적인 인바운드 연결 수가 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 프록시의 경우:
+ 다음 명령을 사용하여 Envoy 구성에서 TLS 트러스트 스토어가 부트스트랩되었는지 확인합니다.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
TLS 시작 시 백엔드 인증서를 검증하는 데 사용된 인증서에 대한 항목이 `certificates[].ca_certs` 아래에 하나 이상 표시됩니다.
+ 다음 예제 명령 및 출력에서 볼 수 있듯이 백엔드 클러스터에 대한 성공적인 아웃바운드 연결 수가 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 문제](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 지원 서비스](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 연결을 시작하는 Application Load Balancer의 경우 `TargetGroup` 프로토콜이 `HTTPS`로 설정되어 있는지 확인합니다. 상태 확인을 사용하는 경우 `HealthCheckProtocol`이 `HTTPS`로 설정되어 있는지 확인합니다.
+ TCP를 통해 서비스에 대한 TCP 연결을 시작하는 Network Load Balancer의 경우 `TargetGroup` 프로토콜이 `TLS`로 설정되어 있는지 확인합니다. 상태 확인을 사용하는 경우 `HealthCheckProtocol`이 `TCP`로 설정되어 있는지 확인합니다.
**참고**
`TargetGroup`을 업데이트하려면 `TargetGroup` 이름을 변경해야 합니다.
이를 올바르게 구성했으면 로드 밸런서가 Envoy 프록시에 제공된 인증서를 사용하여 서비스에 대한 보안 연결을 제공해야 합니다.
문제가 여전히 해결되지 않으면 [GitHub 문제](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 지원 서비스](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 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [Migrating from to 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 리소스를 App Mesh에서 찾을 수 없음
**증상**
Kubernetes 사용자 지정 리소스 정의(CRD)를 사용하여 App Mesh 리소스를 생성했지만 AWS Management Console 또는 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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## Envoy 사이드카를 삽입한 후 포드의 준비 상태 및 활성화 상태 확인이 실패함
**증상**
애플리케이션용 포드는 이전에 성공적으로 실행되었지만 Envoy 사이드카를 포드에 삽입한 후에는 준비 상태 및 활성화 상태 확인이 실패하기 시작합니다.
**해결 방법**
포드에 삽입된 Envoy 컨테이너가 App Mesh의 Envoy Management Service로 부트스트랩되었는지 확인하세요. [Envoy가 오류 텍스트를 나타내며 App Mesh Envoy Management Service에서 연결이 끊김](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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.
## 포드가 AWS Cloud Map 인스턴스로 등록 또는 등록 취소되지 않음
**증상**
Kubernetes 포드가 수명 주기의 AWS Cloud Map 일부로에 등록되거나에서 등록 취소되지 않습니다. 포드가 성공적으로 시작되어 트래픽을 처리할 준비가 되었지만 수신이 불가능할 수 있습니다. 포드가 종료되더라도 클라이언트는 여전히 IP 주소를 유지하고 트래픽을 보내려고 시도하지만 실패할 수 있습니다.
**해결 방법**
이는 알려진 문제입니다. 자세한 내용은 [포드가 AWS Cloud Map를 포함하는 Kubernetes에서 자동으로 등록/등록 취소되지 않음](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/159) GitHub 문제를 참조하세요. 포드, 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 문제](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 지원 서비스](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 문제](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 지원 서비스](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 문제](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 지원 서비스](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` 지원이 제공되지 않습니다.
**해결 방법**
이 문제를 해결하려면 다음 세 가지 중 한 가지 방법을 시도하면 됩니다.
+ `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 문제](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 지원 서비스](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` 환경 변수가 정의된 경우 webhook는 포드를 건너뜁니다. 이러한 변수 중 어느 것도 제공하지 마세요. webhook이 자동으로 삽입합니다.
```
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 문제](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 지원 서비스](https://aws.amazon.com/premiumsupport/)에 문의하세요.