AWS RDS db.t2 limiares e monitoramento de desempenho de instâncias

Question

Estamos implantando uma configuração padrão de servidor da Web para softwares CMS convencionais, como o Drupal & WordPress, com o servidor & armazenamento em EC2 / EBS e o banco de dados para aqueles pacotes de software em RDS / MySQL.

Normalmente, entramos em produção com uma CPU t2.micro e um banco de dados db.t2.micro , o que deixa os clientes satisfeitos conosco & AWS, pois eles podem ficar no nível gratuito pelo primeiro ano. As ferramentas de monitoramento padrão no EC2 mostram claramente quando podemos estar excedendo o recurso mais caro para o host da Web, que é Utilização da CPU . Se o limite se aproximar ou ultrapassar 10%, sabemos que chegou a hora de migrar para o tipo de instância t2.small .

Estamos muito menos certos sobre como determinar quando precisaremos atualizar de db.t2.micro para db.t2.small & talvez além. Esses requisitos não envolveriam réplicas de multi-AZ ou de leitura, apenas condições em que o software do CMS poderia se basear no banco de dados durante os períodos de pico que precisaríamos detectar por meio de um gráfico ou alarme.

Os documentos para as instâncias do EC2 indicam claramente quais são os seus próprios limites, e eu queria saber se esses limites para instâncias de RDS podem ser recomendados para nosso caso simples. Os requisitos gerais em Práticas recomendadas para o Amazon RDS são úteis, embora eu não tenha seguido todos os links, pois estou simplesmente tentando definir limites que podemos colocar em prática que exigirão claramente uma instância de banco de dados atualizar de uma maneira que meus clientes não técnicos possam entender & observar.

Eu confesso que não sou um DBA; Pela natureza do meu trabalho, deixei a arquitetura do banco de dados para os projetistas do software CMS. Eu certamente estou disposto a aprender o básico da avaliação de desempenho se alguém me disser por onde começar no que se refere a essa configuração na plataforma da AWS. Talvez eu não tenha encontrado os documentos ou tutoriais oficiais certos ainda.

Alternativamente: só precisamos saber como medir quantitativamente se algum atraso no acesso à nossa instância do RDS é o resultado do tamanho da instância ser muito pequeno (ou talvez os parâmetros do recurso MySQL definidos serem muito baixos) com base no que estamos vendo CloudWatch.

De forma trivial, posso dizer se a métrica CloudWatch Freeable Memory chega perto de zero, então precisaríamos de uma atualização de instância. E como com a nossa instância EC2, também deve haver um máximo CPU Utilization que eu acho que seria muito abaixo de 100%, embora eu não tenha visto isso documentado como eu tenho para o EC2. Eu imagino que haveria um máximo prático para Conexões de BD . Finalmente, espero que alguém me diga como interpretar Write IOPS & Leia IOPS e se estes imporem limitações de desempenho em pequenas configurações como as nossas ou se forem simplesmente usados para calcular o custo.

p.s., tentei postar isso em Fóruns da AWS: Serviço de banco de dados relacional da Amazon , mas o link Postar novo tópico produz atualmente um "loop de redirecionamento". (Desculpe, não posso incluir mais URLs aqui, mas não tenho permissão.)

[editar, resposta a comentario] obrigado @Ross, eu não sabia que CPUCreditBalance também estava disponível no RDS (eu tinha visto no EC2); não viu que havia uma segunda tela com mais 7 métricas com todas as 17 selecionáveis de uma lista. Ainda estou me perguntando quais limitações podem ser impostas aos recursos monitoráveis que não sejam a CPU, especialmente a atividade de E / S, de acordo com o tipo de instância do RDS.

p.p., refinei a questão um pouco mais & postado em fóruns da AWS ( Como determinar se as instâncias do RDS T2 são dimensionadas corretamente com as estatísticas do CloudWatch? )

    

Answer 1

Eu tive alguma perspectiva sobre isso nos últimos meses & Acredito que esses itens para assistir abordarão todas as preocupações acima:

1) O comentário do @Ross na postagem original é a chave. As instâncias T2, não importa a escala e não importa se são EC2 ou RDS, deixarão de funcionar quando seus créditos de CPU acabarem à medida que as demandas de CPU de pico continuarem.

2) O modo de falha de um servidor da web CMS que vimos com mais frequência é mostrado exatamente por essa condição: o gráfico do CloudWatch mergulha na direção zero quando a porcentagem da CPU necessária por httpd processa excede a porcentagem da CPU atribuída a esse tipo de instância (veja o link do doc abaixo).

3) A solução rápida para uma instância T2 que esgotou os créditos da CPU é desligar, atualizar o tipo de instância e iniciar a instância novamente, o que leva cerca de 3-4 minutos. A descrição mais importante das capacidades de diferentes tipos de instâncias está aqui: link

4) Qualquer servidor da Web de produção na AWS deve ter um endereço Elastic IP atribuído antecipadamente por esse motivo: se não, e a instância for redimensionada, o endereço IP será alterado, deixando o servidor da Web inacessível muito além do que seria 3-4 minutos de inatividade.

5) A única maneira de adquirir mais créditos de CPU é atualizar o tipo de máquina. A quantidade de créditos que cada tamanho de instância T2 pode conter é descrita no link doc acima: é sempre igual ao trabalho da CPU que o tipo de instância faria em 24 horas.

6) A máquina pode retornar à sua escala original durante um pouco de tempo de inatividade programado (novamente, 3-4 minutos) depois que o desempenho de pico exigir a redução.

7) A atividade de E / S não causou qualquer degradação no desempenho do nosso servidor da Web em nenhum período de pico até o momento. A quantidade de IOPS é determinada estritamente pelo tamanho do volume do EBS. O significado exato de IOPS e esse relacionamento são descritos aqui: link

8) Nenhuma das métricas do Cloud Watch Freeable Memory nem Conexões com o DB foram de alguma forma antecipando ou corrigindo problemas de desempenho em um ambiente intensivo de servidor da Web.