Комментарии 4
Распределённость дорогая. Вы пробовали убрать распределённость и запустить тот же процесс на условном толстом сервере (100+ ядер, 500+Гб памяти)?
(Из не имеющих под собой никаких оснований предположений) предположу, что вы получите примерно 10х экономию ресурсов и несколько кратное ускорение джоб из-за экстремальной локальности данных, полного переиспользования кеша и надёжных интерфейсов (IPC на localhost дешевле и проще, чем сетевое взаимодействие).
Распределённость дорогая.
Не совсем верное утверждение – распределенность сложная, дорогой с т.з. потребителя она становится при упрощении системы, в нашем случае, например, при отказе от data affinity.
Вы пробовали убрать распределённость и запустить тот же процесс на условном толстом сервере (100+ ядер, 500+Гб памяти)?
Из не имеющих под собой никаких оснований предположений) предположу, что вы получите примерно 10х экономию ресурсов и несколько кратное ускорение джоб из-за экстремальной локальности данных, полного переиспользования кеша и надёжных интерфейсов (IPC на localhost дешевле и проще, чем сетевое взаимодействие).
Конечно пробовали. И для сборок, которые затрагивают значительную часть репозитория, мы получили времена, примерно в 5 раз превышающие время выполнения такой же сборки на умеренно загруженном кластере. Но основная проблема в том, что в каждый момент времени мы выполняем больше 2х сотен сборок одновременно, и все эти сборки имеют значительное пересечение по промежуточным артефактам сборочного графа. Интенсивное использование data affinity (запуск сборочных нод на тех хостах, которые имеют большее количество входных данных для ноды) и распределенного кеша (воркеры могут обмениваться сборочными артефактами) позволяет нам превосходить по скорости локальную сборку. В целом, как я говорил в докладе, эффективное управление сборочным кэшом позволяет нам экономить значительные объемы вычислительных ресурсов.
По описанию похоже на Bazel. Так это Bazel или вы что-то свое похожее сделали?
Конечно с таким уровнем детализации, как в докладе, все распределенные системы сборки будут похожи. Нет, мы не используем Bazel, у нас собственная система сборки, отличающаяся, как минимум, двумя аспектами — наши сборочные файлы значительно более лаконичные, и сборочный граф, которым оперирует система сборки, может быть сериализован и использован не только для трассировки зависимостей, но и для многих других целей, таких как определение diff'а (разницы по сборочных артефактам, в том числе и промежуточным) между двумя ревизиями, анализа критического пути, инициации системы CI по изменениями в зависимостях проекта, получение и инъекция статистических данных.
Сборка и тестирование в монорепозитории: кластер распределённой сборки DistBuild. Доклад Яндекса