Независимо от того, развиваете ли вы новое приложение или уже управляете сервисом с высоким трафиком, вы можете воспользоваться советами и рекомендациями этого руководства по плавному масштабированию с помощью FCM. Эти концепции и практики помогут вам избежать негативных последствий при отправке больших объёмов сообщений.
Ключевые термины и понятия
Запрос сообщения : запрос сообщения FCM; взаимозаменяемо используется с терминами «запрос», «сообщение» или «запрос».
Запросов в секунду (RPS) : метрика, описывающая скорость входящих запросов к FCM; используется взаимозаменяемо с запросами в секунду (QPS).
Токены квоты, сегменты квоты и пополнения : при отправке сообщений через API FCM HTTP v1 каждый запрос расходует выделенный токен квоты в заданном временном окне. Это окно, называемое « сегментом квоты », полностью заполняется в конце этого временного окна. Например, API HTTP v1 выделяет 600 тыс. токенов квоты на каждый сегмент квоты длительностью в 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 так быстро, как позволяет система, вместо применения ограничения на стороне сервера. Обратите внимание на следующее:
- Нужно ли, чтобы все ваши клиенты получали одно и то же уведомление в течение одной минуты? Будет ли, например, пятиминутный интервал доставки соответствовать потребностям вашего бизнеса?
- Можно ли сегментировать клиентов по приоритетам, чтобы сгладить пики активности?
- Можно ли запланировать отправку уведомлений заранее?
По возможности избегайте стратегий, которые приводят к мгновенному исчерпанию квоты отправки FCM, а затем повторяют эту схему, как только заполняется контейнер токенов. Такая схема доступа создаёт проблемы с балансировкой нагрузки для FCM и зависимых от него систем. Увеличивайте трафик как можно более плавно. Как минимум, увеличивайте количество запросов в секунду от 0 до максимального в течение 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% или меньше. Выдерживайте каждый шаг (наблюдайте за поведением системы под нагрузкой) от 1 дня до 1 недели. Это позволит обнаружить потенциальные проблемы до следующего повышения производительности.
- Постепенное увеличение трафика: при каждом «шаге» увеличения трафика равномерно распределяйте его в течение как минимум часа. Это позволит инфраструктуре балансировки нагрузки FCM соответствующим образом масштабировать ваш новый трафик, минимизируя вероятность возникновения точек доступа и заторов.
Ниже представлен гипотетический сценарий глобальной миграции 500 000 запросов в секунду с устаревшего HTTP API FCM на API FCM HTTP v1:
| Неделя | Шаг | Стратегия постепенного наращивания |
|---|---|---|
| 0 | 1% ускорение | Плавное увеличение скорости от 0 до 5000 RPS до FCM HTTP v1 в течение часа. |
| 1 | 5% ускорение | Плавное увеличение скорости с 5000 до 25000 об/с в течение 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, если применимо что-либо из следующего:
- Квоты по умолчанию больше не соответствуют вашему варианту использования
- Вы меняете свои схемы отправки сообщений в течение 3-месячного окна в масштабе 100 000 запросов в секунду по всему миру или 30 000 запросов в секунду по континенту.