Независимо от того, развиваете ли вы новое приложение или уже управляете сервисом с высоким трафиком, вы можете воспользоваться идеями и рекомендациями этого руководства по плавному масштабированию с помощью FCM. Эти концепции и методы помогут вам избежать негативных последствий при отправке больших объемов сообщений.
Основные термины и понятия
Запрос сообщения. Запрос сообщения FCM. Также используются термины "запрос", "сообщение" и "запрос".
Количество запросов в секунду. Показатель, описывающий частоту входящих запросов к FCM. Используется взаимозаменяемо с количеством запросов в секунду.
Токены квоты, сегменты-маркеры и пополнение. При отправке сообщений через FCM HTTP v1 API каждый запрос расходует выделенный токен квоты в заданном временном окне. Это окно, называемое сегментом-маркером, заполняется в конце временного окна. Например, HTTP v1 API выделяет 600 тысяч токенов квоты на каждый одноминутный сегмент-маркер, который полностью пополняется в конце каждого одноминутного окна.
Ограничение на стороне сервера. Если объем трафика превышает емкость сервиса 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 между регионами без сглаживающих факторов, таких как постепенное наращивание, может вызвать всплески.
Использование токенов квоты в начале периода. Если вы израсходуете все токены квоты в начале периода, а не распределите запросы равномерно по всему периоду, это приведет к колебаниям, которые затруднят и удорожат балансировку нагрузки.
Особые события. Всплески трафика во время праздников (Новый год) или спортивных мероприятий (чемпионат мира по футболу).
Как сгладить пики трафика
В этом разделе описаны стратегии, позволяющие сгладить пики трафика, когда это возможно.
Используйте FCM только в подходящих случаях
В некоторых случаях использовать FCM для доставки уведомлений не нужно или нецелесообразно.
Например, для уведомлений о мероприятиях в календаре можно запланировать локальную задачу в приложении, чтобы показывать уведомление в нужное время, а не отправлять его с сервера приложения. Ограничьте сообщения FCM синхронизацией календаря.
Избегайте шипов
Один из антипаттернов масштабирования – отправка уведомлений FCM с максимально возможной скоростью вместо применения регулирования на стороне сервера. Вот что можно сделать.
- Должны ли все ваши клиенты получать одно и то же уведомление в течение одной минуты? Например, устроит ли вас пятиминутное окно доставки?
- Можно ли сегментировать клиентов по приоритету, чтобы сгладить пики?
- Можно ли запланировать отправку уведомлений заранее?
По возможности избегайте стратегий, которые приводят к немедленному исчерпанию квоты на отправку FCM, только для того, чтобы повторить шаблон, как только ваш сегмент-маркер заполнится. Такой шаблон доступа создает проблемы с балансировкой нагрузки для FCM и зависимых от него систем. Увеличивайте трафик как можно медленнее. Минимальный период увеличения нагрузки от 0 до максимального количества запросов в секунду – 60 секунд. Чем длиннее период, тем выше доход на показ.
Избегайте трафика в начале часа
По возможности не отправляйте сообщения в течение двух минут после начала каждого часа, а также 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 запросов в секунду по всему миру с FCM Legacy HTTP API на FCM HTTP v1 API.
| Неделя | Шаг | Стратегия постепенного увеличения доли показов |
|---|---|---|
| 0 | 1 % | Плавно увеличивайте количество запросов в секунду с 0 до 5000 к FCM HTTP v1 в течение часа. |
| 1 | 5 % | Плавно увеличивайте нагрузку с 5000 до 25 000 запросов в секунду в течение двух часов. |
| 2 | Увеличение доли показов товаров со скидками на 10 % | Постепенно увеличивайте количество запросов в секунду с 25 000 до 50 000 в течение двух часов. |
| 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
Обратитесь в службу поддержки Firebase, если:
- Квоты по умолчанию больше не соответствуют вашим потребностям.
- Вы меняете схему отправки в течение трех месяцев в масштабе 100 000 запросов в секунду по всему миру или 30 000 запросов в секунду на одном континенте.