Б Бёрнс - Распределенные системы. Паттерны проектирования

Подобного рода обработку можно реализовать на основе суще-ствующего Docker-образа ffmpeg . Популярностью пользует-ся образ jrottenberg/ffmpeg ( https://hub.docker.com/r/jrottenberg/ ffmpeg/ ).

Определив простой контейнер-источник и еще более простой контейнер-исполнитель, нетрудно заметить, какие преиму-щества имеет обобщенная, контейнерно-ориентированная система управления очередью. Она существенно сокращает время между проектированием и реализацией очереди задач. Динамическое масштабирование исполнителей

Рассмотренная ранее очередь задач хорошо подходит для об-работки заданий по мере их поступления, но может привести к скачкообразной нагрузке на ресурсы кластера оркестратора контейнеров. Это хорошо, когда у вас много разных видов зада-

ний, создающих нагрузочные пики в разное время и тем самым равномерно распределяющих нагрузку на кластер во времени. Но если у вас недостаточно видов нагрузки, подход «то густо, то пусто» к масштабированию очереди задач может потребо-вать резервирования дополнительных ресурсов для поддержки всплесков нагрузки. В остальное время ресурсы будут простаи-вать, без надобности опустошая ваш кошелек. Глава 10. Системы на основе очередей задач 185

Для решения данной проблемы можно ограничить общее ко-личество объектов Job , порождаемых очередью задач. Это есте-ственным образом ограничит количество параллельно обра-батываемых заданий и, следовательно, снизит использование ресурсов при пиковой нагрузке. С другой стороны, увеличится длительность исполнения каждой отдельной задачи при высо-кой нагрузке на кластер.

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

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

Рассмотрим очередь задач, в которой новое задание появ-ляется в среднем раз в минуту, а его выполнение занимает в среднем 30 секунд. Такая очередь в состоянии справиться с потоком приходящих в нее заданий. Даже если одномоментно придет большой пакет заданий, образовав затор, то со време-

нем затор будет ликвидирован, поскольку до поступления очередного задания очередь успевает обработать в среднем два задания.

Если же новое задание приходит каждую минуту и на обработку одного задания уходит в среднем 1 минута, то такая система 186Часть III. Паттерны проектирования систем пакетных вычислений идеально сбалансирована, но при этом плохо реагирует на из-менения в нагрузке. Она в состоянии справиться с всплесками нагрузки, но на это ей потребуется довольно много времени. У системы не будет простоя, но не будет и резерва машинного времени, чтобы скомпенсировать долгосрочное повышение ско-рости поступления новых задач. Для поддержания стабильности системы необходимо иметь резерв на случай долгосрочного роста нагрузки или непредвиденных задержек при обработке заданий.

Наконец, рассмотрим систему, в которой поступает одно за-дание в минуту, а обработка задания занимает две минуты. Такая система будет постоянно терять производительность. Длина очереди задач будет расти вместе с задержкой между поступлением и обработкой задач (и степенью раздраженности пользователей).

За значениями этих двух показателей необходимо постоянно следить. Усреднив время между поступлением заданий за длительный период времени, например на основе количества заданий за сутки, получим оценку межзадачного интервала . Необходимо также следить за средней продолжительностью обработки задания (без учета времени, проведенного им в оче-реди). В стабильной очереди задач среднее время обработки задачи должно быть меньше межзадачного интервала. Чтобы обеспечить выполнение такого условия, необходимо динами-чески подстраивать количество доступных очереди вычисли-тельных ресурсов. Если задания обрабатываются параллельно, то время обработки следует разделить на количество парал-лельно обрабатываемых заданий. К примеру, если одно зада-ние обрабатывается минуту, но параллельно обрабатываются четыре задачи, то эффективное время обработки одной задачи составляет 15 секунд, а значит, межзадачный интервал должен составлять не менее 16 секунд.