Переход от SSH к REST-based job submission меняет поведение data pipeline на уровне архитектуры. Это про управляемость, отказоустойчивость и контроль ресурсов.
Проблема проявляется не сразу — до момента, когда система упирается в масштаб. В рассматриваемом случае более 700 джобов выполнялись через SSH к EMR-кластерам. Это включало всё: от Spark и MapReduce до произвольных CLI-команд. Такой подход выглядел простым: подключиться к master-ноде и выполнить команду. Но с ростом количества пайплайнов SSH превратился в источник нестабильности. Соединение было stateful: при падении клиента (например, pod в Kubernetes) джоб мог продолжить выполняться, зависнуть или оставить “зомби”-процессы. Параллельно росла зона риска: прямой доступ к production-кластерам, ключи, сложная модель доступа. В какой-то момент это стало блокером для дальнейшей эволюции инфраструктуры.
Решение оказалось не в “улучшении SSH”, а в отказе от него. Команда перешла к REST-based job submission через API. Ключевая идея — перенести управление жизненным циклом джоба на серверную сторону. Вместо удержания соединения клиент отправляет HTTP-запрос, а дальше система сама отслеживает выполнение. Это снижает связанность компонентов и делает поведение предсказуемым. Для Hadoop-стека (Spark, Hive, MapReduce) уже существовали API: Livy и HiveServer2. Основная сложность была в другом — более 300 задач представляли собой произвольные shell-команды без REST-интерфейса. Здесь использовали YARN Distributed Shell. Это позволило запускать любой shell-скрипт внутри контейнера YARN с управлением ресурсами и стандартным lifecycle. Компромисс очевиден: добавляется слой абстракции, но взамен появляется единая модель исполнения.
Архитектурно ключевым элементом стал промежуточный сервис — REST-гейтвей для запуска джобов. Он принимает запросы от оркестратора (Airflow), занимается аутентификацией, отправляет задачи в вычислительные движки (EMR/YARN, Trino, Snowflake) и отслеживает статус. Это устраняет необходимость прямого доступа к кластерам. Теперь Airflow не держит SSH-сессии, а работает через API. Даже если оркестратор перезапускается, джоб продолжает выполняться, а состояние можно получить через тот же API. Такой паттерн давно обсуждается в индустрии как способ уменьшить связанность и повысить устойчивость распределённых систем.
Имплементация оказалась нетривиальной. Миграция затронула сотни джобов и несколько регионов с разной сетевой топологией. Один из неожиданных эффектов — проявление скрытых проблем. Например, после перехода на YARN начали падать задачи из-за ограничений виртуальной памяти (vmem). Ранее SSH обходил эти ограничения, выполняя команды напрямую на master-ноде. После миграции ресурсы стали реально контролироваться. Пришлось отключить vmem checks, следуя рекомендациям AWS, так как они могут давать ложные срабатывания. Второй класс проблем — сетевые зависимости. Некоторые джобы зависели от конкретной маршрутизации (например, доступ к key management сервисам), что не было явно описано. При переносе в другие кластеры это ломалось. Это показало важный момент: SSH маскирует инфраструктурные зависимости, а более строгая модель исполнения их вскрывает.
Результаты проявились на нескольких уровнях. Безопасность стала проще: исчез SSH-доступ к production-кластерам, аутентификация перешла на service-to-service токены, появился аудит через API-логи. Управление ресурсами стало предсказуемым: все задачи выполняются в контейнерах YARN, без конкуренции за master-ноду. Надёжность выросла за счёт server-side lifecycle — джобы переживают сбои клиентов и корректно завершаются. Observability также изменилась: вместо ручного подключения к нодам доступны структурированные логи, статусы и метрики через API.
При этом важно отметить: конкретные численные метрики улучшений не приведены. Но по описанию видно, что изменения затронули ключевые свойства системы — отказоустойчивость (reliability), наблюдаемость (observability) и управляемость ресурсов (resource management). Это эволюционное улучшение архитектуры, а не просто смена интерфейса.
Главный вывод — переход от SSH к REST-based job submission меняет не только способ запуска задач, но и саму модель системы. SSH удобен на старте, но плохо масштабируется и скрывает проблемы. REST-подход, особенно в связке с менеджерами ресурсов вроде YARN, делает систему более явной. А значит — более управляемой.