Системный дизайн: сервис скрейпинг-джоб

Шаг 4 из 36

Функциональные требования

Требования хранятся файлом в репозитории сервиса, как словарь в главе про DDD. Вики со временем расходится с тем, что делает сервис. Файл рядом с кодом правят в том же коммите, и на ревью видно, какое требование изменилось вместе с кодом.

Таблица справа — этот файл. Строки шага лежат под текстом, их нужно перенести в таблицу. Документ один на весь разбор: на шагах про SLO и расчёты в нём появятся числа и новые свойства.

Функциональное требование описывает действие системы. У каждого действия есть тот, кто его вызывает, поэтому в таблице для него отдельная колонка. Если вызывающего нет, это не требование, а преждевременное решение об устройстве.

Строки пронумерованы, чтобы на них можно было ссылаться: «FR-5 требует, чтобы воркер умел прервать работу» короче пересказа.

Очереди, пула и повторов в таблице нет. Это способы реализации, хотя их часто пытаются записать в функции первыми.

Шаг 5 из 36

Что вне рамок

Список того, чего система не делает, стоит записать так же явно, как список функций. Через полгода кто-нибудь спросит, почему нет расписаний, и ответ должен быть в документе.

• Обход капчи и антибот-защиты. Меняет и техническую, и юридическую сторону задачи. Если это нужно, это отдельный продукт со своими рисками.
• Биллинг за выполненные джобы. Отдельный контекст со своим словарём. Если включить его сюда, придётся проектировать два сервиса одновременно.
• Расписания. Сейчас джобу ставят снаружи. Для запуска по времени нужен отдельный планировщик: со своим состоянием, пропущенными запусками и правилом на случай, если предыдущий прогон ещё идёт.
• Разбор ответа в структуру. Мы отдаём то, что вернула цель. Превращение HTML в таблицу — отдельная задача со своим циклом разработки, и сбор не должен от неё зависеть.

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

Шаг 6 из 36

Нефункциональные требования

Второй раздел — свойства. Нефункциональное требование не добавляет системе действий. Оно задаёт гарантию для тех, что уже есть.

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

Колонка «Цель» пока пустая. «Приём отвечает быстро» — свойство, «за 200 мс в 99 случаях из 100» — обещание. Обещания появятся на следующем шаге и встанут в эту колонку: у NFR-2 появится число, формулировка останется прежней.

Шаг 7 из 36

Числа, к которым привязываемся

Свойство без числа нельзя проверить: о том, быстро ли отвечает приём, можно спорить сколько угодно. SLO задаёт долю запросов, порог и окно, за которое их считают.

• Доступность приёма — 99,9% за 30 дней. Это 43 минуты в месяц, когда джобы не принимаются. Сто процентов обошлись бы намного дороже, чем стоит эта задача.
• Приём отвечает за 200 мс в 99 случаях из 100. Считаем верхнюю границу, а не среднее: среднее скрывает медленные ответы, после которых клиент повторяет запрос.
• 95% джоб стартуют в первую минуту. Это обещание про очередь. Оно нарушается, когда поток больше, чем успевает разобрать пул.
• 99% принятых джоб доходят до конечного состояния без участия человека. Конечные состояния — «готово» и «упала окончательно». Джоба, которая навсегда осталась в «выполняется», хуже упавшей.

По этим числам принимают решения. Нарушено первое — расширяем приём. Нарушено третье — увеличиваем пул или делим очередь.

Шаг 8 из 36

Расчёт: сколько джоб в секунду

Пользователи и их привычки задают поток джоб. Поток и длительность джобы задают одновременность, а от неё зависит размер пула. Калькулятор справа: подставь свои значения.

50 000 пользователей по 8 джоб в сутки дают 400 000 джоб в сутки, в среднем меньше пяти в секунду. Нагрузка неравномерная: утром и вечером людей больше, и при шестикратном пике получается 28 джоб в секунду.

Число одновременно выполняемых джоб считается по закону Литтла: поток, умноженный на время одной джобы. 28 джоб в секунду по 20 секунд — 556 джоб одновременно. Размер пула определяется этим числом, а не количеством пользователей.

Записями поток не исчерпывается. Пока джоба выполняется, о ней спрашивают, и спрашивают с той минуты, как она принята. Пять секунд в очереди плюс двадцать на выполнение при опросе раз в пять секунд — это пять запросов статуса и ещё один за результатом. Шесть чтений на одну запись, то есть 167 чтений в секунду на пике против 28 записей. Пул считается по записям, а база живёт под чтениями, и второе число в разборах теряют чаще первого. Что с ним делать — на шаге про кэш.

Ожидание здесь ползунок, а не результат: каким оно будет, закон Литтла не говорит. Зато он переводит его в джобы — 139 штук в очереди на пике — и позволяет проверить NFR-8. Пока среднее ожидание пять секунд, обещание «95% джоб стартуют в первую минуту» выполнимо; подвинь ползунок к минуте, и оно нарушено, а заодно вырастет поток чтения.

Последняя строка в таблице отвечает на вопрос, зачем очередь нужна вообще. Она считает другой случай: пул рассчитан по среднему потоку, и тогда за пять минут пика скапливается почти семь тысяч джоб. Разница между средним и пиком никуда не девается, она копится. Пул из расчёта по пику её не накапливает, но стоит дороже и простаивает большую часть суток.

Попробуй изменить длительность. При двух секундах хватит пула на полсотни джоб и одной машины. При тридцати одновременно в работе больше восьмисот джоб: нужны кластер, автоскейл и отдельный бюджет. Задача та же, изменилась только скорость целевого API. Поэтому первым вопросом к продукту было, что именно мы скрейпим.

Шаг 9 из 36

Расчёт: сколько воркеров

Одновременность посчитана, но один воркер обрабатывает больше одной джобы. Скрейпер почти всё время ждёт сеть, и один процесс держит десятки открытых запросов. Если считать по джобе на воркер, машин понадобится в двадцать раз больше.

При 20 джобах на воркер 556 одновременных джоб дают 28 воркеров. Сколько джоб реально держит один воркер, нужно измерить. Ограничением может стать память (ответ цели хранится в ней целиком), файловые дескрипторы, исходящие соединения или лимиты клиентской библиотеки.

Из этого следуют два требования к архитектуре.

Пул масштабируется по глубине очереди и возрасту самой старой джобы. Загрузка процессора у скрейпера низкая и в норме, и при аварии, поэтому автоскейл по ней ничего не заметит.

Воркер может упасть в любой момент. Машина с 20 джобами в работе при падении оставляет 20 джоб, которые нужно вернуть в очередь. Как это сделать, разберём на шаге про жизненный цикл.

Шаг 10 из 36

Расчёт: сколько данных

Результат не помещается в строку базы. 200 КБ на джобу при 400 000 джоб в сутки — это 76 ГБ в день и больше 2 ТБ за месяц хранения. Держать такой объём в таблице джоб нельзя.

Из этой оценки следуют три решения.

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

Срок хранения — требование. «Храним месяц» значит, что кто-то удаляет старые данные. Иначе объём растёт линейно, и первым ограничением станет счёт за хранилище.

Размер результата — входной параметр. В калькуляторе на шаге выше измени его с 200 КБ на 20 МБ: объём за месяц вырастет с 2 ТБ до 200 ТБ, и выбор хранилища станет вопросом бюджета.

Шаг 11 из 36

C1: система и всё, что с ней разговаривает

Теперь можно рисовать. Первый кадр — C1: система одним блоком.

Слева пользователи: человек в интерфейсе и чужой скрипт. Справа целевые API. Мы их не контролируем: они бывают медленными и недоступными и ограничивают нас лимитами. Вниз идёт вебхук для тех, кто попросил уведомление.

Кадр показывает границу системы. Целевые API в неё не входят, хотя задача про них: их доступность не входит в наш SLO, лимиты устанавливают они, формат ответа тоже их. Мы можем только работать с ними как с ненадёжной внешней средой.

Отсюда разделение обещаний. «Джоба принята» мы гарантируем сами. «Данные будут» — только если цель ответит.

Шаг 12 из 36

Вход: gateway

Первый элемент внутри границы — точка входа, api-gateway. Сюда приходят все внешние запросы: и «поставь джобу», и «что с ней».

Gateway проверяет, кто пришёл, отсекает лишний трафик и передаёт запрос дальше. Он выделен отдельно, потому что аутентификация и лимиты на клиента нужны и пишущей, и читающей стороне. Если реализовать их дважды, правила со временем разойдутся.

• Новое на схемеapi-gatewayТочка входа: проверяет, кто пришёл, держит общие лимиты и раздаёт запрос внутрь. Про джобы не знает ничего.

Шаг 13 из 36

Запись: командная сторона

За gateway стоит job-command — единственный сервис, который создаёт джобы, — и база jobs-pg, где они хранятся.

Запись и чтение здесь разделены по CQRS: командная сторона создаёт и меняет джобы, читающая только отвечает на вопросы о них. Нагрузка у сторон разная. Джобу создают один раз, а спрашивают о ней десятки раз: человек обновляет список, скрипт опрашивает свою тысячу джоб. Если масштабировать обе стороны как одно целое, мощности придётся подбирать под чтение, и запись получит их с большим запасом. Подробнее о разделении — в главе про CQRS.

Командный сервис проверяет параметры, проверяет ключ идемпотентности и записывает джобу.

Очереди на кадре пока нет: сначала разберём запись, потом — как о ней узнают остальные части системы.

• Новое на схемеjob-commandЕдинственный, кто создаёт джобу. В целевые API не ходит никогда.
• Новое на схемеjobs-pgpostgresХранит джобы: чья, в каком состоянии, сколько было попыток.

Шаг 14 из 36

Как о джобе узнаёт очередь

Простой вариант — записать джобу в базу и сразу отправить сообщение в очередь — ненадёжен. Если запись прошла, а публикация упала, джоба есть, но её никто не выполнит. Если сообщение ушло, а транзакция откатилась, очередь ссылается на несуществующую джобу. Одна транзакция не может охватить и базу, и брокер.

Поэтому командный сервис пишет только в базу, а в шину событие отправляет отдельный публикатор job-publisher. Отдельная таблица для этого не нужна: джоба записывается с пустой колонкой published_at. На схеме появляются два элемента: публикатор и шина. Как это работает по шагам — дальше.

• Новое на схемеjob-publisherНаходит в jobs строки с пустой отметкой публикации, отправляет событие в шину и проставляет время. Может отправить повторно — доставка «хотя бы раз».
• Новое на схемеMQЗадания, которые ещё не взяли, и события о завершённых. Стоит внутри границы: шину мы эксплуатируем сами.

Шаг 15 из 36

Приём и публикация изнутри

Приём — одна транзакция с одной записью: INSERT INTO jobs с пустым published_at. После COMMIT строка либо есть вместе с отметкой «опубликовать», либо её нет. Вторая таблица не нужна: состояние джобы и отметка о публикации лежат в одной строке.

Публикатор работает отдельным циклом: выбирает строки с пустым published_at, отправляет событие в шину и проставляет время. Шина в транзакцию не входит, поэтому между отправкой и отметкой есть окно. Если публикатор упадёт в этом окне, после перезапуска он найдёт ту же строку и отправит событие ещё раз. Доставка «хотя бы раз» означает, что воркер может получить одну джобу дважды, поэтому взятие джобы в работу проходит через статус в базе.

Тем же способом уходит и событие о завершении: воркер ставит статус «готово» вместе с пустым finish_published_at, а событие отправляет публикатор. Сам воркер в шину не пишет.

Справа три сценария: всё прошло, сервис упал до COMMIT, публикатор упал после отправки. Сравни, что остаётся в таблице и в очереди.

Шаг 16 из 36

Пул воркеров

Пул воркеров scrape-worker выполняет работу: читает очередь, берёт джобу и обращается к чужому API.

Пул масштабируется отдельно от приёма, по глубине очереди и возрасту самой старой джобы. По расчётам это 28 процессов по 20 джоб, и число зависит от скорости целевого API.

Граница на кадре отделяет то, что мы контролируем, от того, что нет. Слева наш пул, справа чужие API. Со своей стороны мы можем задать таймаут, повторы и лимит на домен.

• Новое на схемеscrape-workerБерёт джобу из очереди и обращается к чужому API. Больше никто в системе к внешним API не ходит.

Шаг 17 из 36

Взятие джобы и зависшие

Получить сообщение из очереди ещё недостаточно, чтобы взять джобу. Воркер ставит ей статус «в обработке» и время взятия и только потом обращается к цели. Если придёт повторная копия сообщения, воркер увидит, что джоба уже занята, и пропустит её.

У этого подхода есть известная проблема: воркер может упасть, не закончив работу. Тогда джоба останется «в обработке» навсегда, и дашборд её не покажет, потому что формально она выполняется.

Решение использует то же время взятия. В сервисе планировщика job-scheduler есть крон-модуль: раз в минуту он находит джобы, которые слишком долго висят в обработке, ставит им статус queued и очищает published_at. Публикатор отправит их в очередь заново. На схеме C2 виден сам job-scheduler: крон — модуль внутри него, а модули покажем на уровне C3, после итоговой схемы C2.

• Новое на схемеjob-schedulerПланировщик: выбирает следующую джобу, решает, когда попытки кончились, а его крон-модуль раз в минуту возвращает в очередь зависшие джобы.

Шаг 18 из 36

Чтение: статусы и история

job-query закрывает требование из задания: видеть, что происходит с джобами.

Читающая сторона отвечает на три вопроса: в каком состоянии джоба, какие джобы есть у пользователя и что происходило с конкретной джобой. Третий полезнее всего: история попыток с ответами цели показывает, например, «три таймаута, потом 401», и по ней понятно, что чинить.

Gateway отправляет такие запросы сюда, а не в командный сервис. Требования к ним разные: приём должен отвечать за 200 мс и работать при падении целей, а список джоб может отдаваться на сотню миллисекунд медленнее.

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

Шаг 19 из 36

Кэш на читающей стороне

167 чтений в секунду на пике против 28 записей, и все 167 идут в jobs-pg — в ту же базу, в которую пишет приём. Доступность приёма — это NFR-1, а значит, цикл опроса в чужом скрипте способен уронить приём джоб, к которому отношения не имеет.

Между job-query и базой встаёт jobs-cache — промежуточный буфер, в котором лежит ответ на GET /jobs/{id}: состояние, ссылка на результат, отметки времени. Ключ — job:{id}.

Схема обращения — cache-aside. Читающая сторона сама идёт сначала в кэш: при попадании ответ отдаётся без обращения к базе, при промахе job-query читает строку из jobs-pg и сам кладёт её в кэш. Пишущая сторона о кэше не знает вовсе — ни job-command, ни воркер в него не пишут. Сквозная запись, при которой значение попадает в кэш в момент записи в базу, потребовала бы обратного: о кэше пришлось бы знать обоим.

Списка джоб в кэше нет. У GET /jobs?status= ответ свой на каждое сочетание фильтра, сортировки и страницы, а недействительным его делает любая чужая джоба того же пользователя. Ключей много, коэффициент попаданий низкий, вытеснять приходится часто. В кэш идёт то, что запрашивают чаще всего и на что отвечают одинаково: одна джоба по идентификатору.

Дальше — согласованность. Джоба перешла в конечное состояние, а в кэше лежит «выполняется»; клиент читает устаревшее значение и продолжает опрашивать. Нагрузку кэш в этом случае не снял, а задержку добавил. Поэтому у записи два срока жизни.

Пока джоба не в конечном состоянии, TTL — две секунды. Одного опрашивающего такой TTL не спасает: при интервале опроса в пять секунд он промахивается каждый раз. Расчёт на то, что читателей у одной джобы обычно несколько — открытая вкладка, скрипт и обновление страницы дают несколько запросов в одну секунду, и до базы доходит один из них.

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

Переключает между режимами событие. Факт о завершении джобы уже идёт в шине — его ради вебхука публикует job-publisher. Читающая сторона подписывается на ту же очередь и удаляет ключ; следующий запрос один раз сходит в базу и положит в кэш конечное состояние.

Короткий TTL при этом остаётся, и не как дубль инвалидации. У cache-aside есть гонка, которую инвалидация по событию не закрывает: job-query промахнулся и читает строку из базы, в это время джоба завершается, событие приходит и удаляет ключ, которого ещё нет, — а следом job-query кладёт в кэш уже устаревшее «выполняется». Окно узкое, но ограничивает его только TTL.

Вторая известная неприятность — лавина промахов, когда у горячего ключа истекает срок и в базу одновременно уходят все пришедшие за ним запросы. Здесь ей негде развернуться: при TTL в две секунды и десятке читателей на джобу это единицы запросов. На длинном TTL и более горячих ключах пришлось бы пускать к базе одного, а остальных заставлять ждать его ответа.

Каким получится коэффициент попаданий, зависит от того, сколько читателей приходится на одну джобу. Это число измеряют — как и то, сколько джоб держит один воркер.

• Новое на схемеjobs-cacheredisПромежуточный буфер перед jobs-pg: ответ на GET /jobs/{id}. При попадании опрос статуса до базы не доходит.

Шаг 20 из 36

Как забрать результат

Для клиента у джобы два состояния: она ещё выполняется или уже готова. Узнать это — обычный запрос в базу через job-query. В ответе статус и, если джоба готова, ссылка на результат.

Сами данные лежат в results-s3: их объём — терабайты, и в базе состояний им не место. job-query не пропускает их через себя, а возвращает временную подписанную ссылку, и клиент скачивает результат из хранилища напрямую.

Статус «готово» воркер ставит только после того, как файл уже в хранилище, поэтому по ссылке из готовой джобы результат всегда есть. Как устроено хранение и удаление по сроку — на шаге «Где лежат результаты».

• Новое на схемеresults-s3s3Результаты джоб. Их объём — терабайты, поэтому они хранятся отдельно от базы состояний.

Шаг 24 из 36

C3: внутри job-scheduler

Спускаемся на уровень ниже. C3 показывает, из чего состоит один сервис. Берём job-scheduler: на C2 он был одной коробкой, которая пишет в базу, а внутри у него три модуля.

• stuck-sweeper — крон-модуль из шага про аренду. Раз в минуту находит джобы с истёкшей арендой, возвращает их в queued и очищает published_at.
• retry-planner — решает, что делать после неудачной попытки. При временном отказе назначает следующую попытку с backoff, при постоянном отказе или исчерпанных попытках переводит джобу в failed. Подробнее — на шаге про повторы.
• jobs-repository — единственный модуль, который обращается к jobs-pg. Два других работают через него.

Ни один модуль не пишет в шину. Они меняют строку джобы и очищают отметку публикации, а событие отправляет job-publisher. Поэтому у планировщика та же гарантия, что у приёма: изменение состояния и отметка «опубликовать» — одна запись.

• Новое на схемеstuck-sweeperКрон-модуль: раз в минуту возвращает в очередь джобы с истёкшей арендой.
• Новое на схемеretry-plannerНазначает следующую попытку с backoff или переводит джобу в failed, когда попытки кончились.
• Новое на схемеjobs-repositoryЕдинственный модуль, который обращается к jobs-pg.

Шаг 25 из 36

Контракт: расписка вместо результата

POST /jobs отвечает 202 Accepted, а не 200 с данными: данных ещё нет, а открытое соединение оборвёт таймаут балансировщика. В ответе расписка — идентификатор и адрес, где следить.

Ключ идемпотентности: клиент, не дождавшийся ответа, повторит запрос и получит ту же джобу, а не вторую.

Результат отдаёт не API, а хранилище по подписанной ссылке: большие объёмы оно отдаёт дешевле. Вебхук дополняет опрос, но не заменяет: он может не дойти.

• POST/jobs202 Accepted

  Поставить джобу. Ответ сразу, данных в нём нет: только расписка и адрес, где следить.

  запрос

  Idempotency-Keyurlparamspriority

  ответ

  idstatus: queuedlinks.self

• GET/jobs/{id}200 OK

  Состояние джобы, число попыток и последняя ошибка цели.

  ответ

  statusattemptslast_error

• GET/jobs?status=200 OK

  Свои джобы с фильтром по состоянию: скрипту с тысячей джоб хватает одного запроса.

  ответ

  items[]next_cursor

• GET/jobs/{id}/result200 OK

  Не данные, а подписанная ссылка на хранилище со сроком действия.

  ответ

  urlexpires_at

• POST{callback_url}200 OK

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

  запрос

  idstatusfinished_at

Шаг 26 из 36

Жизненный цикл джобы

Состояний у джобы немного, и их видит пользователь.

queued → running → succeeded или failed. Кроме того, cancelled: пока джоба не начала выполняться или пока воркер может её прервать. Из running есть переход обратно в queued: попытка не удалась, и джоба ждёт следующей.

В running джобу переводит воркер, когда берёт её. В succeeded — тоже он, но только после того, как результат сохранён в хранилище, иначе появится «готово» без данных. В failed джоба переходит, когда закончились попытки. Это решает планировщик, а не воркер.

Отдельно нужно обработать джобу, которую взяли и потеряли: воркер упал, а джоба осталась в running. Для этого используется аренда: воркер продлевает срок владения джобой, а если срок истёк, джоба возвращается в очередь. Без аренды джобы упавшей машины не вернутся, и дашборд этого не покажет, потому что формально они выполняются.

Шаг 27 из 36

Таймауты, повторы и что считать провалом

Задание требует, чтобы джобы не падали без причины. Для этого нужно различать два вида отказов. Граница проходит не по коду ответа, а по тому, может ли повторная попытка дать другой результат.

Временные отказы. Таймаут, разрыв соединения, 429, 503. Повторять стоит, но не сразу и не всем пулом одновременно. Нужен экспоненциальный backoff со случайным разбросом. Без разброса тысяча джоб, упавших в одну секунду, повторится тоже в одну секунду и снова перегрузит цель, которая только начала восстанавливаться.

Постоянные отказы. 404, 401, неверные параметры, невалидный ответ. Повтор даст тот же результат и потратит ещё один запрос к цели. Такая джоба сразу переходит в failed.

Число попыток ограничено. Джобы, которые исчерпали попытки, попадают в отстойник, где их разбирает человек. Например, сто джоб к одному домену с ответом 401 обычно означают один просроченный ключ.

Повтор безопасен, только если цель не считает его новым действием. Для чтения это почти всегда так, но это стоит проверить до того, как включать повторы.

Шаг 28 из 36

Вежливость к чужим API

Свой пул мы посчитали, но у цели свои ограничения. 28 воркеров по 20 джоб дают до 560 параллельных запросов. Если все они уйдут на один домен, нас заблокируют раньше, чем закончатся наши мощности.

Поэтому лимит задаётся для каждой цели: столько-то запросов в секунду и столько-то одновременных соединений на домен. Это токен-бакет на хост, общий для всех воркеров, поэтому он хранится не в памяти процесса, а там, где его видят все воркеры.

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

Заголовок Retry-After в ответе цели нужно соблюдать. Если его игнорировать, временное ограничение может превратиться в постоянную блокировку.

Шаг 29 из 36

Шумный сосед

Изоляция арендаторов записана в требованиях одной строкой. Симулятор справа показывает, что она означает на практике.

Три пользователя: магазин и аналитик с небольшим потоком и краулер, который сразу поставил 400 джоб. Пул из восьми воркеров по четыре секунды на джобу обрабатывает две джобы в секунду. Включи общую очередь: за первые секунды краулер выполняет десятки джоб, а у соседей нет ни одной готовой, и их очередь растёт. Система при этом работает правильно: она выполняет джобы в порядке поступления.

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

Справедливый порядок усложняет планировщик: нужна очередь на каждого арендатора, учёт выданных слотов и правило для арендатора, который долго молчал и вдруг пришёл с работой. Следующий шаг — веса: платящим клиентам можно выделять больше, чем бесплатным. Размер весов решает продукт.

Шаг 31 из 36

Что мерить

Метрик у такой системы много, но для решений достаточно четырёх.

• Возраст самой старой джобы в очереди. Важнее длины очереди: тысяча джоб, которые разбираются за минуту, — нормальная работа, а десять джоб, которые ждут час, — авария. По этой же метрике удобно масштабировать пул.
• Время до первой попытки, p95. Прямо соответствует SLO. Остальные метрики помогают понять, почему он нарушен.
• Доля отказов по классам и доменам. Общая доля отказов смешивает просроченный ключ одного клиента с проблемами одной цели. Сто ответов 401 от одного домена — это один инцидент.
• Глубина очереди по арендаторам. Показывает шумного соседа до того, как на него пожалуются.

Отдельно нужно отслеживать джобы, взятые упавшим воркером. Формально они в running, и обычные метрики считают их нормальными. Их находят только по времени в состоянии: если джоба выполняется дольше срока аренды, она должна попадать в отчёт.

Шаг 32 из 36

Новое требование: приоритеты

Через полгода продукт приходит с новой просьбой: часть джоб срочная. Магазину нужна цена конкурента до конца распродажи, а ночная выгрузка аналитика может подождать.

В POST /jobs появляется поле priority: high, normal или low, по умолчанию normal. Оно пишется в строку jobs вместе с остальными полями джобы.

Одна очередь приоритета не даёт: брокер отдаёт сообщения по порядку. Поэтому очередей работы теперь три: jobs.high, jobs.normal и jobs.low. Публикатор читает приоритет из строки и кладёт событие в нужную. Outbox не меняется, меняется только маршрут. Повтор после сбоя возвращается в ту же очередь.

Главное здесь — как воркер выбирает очередь. Если всегда сначала high, то при постоянном потоке срочных джоб low не стартует никогда. Поэтому воркер берёт с весами: из десяти джоб шесть из high, три из normal и одну из low. Пустая очередь отдаёт свою долю остальным.

Справедливость по арендаторам остаётся внутри каждой очереди: приоритет решает, из какой очереди брать, а справедливость — чью джобу из неё.

• Новое на схемеjobs.highСрочные джобы. Воркер берёт отсюда шесть из десяти.
• Новое на схемеjobs.normalПриоритет по умолчанию. Три из десяти.
• Новое на схемеjobs.lowТо, что может подождать. Одна из десяти, но никогда не ноль.

Шаг 33 из 36

Приоритеты в симуляторе

Тот же пул из восьми воркеров и тот же краулер с залпом в 400 джоб. Теперь у каждого арендатора свой приоритет: магазин — high, краулер — normal, аналитик — low.

Запусти на «строго по приоритету». Магазин получает слот сразу, краулер разбирает свой залп, а аналитик не стартует ни разу, пока у краулера есть работа. Никто не ошибся: low просто всегда последний.

Переключи на веса. Краулер и магазин по-прежнему впереди, но аналитик получает свою долю — одну джобу из десяти, — и его очередь движется.

Поменяй приоритеты над схемой: поставь краулеру high. Залп всё равно не займёт весь пул: у high шесть взятий из десяти, остальное достаётся другим очередям.