Entrar em produção é um evento emocionante e assustador ao mesmo tempo.
Fazer isso com um aplicativo sem servidor pode ser ainda mais assustador se você não estiver ciente de todas as ressalvas.
Este blog abordará minha lista de verificação pessoal de produtização para aplicativos sem servidor.
No entanto, alguns itens na lista de verificação são relevantes para aplicativos SaaS em geral.
Categorias
A lista de verificação é dividida em cinco categorias:
Desempenho
Segurança
Práticas de CI/CD
Recuperação de crise
Observabilidade e prontidão de suporte
Desempenho
Executar testes de desempenho
Seu aplicativo sem servidor funciona e todos os testes estão verdes.
Ótimo, mas você examinou o desempenho geral e os gargalos ocultos que podem travar seu aplicativo?
Não espere que problemas de desempenho ocorram; resolva-os o mais rápido possível:
1. Use o rastreamento do AWS X-Ray para encontrar gargalos no seu código e refatorá-los.
2. Use o AWS Lambda Power Tuning para equilibrar custo e desempenho.
3. Considere mudar para a CPU Graviton para suas funções Lambda.
Leia mais sobre rastreamento e monitoramento de desempenho aqui .
Esconderijo
Melhore os gargalos de desempenho adicionando mecanismos de cache.
Muitos mecanismos de cache podem proporcionar um aumento substancial no desempenho do seu aplicativo.
Para o AWS Lambda, um cache na memória ( memorização ) ou uma tabela de cache do DynamoDB (com/sem DAX ) geralmente são considerados uma solução fácil e podem proporcionar um aumento imediato no desempenho.
Leia mais sobre isso no post de Yan Cui.
Segurança
Testes de penetração
Testes de penetração são óbvios e obrigatórios em qualquer serviço, especialmente um serviço sem servidor.
Execute testes de penetração em uma conta AWS dedicada com uma configuração que corresponda à sua conta de produção.
Revisão de Segurança Interna
Realize uma revisão interna de segurança do aplicativo com um especialista em segurança da AWS para identificar pontos de falha e tomar medidas para resolvê-los.
AWS WAF
Use o AWS Web Application Firewall (WAF) - use regras gerenciadas pela AWS em seus API Gateways e distribuições do CloudFront.
Inspeção AWS Lambda
Habilite o Amazon Inspector em suas funções e camadas do AWS Lambda.
"O Amazon Inspector verifica funções e camadas inicialmente na implantação e as verifica novamente automaticamente quando há alterações nas cargas de trabalho, por exemplo, quando uma função do Lambda é atualizada ou quando uma nova vulnerabilidade ( CVE ) é publicada."
Saiba mais sobre isso aqui .
Verificador de vulnerabilidades de CI/CD
Use um scanner de vulnerabilidades no seu pipeline de CI/CD. Enquanto o Amazon Inspector verifica camadas e funções Lambda implantadas para vulnerabilidades, é sempre bom "mudar para a esquerda" e fazer essas verificações o mais cedo possível no pipeline de CI/CD.
Usei ferramentas como Snyk, que fazem o trabalho. Leia mais sobre isso aqui .
Melhores práticas de segurança do IAC
Use as permissões do AWS IAM e as diretrizes de práticas recomendadas da AWS na sua estrutura de implantação.
Você quer evitar violações de segurança, como um API Gateway desprotegido, um bucket S3 aberto ou uma função IAM excessivamente permissiva.
Se você usar o CDK, deverá implementar o CDK nag; caso contrário, use cfn-nag .
Confira um exemplo funcional de código nag do CDK na minha postagem do blog sobre as melhores práticas do CDK de acordo com as diretrizes de segurança .
Práticas de CI/CD
Implantação Canary para funções AWS Lambda
Implantação canário para AWS Lambda - para um ambiente de produção, use implantações canário com reversões automáticas à primeira vista dos logs de erro do AWS Lambda ou alarmes acionados do AWS CloudWatch.
As implantações Canary transferem gradualmente o tráfego para sua nova versão do AWS Lambda e revertem a mudança ao primeiro sinal de erros.
Uma maneira de fazer isso é usar o AWS Code Deploy com o AWS Lambda.
Leia mais sobre isso aqui .
Implantação Canary para configuração dinâmica do Lambda
As implantações canárias também são relevantes no domínio da configuração dinâmica de aplicativos.
Os sinalizadores de recurso são um tipo de configuração dinâmica e permitem que você altere rapidamente o comportamento da sua função AWS Lambda. Uma maneira de melhorar a confiança no lançamento de recurso é poder ativar ou desativar um recurso rapidamente.
Recomendo usar o AWS AppConfig com o utilitário de sinalizadores de recursos do AWS Lambda Powertools para obter a melhor experiência com sinalizadores de recursos.
Concorrência Provisionada
Inicializações a frio do AWS Lambda podem se tornar um problema em casos de uso críticos para os negócios ou em tempo real. Serviços críticos como login do cliente e carregamento da página principal vêm à mente.
Para esses casos de uso, e apenas na conta de produção, sugiro habilitar a simultaneidade provisionada para que seu serviço esteja sempre ativo e pronto para ser atendido.
Leia mais sobre isso aqui .
Concorrência Reservada
O serviço AWS Lambda dimensiona suas funções de acordo com a carga.
No entanto, cada conta e região da AWS tem uma quantidade máxima de lambdas simultâneas , que são compartilhadas entre TODAS as funções lambda.
Se duas funções lambda forem implantadas na mesma conta e região, uma função pode ser dimensionada drasticamente e causar privação e limitação na outra função (erro HTTP 429), pois a conta inteira atinge a cota máxima simultânea.
Definir simultaneidade reservada por função lambda pode evitar isso.
Leia mais sobre isso aqui .
Recuperação de crise
Você deve aceitar que é apenas uma questão de tempo até que algo terrível aconteça.
Você não pode se preparar para tudo, mas pode ter apólices de seguro e preparar seus serviços para todas as catástrofes.
Vamos rever alguns itens que podem preparar seu serviço para o pior.
Engenharia do caos
Este é complicado. Espere o inesperado. Interrupções e erros de servidor vão acontecer, mesmo no Serverless.
Você precisa estar preparado.
Use a Simulação de Injeção de Falhas da AWS para criar caos na sua conta da AWS, fazer com que suas chamadas de API da AWS falhem e ver como seu serviço se comporta.
Tente projetar para falhas o mais cedo possível em sua jornada sem servidor.
Cópias de segurança
Faça backup dos seus dados e dos dados dos clientes.
Habilite backups de hora em hora de suas tabelas DynamoDB, bancos de dados Aurora, índices OpenSearch ou qualquer outra entidade de banco de dados. É melhor prevenir do que remediar.
Alguns serviços, como o DynamoDB, oferecem backups automáticos e facilidade de restauração.
Veja mais práticas recomendadas de backup do CDK aqui .
Restaurar do backup
Crie um processo para restaurar dados de produção a partir do backup.
Criar um backup é uma coisa, mas restaurar a partir de um backup quando o tempo está passando e clientes chateados estão batendo na sua porta é outra.
Você deve criar um processo bem definido para restaurar qualquer banco de dados de forma rápida e segura.
Desenvolva os scripts necessários, defina o processo de restauração (quem o executa, quando, como), teste-o em ambientes de não produção e treine sua equipe de suporte para usá-lo.
Ações ad hoc de produção
Crie um processo para fazer alterações/scripts/correções ad-hoc na conta de produção. Às vezes, você não pode esperar por uma correção de bug para implantar da conta dev para a produção, e pode levar muito tempo para passar por todos os estágios do pipeline de CI/CD.
Às vezes, você precisa de uma maneira rápida, auditada e segura de alterar dados de produção.
Certifique-se de que ele seja auditado, exija aprovações extras e não viole nenhuma regulamentação à qual você seja obrigado.
Redundância de dados
Design para redundância de dados. As regiões da AWS podem cair. Sim, isso acontece .
No entanto, você não pode deixar todo o seu serviço ir por água abaixo junto.
Projete backups de várias regiões conforme explicado aqui .
Simule a interrupção na região primária e verifique se o aplicativo funciona na região secundária.
Quando a região primária estiver ativa novamente, valide se os dados do cliente estão sincronizados com a região secundária.
Observabilidade e prontidão de suporte
Boas práticas de observabilidade e registro deixarão seus desenvolvedores e equipes de suporte felizes.
ID de correlação
Aos meus olhos, a sessão de depuração perfeita é aquela em que consigo rastrear uma única atividade do usuário em vários serviços com apenas um ID — o famoso valor de ID de correlação .
Uma maneira de obter essa experiência é injetar um valor de ID de correlação nos seus logs de serviço.
Além disso, você deve passar esse valor para qualquer chamada seguinte aos serviços por meio de cabeçalhos de solicitação/evento (atributos do AWS SNS/cabeçalhos HTTP, etc.).
Veja um exemplo aqui com o AWS Lambda Powertools Logger.
Painéis de Observabilidade
Crie painéis do AWS CloudWatch que forneçam uma visão geral de alto nível do status do seu serviço para sua equipe de SRE.
Ele deve conter logs de erros gerenciáveis e informações de serviço, para que pessoas não desenvolvedoras possam identificar rapidamente os erros e suas causas raiz.
Deixe os painéis complicados contendo métricas de serviço de baixo nível do CloudWatch para os painéis do desenvolvedor.
Trabalhe em estreita colaboração com a equipe de SRE, adicione mensagens de log precisas descrevendo problemas de serviço e crie o painel.
Leia mais sobre observabilidade e CloudWatch aqui .
Alertas
Defina alertas do CloudWatch em logs de erros críticos ou métricas do CloudWatch que se correlacionam a uma deficiência grave de serviço ou negação de serviço.
Isso pode incluir falhas na função Lambda, problemas de latência, tempos limite da função Lambda, erros do DynamoDB, problemas de login do Cognito, etc.
Cada alarme precisa ser investigado e mitigado rapidamente.
Treinamento
Invista tempo e esforço em treinamento de suporte para desenvolvedores e SREs.
Cada log de erro do painel ou métrica do CloudWatch deve ter uma ação predefinida para o SRE executar.
Inclua diretrizes como "Se você vir 'X' e 'Y', provavelmente significa que Z é um problema. Siga estas etapas para mitigar Z".
Certifique-se de que os SREs entendam a arquitetura de alto nível orientada a eventos do serviço para que possam oferecer suporte a ele de forma mais eficiente.
Métricas de KPI
Adicione métricas de KPI - indicadores-chave de desempenho são métricas "especiais" que, em teoria, podem prever o sucesso do seu serviço.
Os KPIs servem como um meio de prever o futuro do negócio. Os KPIs são estrategicamente projetados para dar suporte ao caso de uso do negócio. Eles exigem um profundo entendimento do seu negócio e dos usuários e, como tal, exigem uma definição cuidadosa.
Não cumpra KPIs bem definidos e veja seu serviço fracassar. Tenha sucesso em atingir seus KPIs e seu serviço terá mais chances de sucesso.
Aprenda aqui como implementar KPIs no seu serviço Serverless com métricas personalizadas do AWS CloudWatch.