Slack migra para uma arquitetura celular

• A Slack fez a transição, nos últimos 1,5 ano, de uma estrutura única para uma estrutura baseada em células para aumentar a redundância e limitar o impacto de falhas de site
• A mudança foi impulsionada pela necessidade de melhorar a resiliência do serviço da Slack após o incidente de junho de 2021, quando uma falha de rede causou degradação do serviço para clientes da Slack
• Na arquitetura celular, cada serviço opera como um serviço virtual por zona de disponibilidade (AZ), de modo que uma falha em uma AZ não afete as demais
• Ela também inclui a capacidade de drenar o tráfego de uma AZ com problemas, isolando-a de forma eficaz do restante do sistema
• O mecanismo de drenagem foi projetado para ser rápido, sem erros, gradual e independente dos recursos da AZ que está sendo drenada
• A transição para a arquitetura celular incluiu uma estratégia chamada siloing, que faz com que os serviços recebam e enviem tráfego apenas dentro de sua própria AZ. Isso ajuda a conter todas as falhas dentro de uma única AZ
• A implementação do mecanismo de movimentação de tráfego concentrou-se no sistema que roteia as consultas dos usuários para os serviços centrais
• A nova arquitetura oferece suporte à drenagem de AZ usando recursos do Envoy, como weighted clusters e atribuição dinâmica de pesos via RTDS
• Essa transição mudou a forma como a Slack opera e constrói seus serviços, fornecendo novas ferramentas robustas para gerenciamento de tráfego e mitigação de falhas
• Em futuras publicações no blog, a empresa abordará com mais profundidade os detalhes técnicos da implementação e discutirá como a nova arquitetura impactou a operação da Slack

[GN⁺]

Comentários do Hacker News

• A migração do Slack para uma arquitetura celular chamou atenção por causa da sua abordagem única de operação e monitoramento.
• A estratégia da empresa é resolver as requisições dentro de uma única zona de disponibilidade (AZ) da AWS, simplificando as operações e facilitando o monitoramento.
• Essa abordagem permite detectar e mitigar com facilidade incidentes em um único cluster ao comparar métricas entre clusters.
• No entanto, essa estratégia também gera redundância em computação, cache e outros recursos, já que a maioria dos serviços precisa rodar em vários clusters.
• Alguns usuários questionam a eficiência do sistema de requisições de API do Slack, que pode fazer fan-out de centenas de RPCs para os backends dos serviços.
• Há debate sobre a diferença entre usar afinidade com zona de disponibilidade da AWS e simplesmente descartar uma AZ fora do ar em um ponto superior de roteamento.
• Foram levantadas preocupações sobre a redundância de executar tudo na AWS USE1, já que problemas relacionados à USE1 podem afetar vários serviços.
• Surgiram dúvidas sobre como os dados dos usuários são tratados nessa arquitetura, especialmente em caso de multiplicação de AZs.
• Alguns usuários relembram arquiteturas semelhantes em que trabalharam no passado, como um sistema operacional distribuído chamado Metal Cell.
• Há discussão sobre a possibilidade de tarefas intensivas em recursos continuarem rodando indefinidamente em uma AZ isolada, mesmo sem a chegada de novas requisições de usuários.
• Os usuários também querem saber em que linguagem de programação o Slack é escrito atualmente, perguntando se ainda é Hack/PHP.
• Alguns usuários expressam decepção com o desempenho do Slack, comparando-o de forma desfavorável com outros apps de chat, como o Discord.