Desempenho de computação e armazenamento

Os tópicos anteriores tratavam de enxergar um problema e reagir a ele. Este trata dos problemas que nunca disparam alarme: uma instância com o dobro do tamanho necessário, um volume que fica sem créditos de burst às 3 da manhã, uma transferência que usa um quinto da banda que você paga. Nada está quebrado em nenhum desses casos, e é por isso que eles sobrevivem meses, e por isso que a prova dedica um task statement inteiro a encontrá-los.

O que este tópico cobre

• Findings, finding reasons e performance risk do Compute Optimizer, e a métrica que o CloudWatch não coleta sem um agent
• O modelo de créditos de CPU por trás das instâncias burstable da família T, e a diferença entre modo standard e unlimited
• Largura de banda de fluxo único contra agregada, créditos de I/O de rede e os contadores de allowance da ENA que revelam throttling que as médias do CloudWatch escondem
• Placement groups cluster, partition e spread, com os limites e os erros de capacidade que vêm com cada um
• Tipos de volume EBS e seus modelos de provisionamento, a ligação entre tamanho de I/O e throughput, e a aritmética de créditos de burst do gp2
• Diferenciar um volume sofrendo throttling de uma instância sofrendo throttling, e modificar um volume vivo com Elastic Volumes
• Taxas de requisição do S3 por prefixo, respostas 503 Slow Down, byte-range fetches, multipart uploads e a escolha entre Transfer Acceleration, DataSync e dispositivos Snow
• Modos de desempenho, modos de throughput e políticas de lifecycle do EFS, além dos 4 file systems do FSx e do Mountpoint for Amazon S3

Por que isso importa

A Task 1.3 do guia da SOA-C03 pede que você otimize recursos de computação com métricas de desempenho e tags, analise métricas do EBS e escolha o tipo de volume certo, implemente estratégias de transferência no S3, avalie opções de armazenamento compartilhado e ajuste instâncias EC2 junto com o armazenamento e a rede delas. Essas questões raramente cobram definição. Elas dão um sintoma e um conjunto de números e perguntam qual limite você está atingindo.

O padrão se repete em quase tudo aqui: a AWS entrega um baseline que você sustenta para sempre mais um balde de créditos para passar dele, e o incidente acontece quando o balde esvazia. Aprenda a reconhecer esse formato uma vez, em CPUCreditBalance, BurstBalance, EBSByteBalance%, créditos de I/O de rede e BurstCreditBalance do EFS, e uma fatia grande deste domínio vira a mesma pergunta vestida com nomes de serviço diferentes.