【ITニュース解説】Rate Limiting Queue Consumers in Node.js: A Simple Library and API Combo

あるサービスで、多数の利用者に情報を一送するシステムを構築する際、一度に大量の処理が集中し、システムが停止したり、他のサービスに悪影響を与えたりする問題を避けるために、「レートリミット」という仕組みを導入するのが一般的だ。この記事は、Node.jsというプログラミング言語を使って、そのようなシステム、特に顧客サポートサービスが出荷情報を多数の購読者にまとめて通知するシナリオにおいて、どのようにレートリミットを効果的に適用するかについて解説している。

レートリミットがない場合、例えば新しい出荷情報が出た途端、システムはそれを通知しようと一斉に動き出す。これを「バースト」と呼ぶが、もしこのバーストによって通知先のシステムが過負荷になってエラーを返すと、システムは自動的に再試行（リトライ）する。しかし、このリトライもまたバースト的に発生し、さらに状況を悪化させてしまう。結果として、システムが遅くなっているのか、完全に停止しているのか、運用担当者には判別が難しくなってしまうのだ。

この問題を解決するために提案されているのは、キューからのメッセージ配信、レートリミット、そしてメッセージの再試行といった機能を、それぞれ独立した役割として扱うシンプルなアプローチである。つまり、情報を通知するコンシューマ（キューからメッセージを取り出して処理するプログラム）は、通知を行う前に必ずレートリミッター（処理の上限を管理する仕組み）に「今、処理してもいいですか？」と許可を求めるように設計する。

具体的なコンシューマの動作は以下の通りだ。まず、処理すべきメッセージをキューから一つ読み込む。次に、レートリミッターに問い合わせて、処理を実行する許可を得る。許可が得られたら、通知先のシステムに対してメッセージを送信する。通知が成功したら、キューに対して「このメッセージの処理は完了しました」と通知（承認）し、メッセージをキューから削除する。もし一時的なエラー（例えば通知先のシステムが一時的に忙しかったなど）が発生した場合は、そのメッセージを少し時間を置いてから再試行するようにキューに戻す。しかし、もし「この宛先は存在しない」といった永続的なエラーが発生した場合は、そのメッセージを「デッドレターパス」と呼ばれる特別な場所に移動させる。これにより、エラーの原因を後で調査できるようになる。

このアプローチの大きなメリットは、システムが共有の処理予算（レートリミット）を使い切った場合、コンシューマが「予算が空くまで待つ」という挙動を明確にすることにある。これによって、システムが過負荷になることを防ぎつつ、現在のボトルネックがどこにあるのか（キューが古くなっているのか、リミッターが待機しているのかなど）を明確に監視できるようになる。システムがうまく機能しているかどうかは、最終的に問題が発生したときにどれだけ早く復旧できるかにかかっている。そのため、レートリミッターは単に機能するだけでなく、その内部状態（どれくらい待機しているか、どれくらいのペースで処理しているか）が明確に可視化されている必要があるのだ。

メッセージの設計も重要だ。例えば、「出荷更新」のメッセージは、ただ「この出荷情報を全員に送る」というものではなく、一つ一つの通知を「この更新を、この購読者に送る」という独立した仕事として扱う。それぞれの仕事には、出荷情報の一意なID、購読者の一意なID、そして「冪等性（べきとうせい）キー」という特別な識別子を含める。冪等性キーを使うことで、もし同じ通知が何らかの理由で二度送信されてしまっても、通知先のシステムはそれが重複した処理であることを認識し、実際には一度しか処理しないようにできる。これにより、顧客に同じ通知が複数回届くといった問題を回避できるのだ。もし一つのメッセージに何千もの受信者情報が含まれていると、その中の一つの宛先に問題があっただけで、全体の通知処理が止まってしまう可能性があるため、メッセージは細かく分割しておくべきである。

リトライのポリシーについても、単に「エラーになったら再試行」ではなく、エラーの種類に応じて対応を変えるべきだ。一時的なネットワークのタイムアウトや、通知先システムからの「一時的に待ってほしい」という応答は再試行の対象だが、明らかに不正なデータや存在しない宛先への通知は、何度試しても成功しないため、すぐにデッドレターパスへ送るべきである。リトライの際には、「指数バックオフとジッター」という技術を使うことが推奨されている。これは、再試行までの時間をエラーが続くたびに少しずつ長くし（指数バックオフ）、さらにランダムな短い時間（ジッター）を加えることで、システム全体が一斉にリトライを開始して再び過負荷になるのを防ぐ効果がある。このとき、何回目の試行であるかという情報はメッセージ自体に含めておくことで、コンシューマが途中で再起動しても正しいリトライポリシーを継続できる。

システムを運用する上で、適切な監視とアラートの設定は不可欠だ。監視すべきは、キューの中にどれくらい長い時間メッセージが残っているか（キューの古さ）、レートリミッターが処理の許可を出すまでにどれくらいの時間待機させているか（リミッターの待機時間）、通知が完了するまでにどれくらいの時間がかかっているか（配信の遅延）、そして通知の結果が成功、一時的失敗、永続的失敗のどれに分類されるか、といった指標である。単に処理したメッセージの数だけを見ていても、システム内部で何が起こっているかは分からないため、これらの詳細な指標がトラブルシューティングには役立つ。アラートは、システムの稼働状況ではなく、回復の必要性に合わせて設定すべきだ。例えば、最も古いキューメッセージの滞留時間が継続的に増加し、かつ成功した配信数が通常のレベルを下回る場合にアラートを出す。また、デッドレターパスに送られるメッセージが増加した場合にも別のアラートを出す。これらは異なる種類の問題を示しており、それぞれ異なる対応が必要となるからだ。

最後に、よくある設計上の疑問点について触れる。一つは、「ローカルなレートリミッターの方がシンプルではないか」という意見だ。確かに、コンシューマが一つしかない場合はローカルなリミッターでも問題ない。しかし、複数のコンシューマプロセスが稼働している場合、それぞれが独立してレートリミットを消費しようとすると、設定された上限を簡単に超えてしまい、通知先のシステムに過負荷をかけてしまう可能性がある。このような場合は、複数のプロセス間で共有される、一元的なレートリミッターを利用するか、処理を分割して各コンシューマの責任範囲を明確にする必要がある。

もう一つは、「冪等性キーを導入すると設計が複雑になるのではないか」という意見だ。しかし、この仕組みがないために、顧客に同じ通知が二度届く可能性を考えると、冪等性の導入はむしろシステムの信頼性を高める上で非常に重要だ。例えば、コンシューマが通知を送信した後、キューへの承認を行う前にクラッシュしてしまうと、キューはメッセージを未処理と判断して再度配信してしまう可能性がある。冪等性キーがあれば、通知先のシステムはこの重複したメッセージを適切に処理できる。もし通知先のシステムが冪等性に対応していない場合、開発者は重複通知を許容するか、あるいはより複雑な手段で配信履歴を管理するかの選択を迫られることになる。

結局のところ、本当にシンプルで運用しやすいシステムとは、問題が発生した際に「何が起きているのか」「どこで詰まっているのか」がすぐに分かり、迅速に復旧できるシステムのことを指す。そのためには、メッセージの待機状態、リトライの状況、そして処理を諦める判断が、すべて明確に可視化されている必要があるのだ。