SEDA — para sistemas com muito throughput

Hoje um amigo enviou um texto, compartilhando conhecimento, achei interessante, mas sem tempo pra ler.

Pedi pra IA resumir o texto que fala sobre SEDA, listar os prós e contras… Leia o resultado 😉

O texto discute a arquitetura SEDA (Staged Event-Driven Architecture) para serviços de internet escaláveis e bem condicionados. Um serviço bem condicionado comporta-se como um simples pipeline, onde o throughput (vazão) aumenta proporcionalmente com a carga oferecida até que o pipeline esteja cheio, e a partir desse ponto, a carga adicional não degrada o throughput. Além disso, após a saturação, o tempo de resposta não deve aumentar mais rápido que linearmente com o número de clientes.

Benefícios do SEDA:

1. Prevenção de Sobrecarga de Recursos: SEDA evita o comprometimento excessivo de recursos quando a demanda excede a capacidade do serviço, facilitando o despejo de carga e a priorização da disponibilidade em detrimento da qualidade quando a saturação é alcançada.
2. Concorrência Extensiva e Facilidade de Programação: Combina abordagens baseadas em threads e eventos para concorrência, aproveitando os benefícios de ambas.
3. Gerenciamento Dinâmico de Recursos: Permite o ajuste dinâmico de alocações de recursos e agendamento, adaptando-se a condições de sobrecarga.
4. Isolamento e Modularidade: A introdução de filas de eventos entre estágios decuplica sua execução, promovendo isolamento, modularidade e gerenciamento de carga independente.
5. Flexibilidade e Robustez: SEDA demonstra flexibilidade de controle e robustez sobre grandes variações de carga, superando outros designs de serviço em termos de desempenho e escalabilidade.

Contras do SEDA:

1. Complexidade na Programação: A complexidade do agendador de eventos, necessário para controlar a execução de máquinas de estado finito, pode tornar a implementação e modulação mais difícil.
2. Latência Incrementada: A introdução de filas entre módulos aumenta a latência em comparação com chamadas de função diretas, devido ao controle explícito de fronteira.
3. Necessidade de Gestão de Aplicativos: A redução do tempo de resposta, além do despejo de carga, envolve operações complexas que lidam com a lógica do aplicativo, requerendo uma abordagem mais detalhada e específica.

O SEDA é avaliado por meio de aplicações como um servidor HTTP de alto desempenho e um roteador de pacotes para a rede de compartilhamento de arquivos peer-to-peer Gnutella, mostrando resultados positivos em termos de controle de flexibilidade e robustez sob diversas condições de carga. A arquitetura propõe uma solução para o escalonamento horizontal de serviços sofisticados, facilitando a distribuição de estágios em múltiplos servidores, o que pode ser particularmente útil em datacenters de grande escala.

Depois, pedi pra IA descrever um sistema utilizando SEDA e as tecnologias da AWS. Leia…

Para aplicar a arquitetura SEDA (Staged Event-Driven Architecture) utilizando as tecnologias da AWS, podemos considerar a criação de uma aplicação distribuída que faz uso extensivo de serviços gerenciados para lidar com a escalabilidade, o gerenciamento de eventos e a execução concorrente de tarefas. Abaixo, segue um exemplo de como implementar uma aplicação SEDA na AWS:

1. Definição das Etapas e Fila de Eventos

Cada etapa da aplicação SEDA pode ser implementada como uma função AWS Lambda, que é naturalmente adequada para o processamento de eventos e pode ser dimensionada automaticamente para lidar com aumentos de carga. As filas de eventos entre as etapas podem ser implementadas usando o Amazon SQS (Simple Queue Service), que oferece filas de mensagens altamente disponíveis e duráveis para armazenar mensagens enquanto elas aguardam o processamento.

2. Gerenciamento Dinâmico de Recursos

Para gerenciar dinamicamente os recursos alocados para cada etapa, pode-se usar o AWS Auto Scaling junto com o AWS Lambda. Isso permite ajustar automaticamente o número de instâncias de função Lambda em execução com base nas métricas de desempenho, como o comprimento da fila SQS associada.

3. Processamento de Eventos e Carga de Trabalho

Cada função Lambda processa eventos de sua fila SQS correspondente. A função lê a mensagem da fila, executa a lógica de processamento necessária e, em seguida, passa os resultados para a próxima fila SQS do estágio seguinte, se aplicável.

4. Isolamento e Modularidade

A separação das diferentes lógicas de processamento em funções Lambda distintas e o uso de filas SQS para comunicação entre essas funções proporcionam um alto nível de isolamento e modularidade. Isso facilita a manutenção, a depuração e a implementação de mudanças, além de permitir o gerenciamento independente da carga de cada etapa.

5. Exemplo Prático

Imagine uma aplicação de processamento de imagens onde as etapas incluem o upload da imagem, a análise da imagem, a aplicação de filtros e, finalmente, o armazenamento da imagem processada. Cada uma dessas etapas pode ser implementada como uma função Lambda separada, com filas SQS transferindo dados entre as etapas. O Amazon S3 pode ser usado para armazenar as imagens durante o processo. O AWS CloudWatch é utilizado para monitorar as métricas de desempenho e ajustar o dimensionamento automaticamente.

6. Avaliação e Monitoramento

O monitoramento contínuo do desempenho de cada etapa e da fila pode ser realizado usando o AWS CloudWatch, que pode disparar alertas e acionar políticas de autoescala baseadas em métricas pré-definidas.

Implementar uma arquitetura SEDA na AWS, portanto, aproveita uma combinação de serviços gerenciados para fornecer uma solução robusta, escalável e bem-condicionada a cargas variáveis, mantendo a modularidade e a flexibilidade necessárias para o desenvolvimento ágil e a manutenção de aplicações complexas

Também perguntei qual a diferença entre SEDA e EDA? Leia a resposta

A SEDA (Staged Event-Driven Architecture) e a EDA (Event-Driven Architecture) são duas abordagens de design de sistemas que lidam com a asincronia e a escalabilidade de maneira eficaz, porém possuem algumas diferenças fundamentais em suas estruturas e abordagens.

Event-Driven Architecture (EDA):

• Baseada em Eventos: Na EDA, o design do sistema é centrado em eventos. Um evento é uma mudança significativa no estado do sistema ou uma ação importante que ocorre. Quando um evento ocorre, ele é publicado para o restante do sistema, geralmente através de um sistema de mensagens ou um broker de eventos.
• Desacoplamento: Os componentes do sistema são desacoplados, significando que eles não chamam uns aos outros diretamente. Em vez disso, eles comunicam-se através do envio e recebimento de eventos. Isso facilita a escalabilidade, a manutenção e a evolução do sistema.
• Assíncrono por Natureza: Os componentes que lidam com os eventos geralmente operam de maneira assíncrona, permitindo que o sistema seja mais responsivo e eficiente ao lidar com cargas de trabalho variáveis.

Staged Event-Driven Architecture (SEDA):

• Arquitetura de Estágios: Na SEDA, o sistema é dividido em uma série de estágios conectados por filas de eventos. Cada estágio é responsável por uma parte específica do processamento e pode ter seu próprio pool de threads para processar os eventos de forma assíncrona.
• Gerenciamento de Recursos Dinâmico: SEDA foca fortemente no gerenciamento dinâmico de recursos, ajustando o alocamento de recursos (como threads) de acordo com a carga de trabalho. Isso permite que o sistema mantenha alta performance sob diversas condições de carga, evitando tanto a subutilização quanto a sobrecarga dos recursos.
• Decisões Baseadas em Filas: As filas entre os estágios permitem que o sistema faça decisões informadas sobre o gerenciamento de carga, como o descarte de tarefas quando o sistema está sobrecarregado, para garantir que o sistema continue operando de maneira eficiente.

Diferenças Principais:

1. Estruturação: Enquanto a EDA é centrada no conceito de eventos que desacoplam os componentes do sistema, a SEDA organiza o processamento em estágios conectados por filas, permitindo um controle mais granular sobre o fluxo de eventos e o gerenciamento de recursos.
2. Gerenciamento de Recursos: SEDA enfatiza o gerenciamento dinâmico de recursos e a capacidade de adaptar-se a diferentes cargas de trabalho, algo que é menos explícito na EDA tradicional.
3. Flexibilidade vs. Complexidade: SEDA pode oferecer uma maior flexibilidade e controle sobre o processamento e o gerenciamento de recursos, mas isso pode vir à custa de uma maior complexidade na implementação e no gerenciamento do sistema.

Ambas as arquiteturas oferecem vantagens significativas para o design de sistemas distribuídos e escaláveis, com a escolha entre elas dependendo dos requisitos específicos do sistema, como a necessidade de gerenciamento dinâmico de recursos, a preferência por uma estrutura de eventos pura ou uma combinação de ambas as abordagens para melhor atender às necessidades do projeto.

Faz sentido?

Minha conclusão

• SEDA usa EDA
• Nada de novo
• SEDA te faz pensar em como obter o auto scaling pra manter o throughput sem impacto com o aumento do TPS

SEDA: An architecture for well-conditioned scalable internet services