FCM のスロットリングと割り当て

Google の目標は、すべてのメッセージを常に FCM 経由で配信することです。ただし、すべてのメッセージを配信すると、結果として全体的なユーザーエクスペリエンスが低下する場合があります。また、FCM がすべての送信者にスケーラブルなサービスを提供できるようにするには、境界を設定する必要がある場合もあります。このセクションで説明する上限と割り当ての種類は、これらの重要な要素のバランスを取ることに役立ちます。

ダウンストリームメッセージのスロットリング

HTTP v1 API では、ダウンストリームメッセージングに対する各プロジェクトの 1 分あたりの割り当てが導入されました。デフォルトの割り当て（1 分あたり 60 万件のメッセージ）は、システムの安定性を確保して急増するプロジェクトの影響を最小限に抑えながら、FCM デベロッパーの 99% 以上をカバーします。

トラフィックパターンが急増することにより、割り当て超過エラーが発生する可能性があります。割り当て超過のシナリオでは、次の 1 分間に割り当てが再び利用可能になるまで、HTTP ステータスコード 429（QUOTA_EXCEEDED）が返されます。429 レスポンスは、過負荷の状況でも返される可能性があるため、公開されている推奨事項に沿って 429 を処理することを強くおすすめします。

次のことに注意してください。

ダウンストリームの割り当てでは、リクエスト数ではなくメッセージ数を測定します。
クライアントエラー（HTTP ステータスコード 400～499）がカウントされます（429 は除く）。
割り当ては分単位ですが、この分単位は時計と連動したものではありません。

割り当てのモニタリング

割り当て、使用量、エラーは Google Cloud コンソールで確認できます。

Google Cloudコンソールに移動
[API とサービス] を選択します。
テーブルのリストから [Firebase Cloud Messaging API] を選択します。
[QUOTA & SYSTEM LIMITS] を選択します。

注: これらのグラフは、割り当ての分数と正確に時間的に調整されているわけではありません。つまり、トラフィックが割り当てを下回っているように見える場合でも、429 が配信されることがあります。

割り当ての増加をリクエストする

割り当ての増加をリクエストする前に、次の点を確認してください。

1 日に 5 分間以上連続して、使用量が割り当ての 80% 以上になる。
クライアントエラー率が 5% 未満である（特にトラフィックのピーク時）。
大規模なメッセージ送信のベストプラクティスを遵守している。

これらの条件を満たしている場合は、最大 25% の割り当て増加リクエストを送信できます。FCM はリクエストを満たすためにあらゆる実用的な努力を払いますが、増加を保証するものではありません。

間近に迫ったリリースや一時的なイベントのためにダウンストリームメッセージの割り当てを増やす必要がある場合は、リクエストに対応するのに十分な時間を確保できるように、少なくとも 15 日前までに割り当てをリクエストしてください。大規模なリクエスト（1 分あたり 1,800 万件を超えるメッセージ）の場合は、少なくとも 30 日前までにお知らせください。リリースや特別なイベントリクエストには、引き続きクライアントエラー率とベストプラクティスの要件が適用されます。

FCM 割り当てに関するよくある質問もご覧ください。

トピックメッセージの制限

トピック登録の追加や解除レートは、プロジェクトごとに 3,000 QPS に制限されています。

メッセージ送信レートについては、ファンアウトのスロットル処理をご覧ください。

ファンアウトのスロットル処理

メッセージのファンアウトは、複数のデバイスにメッセージを送信するプロセスです。トピックとグループをターゲットにする場合や、Notifications Composer を使用してオーディエンスまたはユーザーセグメントをターゲットにする場合に使用されます。

メッセージのファンアウトは瞬間的ではないため、同時に複数のファンアウトが進行する場合があります。プロジェクトあたりのメッセージの同時ファンアウト数は 1,000 に制限されています。1,000 に達すると、一部の進行中のファンアウトが完了するまで、追加のファンアウトリクエストが拒否されたり、リクエストしたファンアウトが遅延したりする場合があります。

実際に到達可能なファンアウトレートは、同時にファンアウトをリクエストするプロジェクトの数に影響されます。個々のプロジェクトに対するファンアウト数 10,000 QPS は一般的なレートですが、その数は保証されたものではなく、システム全体の負荷によって異なります。利用可能なファンアウト容量は、ファンアウト要求間ではなくプロジェクト間で分割される点に注意してください。そのため、プロジェクトで 2 つのファンアウトが進行中の場合、各ファンアウトには使用可能なファンアウトレートの半分しか表示されません。ファンアウト速度を最大化するには、進行中のアクティブなファンアウトを一度に 1 つのみにすることをおすすめします。

折りたたみできるメッセージのスロットル処理

折りたたみできるメッセージで説明したように、折りたたみできるメッセージとは、前のメッセージを置き換えるように設計された、コンテンツを含まない通知です。同じメッセージがアプリに頻繁に繰り返し送信されている場合、ユーザーの電池の消耗を抑えるためにメッセージを遅延（スロットル）させます。

たとえば、1 つのデバイスに大量の新しいメール同期リクエストを送信した場合、デバイスが同期する平均頻度を下げられるように次のメール同期リクエストを数分遅延させることがあります。このスロットル処理は、ユーザーの電池への影響を抑えるために厳重に行われています。

ユースケースで高いバースト送信パターンを必要とする場合は、折りたたみできないメッセージを選択するのが適切な場合があります。このようなメッセージでは、電池コストを削減するためにメッセージにコンテンツを含めるようにしてください。

折りたたみできるメッセージでは、メッセージのバーストは 1 デバイスにつき 1 アプリあたり 20 件に制限され、3 分ごとにメッセージ 1 件が差し替えられます。

デバイス 1 台に対する最大メッセージレート

Android の場合、1 台のデバイスに送信できるメッセージは、1 分あたり最大 240 件、1 時間あたり最大 5,000 件です。このしきい値が高いのは、ユーザーがチャットで高速にやりとりしている場合など、短期間のトラフィックのバーストを許容するためです。この制限により、送信ロジックのエラーによって誤ってデバイスの電池が消耗されるのを防ぐことができます。

iOS の場合、レートが APNs の制限を超えるとエラーが返されます。