Независимо от того, развиваете ли вы начинающее приложение или уже используете сервис с высоким трафиком, вы можете извлечь пользу из идей и рекомендаций этого руководства о том, как плавно масштабировать с помощью 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 минуты? Будет ли 5-минутный интервал доставки, например, соответствовать потребностям вашего бизнеса?
- Можно ли сегментировать клиентов по приоритетам, чтобы сгладить резкие скачки спроса?
- Можно ли запланировать отправку уведомлений заранее?
По возможности : избегайте стратегий, которые приводят к немедленному исчерпанию вашей квоты отправки FCM, только чтобы повторить шаблон, как только ваш контейнер токенов пополнится. Такой шаблон доступа создает проблемы балансировки нагрузки для FCM и его зависимых систем. Наращивайте трафик как можно более постепенно. Как минимум, наращивайте от 0 до максимального RPS в течение 60-секундного временного окна. Предпочитайте более длительные окна для более высокого RPS.
Избегайте «часового» трафика
По возможности : избегайте отправки сообщений в течение 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 RPS с FCM Legacy HTTP API на FCM HTTP v1 API:
| Неделя | Шаг | Стратегия постепенного наращивания |
|---|---|---|
| 0 | 1% наращивание | Плавное увеличение скорости от 0 до 5000 RPS до 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 RPS за 6 часов |
| 5 | 75% наращивание | Увеличение скорости с 250 000 до 375 000 RPS за 6 часов |
| 6 | 100% наращивание | Увеличение скорости с 375 000 до 500 000 RPS за 6 часов |
Гипотетический план отката:
- Если задержка 95-го процентиля увеличивается до значения более 500 мс или если коэффициент ошибок превышает 1% в течение более часа на любом этапе, используйте динамическую конфигурацию для немедленного отката к предыдущему этапу.
- Продолжайте откат к предыдущим шагам до тех пор, пока задержка и коэффициент ошибок не вернутся к номинальным уровням.
Когда следует обращаться в FCM
Обратитесь в службу поддержки FCM через Firebase , если применимо любое из следующих условий:
- Квоты по умолчанию больше не соответствуют вашему варианту использования
- Вы меняете шаблоны отправки в течение 3-месячного окна в масштабе 100 000 RPS по всему миру или 30 000 RPS по континенту.