【ITニュース解説】Property Renewal Notifications — Choosing a Queue Service to Implement Rate-Limiting in Message Processing

システムエンジニアを目指す皆さん、普段使っているウェブサービスやアプリで、何か重要な通知を受け取ることがあるだろう。例えば、サービスの利用期限が近づいたときの「更新リマインダー」のようなものだ。こうした通知は、ただ「送ればよい」というものではなく、ビジネス上の様々な要件を満たしながら、確実に、そして適切なタイミングでユーザーに届ける必要がある。

今回の記事では、不動産の賃貸更新通知を例に、メッセージ処理において信頼性の高いシステムをどのように設計し、特に「レートリミット」（一定時間あたりの処理回数制限）という制約がある中で、どの「キューサービス」を選び、どう活用すべきかについて深く掘り下げている。

まず、キューサービスとは何かを理解しよう。キュー（Queue）は「行列」という意味で、コンピュータシステムにおいては、処理すべきタスクやメッセージを一時的に貯めておく場所と考えると良い。例えば、大量の通知を一度に送ろうとすると、システムの負荷が高まりすぎたり、外部のメール送信サービスが「一度にそんなに送らないで！」と拒否したりすることがある。キューを使うことで、メッセージをいったん貯めておき、システムが処理できるペースで一つずつ取り出して処理したり、外部サービスの制限に合わせてゆっくり送ったりすることが可能になる。これにより、システムの安定性を保ち、メッセージの取りこぼしを防ぎ、さらには処理が失敗した場合の再試行も容易になるのだ。

さて、賃貸更新通知のような重要なメッセージを扱う場合、いくつかの「絶対に守らなければならないこと」がある。記事ではこれを「不変条件」と呼んでいる。 一つ目は、「どの通知が何に対するものか」を正確に識別できることだ。例えば、「どの物件の、どの種類の通知を、いつの期限について送るのか」といった情報が、システム全体で一意に識別できる安定したキー（鍵）として存在しなければならない。システムが再起動しても、このキーは変わらず、通知のレコードが消えることも許されない。 二つ目は、「メッセージが実際に外部のサービスに届けられるまで、成功したと主張してはいけない」ということだ。例えば、通知を送信する担当のプログラム（ワーカー）が、まだ外部に送っていないのに「送ったよ！」と勘違いして、その通知の記録を削除してしまうような事態は、ビジネスにとって大きな失敗となる。 三つ目は、「途中でエラーが起きても、安全に再試行できる」こと。もし通知が途中で止まってしまった場合、もう一度送ろうとしたときに、同じユーザーに二重に通知を送ってしまうようなことがあってはならない。これはユーザーからの信頼を失う行為だ。

更新通知システムには、2つの異なる「時間の流れ」が存在すると記事は指摘している。一つは「ビジネスの時計」で、これは「いつ通知を送るべきか」というビジネス上の期限（例：物件の審査が完了した後）を指す。もう一つは「配信の時計」で、これは「外部の送信サービスが、いつならメッセージを受け付けられるか」という技術的な制約（例：レートリミット）を指す。この二つの時計を混同して、「この時刻になったらすぐ送る」といった単純な設計にしてしまうと、レートリミットを超過してメッセージが拒否されたり、ビジネス上の期限は満たしているのにいつまでもメッセージが送られなかったりする問題が発生する。大切なのは、ビジネス上「送って良い」状態になっても、技術的な制限で「今は送れない」場合は、一時的に待機させる仕組みが必要だということだ。

これらの「絶対に守るべきこと」と「時間の流れ」を考慮すると、システム全体のアーキテクチャ（設計）は、キューだけでは完結しないことがわかる。記事では「失敗の境界線」として、メッセージ処理の各段階で発生しうる問題と、それに対する対策を示している。 まず、キューにメッセージを投入する前。アプリケーション側でデータベースへの書き込みなどが失敗した場合に備え、「アウトボックスパターン」と呼ばれる永続的な手渡し方法が必要だ。これは、メッセージを送信する前に、まず安全な場所にメッセージの記録を残すことで、システムがクラッシュしてもメッセージが失われないようにする仕組みだ。 次に、キューに投入されてから、ワーカーがメッセージを処理し始めるまで。この間も、システムは「処理待ちのメッセージ」の状態を正確に把握し、期限が過ぎたものがあれば見つけ出せるようにしておく必要がある。 そして、ワーカーがメッセージを処理している最中。レートリミットは、一つだけのワーカーではなく、複数のワーカーが同時に動作する場合でも正しく機能しなければならない。つまり、ワーカーごとに独立したレートリミットではなく、システム全体で共有されるレートリミットが必要となる。 最後に、外部のプロバイダー（メール送信サービスなど）にメッセージを送信した後。メッセージを送信したにもかかわらず、ネットワークエラーなどで応答がタイムアウトした場合、本当にメッセージが届いたのか、届かなかったのかが不明確になることがある。このような「不確実な結果」に備え、二重送信を防ぐための「べき等性キー」（同じ操作を何度行っても同じ結果になるようにするための識別子）や、状態を照合する仕組みが必要となる。これらの要素が組み合わさって、初めて信頼性の高いシステムが作られるのだ。キューは、このアーキテクチャの中の一つの重要な部品に過ぎない。

では、実際にキューサービスを選ぶ際、どのような選択肢があるのだろうか。記事では主に3つのタイプを比較している。 一つ目は、Redisをバックエンドに利用するワーカーキューだ。BullMQのようなライブラリがこれに該当する。これは高速な処理や、遅延実行、リトライ機能を提供し、JavaScriptなどのプログラミング言語でワーカーを動かすのに慣れたチームには扱いやすいかもしれない。しかし、Redis自体のデータ永続性（データが消えない保証）や、システムが停止した際の切り替え設定が、メッセージの確実な配信に直接影響するため、これらの運用スキルがチームに求められる。 二つ目は、AMQP（Advanced Message Queuing Protocol）という標準プロトコルに基づくメッセージブローカーだ。RabbitMQなどが代表的だ。これらは、メッセージの明示的な受信確認（アック）、複雑なルーティング、そしてエラーになったメッセージを別のキューに送る「デッドレターパス」といった高度な機能を提供する。ただし、ワーカーがメッセージを受け取ったこと（アック）と、実際に外部サービスへの送信が成功したこととは別の話であり、ワーカーは送信後のクラッシュにも対応する必要がある。 三つ目は、クラウドプロバイダーが提供するマネージドキューサービスだ。Amazon SQSなどがこれに当たる。これらのサービスは、キューの運用やインフラの管理をクラウドプロバイダーに任せられるため、運用負担が少ないのが大きなメリットだ。しかし、メッセージが他のワーカーから見えなくなる「可視性タイムアウト」や、メッセージの保持期間、リトライの挙動といった設定が、ビジネス上の期限とどのように整合するかを注意深く設計する必要がある。もし、ワーカーが処理に時間がかかりすぎて可視性タイムアウトを過ぎてしまうと、別のワーカーが同じメッセージを処理し始めてしまう可能性がある。

記事で「拒否されたオプション」として挙げられているのは、アプリケーションのメモリ内だけで動作するタイマーだ。これは、例えば一時的なキャッシュを更新するといった「多少失敗しても問題ない」処理や、開発環境でのテストには使えるかもしれない。しかし、更新通知のような「絶対に失敗が許されない」処理には向かない。なぜなら、アプリケーションのデプロイ（更新）、クラッシュ、複数のサーバーでの分散処理、さらにはサーバーの時計のずれといった要因によって、メモリ内のタイマーは簡単に信頼性を失い、予定通りの通知ができなくなるからだ。

信頼性の高いメッセージ処理を実現するための具体的なコードのイメージも提示されている。重要なのは、通知の識別キー（idempotency_key）を使い、通知の状態変化（処理中、送信済み、再試行待ちなど）を永続的に記録することだ。ワーカーは、まずレートリミッターを使って送信許可を得てから、通知のステータスを「送信試行中」に更新する。その後、実際に外部サービスへ送信し、結果に応じてステータスを「送信済み」または「再試行待ち」に更新する。ここで大切なのは、「送信試行中」や「送信済み」といった状態への更新処理が、何度実行されても同じ結果になる「べき等」であることだ。もし、送信後、ステータス更新前にワーカーがクラッシュしても、次に処理が再開されたときに二重送信にならないよう、外部サービス側でもべき等性を考慮した設計や、送信履歴を照合する仕組みが必要となる。また、レートリミッターは複数のワーカーで共有されるべきであり、単一のワーカーのメモリ内だけで動作するものであってはならない。

このようなシステムを本番環境に投入する前には、徹底的なテストが不可欠だ。単に「うまく動くか」というハッピーパスだけでなく、様々な「失敗の境界線」を意識したテストを行う必要がある。例えば、通知の期限が来る前にシステムが停止したらどうなるか、レートリミットを使い切ったらどうなるか、メッセージを送信した直後にワーカーがクラッシュしたらどうなるか、といった具合だ。これらのテストを通して、システムがどのような状態変化を起こし、次にどうなるかを明確に記録できることが重要だ。

さらに、運用が始まったら「監視」が極めて重要になる。キューにメッセージがどれだけ貯まっているか（キューの深さ）だけでなく、最も古い未処理の通知がどれくらい長く待機しているか、何回処理を試みたか、レートリミッターによってどれくらい待たされたか、といったビジネス上の意味を持つ指標を監視する必要がある。これらを監視することで、単にシステムが動いているだけでなく、「ビジネス上の期限が守られているか」を継続的に確認できる。

最終的に、どのキューサービスを選ぶべきか、という問いへの答えはシンプルだ。「そのキューサービスが持つ、データの永続性、タスクの確保方法、リトライの仕組み、そして監視のセマンティクス（意味合い）を、自分たちのチームが理解し、運用でき、そしてビジネスの責任者に説明できるかどうか」で決まる。単にAPIが使いやすいとか、世間で流行っているからといった理由ではなく、システムが再起動しても重要な通知を失わないか、二重送信を防げるか、といった根源的な信頼性を確保できるかどうかが最も重要だ。そして、これらの要件を満たすために、Redisベースのキュー、AMQPブローカー、またはマネージドキューのどれを選ぶかは、チームのスキルセットや運用体制に応じて判断すべき「デリバリーの決断」なのだ。

キューサービスは「仕事が保持される、または再配信される」ということを約束するが、メッセージが最終的にどうなったか（届いたのか、届かなかったのか、二重に送られたのか）を完全に保証するのは、キューだけでなく、アウトボックス、ワーカー、外部サービスとの連携、エラーハンドリングなど、システム全体のワークフローなのだ。このことを理解し、コード、監視、そしてインシデント発生時の調査で、それぞれの役割と保証範囲を明確に区別することが、信頼性の高いシステムを構築する鍵となる。