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

В реалиях Яндекса потребителей вычислительных ресурсов намного больше, чем самих ресурсов, поэтому критически важным компонентом любого большого вычислительного кластера YT является планировщик. При разработке планировщика приходится решать целый спектр задач:
* Планировщик должен быть **отказоустойчивым**. Если по каким-то обстоятельствам планировщик перестаёт быть доступен (maintenance, аппаратный сбой, сетевые неполадки, падение из-за программной ошибки), это должно минимальным образом влиять на прогресс уже бегущих вычислений и на возможность запускать новые.
* Планировщик должен быть **эффективным**. Иными словами, если планировщик работает неэффективно, то может возникнуть ситуация, при которой вычислительный кластер не утилизирован на 100% только потому, что планировщик не успевает распределять задачи между машинами. В идеале планировщик должен быть **горизонтально масштабируемым**, то есть, архитектура системы должна позволять вводить несколько планировщиков, равномерно распределяя нагрузку между ними.
* Планировщик должен быть **честным**. В системе, в которой ресурсов не хватает, чтобы в любой момент времени удовлетворить потребности всех клиентов, приходится задумываться о том, по какому принципу вычислительные мощности надо распределять между потребителями. Стоит помнить, что потребители бывают разных видов - у кого-то могут быть CPU-intensive вычисления, кому-то нужны нетривиальные ресурсы на машине (такие, как, например, GPU), кому-то нужно много RAM, что усложняет модель ресурсов и делает задачу честного планирования весьма творческой и нетривиальной.

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