기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
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 로 마이그레이션을
계획된 배포 기간과 일부 호스트의 예상치 못한 손실 발생 시 요청 실패가 전혀 발생하지 않도록 한다는 목표를 달성하기 위해 이 주제의 모범 사례는 다음 전략을 구현합니다.
-
안전한 기본 재시도 전략을 사용하면 애플리케이션 관점에서 요청이 성공할 가능성을 높일 수 있습니다. 자세한 내용은 재시도를 통해 모든 경로 계측 단원을 참조하십시오.
-
재시도된 요청이 실제 대상으로 전송될 가능성을 최대화하여 재시도된 요청의 성공 가능성을 높입니다. 자세한 내용은 배포 속도 조정, 스케일 인 전에 스케일 아웃, 컨테이너 상태 검사 구현 단원을 참조하세요.
실패를 크게 줄이거나 없애려면 다음과 같은 모든 방법으로 권장 사항을 구현하는 것이 좋습니다.
재시도를 통해 모든 경로 계측
모든 가상 서비스가 가상 라우터를 사용하도록 구성하고 모든 경로에 대한 기본 재시도 정책을 설정합니다. 이렇게 하면 호스트가 다시 선택되고 새 요청이 전송되어 요청 실패를 줄일 수 있습니다. 재시도 정책의 경우 maxRetries
값을 2 이상으로 설정하고 재시도 이벤트 유형을 지원하는 각 경로 유형의 재시도 이벤트 유형에 대해 다음 옵션을 지정하는 것이 좋습니다.
-
TCP –
connection-error
-
HTTP 및 HTTP/2 –
stream-error
및gateway-error
-
gRPC –
cancelled
및unavailable
다른 재시도 이벤트는 요청이 악의 case-by-case적이지 않은 경우와 같이 안전하지 않을 수 있으므로 이를 기준으로 고려해야 합니다. maxRetries
및 perRetryTimeout
에 대해 요청의 최대 지연 시간(maxRetries
* perRetryTimeout
)과 추가 재시도의 성공률 증가 사이에서 적절한 균형을 이루는 값을 고려하고 테스트해야 합니다. 또한 Envoy가 더 이상 존재하지 않는 엔드포인트에 연결하려고 시도할 경우 해당 요청이 전체 perRetryTimeout
을 소비할 것으로 예상할 수 있습니다. 재시도 정책을 구성하려면 경로 생성 섹션을 참조한 후 라우팅할 프로토콜을 선택하세요.
참고
2020년 7월 29일 또는 그 이후의 경로를 구현하고 재시도 정책을 지정하지 않은 경우, App Mesh는 2020년 7월 29일 또는 그 이후에 생성한 각 경로에 대해 이전 정책과 유사한 기본 재시도 정책을 자동으로 생성했을 수 있습니다. 자세한 내용은 기본 경로 재시도 정책 단원을 참조하십시오.
배포 속도 조정
롤링 배포를 사용하는 경우 전체 배포 속도를 줄이세요. 기본적으로 Amazon은 최소 100%의 정상 작업과 200%의 총 작업으로 배포 전략을 ECS 구성합니다. 배포 시 이로 인해 높은 드리프트가 나타나는 두 지점이 발생합니다.
-
요청을 완료할 준비가 되기 전에 Envoy에서 새 태스크의 100% 플릿 크기를 확인할 수 있습니다(완화 방법은 컨테이너 상태 검사 구현 참조).
-
태스크가 종료되는 동안 Envoy에서 이전 태스크의 100% 플릿 크기를 확인할 수 있습니다.
이러한 배포 제약으로 구성된 경우 컨테이너 오케스트레이터는 모든 이전 대상을 동시에 숨기고 모든 새 대상을 표시하는 상태가 될 수 있습니다. Envoy 데이터 영역은 결과적으로 일관된 상태를 유지하므로 데이터 영역에 표시되는 대상 집합이 오케스트레이터의 관점과는 다르게 표시되는 기간이 발생할 수 있습니다. 이를 완화하려면 정상 태스크는 최소 100%로 유지하고 총 태스크는 125%로 줄이는 것이 좋습니다. 이렇게 하면 발산이 줄어들고 재시도의 안정성이 향상됩니다. 다양한 컨테이너 런타임의 경우 다음 제안 사항을 따르는 것이 좋습니다.
Amazon ECS
원하는 서비스 개수가 2~3개인 경우 maximumPercent
를 150퍼센트로 설정하세요. 그렇지 않으면 maximumPercent
를 125%로 설정하세요.
Kubernetes
maxUnavailable
을 0%로, maxSurge
를 25%로 설정하여 배포의 update strategy
을 구성합니다. 배포에 대한 자세한 내용은 Kubernetes 배포
스케일 인 전에 스케일 아웃
스케일 아웃과 스케일 인 모두 재시도에서 요청이 실패할 가능성이 있습니다. 스케일 아웃을 완화하는 태스크 권장 사항도 있지만 스케일 인에 대한 유일한 권장 사항은 한 번에 스케일 인되는 태스크의 비율을 최소화하는 것입니다. 이전 ECS 작업 또는 배포에서 확장하기 전에 새 Amazon 작업 또는 Kubernetes 배포를 확장하는 배포 전략을 사용하는 것이 좋습니다. 이 스케일링 전략을 사용하면 속도는 동일하게 유지하면서 태스크 또는 배포의 스케일 인 비율을 낮출 수 있습니다. 이 연습은 Amazon ECS 작업과 Kubernetes 배포 모두에 적용됩니다.
컨테이너 상태 검사 구현
스케일 업 시나리오에서는 Amazon ECS 작업의 컨테이너가 순서를 벗어날 수 있으며 처음에는 응답하지 않을 수 있습니다. 다양한 컨테이너 런타임의 경우 다음 제안 사항을 따르는 것이 좋습니다.
Amazon ECS
이를 완화하려면 아웃바운드 네트워크 연결이 필요한 컨테이너를 시작하기 전에 컨테이너 상태 검사 및 컨테이너 종속성 순서 지정을 사용하여 Envoy가 정상적으로 실행되고 있는지 확인하는 것이 좋습니다. 태스크 정의에서 애플리케이션 컨테이너와 Envoy 컨테이너를 올바르게 구성하려면 컨테이너 종속성을 참조하세요.
Kubernetes
없음. Kubernetes용 App Mesh 컨트롤러에서 AWS Cloud Map 인스턴스의 등록 및 등록 취소 시 Kubernetes 라이프니스 및 준비
DNS 해상도 최적화
서비스 검색DNS에 를 사용하는 경우 메시를 구성할 때 DNS 해상도를 최적화하려면 적절한 IP 프로토콜을 선택해야 합니다. App Mesh는 IPv4
및 를 모두 지원하며IPv6
, 선택한 내용은 서비스의 성능과 호환성에 영향을 미칠 수 있습니다. 인프라가 를 지원하지 않는 경우 기본 IPv6_PREFERRED
동작에 의존하지 않고 인프라에 맞는 IP 설정을 지정하는 IPv6
것이 좋습니다. 기본 IPv6_PREFERRED
동작은 서비스 성능을 저하시킬 수 있습니다.
-
IPv6_PREFERRED – 기본 설정입니다. Envoy는 먼저 IPv6 주소 DNS 조회를 수행하고
IPv6
주소를 찾을 수 없는IPv4
경우 로 돌아갑니다. 이는 인프라가 주로 를 지원IPv6
하지만IPv4
호환성이 필요한 경우에 유용합니다. -
IPv4_PREFERRED – Envoy는 먼저
IPv4
주소를 검색하고 사용 가능한IPv4
주소가 없는IPv6
경우 로 돌아갑니다. 인프라가 주로 를 지원IPv4
하지만IPv6
호환성이 있는 경우 이 설정을 사용합니다. -
IPv6_ONLY – 서비스가
IPv6
트래픽을 독점적으로 지원하는 경우 이 옵션을 선택합니다. Envoy는IPv6
주소에 대한 DNS 조회만 수행하여 모든 트래픽이 를 통해 라우팅되도록 합니다IPv6
. -
IPv4_ONLY – 서비스가
IPv4
트래픽을 독점적으로 지원하는 경우 이 설정을 선택합니다. Envoy는IPv4
주소에 대한 DNS 조회만 수행하여 모든 트래픽이 를 통해 라우팅되도록 합니다IPv4
.
가상 노드 설정을 메시 수준에서 재정의하여 메시 수준과 가상 노드 수준 모두에서 IP 버전 기본 설정을 지정할 수 있습니다.
자세한 내용은 Service Meshes 및 Virtual Nodes를 참조하세요.