Sem servidor não significa DevOpsLess ou NoOps

Ao selecionar serverless e Lambda como a arquitetura preferida para suas operações em nuvem, você precisa entender as limitações inerentes para escalar assim que seu aplicativo e código de produto começarem a crescer em tamanho e complexidade.

Serverless é uma boa opção para acelerar rapidamente ao criar o código do seu aplicativo, mas há um equívoco comum de que serverless significa DevOpsLESS ou NoOps, e isso simplesmente não é o caso.

Além do mais, às vezes você tem que realmente investir em design e arquitetura com antecedência para não bater em um muro mais tarde ou incorrer em muitas dívidas técnicas. Nesta postagem, forneceremos uma visão geral de algumas das limitações que encontramos ao construir o Jit, uma plataforma DevSecOps de software como serviço, baseada em arquitetura sem servidor e baseada em eventos.

Uma rápida visão geral das pegadinhas sem servidor

Quando seus aplicativos começam a crescer, há desafios exclusivos do paradigma sem servidor que serão rapidamente encontrados se você não planejar com antecedência. Gostaríamos de ajudar aqueles que exploram a tecnologia sem servidor a estarem cientes do que precisam para projetar seus aplicativos, antes mesmo de começarem (ou possivelmente retrabalharem rapidamente, se já o fizeram).

Estrangulamento

A limitação do Lambda ocorre como resultado do número de instâncias que você pode executar simultaneamente. (Este post explica como superar isso).

O AWS Lambda limita isso a 1.000 por padrão (você pode solicitar o aumento desse limite, mas precisa estar ciente de que ele existe em primeiro lugar). No entanto, observe que isso tem implicações de custo; portanto, você não deve aumentar automaticamente seu limite antes de examinar o design de sua arquitetura e garantir que realmente precisa disso.

Isso significa que quanto mais eventos ou serviços você executar simultaneamente, mais rapidamente você atingirá um obstáculo. Isso é algo em que você precisa pensar já na primeira linha do código se planeja executar inteiramente em uma arquitetura sem servidor.

Embora seu projeto possa funcionar hoje em pequena escala, você precisa pensar muito cedo se ele será dimensionado linearmente.

Lembre-se de que o objetivo desta limitação é proteger você e a AWS contra erros ou design incorreto. Por exemplo, imagine um caso em que de alguma forma um Lambda chama a si mesmo em um loop. Sem esse mecanismo de proteção integrado, você poderia alcançar milhões de invocações.

Embora seu projeto possa funcionar hoje em pequena escala, você deve pensar desde o início se ele será dimensionado linearmente quando você tiver milhares de inquilinos ou clientes (ou mais). Dependendo de como você arquiteta seus recursos, Lambdas e microsserviços (e quão “micro” é cada serviço), se você dividir seus serviços em pedaços muito pequenos, poderá acabar quebrando todo o fluxo da cadeia de serviços devido à limitação de muitos serviços paralelos. eventos.

Isso significa que você precisa estar bem ciente de quanto tráfego está lidando atualmente, na forma de eventos por minuto, e até mesmo picos e tráfego atípico que seus serviços gerenciam. Tudo isso precisa ser considerado, além do método de invocação de comunicação empregado para cada um – sincronizado ou assíncrono (abordaremos isso mais profundamente posteriormente) – onde, com a invocação síncrona, cada serviço ou chamada de sistema se soma e pode sobrecarregar o sistema.

É importante estar ciente de que a forma como a limitação funciona não é exatamente previsível. Portanto, mesmo que você tenha o monitoramento implementado para garantir que não atingirá 1.000 eventos paralelos e pense que está coberto, isso pode realmente acontecer com seu primeiro pico, onde a limitação pode ocorrer em um limite ainda mais baixo, pois isso é essencialmente comportamento inesperado (mas documentado nos documentos da AWS). Portanto, uma boa prática é arquitetar seus sistemas de forma que possam se recuperar quando isso acontecer (como idempotência e novas tentativas).

Tempos limite

Como o próprio nome indica, serverless não é executado em servidores que funcionam para sempre; eles fornecem um tempo de execução efêmero que tem, no máximo, uma janela total de 15 minutos para o tempo de execução da função. Isso pode afetar o tamanho da entrada que seu serviço pode manipular. Ao projetar suas funções desde o início e o tamanho da entrada aumentar continuamente junto com o tempo de processamento, você poderá encontrar tempos limite durante o tempo de execução.

Portanto, um padrão de design recomendado para serviços ou funções com um tempo de execução que é dimensionado linearmente com o tamanho da sua entrada é dividir a entrada em partes ou lotes e tratá-los em Lambdas diferentes. Também é uma boa prática usar filas, ao fazer isso, para evitar estrangulamento.

Tamanho do Evento

O padrão de design orientado a eventos, popular em sistemas baseados em servidor, muitas vezes requer uma diversidade de serviços na cadeia para manipulação de eventos, incluindo um gateway de API, SQS (Amazon Simple Queue Service), ponte de eventos, SNS (pub/sub da Amazon). serviço), onde cada um deles tem diferentes limites de tamanho de evento. Cada recurso que você usa pode ter limites de tamanho diferentes dos quais você precisa estar ciente, onde a passagem de dados ao longo da cadeia pode ser interrompida ao enviar uma carga útil grande.

Cada um desses recursos na cadeia é capaz de processar cargas úteis de tamanhos diferentes, e isso significa que você terá eventos com falha se não levar isso em consideração antecipadamente.

Isso significa que você não pode enviar cargas ilimitadas entre recursos e precisa estar ciente disso ao criar suas funções e serviços. Cada um desses recursos na cadeia é capaz de processar cargas úteis de tamanhos diferentes, o que significa que você terá eventos com falha se não levar isso em consideração antecipadamente e garantir que essa carga útil possa ser recebida em todos os serviços e recursos do sistema.

Uma solução, essencialmente uma solução alternativa, pode ser passar grandes cargas por meio de um bucket S3, aproveitando um recurso diferente que ofereça suporte ao tamanho da carga. (Dica profissional: pesquise “cotas de serviço AWS” para saber mais sobre os recursos que você usa. Esta é uma boa referência para começar.)

Idempotência

Devido a todos os desafios e motivos descritos acima, e porque sempre ocorrerão falhas, a latência acontece. Lambdas e recursos sem servidor geralmente são criados em mecanismos de nova tentativa. É aqui que a idempotência é crítica. Os serviços precisam entregar o mesmo resultado para uma determinada entrada, não importa quantas vezes eles sejam repetidos ou parcialmente repetidos (isso significa que mesmo que apenas uma parte do fluxo seja repetida, o resultado ainda precisa ser o mesmo).

Você precisa projetar a idempotência com antecedência para que novas tentativas e repetições não afetem o estado dos seus sistemas de produção. Uma boa prática é garantir que, ao executar dados, você crie IDs determinísticos exclusivos, mas não aleatórios, para cada instância. Este é um bom guia para fazer isso direito.

Perda de memória

Para entender como acontecem os vazamentos de memória, primeiro você precisa entender como funciona o mecanismo que executa seu código, pois ele também tem suas limitações. Quando se trata de funções Lambda, o mesmo executor Lambda é reutilizado continuamente até morrer. Talvez ele funcione 1.000 vezes perfeitamente, mas pode começar a falhar na 1.001ª execução e causar problemas com seus serviços.

Por exemplo, pegue o código Python com o mesmo interpretador que é usado repetidamente. Se esse código adicionar objetos de memória global a cada execução que possa passar por diferentes instâncias de execuções, isso poderá levar a vazamentos de memória, onde você excederá os limites de memória da instância. E então seu Lambda irá travar.

Isto é particularmente importante ao usar recursos compartilhados e com arquitetura multitenancy. Você precisa garantir que não deixará para trás recursos não utilizados, dados confidenciais ou essencialmente outro lixo. Quando se trata de isolamento de locatário, se você estiver usando memória compartilhada, precisará ter muito cuidado para que os dados não vazem entre instâncias, pois assim os dados podem vazar entre locatários. Compartilhamos uma postagem sobre isolamento de locatário na camada de dados, mas isso é igualmente verdadeiro para o tempo de execução.

Sincronizar vs. Invocação Assíncrona

A invocação síncrona em serverless pode levar a muitos problemas (alguns dos quais foram mencionados acima, como limitação). Quando possível, e respostas imediatas não são necessárias, o padrão de invocação assíncrona é de longe preferido com serverless.

Serverless geralmente foi projetado para ser mais assíncrono e sem estado do que síncrono e com estado, por isso é sempre melhor aproveitar a força da tecnologia. Quando você precisar de invocação síncrona, certifique-se de ter as proteções corretas instaladas, como usar um gateway de API, e ter visibilidade por meio do registro adequado.

Grades de proteção para tolerância a custos e falhas

Isso foi complicado e provavelmente assustador para aqueles que exploram a tecnologia sem servidor como sua infraestrutura preferida. Dito isso, o serverless é extremamente poderoso, escalável e flexível, e com as proteções corretas instaladas, você pode evitar esses problemas quase totalmente.

Outra preocupação comum quando se trata de execução sem servidor é, obviamente, o custo, e isso não deve ser ignorado. A maneira como você projeta e arquiteta seus aplicativos também terá implicações diretas nos custos. Você precisa ter os mecanismos adequados para não exceder excessivamente os recursos, começando com alertas de cobrança e design de sistema geralmente consciente dos custos, o que é uma prática extremamente importante com serverless.

A maneira como você projeta e arquiteta seus aplicativos também terá implicações diretas nos custos.

Outras áreas que são uma postagem completa no blog são o monitoramento e o teste de aplicativos sem servidor. Na verdade, é fundamental ter o monitoramento, a observabilidade, o registro e o rastreamento corretos para garantir que, ao escrever um aplicativo composto de 50 Lambdas, você possa testar se o fluxo está funcionando corretamente e continua funcionando corretamente durante o tempo de execução na produção .

Isto é particularmente verdade quando a produção significa 10.000 inquilinos. Uma vantagem adicional de estar ciente de como a arquitetura sem servidor funciona nos bastidores é que, ao seguir as diretrizes sugeridas aqui, você obterá melhorias significativas de custos, como subproduto, juntamente com um melhor design do sistema.

Projetando para resiliência e robustez com aplicativos sem servidor

Serverless é uma excelente escolha para quem busca execução rápida, foco na entrega e implementação de produtos e recursos sem muito gerenciamento e sobrecarga de infraestrutura. Ao optar por executar sem servidor, você precisa ter em mente que isso significa usar vários recursos diferentes da AWS e é fundamental entender como cada um funciona de forma independente e em conjunto, juntamente com suas limitações e falhas.

Em nossa próxima postagem, mergulharemos em padrões de design sem servidor recomendados adicionais, incluindo isolamento de locatário, pools de conexão para bancos de dados e privilégio mínimo, além de como evitar antipadrões como falta de locatário, loops infinitos, invocações ineficientes e instâncias de CPU e RAM excessivamente grandes.

Lembre-se, como todos os aplicativos nativos da nuvem no cenário imprevisível e dinâmico da nuvem, garantir que você tenha a visibilidade adequada sobre a forma como seus aplicativos estão funcionando por meio de monitoramento e registro é especialmente importante com aplicativos sem servidor.

Também é essencial garantir a segurança, bem como a privacidade dos dados, para não comprometer dados críticos ao usar recursos compartilhados e multilocação. Existem excelentes ferramentas DevSecOps que podem ajudá-lo a fazer isso. Ao entender como suas tecnologias funcionam nos bastidores, você pode otimizar seu design, arquitetura e código de aplicação para obter melhor desempenho, segurança e tolerância a falhas.

A postagem Serverless não significa DevOpsLess ou NoOps apareceu pela primeira vez em The New Stack.