A transição do uso de conexões SSH para APIs REST na execução de jobs no Amazon EMR representa um marco na modernização da infraestrutura de dados do Slack. Ao descontinuar o acesso direto via terminal para seus mais de 700 operadores no Apache Airflow, a empresa não apenas elevou sua postura de segurança, mas também eliminou gargalos operacionais que limitavam a escala de seus sistemas críticos.
Para profissionais de Engenharia de Dados e DevOps no Brasil, este movimento ilustra um dilema comum: o uso de atalhos técnicos, como o SSH para prototipagem rápida de pipelines, que acabam se tornando dívida técnica pesada à medida que a organização cresce. A implementação de uma camada de orquestração interna, batizada de Quarry, centralizou a governança de oito regiões globais de dados, substituindo comandos arbitrários por chamadas estruturadas e auditáveis.
O fim do gargalo operacional: O risco do SSH em produção
Historicamente, o SSH é utilizado por ser uma via rápida para conectar o orquestrador aos nós mestres do cluster. No entanto, em um ambiente de produção de alta escala, essa conveniência torna-se um passivo. A dependência de rede constante entre o cliente e o cluster cria falhas silenciosas e instabilidades que tornam a depuração um desafio constante.
Além da confiabilidade, a segurança foi o pilar central da mudança. A gestão de chaves SSH em centenas de nós gera um overhead de manutenção insustentável e amplia significativamente a superfície de ataque da infraestrutura. Com a arquitetura REST, o Slack passou a utilizar:
- Logging Estruturado: Visibilidade total sobre quem executa jobs e em quais horários.
- Monitoramento Centralizado: Métricas precisas que evitam a ocorrência de jobs zumbis.
- Auditoria Compliance: Rastreabilidade completa, requisito indispensável para empresas que lidam com grandes volumes de dados.
Como a migração foi estruturada na prática
Migrar centenas de fluxos de trabalho sem interromper o serviço exigiu uma estratégia de transição incremental, realizada ao longo de três trimestres. O maior desafio técnico foi tratar workloads que dependiam de scripts shell legados, os quais não possuem interfaces nativas como Livy ou HiveServer2.
A arquitetura REST não é apenas uma melhoria pontual, mas a base que permite ao Slack migrar workloads de Spark para Kubernetes no futuro, garantindo desacoplamento entre o orquestrador e a infraestrutura de processamento.
A equipe de engenharia do Slack utilizou o Apache Hadoop YARN Distributed Shell para contornar essa limitação. Esta ferramenta permitiu encapsular comandos shell em containers gerenciados, garantindo que cada job tivesse isolamento de recursos e tolerância a falhas, superando as limitações do acesso direto via terminal.
Lições para times de Engenharia no Brasil
O caso do Slack funciona como um espelho para times de tecnologia brasileiros que lidam com infraestrutura de dados complexa. O uso de APIs REST para a submissão de jobs em vez de conexões via protocolo SSH expôs gargalos como configurações inadequadas de memória no YARN e falhas de rede entre contas na cloud que antes eram mascaradas pela natureza não estruturada das conexões SSH.
A principal lição é a proatividade: combater a dívida técnica antes que ela se torne um impeditivo de escala. Ao desacoplar o Airflow da infraestrutura física do EMR, a empresa ganhou a flexibilidade necessária para atualizar componentes sem quebrar pipelines, um movimento essencial para qualquer organização que busca maturidade em engenharia de dados.
Perguntas Frequentes
O que motivou a troca do SSH pelo REST no Slack?
O principal motivador foi a segurança e a necessidade de escalabilidade. O SSH exigia a gestão complexa de chaves, dificultava a auditoria e gerava instabilidades operacionais com falhas de rede, tornando a observabilidade dos jobs em produção ineficiente.
Como foram migrados os jobs que dependiam de scripts shell?
O Slack utilizou o Apache Hadoop YARN Distributed Shell, que permitiu a execução de comandos shell dentro de containers isolados, oferecendo melhor controle de recursos e maior resiliência em relação ao acesso direto via terminal.
Qual o maior ganho da nova arquitetura REST?
A arquitetura trouxe um ciclo de vida de job totalmente gerenciado, com submissão, monitoramento e logging estruturado, além de preparar o ambiente para a adoção de tecnologias futuras, como a execução de workloads de Spark em Kubernetes.
