【ITニュース解説】The order was committed and nothing else ever heard about it

今回のニュース記事は、一見正常に見えるシステムがいかに大きな問題を抱え込むか、そしてその解決策がいかに重要かを教えてくれる。ある日、企業の財務担当者が、週末に受け付けられた214件の注文が、支払い済みであるにもかかわらず発送されていないことに気づいた。これらの顧客の中には、すでに発送状況について問い合わせの電話をしてきた人もいた。しかし、この異常事態にもかかわらず、システムのどこにもエラーを示すログはなく、監視用のダッシュボードもすべて緑色で、システムは「問題なし」と判断していた。なぜこのようなことが起きたのだろうか？

原因は、注文処理の仕組みにあった。顧客が注文を完了すると、まず注文サービスがその注文データをデータベースに書き込み、保存する。その後、その注文が発送されるべきであることを知らせるための「イベント」を、別のサービス（発送サービスなど）が受け取れるように発行する。

問題が起きたのは、このイベントを発行するタイミングだった。ある土曜日の朝、イベントを中継する役割を果たす「イベントブローカー」というシステムが、メンテナンスのために12分間だけ利用できなくなった。この時、注文サービスはイベントのパブリッシュ（発行）に失敗した。

しかし、この失敗はエラーとして扱われなかった。何年も前に、開発者が「注文データはすでにデータベースに保存されているのだから、メッセージング（イベント発行）の一時的な問題で顧客のチェックアウトを失敗させてはいけない」という人道的な理由から、このイベントパブリッシュの失敗をキャッチし、警告レベルのログとして記録するだけにしてしまったのだ。

その結果、顧客は注文完了の確認を受け取り、注文データはデータベースに確かに存在し、支払いも正常に完了していた。ただ一つ欠けていたのは、発送に必要なイベントが発行されなかったこと。そして、その不完全な状態を示す唯一の痕跡は、誰も確認しない警告ログの中に埋もれていた214行のメッセージだけだった。システムは自身が半分失敗していることを知らず、何の問題もないと信じ込んで動作し続けていたのだ。

この根本的な問題は、一つのリクエストの中で「注文データをデータベースに保存する」と「発送イベントを発行する」という、二つの異なるシステムに対する処理が、一体のものとして扱われていなかったことに尽きる。システムは、「最初の処理は成功したが、二番目の処理は失敗した」という中間状態を「エラーではない」と判断してしまった。これは、システムが自身の内部状態について嘘の記録を残し、それを正しいと信じ込んで稼働し続けていたことを意味する。

このような問題を解決するために、開発チームはシステムを改修した。主要な変更点は、「Outboxパターン」と呼ばれる手法の導入だ。これは、注文データをデータベースに保存するのと同じトランザクション（一連の不可分な処理）の中で、発送イベントも「Outboxテーブル」と呼ばれる特別なテーブルに書き込むようにする、というものだ。これにより、注文データがデータベースに保存されるか、または保存されないか、というのと同じタイミングで、関連するイベントもOutboxテーブルに記録されるか、または記録されないか、のどちらかになる。つまり、注文データとイベントの記録が、もはやバラバラではなく、一体のものとして扱われるようになったのだ。

このOutboxテーブルに保存されたイベントは、次に「リレーサービス」という別の専用サービスによって監視される。リレーサービスは、Outboxテーブルから未送信のイベントを読み取り、本来のイベントブローカーへとパブリッシュする。イベントが正常にパブリッシュされると、リレーサービスはOutboxテーブルの該当するイベントを「送信済み」とマークする。もしパブリッシュに失敗した場合でも、リレーサービスは無限に再試行を繰り返すため、最終的にはイベントが確実に配信されるようになる。この方式は「少なくとも一度」の配信を保証するため、イベントを受け取る側のサービスは、同じイベントが複数回届いても正しく処理できるよう、イベントIDを使って重複を排除する仕組みが必要になる。

この改善策で最も効果的だったのは、新しい監視体制だ。Outboxテーブルの中に、最も古い未送信のイベントがどれくらいの時間留まっているかを常に監視し、その時間が2分を超えたらすぐにアラートを発するように設定された。このアラートは導入後すでに3回発報しており、そのたびに、以前であれば週末の未発送問題として水曜日に発覚していたであろう問題を、早期に発見して解決できるようになった。また、イベントパブリッシュの失敗時に例外を黙って飲み込むこともやめた。

このニュース記事が私たちに教えてくれる最も重要な教訓は、システムが成功したことだけを記録するように設計されていると、処理の途中で失敗した重要な作業が完全に失われてしまう、ということだ。もし二つのことが同時に「真」である必要があるのなら、それらは「一緒に」記録される必要がある。あるいは、もし一緒に記録できない場合でも、その不整合を検知し、適切な行動をとる専門の仕組みが必要不可欠だということだ。システムの信頼性は、隠された失敗をどれだけ早く、正確に、そして確実に検出できるかにかかっている。