View a markdown version of this page

Documento de planejamento de experimentos - AWS Orientação prescritiva
Estado estacionárioRequisitos de observabilidadeDefinição do experimentoHipóteseProcesso experimentalCronograma do experimentoResultados do experimentoDefeitos identificados

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á.

Documento de planejamento de experimentos

Estado estacionário

Nome do processo Site de adoção de animais de estimação

Arquitetura física

(Link para o diagrama de arquitetura.)

Arquitetura lógica

(Link para o diagrama lógico.)

Definir estado estacionário

O tempo médio de carregamento da página, medido usando o Largest Contentful Paint (LCP), para o site de adoção de animais de estimação é de 2,5 segundos ou menos com uma latência de 99 percentis (P99) de 4,0 segundos ou menos com uma linha de base de 5.000 usuários simultâneos.

Métricas de estado estacionário

Métrica LCP capturada em toda a base de usuários e métricas douradas (latência, taxa de transferência, taxas de erro, saturação).

Observabilidade em estado estacionário

O LCP será capturado pelo navegador do usuário, enviado para a Amazon CloudWatch e inspecionado com CloudWatch RUM. Em um período de 60 segundos, a média e o tempo de LCP do P99 serão agregados para todas as solicitações nesse período. As métricas douradas de alto nível são capturadas usando CloudWatch.

Processo para atingir o estado estacionário

O Grafana K6 será usado para criar uma carga que simula os níveis normais de tráfego de produção de aproximadamente 5 mil usuários simultâneos.

Requisitos de observabilidade

As equipes devem ser capazes de ver o seguinte:

  • Estado estacionário: o que será observado para verificar se a aplicação está em condições normais?

  • Condição de falha: como a condição de falha aparecerá no painel? Por exemplo:

    • Alarmes que devem ser acionados

    • Registros que devem ser gerados

  • Impacto da falha: o que deve ser observado para visualizar os componentes que devem ser afetados (escopo do impacto)?

  • Recuperação: Como a recuperação será visualizada e medida para capturar o MTTR?

  • Depuração: detalhes da solução de problemas em falhas de experimentos.

A tabela a seguir fornece sugestões e exemplos para um gráfico de requisitos de observabilidade. Você deve definir o que deve ser observado com base em seu experimento específico.

O que precisa ser observado Link para a ferramenta de observabilidade O que está sendo observado

Fonte de entrada

Painel de controle Grafana K6

  • Contagem contínua de contêineres

  • Solicitações por segundo

Integridade geral do aplicativo

  • CloudWatch Painel de adoção de animais de estimação

  • Painel de experiência do usuário (RUM) para adoção de animais de estimação

  • Contagem de nós saudáveis do Amazon EKS

  • Utilização da CPU do nó Amazon EKS

Saúde do fluxo de trabalho

CloudWatch Painel de adoção de animais de estimação

Tempo de LCP, métricas douradas

Rastreamentos

Painel X-Ray para adoção de animais de estimação

  • Latência da solicitação

  • Request count

  • Contagem de falhas

Logs

CloudWatch Registros de adoção de animais

Quaisquer erros encontrados pelos pods serão enviados para o CloudWatch Logs.

Definição do experimento

Nome do experimento Stress de CPU no Amazon EKS PetSite pod

Código-fonte do experimento

(Link para o repositório de origem do experimento.)

Descrição do experimento

Esse experimento explora como um aumento no uso da CPU do pod de PetSite aplicativos afetaria a experiência geral do cliente. Ao injetar estresse da CPU em cada PetSite pod em execução, poderemos entender se há impacto nos clientes e a extensão desse impacto.

Requisitos ou parâmetros do experimento

Carga de aplicação: média de produção

Seletor de etiquetas para pods: app=petsite

Duração do experimento

10 minutos

Ambiente

Ambiente de teste Alpha

Recursos alvo do experimento

PetSite cápsulas de aplicação

Linha de base do experimento que é introduzida por meio da ferramenta de geração de carga

  • 54% das solicitações têm um LCP de <2,5 segundos.

  • 46% das solicitações têm um LCP de <4 segundos.

  • Nenhum erro é observado.

Condição de recuo

Nenhum

Hipótese

E se Impacto Recuperação

O que aconteceria com o estado estável se os pods de PetSite aplicativos experimentassem ou causassem mais de 60% de utilização da CPU por 10 minutos sob o tráfego normal em nível de produção?

 

Os tempos de LCP permanecerão abaixo de 2,5 segundos para P50 de usuários com P99 de 4,0 segundos ou menos. O consumidor deve ser capaz de carregar a página de PetSite destino.

Detecção:

  • O estresse da CPU será detectado pelos alarmes configurados em CloudWatch.

  • As métricas de LCP também gerarão alarmes para a degradação da experiência do usuário.

Autocura:

  • A natureza distribuída da arquitetura de microsserviços significa que muitas instâncias de pods estão sendo executadas em várias zonas de disponibilidade. 

  • O plano de controle do cluster EKS afastará o tráfego dos pods afetados e lançará novos pods nos nós de trabalho.

Recuperação:  

Quando a utilização da CPU voltar ao normal, o LCP deverá se recuperar automaticamente.

Processo experimental

Adapte o seguinte exemplo de step-by-step processo ao seu experimento específico:

  1. Valide o acesso e a funcionalidade de todos os AWS X-Ray painéis CloudWatch, Amazon e CloudWatch RUM.

  2. Valide a integridade do ambiente de aplicativos:

    1. Confirme se o cluster EKS está íntegro usando o CloudWatch painel.

    2. Visite a implantação do aplicativo do site de teste de adoção de animais de estimação no URL de exemplo.

  3. Inicie uma carga para atingir o estado estável:

    1. Confirme se o gerador de carga está funcionando e enviando 5000 solicitações por segundo.

    2. Aguarde 5 minutos para que o aplicativo atinja seu estado estável.

    3. Confirme o estado estável do aplicativo usando o painel do CloudWatch RUM.

  4. Iniciar uma falha (experimento):

    1. Abra o AWS FIS console.

    2. Execute o pet-adoption-pod-stress experimento.

    3. Confirme se o experimento está sendo executado no console.

  5. Observe o impacto da falha em seu aplicativo:

    1. Capture capturas de tela do CloudWatch RUM e dos CloudWatch painéis e anote quaisquer pontos de dados anômalos.

    2. Depois que o experimento for concluído AWS FIS, capture capturas de tela adicionais para registrar se o aplicativo retorna ao estado estacionário na ausência de estresse e observe quaisquer anomalias nos pontos de dados.

    3. Se o estado estacionário não for retomado, tome medidas para recuperar o aplicativo e registre as etapas realizadas.

  6. Valide se o ambiente voltou ao normal:

    • Analise todas as métricas de negócios, experiência do usuário, aplicativos e infraestrutura para verificar se o sistema voltou a um estado conhecido. Capture capturas de tela do painel, se for útil.

Cronograma do experimento

Certifique-se de capturar o cronograma do end-to-end experimento, começando com a geração de carga, a injeção da falha, a observação do impacto e a recuperação do aplicativo, e terminando quando você interrompe a geração de carga. Isso é ilustrado no exemplo a seguir.

Exemplo de cronograma para um experimento de caos.

Resultados do experimento

ID de execução do experimento Resultados do experimento

PET-ADOPT-EXP-23

(Link para os resultados do experimento.)

Defeitos identificados

  • O cluster Kubernetes não detectou o comprometimento da CPU dos PetSite pods, por isso não agendou implantações adicionais.

  • Não houve aumento nas taxas de erro 4XX ou 5XX como resultado desse experimento.

  • Precisamos ajustar a verificação de integridade do pod para considerar o impacto no LCP quando há restrições de recursos.