呼ばずに知らせる──イベント駆動とメッセージキュー

ボタンを押すと、確認メールがすぐ届く。注文すると、在庫が減り、配送の手配が始まる。利用者から見れば一瞬の出来事だが、その裏側では複数のシステムが連携して動いている。問題は、その連携をどうつなぐかだ。素直に考えれば「注文を受けたら、メール送信を呼び、在庫更新を呼び、配送手配を呼ぶ」と順番に命じればよい。しかしこの素直なやり方には、見えにくい弱点がある。

直接呼び出しの危うさ

順番に呼び出していく方式では、呼ばれる側のどれか一つでも遅れたり止まったりすると、その手前で全体が詰まる。メール送信サービスが一時的に重くなっただけで、注文処理そのものが待たされる。さらに、呼ぶ側は相手の数だけ「相手の都合」を知っていなければならない。連携先が増えるほど、依存の糸は複雑に絡み、一か所の不調が思わぬ場所まで波及する。

イベント駆動という考え方は、この前提をひっくり返す。注文を受けた側は、相手を名指しで呼ばない。代わりに「注文が確定した」という出来事（イベント）を、ただ知らせるだけにする。メール送信も、在庫更新も、配送手配も、その知らせを各自で受け取り、それぞれのペースで処理する。送り手は誰が聞いているかを気にせず、受け手は自分の都合で動ける。両者は直接つながっていない。

キューという「待ち行列」

この「知らせ」を仲介するのがメッセージキュー、つまり待ち行列だ。送り手はメッセージをキューに置き、受け手はキューから取り出して処理する。間にキューが挟まることで、二つの効果が生まれる。ひとつは、受け手が一時的に止まっても、メッセージはキューに溜まって消えないこと。受け手が復帰すれば、溜まった分から処理を再開できる。もうひとつは、急な処理の集中を平らにならせること。注文が一気に押し寄せても、受け手は自分のペースで列をさばけばよい。波の高さを、時間をかけて低くするのだ。

こうした非同期メッセージングの利点と注意点は、ソフトウェア設計の分野で長く論じられてきた。マーチン・ファウラーらが整理した企業システムの連携パターン集でも、メッセージングは疎結合を実現する基本手段として位置づけられている。直接呼び出しの密な結びつきを、待ち行列がほどく、という構図だ。

ほどけば、追いにくくなる

もっとも、疎結合には代償がつく。送り手と受け手が直接つながっていないということは、処理が「いまどこを流れているのか」を一目で追えないということでもある。注文がメールを引き起こし、在庫を動かし、配送につながる──その因果の鎖が、コードの上には書かれていない。出来事が出来事を呼ぶ連鎖は、追跡しなければ見えない。だからイベント駆動の現場では、各メッセージに識別子を付けて流れを後から再構成できるようにする可観測性の仕組みが、ほぼ必須の相棒になる。

加えて、キューを介すると、同じメッセージが二度届いたり、送った順と違う順で届いたりすることが起こりうる。だから受け手は、二度届いても結果が変わらないよう冪等に作るのが定石だ。一方で、すべてを非同期にすればよいわけでもない。利用者がその場で結果を待っている処理まで待ち行列に流すと、応答がもたつき、かえって体験を損なう。

イベント駆動とキューは、システムを止まりにくく、波に強くする。だがそれは「つながりを見えなくする」ことと引き換えに得られる強さだ。見えない連携を安心して任せられるかどうかは、流れを後から見えるようにする手間を、どれだけ惜しまずに払えるかにかかっている。基盤の堅牢さは、つなぎ方の巧みさよりも、見失わない工夫の積み重ねから生まれる。