Очередь между сервисами предлагают как решение сразу нескольких проблем: нагрузка, надёжность, независимость сервисов друг от друга. Всё это правда. Неправда в том, что она бесплатна: очередь — ещё одна система в эксплуатации, и её содержание оплачивается инженерными часами каждую неделю.
Считать это можно до того, как что-то поднято. Ниже модель, куда подставляются ваши значения.
Тупик: сравнить по возможностям
Первое, что пробуют, — сравнить, что умеет очередь и что умеет прямой вызов. Список выходит убедительным: переживает перезапуск получателя, сглаживает всплески, повторяет неудачное, позволяет добавить второго читателя без изменения отправителя.
Это не помогает принять решение, потому что сравниваются не те величины. Возможности очевидны, вопрос в цене: развернуть, настроить, следить за отставанием, разбирать застрявшие сообщения, обновлять, дежурить. Список возможностей об этих часах не говорит.
Второй частый ход — посмотреть на цену управляемого сервиса. Она обычно подъёмная и почти никогда не является главной строкой сметы.
Что считать
Считайте в часах, деньги получите в конце, умножив на цену инженерного часа. Модель симметричная: цена есть у обоих путей.
Цена нынешней жизни без очереди. Часы в обычную неделю на то, что очередь могла бы снять: разбор случаев, когда получатель был недоступен и вызов потерялся; ручные повторы; ситуации, когда всплеск нагрузки уронил соседний сервис; ожидание пользователем длинной операции, которая могла бы уйти в фон.
Цена очереди. Разовая: развернуть, описать формат сообщений, переписать отправителя и получателя, перенести существующий обмен. Регулярная: следить за отставанием, разбирать сообщения, которые не удалось обработать, обновлять систему, отвечать на инциденты, где подозреваемых стало больше.
Цена нового класса ошибок. Он появляется обязательно, и его стоит назвать заранее. Сообщение обработано дважды. Сообщения пришли не в том порядке. Отправитель считает операцию выполненной, а она ещё в очереди. Пользователь не видит результата сразу и не понимает, случилось ли что-то.
Отдельная строка, о которой забывают почти всегда, — цена наблюдаемости. Прямой вызов виден целиком: запрос ушёл, ответ пришёл, в журнале одна запись с началом и концом. После появления очереди путь операции разрывается на две половины, лежащие в разных журналах, и связать их можно только сквозным идентификатором, который придётся протащить через отправителя, очередь и получателя. Это не сложно, но это работа, которую надо сделать сразу: без неё первый же вопрос «почему клиент не получил письмо» превращается в получасовое сличение временных меток.
Ещё одна строка — цена ответа на вопрос «а сообщение вообще дошло?». Прямой вызов отвечает на него кодом возврата. Очередь требует места, куда получатель запишет результат, и способа этот результат показать: страницы состояния, отметки в исходной сущности, уведомления. Иначе поддержка не сможет ответить пользователю ничего, кроме «должно обработаться».
Выгода. Считается не в возможностях, а в поведении системы: сколько раз в неделю недоступность получателя стоила вам работы, сколько раз всплеск нагрузки задел соседей.
Где проходит граница
Соотношение, которое обычно определяет ответ: очередь окупается, когда отправителю не нужен ответ прямо сейчас.
Отправка письма, пересчёт отчёта, выгрузка, уведомление — операции, где вызывающий не ждёт результата. Здесь очередь снимает связанность и оплачивает себя первым же сбоем получателя.
Получение данных для показа на экране, проверка права доступа, списание средств с подтверждением — операции, где ответ нужен немедленно. Очередь тут добавляет задержку и сложность, ничего не давая: вам всё равно придётся дождаться.
Второй признак — разница в скорости между отправителем и получателем. Если отправитель порождает всплески, а получатель обрабатывает ровно, очередь работает буфером, и это её главная честная функция. Если оба ровные, буферить нечего.
Третий — число читателей. Одно событие, нужное трём сервисам, через прямые вызовы превращается в три вызова в коде отправителя и в изменение этого кода при появлении четвёртого. Через очередь отправитель не меняется. Но эта выгода появляется на третьем читателе, а не на первом.
Промежуточный вариант, который пропускают
Между прямым вызовом и отдельной системой очередей есть путь, который часто закрывает задачу: таблица в базе, которая у вас уже есть. Запись о задаче, фоновый обработчик, отметка о выполнении, повтор при неудаче.
Это дешевле отдельной системы, использует то, что уже эксплуатируется, и переживает перезапуск. Не даёт высокой пропускной способности и удобной работы с несколькими читателями — но проверить, достаточно ли этого, стоит первым.
Как посчитать до внедрения
Расчёт не требует ни прототипа, ни нагрузочного стенда — только две недели наблюдений.
Первую неделю ведите список: каждый раз, когда операция сорвалась из-за недоступности соседа, каждый раз, когда всплеск нагрузки задел не относящийся к нему сервис, каждый раз, когда кто-то руками повторял неудавшуюся операцию. Записывайте не только факт, но и потраченные минуты. К концу недели у вас число — регулярная цена жизни без очереди.
Вторую неделю потратьте на честную оценку внедрения. Разовые часы считайте по своей команде и своей инфраструктуре, а не по описаниям в документации: развернуть, настроить доступы, описать формат сообщений, переписать обе стороны, перенести существующий обмен, добавить сквозной идентификатор, сделать страницу состояния. Регулярные часы оценивайте по тому, как у вас на самом деле проходит дежурство: сколько времени в неделю уходит на любую систему сравнимой сложности, которая уже эксплуатируется.
Дальше арифметика простая. Разделите разовые часы на разницу между регулярной ценой без очереди и регулярной ценой с ней. Получится срок окупаемости в неделях. Если разница отрицательная, очередь не окупится никогда, сколько бы возможностей она ни давала. Если срок выходит больше полугода, решение стоит отложить: за полгода меняется и нагрузка, и состав команды, и сама задача.
Чего расчёт не покажет
Он не учитывает опыт команды: если очередь уже эксплуатируется для других задач, регулярная часть расходов у вас меньше, и порог сдвигается.
Он не учитывает, что часть выгод проявится только под нагрузкой, которой пока нет. Закладываться на неё разумно, если рост подтверждён планами, а не надеждой.
И он не заменяет разговор о смысле операций. Регулярно оказывается, что половина того, что собирались отправлять в очередь, вообще не нужна: уведомление, которое никто не читает, пересчёт, результат которого никто не смотрит.
Позиция редакции
Мы считаем, что очередь стоит заводить, когда отправителю не нужен ответ сразу и таких операций больше одной, и не стоит — когда её берут ради надёжности вообще. Практический вывод: сначала посчитайте регулярные часы на сопровождение и назовите новый класс ошибок, потом сравнивайте возможности. Обратный порядок всегда даёт ответ «нужна».
Мы неправы, если у вас уже есть очередь, которую содержит команда: там регулярная часть размазана, порог низкий, и заводить в ней ещё один поток разумно даже для одной операции.