イベント駆動アーキテクチャにおける冪等性の設計

要点

at-least-once 配信を前提とする限り、冪等性はオプションの改善ではなく設計の前提条件である。重要なのは冪等キーの一意性境界と保存期間の設計である。

なぜ重複が発生するのか

主要メッセージングサービスの配信保証に関する公式ドキュメントは、多くのキューが at-least-once、つまり最低一回の配信を保証すると明記している。これは同一メッセージが複数回配信される可能性を許容するという意味であり、受信側が重複を検知して無視する仕組みを持たない限り、二重処理は避けられない。

冪等キーの設計が分かれ目になる

冪等キーをどの粒度で発行するかが実装の分かれ目になる。リクエスト単位で発行すれば重複検知は正確になるが、キーの保存期間を長く取るほどストレージが肥大する。逆に保存期間を短くすると、遅延した重複メッセージがキー失効後に届いた場合、二重処理を防げなくなる。分散システムに関する標準的な文献（Kleppmann 著、Designing Data-Intensive Applications）の公表資料でも、冪等性キーの有効期限設計はメッセージの最大遅延時間を上回る必要があると説明されている。ただし、この保存期間の問題は、キーにビジネス上の意味のある識別子（注文番号など）を使うことで、外部ストレージを持たずに済むケースもある。

順序保証との干渉

冪等性の実装は、順序保証の仕組みと干渉することがある。メッセージが再順序化された場合、冪等キーによる重複排除だけでは処理順序の逆転を防げず、状態遷移を伴う処理では別途バージョン番号による排他制御が必要になる。CI パイプラインの間欠障害と同様に、こうした問題は平常時には表面化せず、負荷やネットワーク遅延が重なったときに顕在化する。業務システムをRPA から API 連携へ移行する際も、非同期処理を挟むなら同じ冪等性の設計が必要になる。

配信保証のレベルを正しく理解し、それに見合った冪等性の粒度を選ぶことが、後からの手戻りを避ける最も確実な方法である。