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