As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Práticas recomendadas do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Para atingir a meta de zero solicitações com falha durante as implantações planejadas e durante a perda não planejada de alguns hosts, as práticas recomendadas deste tópico implementam a seguinte estratégia:
+ Aumente a probabilidade de uma solicitação ser bem-sucedida do ponto de vista do aplicativo usando uma estratégia de repetição padrão segura. Para obter mais informações, consulte [Instrumente todas as rotas com novas tentativas](#route-retries).
+ Aumente a probabilidade de uma nova solicitação ser bem-sucedida maximizando a probabilidade de que a solicitação repetida seja enviada para um destino real. Para obter mais informações, consulte [Ajuste a velocidade de implantação](#reduce-deployment-velocity), [Aumente a escala horizontalmente antes de reduzi-la](#scale-out) e [Implemente verificações de integridade do contêiner](#health-checks).
Para reduzir ou eliminar significativamente as falhas, recomendamos que você implemente as recomendações em todas as práticas a seguir.
## Instrumente todas as rotas com novas tentativas
Configure todos os serviços virtuais para usar um roteador virtual e defina uma política de repetição padrão para todas as rotas. Isso atenuará as solicitações com falha selecionando novamente um host e enviando uma nova solicitação. Para políticas de repetição, recomendamos um valor de pelo menos dois para `maxRetries` e especifique as seguintes opções para cada tipo de evento de repetição em cada tipo de rota que suporte o tipo de evento de repetição:
+ **TCP**: `connection-error`
+ **HTTP e HTTP/2**: `stream-error` e `gateway-error`
+ **gRPC**: `cancelled` e `unavailable`
Outros eventos de repetição precisam ser considerados case-by-case com base no fato de que podem não ser seguros, por exemplo, se a solicitação não for idempotente. Você precisará considerar e testar valores de `maxRetries` e `perRetryTimeout` que façam a compensação adequada entre a latência máxima de uma solicitação (`maxRetries` \$1 `perRetryTimeout`) e o aumento da taxa de sucesso de outras tentativas. Além disso, quando o Envoy tenta se conectar a um endpoint que não está mais presente, você deve esperar que a solicitação consuma o `perRetryTimeout` totalmente. Para configurar uma política de repetição, consulte [Criar uma rota](routes.md#create-route) e selecione o protocolo que você deseja rotear.
**nota**
Se você implementou uma rota em ou após 29 de julho de 2020 e não especificou uma política de repetição, o App Mesh pode ter criado automaticamente uma política de repetição padrão semelhante à política anterior para cada rota criada em ou após 29 de julho de 2020. Para obter mais informações, consulte [Política padrão de tentativas de rotas](envoy-defaults.md#default-retry-policy).
## Ajuste a velocidade de implantação
Ao usar implantações contínuas, reduza a velocidade geral de implantação. Por padrão, o Amazon ECS configura uma estratégia de implantação de no mínimo 100% de tarefas íntegras e 200% de tarefas totais. Na implantação, isso resulta em dois pontos de grande desvio:
+ O tamanho de 100% da frota de novas tarefas pode ser visível para os Envoys antes de estarem prontos para concluir as solicitações (consulte [Implemente verificações de integridade do contêiner](#health-checks) para mitigações).
+ O tamanho de 100% da frota de tarefas antigas pode ser visível para os Envoys enquanto as tarefas estão sendo encerradas.
Quando configurados com essas restrições de implantação, os orquestradores de contêineres podem entrar em um estado em que ocultam simultaneamente todos os destinos antigos e tornam visíveis todos os novos destinos. Como seu plano de dados do Envoy é eventualmente consistente, isso pode resultar em períodos em que o conjunto de destinos visíveis em seu plano de dados divergiu do ponto de vista do orquestrador. Para mitigar isso, recomendamos manter um mínimo de 100% de tarefas íntegras, mas reduzir o total de tarefas para 125%. Isso reduzirá a divergência e melhorará a confiabilidade das novas tentativas. Recomendamos as seguintes configurações para diferentes tempos de execução do contêiner:
**Amazon ECS**
Se o seu serviço tiver uma contagem desejada de dois ou três, defina `maximumPercent` como 150 por cento. Caso contrário, defina `maximumPercent` como 125 por cento.
**Kubernetes**
Configure a `update strategy` de sua implantação definindo `maxUnavailable` como 0 por cento e `maxSurge` como 25 por cento. Para mais informações sobre implantações, consulte a documentação de [Implantações](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) do Kubernetes.
## Aumente a escala horizontalmente antes de reduzi-la
Tanto o aumento quanto a redução da escala horizontalmente podem resultar em alguma probabilidade de falhas nas solicitações nas novas tentativas. Embora existam recomendações de tarefas que mitiguem o aumento, a única recomendação para a redução é minimizar a porcentagem de tarefas escalonadas a qualquer momento. Recomendamos que você use uma estratégia de implantação que aumente horizontalmente a escala de novas tarefas do Amazon ECS ou implantações do Kubernetes antes de reduzir a escala de tarefas ou implantações antigas. Essa estratégia de escalabilidade mantém mais baixa a sua porcentagem de redução de escala em tarefas ou implantações, mantendo a mesma velocidade. Essa prática se aplica tanto às tarefas do Amazon ECS quanto às implantações do Kubernetes.
## Implemente verificações de integridade do contêiner
No cenário de aumento de escala verticalmente, os contêineres em uma tarefa do Amazon ECS podem ficar fora de ordem e podem não responder inicialmente. Recomendamos as seguintes sugestões para diferentes tempos de execução do contêiner:
**Amazon ECS**
Para mitigar isso, recomendamos o uso de verificações de integridade de contêiner e ordenação de dependências de contêiner para garantir que o Envoy esteja funcionando e íntegro antes do início de qualquer contêiner que exija conectividade de rede de saída. Para configurar corretamente um contêiner de aplicativo e um contêiner Envoy em uma definição de tarefa, consulte [Dependência de contêiner](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html#example_task_definition-containerdependency).
**Kubernetes**
[Nenhuma, porque os testes de [atividade e prontidão](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) do Kubernetes não estão sendo considerados no registro e cancelamento do registro de instâncias no AWS Cloud Map controlador App Mesh para Kubernetes.](https://github.com/aws/aws-app-mesh-controller-for-k8s) Para obter mais informações, consulte a GitHub edição [\$1132](https://github.com/aws/aws-app-mesh-controller-for-k8s/issues/132).
## Otimize a resolução de DNS
Se você estiver usando o DNS para descobrir serviços, é essencial selecionar o protocolo IP apropriado para otimizar a resolução do DNS ao configurar suas malhas. O App Mesh é compatível com `IPv4` e`IPv6`, e sua escolha pode afetar o desempenho e a compatibilidade do seu serviço. Se sua infraestrutura não oferecer suporte`IPv6`, recomendamos que você especifique uma configuração de IP que se alinhe à sua infraestrutura, em vez de confiar no comportamento padrão`IPv6_PREFERRED`. O `IPv6_PREFERRED` comportamento padrão pode degradar o desempenho do serviço.
+ **IPv6\$1PREFERRED** — Essa é a configuração padrão. O Envoy realiza uma pesquisa de DNS por IPv6 endereços primeiro e retorna `IPv4` se nenhum `IPv6` endereço for encontrado. Isso é benéfico se sua infraestrutura oferece suporte principal`IPv6`, mas precisa de `IPv4` compatibilidade.
+ **IPv4\$1PREFERIDO** — O Envoy primeiro procura os `IPv4` endereços e retorna `IPv6` se nenhum `IPv4` endereço estiver disponível. Use essa configuração se sua infraestrutura oferecer suporte principal`IPv4`, mas tiver alguma `IPv6` compatibilidade.
+ **IPv6\$1SOMENTE** — Escolha essa opção se seus serviços oferecerem suporte exclusivo ao `IPv6` tráfego. O Envoy só realiza pesquisas de DNS para `IPv6` endereços, garantindo que todo o tráfego seja roteado. `IPv6`
+ **IPv4\$1SOMENTE** — Escolha essa configuração se seus serviços oferecerem suporte exclusivo ao `IPv4` tráfego. O Envoy só realiza pesquisas de DNS para `IPv4` endereços, garantindo que todo o tráfego seja roteado. `IPv4`
Você pode definir as preferências de versão IP tanto no nível da malha quanto no nível do nó virtual, com as configurações do nó virtual substituindo as do nível da malha.
Para obter mais informações, consulte [Service Meshes](https://docs.aws.amazon.com/app-mesh/latest/userguide/meshes.html) and [Virtual Nodes](https://docs.aws.amazon.com/app-mesh/latest/userguide/virtual_nodes.html).