기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# App Mesh 모범 사례
**중요**
지원 종료 알림: 2026년 9월 30일에에 대한 지원을 중단할 AWS 예정입니다 AWS App Mesh. 2026년 9월 30일 이후에는 AWS App Mesh 콘솔 또는 AWS App Mesh 리소스에 더 이상 액세스할 수 없습니다. 자세한 내용은이 블로그 게시물 [에서 Amazon ECS Service Connect AWS App Mesh 로 마이그레이션](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)을 참조하세요.
계획된 배포 기간과 일부 호스트의 예상치 못한 손실 발생 시 요청 실패가 전혀 발생하지 않도록 한다는 목표를 달성하기 위해 이 주제의 모범 사례는 다음 전략을 구현합니다.
+ 안전한 기본 재시도 전략을 사용하면 애플리케이션 관점에서 요청이 성공할 가능성을 높일 수 있습니다. 자세한 내용은 [재시도를 통해 모든 경로 계측](#route-retries) 단원을 참조하십시오.
+ 재시도된 요청이 실제 대상으로 전송될 가능성을 최대화하여 재시도된 요청의 성공 가능성을 높입니다. 자세한 내용은 [배포 속도 조정](#reduce-deployment-velocity), [스케일 인 전에 스케일 아웃](#scale-out), [컨테이너 상태 검사 구현](#health-checks) 섹션을 참조하세요.
실패를 크게 줄이거나 없애려면 다음과 같은 모든 방법으로 권장 사항을 구현하는 것이 좋습니다.
## 재시도를 통해 모든 경로 계측
모든 가상 서비스가 가상 라우터를 사용하도록 구성하고 모든 경로에 대한 기본 재시도 정책을 설정합니다. 이렇게 하면 호스트가 다시 선택되고 새 요청이 전송되어 요청 실패를 줄일 수 있습니다. 재시도 정책의 경우 `maxRetries` 값을 2 이상으로 설정하고 재시도 이벤트 유형을 지원하는 각 경로 유형의 재시도 이벤트 유형에 대해 다음 옵션을 지정하는 것이 좋습니다.
+ **TCP** – `connection-error`
+ **HTTP 및 HTTP/2** – `stream-error` 및 `gateway-error`
+ **gRPC** – `cancelled` 및 `unavailable`
요청이 멱등성 상태가 아닌 경우처럼 다른 재시도 이벤트는 안전하지 않을 수 있으므로 사례별로 고려해야 합니다. `maxRetries` 및 `perRetryTimeout`에 대해 요청의 최대 지연 시간(`maxRetries` \$1 `perRetryTimeout`)과 추가 재시도의 성공률 증가 사이에서 적절한 균형을 이루는 값을 고려하고 테스트해야 합니다. 또한 Envoy가 더 이상 존재하지 않는 엔드포인트에 연결하려고 시도할 경우 해당 요청이 전체 `perRetryTimeout`을 소비할 것으로 예상할 수 있습니다. 재시도 정책을 구성하려면 [경로 생성](routes.md#create-route) 섹션을 참조한 후 라우팅할 프로토콜을 선택하세요.
**참고**
2020년 7월 29일 또는 그 이후의 경로를 구현하고 재시도 정책을 지정하지 않은 경우, App Mesh는 2020년 7월 29일 또는 그 이후에 생성한 각 경로에 대해 이전 정책과 유사한 기본 재시도 정책을 자동으로 생성했을 수 있습니다. 자세한 내용은 [기본 경로 재시도 정책](envoy-defaults.md#default-retry-policy) 단원을 참조하십시오.
## 배포 속도 조정
롤링 배포를 사용하는 경우 전체 배포 속도를 줄이세요. 기본적으로 Amazon ECS는 최소 100% 정상 태스크와 200%의 총 태스크로 이루어진 배포 전략을 구성합니다. 배포 시 이로 인해 높은 드리프트가 나타나는 두 지점이 발생합니다.
+ 요청을 완료할 준비가 되기 전에 Envoy에서 새 태스크의 100% 플릿 크기를 확인할 수 있습니다(완화 방법은 [컨테이너 상태 검사 구현](#health-checks) 참조).
+ 태스크가 종료되는 동안 Envoy에서 이전 태스크의 100% 플릿 크기를 확인할 수 있습니다.
이러한 배포 제약으로 구성된 경우 컨테이너 오케스트레이터는 모든 이전 대상을 동시에 숨기고 모든 새 대상을 표시하는 상태가 될 수 있습니다. Envoy 데이터 영역은 결과적으로 일관된 상태를 유지하므로 데이터 영역에 표시되는 대상 집합이 오케스트레이터의 관점과는 다르게 표시되는 기간이 발생할 수 있습니다. 이를 완화하려면 정상 태스크는 최소 100%로 유지하고 총 태스크는 125%로 줄이는 것이 좋습니다. 이렇게 하면 발산이 줄어들고 재시도의 안정성이 향상됩니다. 다양한 컨테이너 런타임의 경우 다음 제안 사항을 따르는 것이 좋습니다.
**Amazon ECS**
원하는 서비스 개수가 2\$13개인 경우 `maximumPercent`를 150퍼센트로 설정하세요. 그렇지 않으면 `maximumPercent`를 125%로 설정하세요.
**Kubernetes**
`maxUnavailable`을 0%로, `maxSurge`를 25%로 설정하여 배포의 `update strategy`을 구성합니다. 배포에 대한 자세한 내용은 Kubernetes [배포](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 설명서를 참조하세요.
## 스케일 인 전에 스케일 아웃
스케일 아웃과 스케일 인 모두 재시도에서 요청이 실패할 가능성이 있습니다. 스케일 아웃을 완화하는 태스크 권장 사항도 있지만 스케일 인에 대한 유일한 권장 사항은 한 번에 스케일 인되는 태스크의 비율을 최소화하는 것입니다. 기존 태스크나 배포를 스케일 인하기 전에 새 Amazon ECS 태스크 또는 Kubernetes 배포를 스케일 아웃하는 배포 전략을 사용하는 것이 좋습니다. 이 스케일링 전략을 사용하면 속도는 동일하게 유지하면서 태스크 또는 배포의 스케일 인 비율을 낮출 수 있습니다. 이 방법은 Amazon ECS 태스크와 Kubernetes 배포 모두에 적용됩니다.
## 컨테이너 상태 검사 구현
스케일 업 시나리오에서 Amazon ECS 태스크의 컨테이너는 오류로 인해 초기에 응답하지 않을 수 있습니다. 다양한 컨테이너 런타임의 경우 다음 제안 사항을 따르는 것이 좋습니다.
**Amazon ECS**
이를 완화하려면 아웃바운드 네트워크 연결이 필요한 컨테이너를 시작하기 전에 컨테이너 상태 검사 및 컨테이너 종속성 순서 지정을 사용하여 Envoy가 정상적으로 실행되고 있는지 확인하는 것이 좋습니다. 태스크 정의에서 애플리케이션 컨테이너와 Envoy 컨테이너를 올바르게 구성하려면 [컨테이너 종속성](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html#example_task_definition-containerdependency)을 참조하세요.
**Kubernetes**
없음. Kubernetes용 App Mesh 컨트롤러에서 AWS Cloud Map Kubernetes의 인스턴스 등록 및 등록 취소 시 Kubernetes [수명 및 준비](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) 프로브가 고려되지 않기 때문입니다. [https://github.com/aws/aws-app-mesh-controller-for-k8s](https://github.com/aws/aws-app-mesh-controller-for-k8s) 자세한 내용은 GitHub 문제 [\$1132](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/132)를 참조하세요.
## DNS 확인 최적화
서비스 검색에 DNS를 사용하는 경우 메시를 구성할 때 DNS 확인을 최적화하려면 적절한 IP 프로토콜을 선택해야 합니다. App Mesh는 `IPv4` 및를 모두 지원하며`IPv6`, 선택한 항목은 서비스의 성능과 호환성에 영향을 미칠 수 있습니다. 인프라가를 지원하지 않는 경우 기본 `IPv6_PREFERRED` 동작에 의존하지 않고 인프라에 맞는 IP 설정을 지정하는 `IPv6`것이 좋습니다. 기본 `IPv6_PREFERRED` 동작은 서비스 성능을 저하시킬 수 있습니다.
+ **IPv6\$1PREFERRED** – 기본 설정입니다. Envoy는 먼저 IPv6 주소에 대한 DNS 조회를 수행하고 `IPv6` 주소를 찾을 수 없는 `IPv4` 경우 로 돌아갑니다. 이는 인프라가 주로를 지원`IPv6`하지만 `IPv4` 호환성이 필요한 경우에 유용합니다.
+ **IPv4\$1PREFERRED** – Envoy는 먼저 `IPv4` 주소를 검색하고 사용 가능한 `IPv4` 주소가 없는 `IPv6` 경우 로 돌아갑니다. 인프라가 주로를 지원`IPv4`하지만 `IPv6` 호환성이 있는 경우이 설정을 사용합니다.
+ **IPv6\$1ONLY** - 서비스가 `IPv6` 트래픽만 지원하는 경우이 옵션을 선택합니다. Envoy는 `IPv6` 주소에 대한 DNS 조회만 수행하여 모든 트래픽이를 통해 라우팅되도록 합니다`IPv6`.
+ **IPv4\$1ONLY** - 서비스가 `IPv4` 트래픽만 지원하는 경우이 설정을 선택합니다. Envoy는 `IPv4` 주소에 대한 DNS 조회만 수행하여 모든 트래픽이를 통해 라우팅되도록 합니다`IPv4`.
가상 노드 설정을 메시 수준에서 재정의하여 메시 수준과 가상 노드 수준 모두에서 IP 버전 기본 설정을 지정할 수 있습니다.
자세한 내용은 [Service Meshes](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html) 및 [가상 노드](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html)를 참조하세요.