В этом руководстве вы найдете советы и рекомендации по масштабированию с помощью FCM, которые будут полезны как для новых, так и для популярных приложений. Эти концепции и методы помогут вам избежать негативных последствий при отправке большого количества писем.
Основные термины и понятия
Запрос сообщения. Запрос сообщения FCM. Используется как синоним слов "запрос", "сообщение" и "запрос".
Запросы в секунду (RPS). Показатель, описывающий скорость входящих запросов к FCM. Используется как синоним показателя "Запросы в секунду (QPS)".
Токены квоты, корзины токенов и пополнение. При отправке сообщений через FCM HTTP v1 API каждый запрос расходует определенное количество токенов квоты за заданный период времени. Это окно, называемое корзиной токенов, заполняется до конца временного окна. Например, в API HTTP версии 1 для каждого минутного сегмента выделяется 600 000 токенов квоты, которые восстанавливаются до полного объема в конце каждой минуты.
Ограничение на стороне сервера. Если объем трафика превышает возможности сервиса FCM, запросы, которые не могут быть обработаны, отклоняются, чтобы ограничить входящий поток. Ответы об ошибках 429 с заголовками retry-after могут возвращаться, чтобы указать, что вам следует подождать определенный период времени, прежде чем повторять запрос.
Ограничение на стороне клиента. Если клиент обнаруживает сбои запросов, высокую задержку или ошибки 429, он должен добровольно ограничить исходящий трафик, чтобы не усугублять перегрузку.
Экспоненциальная выдержка. При повторных попытках устранить ошибки добавляйте экспоненциально увеличивающиеся временные задержки. Например, 1 с, 2 с, 4 с, 8 с, 16 с, 32 с и т. д.
Джиттеринг. Не отправляйте повторные запросы через одинаковые интервалы времени. При использовании дрожания задержки между повторными попытками выбираются случайным образом, чтобы равномерно распределить их во времени (например, 0,9 с, 2,3 с, 4,1 с, 8,5 с, 17,9 с, 34,7 с).
Усиление повторных попыток. Если неудачные запросы повторяются без экспоненциальной выдержки или дрожания, они часто накапливаются и увеличивают текущую нагрузку на трафик, потенциально "усиливая" и усугубляя проблемы с перегрузкой трафика.
Проблема: скачки трафика
FCM обрабатывает миллионы запросов в секунду. Основная причина системных перегрузок, задержек и сбоев – скачки трафика.
Что такое скачкообразный трафик?
Существует несколько типов скачков трафика.
Пики в начале часа. В первые 30 секунд или 2 минуты каждого часа FCM получает более чем в два раза больше трафика. Похожие, хотя и менее выраженные, пики наблюдаются в начале каждой четверти часа (например, в 00:15, 00:30, 00:45).
Повторные попытки. Повторные попытки выполнить неудачные запросы или запросы с истекшим временем ожидания без экспоненциального отката могут привести к повторяющимся волнам трафика поверх существующих пиков трафика.
Резкие изменения в структуре трафика. Если вы перенаправляете новый трафик в FCM или переводите трафик в FCM в разных регионах без сглаживающих факторов, таких как постепенное увеличение, это может привести к скачкам.
Использование всех токенов квоты в начале периода действия квоты вместо равномерного распределения запросов по периодам действия квоты приведет к колебаниям, которые сложно и дорого сбалансировать.
Специальные события. Резкие колебания трафика во время праздников (Нового года) или спортивных мероприятий (чемпионата мира по футболу).
Сглаживание пиков трафика
В этом разделе описаны стратегии, которые помогут сгладить пики трафика, если это возможно.
Используйте FCM только в подходящих случаях
В некоторых случаях использовать FCM для доставки уведомлений не нужно или нецелесообразно.
Например, для уведомлений о событиях календаря можно запланировать локальную задачу в приложении, чтобы показывать уведомления в нужное время, а не отправлять их с сервера приложения. Ограничьте сообщения FCM синхронизацией календаря.
Избегайте резких скачков
Одна из распространенных ошибок при масштабировании – отправка уведомлений FCM так быстро, как это позволяют системы, вместо того чтобы применять ограничение на стороне сервера. Учитывайте следующее:
- Нужно ли отправлять всем клиентам одинаковые уведомления в течение одной минуты? Например, будет ли пятиминутный интервал доставки соответствовать потребностям вашего бизнеса?
- Можно ли сегментировать клиентов по приоритету, чтобы сгладить пики?
- Можно ли запланировать уведомления заранее?
По возможности избегайте стратегий, которые приводят к немедленному исчерпанию квоты на отправку FCM, а затем повторяются, как только токен-ведро пополняется. Такой шаблон доступа создает проблемы с балансировкой нагрузки для FCM и зависимых систем. Увеличивайте трафик постепенно. Как минимум, увеличьте количество запросов в секунду с 0 до максимального значения в течение 60 секунд. Для более высокой скорости запросов в секунду лучше использовать более длинные окна.
Избегайте пробок в начале часа
По возможности не отправляйте сообщения в течение двух минут после начала каждой четверти часа.
Как реализовать ограничение частоты на стороне сервера
Реализуйте ограничение на стороне сервера, чтобы отслеживать и контролировать поток трафика в FCM.
Обработка повторных попыток
FCM стремится обеспечить высокую доступность, но иногда некоторые запросы могут быть отклонены или не выполнены из-за превышения времени ожидания. Причины могут быть разными, но приведенные ниже рекомендации помогут оптимизировать повторные попытки отправки, чтобы доставлять письма как можно быстрее и при этом не перегружать трафик.
Тайм-ауты
Установите для запросов на отправку время ожидания не менее 10 секунд, прежде чем повторять попытку. Большинство внутренних вызовов удаленных процедур FCM используют 10-секундный тайм-аут.
Ошибки
- При ошибках 400, 401, 403 и 404 следует прервать выполнение и не повторять попытку.
- При ошибке 429 повторите попытку после того, как пройдет время, указанное в заголовке retry-after. Если заголовок retry-after не задан, по умолчанию используется значение 60 секунд.
- При ошибках с кодом 500 повторите попытку с экспоненциальной выдержкой.
Экспоненциальная выдержка
Чтобы избежать усиления повторных попыток, реализуйте экспоненциальную выдержку с дрожанием для повторных запросов. Например, в Firebase Admin SDK реализован алгоритм экспоненциального отката.
Вот ещё несколько рекомендуемых настроек:
- Минимальный интервал. Не пытайтесь сразу же повторить неудачный запрос с помощью FCM. Подождите не менее 10 секунд, прежде чем повторно отправить запрос.
- Максимальный интервал. Установите максимальный интервал для отмены запросов, которые больше не актуальны, вместо того чтобы повторять их бесконечно.
Если запрос постоянно повторяется с экспоненциальной задержкой и по-прежнему не выполняется через 60 минут, это означает, что либо ошибка неправильно классифицирована как повторяемая, либо в FCM произошел сбой, из-за которого повторные попытки могут усугубить ситуацию.
Создавайте планы развертывания и отката и вносите изменения постепенно
При внесении масштабных изменений в трафик, например при увеличении трафика в FCM или перераспределении трафика между регионами или сетями, разработка плана развертывания или отката и постепенное внедрение изменений помогут защитить ваших пользователей, ваш сервис и FCM.
- План развертывания помогает согласовать ожидания заинтересованных сторон. В некоторых случаях (описанных ниже) вам может понадобиться заранее поделиться планом развертывания с командой FCM, чтобы избежать неожиданностей.
- План отката позволяет учесть непредвиденные обстоятельства и подготовить механизмы для быстрого и безопасного восстановления после неожиданных сбоев.
- Постепенное внесение изменений включает два аспекта:
- Пошаговое увеличение: 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% или более мелкие шаги. Протестируйте каждый шаг в течение 1–7 дней, чтобы проверить поведение системы под нагрузкой. Это позволяет выявлять потенциальные проблемы до следующего повышения.
- Постепенное увеличение трафика. При каждом шаге по увеличению трафика распределяйте его равномерно в течение как минимум часа. Это позволяет инфраструктуре балансировки нагрузки FCM правильно масштабировать новый трафик, сводя к минимуму вероятность перегрузки.
Ниже приведен гипотетический сценарий перехода с устаревшего FCM HTTP API на FCM HTTP v1 API для 500 000 запросов в секунду по всему миру.
| Неделя | Шаг | Стратегия постепенного увеличения доли показов |
|---|---|---|
| 0 | 1 % | Плавно увеличьте нагрузку с 0 до 5000 запросов в секунду к FCM HTTP v1 в течение часа. |
| 1 | Увеличение на 5 % | Плавно увеличьте нагрузку с 5000 до 25 000 запросов в секунду в течение двух часов. |
| 2 | Увеличение доли показов на 10 % | Плавно увеличьте нагрузку с 25 000 до 50 000 запросов в секунду в течение двух часов. |
| 3 | Увеличение доли показов на 25 % | Постепенное увеличение с 50 000 до 125 000 запросов в секунду в течение трех часов |
| 4 | Увеличение доли показов на 50 % | Постепенное увеличение с 125 000 до 250 000 запросов в секунду в течение 6 часов |
| 5 | 75 % | Постепенное увеличение с 250 000 до 375 000 запросов в секунду в течение шести часов |
| 6 | 100 % | Постепенное увеличение с 375 000 до 500 000 запросов в секунду в течение 6 часов |
Пример плана отката
- Если задержка на уровне 95 % превышает 500 мс или доля ошибок превышает 1 % более часа на любом этапе, используйте динамическую конфигурацию, чтобы немедленно вернуться к предыдущему этапу.
- Выполняйте откат к более ранним этапам, пока задержка и частота ошибок не вернутся к нормальным значениям.
Когда обращаться в службу поддержки FCM
Обратитесь в FCM через службу поддержки Firebase, если:
- Квоты по умолчанию больше не соответствуют вашим потребностям
- Вы меняете шаблоны отправки в течение трех месяцев в масштабе 100 000 запросов в секунду по всему миру или 30 000 запросов в секунду на континенте.