Ключевой составляющей инфраструктуры Яндекса является система YT, позволяющая распределенно и надежно исполнять вычисления над большими объемами данных. YT (https://habr.com/ru/company/yandex/blog/311104/, https://www.youtube.com/watch?v=VQGfH0sZi18) – это собственная разработка компании. Данная система предоставляет пользователям распределенное отказоустойчивое хранилище данных, а также богатые возможности для выполнения Map-Reduce-вычислений над этими данными.

В докладе мы поговорим про планировщик – компоненту, которая отвечает за оперативное выделение ресурсов под задачи пользователей и соблюдение гарантий, данных пользователям. В одном из предыдущих докладов (https://www.highload.ru/moscow/2019/abstracts/6085) мы рассказывали про архитектуру планировщика и используемые подходы к масштабируемости и отказоустойчивости. В этот раз мы поговорим про то, как решать непосредственно задачу планирования.

Одна из важных задач, стоящих перед компанией – экономия вычислительных ресурсов, которая позволяет уменьшить затраты на покупку и эксплуатацию серверов. Поэтому внутри компании развернуто несколько больших YT-кластеров в разных дата-центрах, в которых на одних и тех же серверах сосуществуют batch-вычисления самых разных проектов: от регулярного построения поискового индекса и решения задач маршрутизации до ad-hoc-аналитики и экспериментов с обучением нейронных сетей на GPU-картах.

Описанная ситуация накладывает на планировщик следующие требования:
1. Отказоустойчивость: любой даунтайм планировщика – это простой десятков тысяч серверов в кластере и нарушение гарантий на время выполнения production-задач.
2. Эффективность: каждую секунду на кластере завершаются тысячи задач; чтобы обеспечивать хорошую утилизацию, планировщик должен оперативно планировать на их место новые задачи.
3. Честность: одним кластером пользуется множество различных потребителей; из продуктовых соображений разным потребителям полагаются те или иные гарантии. Планировщик должен уметь соблюдать гарантии, отраженные в его конфигурации, и оперативно выделять проектам полагающиеся им ресурсы.

Свойство честности, хотя и звучит достаточно просто, на практике накладывает сложные (а временами даже противоречивые!) требования. Политики разделения ресурсов могут быть довольно специфичными. Одновременно могут исполняться различные задачи: и длинные машинные обучения, требующие много памяти и страдающие от вытеснений; и production-процессы, состоящие из десятков тысяч коротких подзадач; и аналитические вычисления, которые не должны мешать production-процессам, но при этом хотят гарантированно получать ресурсы на длительном промежутке времени.

В нашем планировщике мы предоставляем пользователям возможность заводить подпроекты и распределять гарантии между ними. Итоговая конфигурация большого кластера представляет собой дерево, состоящее из тысяч подпроектов, а планировщику приходится в каждый момент времени определять, куда именно следует выделить очередные освободившиеся ресурсы согласно текущему состоянию кластера и заданной конфигурации.

В докладе я подробно расскажу о том, как работает наша стратегия планирования и как мы планируем тысячи задач в секунду. Вас ждут как элегантное алгоритмическое решение задачи построения честного распределения ресурсов, так и сложные технические детали, обуславливающие эффективность планировщика.