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