REL01-BP03 Acomodar restrições e cotas de serviço fixo por meio de arquitetura
Esteja ciente das cotas de serviço, das restrições de serviço e dos limites de recursos físicos que não podem ser alterados. Projete arquiteturas para aplicações e serviços visando evitar que esses limites afetem a confiabilidade.
Os exemplos incluem largura de banda da rede, tamanho da carga útil da invocação da função sem servidor, taxa de intermitência de controle de utilização para um gateway da API e conexões simultâneas de usuários com um banco de dados.
Resultado desejado: a aplicação ou o serviço funciona conforme o esperado em condições normais e de alto tráfego. Eles foram desenvolvidos para funcionar com as limitações referentes às restrições ficas ou cotas de serviço do recurso.
Práticas comuns que devem ser evitadas:
-
Escolher um design que usa um recurso de um serviço sem saber que há restrições de design que causarão falha à medida que você escala.
-
Usar parâmetros de comparação fora da realidade e que atingirão as cotas fixas do serviço durante os testes. Por exemplo, executar testes em um limite de intermitência mas por um período estendido.
-
Escolher um design que não possa ser escalado nem modificado caso seja necessário ultrapassar as cotas fixas do serviço. Por exemplo, um tamanho de carga útil do SQS de 256 KB.
-
A observabilidade não foi projetada nem implementada para monitorar e alertar sobre os limites das cotas de serviço que podem estar em risco durante eventos com tráfego alto.
Benefícios de implementar esta prática recomendada: verificar se a aplicação será executada em todos os níveis de carga de serviços projetados sem interrupção ou degradação.
Nível de risco exposto se esta prática recomendada não for estabelecida: Médio
Orientação para implementação
Ao contrário das cotas de serviço flexíveis ou de recursos que são substituídos com unidades de capacidade mais altas, as cotas fixas dos serviços da AWS não podem ser alteradas. Isso significa que todos esses tipos de serviços da AWS devem ser avaliados com relação a possíveis limites de capacidade rígidos quando usados no design de uma aplicação.
Os limites rígidos são mostrados no console do Service Quotas. Se as colunas mostrarem ADJUSTABLE = No, o serviço tem um limite rígido. Os limites rígidos também são mostrados em algumas páginas de configuração de recursos. Por exemplo, o Lambda tem limites rígidos específicos que não podem ser ajustados.
Como exemplo, ao projetar uma aplicação Python para ser executada em uma função do Lambda, a aplicação deve ser avaliada para determinar se há alguma chance de o Lambda ser executado por mais de 15 minutos. Se código puder ser executado mais do que esse limite de cota de serviço, tecnologias ou designs alternativos devem ser considerados. Se esse limite for atingido depois da implantação na produção, a aplicação sofrerá uma degradação e interrupção até que isso possa ser corrigido. Ao contrário das cotas flexíveis, não há um método para alterar esses limites mesmo sob eventos de emergência de severidade 1.
Depois que a aplicação for implantada em um ambiente de teste, estratégias devem ser usadas para descobrir se algum limite rígido pode ser atingido. Testes de estresse, testes de carga e testes de caos devem fazer parte do plano de teste de introdução.
Etapas de implementação
-
Revise a lista completa de serviços da AWS que poderiam ser usados na fase de design da aplicação.
-
Revise os limites da cota flexível e os da cota rígida para todos esses serviços. Nem todos os limites são mostrados no console do Service Quotas. Alguns serviços descrevem esses limites em locais alternativos.
-
À medida que você planeja a aplicação, revise os fatores que impulsionam a tecnologia e os negócios da workload, como resultados empresariais, casos de uso, sistemas dependentes, destinos de disponibilidade e objetos de recuperação de desastres. Permita que os fatores que impulsionam a tecnologia e os negócios orientem o processo para identificar o sistema distribuído certo para sua workload.
-
Analise a carga do serviço nas regiões e contas. Muitos limites rígidos são regionais para os serviços. No entanto, alguns limites são baseados em conta.
-
Analise arquiteturas de resiliência quanto ao uso de recursos durante uma falha de zona e de região. Na progressão de designs de várias regiões usando as abordagens ativo/ativo, ativo/passivo – quente, ativo/passivo – frio e ativo/passivo – luz-piloto, esses casos de falha resultarão em maior uso. Isso cria um possível caso de uso para atingir limites rígidos.
Recursos
Práticas recomendadas relacionadas:
Documentos relacionados:
-
Pilar Confiabilidade do AWS Well-Architected Framework: Disponibilidade
-
AWS Service Quotas (antigamente conhecido como Limites de serviço)
-
Verificações de práticas recomendadas do AWS Trusted Advisor (consulte a seção Limites de serviço)
-
Parceiro da APN: parceiros que podem ajudar no gerenciamento de configuração
-
Gerenciar o ciclo de vida da conta em ambientes SaaS de conta por locatário na AWS
-
Gerenciar e monitorar o controle de utilização de APIs em suas workloads
-
Visualizar recomendações do AWS Trusted Advisor em grande escala com o AWS Organizations
-
Automatizar aumentos de limites de serviço e suporte corporativo com o AWS Control Tower
Vídeos relacionados:
Ferramentas relacionadas:
