Slack завершил масштабную модернизацию своей платформы данных, заменив выполнение задач по протоколу SSH на основанную на REST архитектуру в своих Amazon EMR пайплайнах. Это решение позволило устранить прямой доступ по SSH к производственным кластерам и перенести более 700 операторов Airflow на централизованную систему подачи заданий.
История проблемы
Ранее Slack использовал операторов Airflow, которые выполняли задачи через открытые SSH-соединения с мастер-узлами Amazon EMR. Изначально этот подход казался простым, но по мере увеличения количества производственных рабочих процессов, включая индексацию и аналитические пайплайны, система начала накапливать операционные и Sicherheits проблемы.
По состоянию на 2024 год использование SSH стало массовым, что только усугубило проблему. Прямой доступ увеличивал атакованную поверхность, а необходимость ротации SSH-ключей создавала дополнительную нагрузку на операционные процессы. Кроме того, надежность была под угрозой: задачи иногда продолжали выполняться после обрыва соединения или бесшумно падали при нестабильности инфраструктуры.
Миграция на REST
Для решения этих проблем Slack внедрил модель подачи заданий на основе REST, используя внутренний оркестратор под названием Quarry. Теперь Airflow отправляет задания через HTTP API, что позволяет сократить зависимость выполнения от клиентского соединения и улучшить наблюдаемость. Каждое задание имеет свой серверный жизненный цикл, который включает подачу, отслеживание через идентификаторы задач и контролируемую отмену.
При этом было необходимо доработать систему для поддержки различных типов нагрузок. Работы с Spark и Hive были переведены с использованием существующих REST интерфейсов, таких как Livy и HiveServer2, в то время как значительная часть задач заключала в себе произвольные команды оболочки. Для их поддержки Slack использовал возможности Apache Hadoop YARN, позволяющие выполнять команды оболочки в управляемых контейнерах с изоляцией ресурсов и отказоустойчивостью.
Значение для разработчиков
Для российских разработчиков это решение может стать сигналом: переход к REST-архитектуре не только улучшает безопасность и надежность, но и упрощает масштабирование систем. Такая модернизация позволяет снизить риски и повысить эффективность работы команд, особенно в условиях активного роста и усложнения облачных инфраструктур.
Следующий шаг для Slack — реализация масштабируемых решений на базе Kubernetes, что ожидается в ближайшие месяцы.