Почему мне следует использовать Cloud Composer?
Недавно мы начали использовать Cloud Composer для наших конвейеров обработки данных. Даже для небольшой среды, которая автоматически масштабируется от 1 до 3 (фактически большую часть времени использует только 1 работник), это довольно дорого — около 350 долларов в месяц. В настоящее время у нас не так много работающих групп DAG, и каждый даг работает ежедневно примерно по 5–10 минут. Таким образом, наша среда Cloud Composer большую часть времени просто простаивает. Поскольку вы платите за среду, которая работает 24 часа в сутки, 7 дней в неделю, а не только во время выполнения задач, ценностное предложение для нас в настоящее время не является хорошим, как вы можете видеть.
Из-за этого у меня серьезные разногласия со своим товарищем по команде. Несмотря на неудачную структуру затрат на данный момент, я по-прежнему считаю, что Airflow/Cloud Composer — лучшее решение для построения конвейеров данных и управления ими, и в будущем у нас наверняка будет больше DAG и более часто запускаемые DAG, поэтому ценностное предложение, несомненно, значительно улучшится. Я очень сторонник использования технологии, ориентированной на будущее.
Однако мой товарищ по команде просто не может смириться с тем фактом, что Cloud Composer настроен так, что работает круглосуточно, независимо от того, выполняется задача или нет, и с нас взимается плата за все эти минуты простоя. По его мнению, долларовая стоимость времени выполнения задачи просто смешна. Он считает, что это явный недостаток в реализации/проектировании Airflow: узлы работают, а затраты растут, когда ничего не обрабатывается. Он утверждает, что мы можем сами создать гораздо более дешевую и столь же функциональную систему, скажем, используя Cloud Scheduler, Cloud Run/Cloud Functions и воспользовавшись преимуществами фоновых триггерных функций в хранилище документов Google Cloud (т. е. Firestore), например, onCreate(), onUpdate. () и т. д., чтобы вызвать зависимости между задачами. Таким образом, в такой системе фиксированная стоимость намного ниже, а стоимость виртуального ЦП/памяти возникает только тогда, когда задачи фактически выполняются.
Я считаю, что изобретать велосипед и создавать собственный инструмент для обработки данных, когда есть проверенное и проверенное решение для наших нужд, совершенно не нужно, тем более что общедоступное решение доказало свою масштабируемость и надежность. Но мне действительно трудно убедить его и опровергнуть его аргументы.
Итак, вот несколько вопросов, в которых я очень ценю ваш вклад:
Почему Cloud Composer использует под капотом GKE вместо Cloud Run или какого-либо другого механизма, который может полностью включаться и выключаться между выполнением задач и, следовательно, не увеличивает затраты? Является ли это недостатком архитектуры Airflow/Cloud Composer, но люди по-прежнему готовы платить за это из-за удобства, и другой альтернативы нет? Или это было намеренное дизайнерское решение и инженерная необходимость?
Какие преимущества предоставляет управляемый сервис Airflow, например Cloud Composer, по сравнению с собственным решением, подобным упомянутому выше, которые важны, но не очевидны сразу?
В общем, если вы являетесь пользователем Cloud Composer, как вы к нему относитесь и как вы оправдываете его затраты; оно того стоило?