【ITニュース解説】How to implement the Outbox pattern in Go and Postgres

システム開発において、複数の処理を確実に連携させることは、信頼性の高いシステムを構築する上で不可欠である。特に、データベースの更新と、その更新に関連するイベント（メッセージ）を外部システムへ送信するような場面では、両方の処理が同時に成功するか、あるいは同時に失敗するかのどちらかである「アトミックな処理」が求められる。この記事は、Go言語とPostgreSQLを使って、このアトミック性を保証するための強力な手法である「Outboxパターン」の実装方法について解説している。

Outboxパターンが必要とされる背景には、マイクロサービスアーキテクチャのような分散システムが普及したことがある。現代のシステムでは、機能ごとに独立した小さなサービス（マイクロサービス）が連携して動作することが一般的だ。例えば、ユーザーが商品を注文した際に、データベースの在庫情報を更新すると同時に、注文完了の通知を別のサービスへ送る必要があるとしよう。もし、在庫更新は成功したが、通知の送信は失敗した場合、ユーザーは通知を受け取れないという不整合な状態が発生する。逆に、通知送信は成功したが、在庫更新が失敗した場合、システム内部では注文が完了していないのに、ユーザーには完了したと誤解させてしまうことになる。

このようなデータ不整合を防ぐため、通常はデータベースのトランザクション機能を利用する。トランザクションとは、複数のデータベース操作を一つのまとまりとして扱い、そのまとまりの中のすべての操作が成功した場合のみ変更を確定させ（コミット）、一つでも失敗した場合はすべての変更を取り消す（ロールバック）仕組みである。これにより、データベース内の整合性は保たれる。しかし、問題は、メッセージの送信のような外部システムとの連携は、このデータベースのトランザクションの範囲外であるという点にある。つまり、データベースの更新とメッセージ送信を同時にトランザクションで管理することはできないのだ。

ここでOutboxパターンが登場する。Outboxパターンは、このデータベースの更新とメッセージ送信の間のアトミック性を保証するための設計パターンである。基本的な考え方は、本来送信したいメッセージそのものを、データベースの更新と同じトランザクション内で、通常の業務データと一緒に「Outboxテーブル」と呼ばれる特別なテーブルに書き込むことである。このOutboxテーブルは、未送信のメッセージを一時的に保存する役割を果たす。

具体的な流れでは、例えば注文処理の例で、商品の在庫情報を更新するデータベース操作と同時に、「注文が完了しました」というメッセージをOutboxテーブルに挿入する。これらの二つの操作は、一つのデータベーストランザクションとして実行される。これにより、在庫更新が成功すればOutboxテーブルへのメッセージ挿入も成功し、逆にどちらか一方が失敗すれば両方ともロールバックされ、何事もなかったかのように元の状態に戻る。これで、データベースの更新と、メッセージを「送信すべきである」という記録が、常に同期されることが保証される。

次に、Outboxテーブルに記録されたメッセージを実際に外部システムへ送信する役割を担うのが、「リレープロセス」と呼ばれる別の独立したサービスである。このリレープロセスは、定期的にOutboxテーブルを監視し、未送信のメッセージを見つけるとそれを読み込む。そして、読み込んだメッセージを、KafkaやRabbitMQのようなメッセージキューシステムを通じて、目的の外部サービスへと送信する。メッセージの送信が成功したら、リレープロセスはOutboxテーブルからそのメッセージを削除するか、あるいは「送信済み」のステータスに更新する。

Go言語とPostgreSQLを使った実装では、PostgreSQLがOutboxテーブルの永続化とトランザクション管理の中心となる。Outboxテーブルは、メッセージを一意に識別するためのID、メッセージの内容（JSON形式が一般的）、作成日時、送信ステータスなどのカラムを持つシンプルな構造となる。

Goアプリケーションは、主要な業務ロジック部分でPostgreSQLへの接続を管理し、トランザクションを開始する。このトランザクション内で、業務データの更新クエリを実行し、続けてOutboxテーブルへのメッセージ挿入クエリを実行する。全てのクエリが成功したらトランザクションをコミットし、一つでも失敗したらロールバックする。Goの標準ライブラリやORM（Object-Relational Mapping）ライブラリを使えば、このようなトランザクション処理は容易に実装できる。

リレープロセスもGo言語で実装される。このリレープロセスは、例えば数秒ごとにOutboxテーブルをポーリングし、未送信のメッセージを取得する。取得したメッセージは、Goの標準ライブラリやサードパーティライブラリを使って、Kafkaクライアントなどを通じてメッセージキューにパブリッシュされる。メッセージキューへのパブリッシュが成功した後、Outboxテーブルの該当するメッセージのステータスを更新するか、完全に削除する。このOutboxテーブルの更新も、リレープロセス内の別のトランザクションとして実行することで、送信の成功とOutboxテーブルの更新のアトミック性を保証できる。

Outboxパターンを導入することで得られる主なメリットは、データベースとメッセージ送信の間で「少なくとも一度」の配信保証（at-least-once delivery）を実現できる点にある。つまり、メッセージは確実に送信されるか、少なくとも送信されるべき状態がOutboxテーブルに永続化されるため、データが失われるリスクが極めて低くなる。これにより、分散システムにおけるデータ整合性の問題が大幅に解決される。

しかし、このパターンにはいくつかの考慮点もある。一つは、システムの複雑さが増すことだ。Outboxテーブルの管理やリレープロセスの運用が必要となるため、直接メッセージキューに送るよりも設計・実装・運用に手間がかかる。また、リレープロセスがネットワーク障害などで一時的にメッセージを重複して送信してしまう可能性もゼロではない。そのため、メッセージを受け取る側のサービス（コンシューマ）は、同じメッセージを複数回受け取っても問題なく処理できるように、「冪等性」（Idempotence）を持つように設計する必要がある。例えば、同じ注文IDのメッセージを複数回受け取っても、最初の1回だけ処理を行い、2回目以降は無視するような仕組みである。さらに、リレープロセスのポーリング間隔によっては、メッセージが送信されるまでにわずかな遅延が発生する可能性もある。

まとめると、Outboxパターンは、データベースのトランザクション保証を活用し、複数の独立した処理（データベース更新とメッセージ送信）の間でデータ整合性を確保するための強力な手法である。Go言語とPostgreSQLを組み合わせることで、堅牢なシステムを構築するための基盤を提供し、分散システムにおける複雑なデータ連携の課題を解決する一助となる。システムエンジニアを目指す初心者にとって、このような設計パターンを理解することは、信頼性の高いシステムを設計・構築する上で非常に重要なスキルとなるだろう。