

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# App Mesh 스케일링 문제 해결
<a name="troubleshooting-scaling"></a>

**중요**  
지원 종료 공지: 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개 이상으로 스케일링할 경우 연결이 실패하고 컨테이너 상태 확인이 실패합니다.
<a name="ts-scaling-exceed-virtual-node-envoy-quota"></a>

**증상**  
가상 노드/가상 게이트웨이에 대해 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`을 나타내며 요청이 실패함
<a name="ts-scaling-out-in"></a>

**증상**  
백엔드 가상 서비스가 수평적으로 스케일 아웃되거나 스케일 인될 경우 다운스트림 애플리케이션의 요청은 `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를 나타내며 충돌함
<a name="ts-scaling-segfault"></a>

**증상**  
트래픽 로드가 높으면 세분화 오류(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/)에 문의하세요.

## 기본 리소스 증가는 서비스 제한에 반영되지 않습니다.
<a name="default-resources-increase"></a>

**증상**  
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/)에 문의하세요.

## 방대한 상태 확인 호출로 인해 애플리케이션이 충돌합니다.
<a name="crash-health-checks"></a>

**증상**  
가상 노드에 대한 활성 상태 확인을 활성화한 후 상태 확인 호출 수가 증가합니다. 애플리케이션에 대한 상태 확인 호출의 양이 크게 증가하여 애플리케이션이 충돌합니다.

**해결 방법**  
활성 상태 확인이 활성화되면 다운스트림의 각 Envoy 엔드포인트(클라이언트)는 라우팅 결정을 내리기 위해 업스트림 클러스터의 각 엔드포인트(서버)에 상태 요청을 보냅니다. 따라서 총 상태 확인 요청 수는 `number of client Envoys` \* `number of server Envoys` \* `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/)에 문의하세요.