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

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

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

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

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

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

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

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

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

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

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

Глава 10. Системы на основе очередей задач 187

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

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

Паттерн Multi-Worker

Одна из основных тем данной книги — использование контей-неров с целью инкапсуляции и повторного применения кода. Она актуальна и для паттернов построения очередей задач, опи-сываемых в данной главе. Помимо контейнеров, управляющих самой очередью, повторно использовать можно и группы кон-тейнеров, образующих реализацию исполнителей. Допустим, каждое задание в очереди вам необходимо обработать тремя разными способами. Например, обнаружить на фотографии лица, сопоставить их с конкретными людьми, а затем размыть соответствующие части изображения. Можно поместить всю обработку в один контейнер-исполнитель, но это одноразовое решение, которое невозможно будет использовать повторно. Для замазывания на фото чего-нибудь еще, например машин, придется с нуля создавать контейнер-исполнитель. Возможности такого рода повторного использования можно добиться путем применения паттерна Multi-Worker , который фактически является частным случаем паттерна Adapter, опи-санного в начале книги. Паттерн Multi-Worker преобразует набор контейнеров в один общий контейнер с программным интерфейсом контейнера-исполнителя. Этот общий контей-нер делегирует обработку нескольким отдельным, повторно 188Часть III. Паттерны проектирования систем пакетных вычислений используемым контейнерам. Данный процесс схематически изображен на рис. 10.4.

Рис. 10.4. Агрегирующий паттерн Multi-Worker, реализованный в виде группыконтейнеров

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

11 Событийно-ориентированная пакетная обработка

В предыдущей главе мы рассмотрели общую инфраструктуру для организации очередей задач, а также несколько простых примеров приложений, их использующих. Очереди задач хоро-шо подходят для однократного преобразования одного набора входных данных в один набор выходных данных. Однако существует ряд приложений пакетной обработки, в ко-торых может понадобиться выполнить несколько преобразова-ний либо породить из одного набора входных данных несколько наборов выходных данных в разных форматах. В таких случаях приходится связывать очереди задач так, что выходные данные одной очереди задач становятся входными данными для другой очереди (или даже нескольких очередей) и т. д. За счет этого образуется последовательность шагов обработки, в которой каждая последующая очередь задач реагирует на событие за-вершения обработки в очереди предыдущего шага. 190Часть III. Паттерны проектирования систем пакетных вычислений Такого рода событийно-ориентированные системы часто назы-ваются системами с потоком задач , поскольку они основаны на потоке задач в направленном ациклическом графе взаимосвя-занных этапов обработки данных. Такая система схематически изображена на рис. 11.1.