Рекомендации по отправке сообщений FCM в больших масштабах

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

Ключевые термины и понятия

Запрос сообщения : Запрос сообщения FCM; используется взаимозаменяемо с терминами «запрос», «сообщение» или «запрос».

Запросы в секунду (RPS) : Показатель, описывающий скорость входящих запросов к FCM; используется взаимозаменяемо с запросами в секунду (QPS).

Квотные токены, корзины токенов и пополнение : При отправке сообщений через API FCM HTTP v1 каждый запрос потребляет выделенный квотный токен в заданном временном окне. Это окно, называемое « корзиной токенов », пополняется до полного уровня по истечении этого временного окна. Например: API HTTP v1 выделяет 600 000 квотных токенов для каждой 1-минутной корзины токенов, которая пополняется до полного уровня по истечении каждой 1-минутной временной интервалы.

Ограничение скорости на стороне сервера : Когда объем трафика превышает пропускную способность службы FCM, запросы, превышающие возможности обслуживания, отклоняются для ограничения скорости входящего потока. Могут быть возвращены ответы с ошибкой 429 и заголовком retry-after указывающие на необходимость подождать определенный период времени перед повторной попыткой запроса.

Ограничение скорости на стороне клиента : Когда клиенты наблюдают сбои запросов, высокую задержку или ошибки 429 , они должны добровольно ограничивать скорость исходящего потока, чтобы избежать усугубления перегрузки.

Экспоненциальная задержка : при повторных попытках обработки ошибок добавляйте экспоненциально возрастающие временные задержки. Например: 1 с, 2 с, 4 с, 8 с, 16 с, 32 с и так далее.

Джиттеринг : Избегание повторных попыток отправки запросов через точно заданные интервалы. При джиттеринге задержки повторных попыток изменяются случайным образом, чтобы равномерно распределить их во времени (например: 0,9 с, 2,3 с, 4,1 с, 8,5 с, 17,9 с, 34,7 с).

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

Проблема: резкие скачки трафика.

FCM обрабатывает миллионы запросов в секунду (RPS). Наибольший вклад в системные перегрузки, проблемы с задержкой и сбои в работе вносят пики трафика.

Что такое «скачки в дорожном движении»?

Существует несколько различных типов всплесков трафика.

Всплески трафика в начале каждого часа: в первые 30 секунд – 2 минуты каждого часа трафик на FCM увеличивается более чем вдвое. Аналогичные, хотя и менее выраженные, всплески наблюдаются также в полчаса и четверть часа (например: 00:15, 00:30, 00:45).

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

Резкие изменения структуры трафика: перенаправление нового трафика на FCM или перемещение трафика на FCM между регионами без сглаживающих факторов, таких как постепенное наращивание нагрузки, может вызвать всплески.

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

Особые события: всплески трафика во время праздников (Новый год) или спортивных мероприятий ( Чемпионат мира по футболу FIFA ).

Решение проблемы резкого увеличения трафика путем «сглаживания кривой».

В этом разделе описываются стратегии, позволяющие сгладить пики трафика, где это возможно, — стратегии «сглаживания кривой».

Используйте FCM только в соответствующих случаях.

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

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

Избегайте резких скачков

Одна из антипаттернов масштабирования — это отправка уведомлений FCM с максимально возможной скоростью, вместо применения регулирования на стороне сервера. Рассмотрим следующий пример:

• Нужно ли всем вашим клиентам получать одно и то же уведомление в течение одной минуты? Будет ли, например, пятиминутный интервал доставки соответствовать потребностям вашего бизнеса?
• Можно ли сегментировать клиентов по приоритетам, чтобы сгладить пики?
• Можно ли настроить отправку уведомлений заранее?

По возможности избегайте стратегий, которые приводят к немедленному исчерпанию квоты отправки FCM, и повторению этой схемы, как только пополнится ваш токен-бак. Такая схема доступа создает проблемы балансировки нагрузки для FCM и зависимых от него систем. Наращивайте трафик как можно более постепенно. Как минимум, увеличивайте трафик от 0 до максимального количества запросов в секунду (RPS) в течение 60 секунд. Предпочтительнее использовать более длинные временные окна для увеличения количества запросов в секунду.

Избегайте пробок, возникающих каждый час.

По возможности : избегайте отправки сообщений в течение 2-минутного промежутка времени после отметок :00, :15, :30 и :45 минут.

Внедрить регулирование скорости на стороне сервера.

Внедрить регулирование трафика на стороне сервера для мониторинга и управления потоком трафика к 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% или более мелкими. На каждом этапе следует « выдерживать » нагрузку (наблюдать за поведением системы под нагрузкой) от одного дня до одной недели. Это позволит выявить потенциальные проблемы до следующего «повышения нагрузки».
  • Постепенное наращивание трафика: на каждом этапе наращивания трафика необходимо равномерно распределять его в течение как минимум часа. Это позволит инфраструктуре балансировки нагрузки FCM соответствующим образом масштабировать новый трафик, минимизируя при этом вероятность возникновения зон перегрузки и заторов.

Вот гипотетический сценарий миграции 500 000 запросов в секунду по всему миру с устаревшего HTTP API FCM на HTTP API FCM версии 1:

Гипотетический план отмены:

• Если задержка в 95-м процентиле превышает 500 мс или если коэффициент ошибок превышает 1% в течение более часа на любом этапе, используйте динамическую конфигурацию для немедленного отката к предыдущему шагу.
• Продолжайте откат к предыдущим шагам до тех пор, пока задержка и коэффициент ошибок не вернутся к номинальным уровням.

Когда следует обращаться в FCM

Обратитесь в службу поддержки Firebase через FCM, если выполняется хотя бы одно из следующих условий:

• Квоты по умолчанию больше не соответствуют вашим потребностям.
• Вы меняете свои схемы отправки в течение 3 месяцев в масштабе 100 000 RPS в глобальном масштабе или 30 000 RPS на континенте.