Transactional OutboxをAWSで実現する

概要

• 本記事の目的は、マイクロサービスアーキテクチャでよく使われるパターン、Transactional Outboxについての説明とAWSで実現する方法をお届けすることとしています。
• Transactional Outboxを説明する中でマイクロサービスアーキテクチャについてや、Sagaパターンについてを詳細に述べることは致しません。

Transactional Outbox

Sagaパターン

• マイクロサービスで複数のリソースの結果整合性を利用する方法として、Sagaパターンと呼ばれるものがあります。
• Sagaパターンというのは、複数にまたがるサービスごとでトランザクションを分解し、それぞれが独立で処理するようなアーキテクチャパターンです。
• Sagaパターンによりトランザクションをサービスごとに分解することの何が嬉しいのか。
  => それは１トランザクションあたりにかかる時間を短縮し、それによって複数行、テーブル全体を長時間ロックすることなく処理を実行できることにあります。
• 下記の図で示しているのが、Sagaパターンの一例です。
• 緑色のヘキサゴンで示したものが、複数のサービスを表しています。

Sagaパターンの複雑性

• Sagaパターンには実装の複雑さがあります。

• どういうことか？ というと、Sagaパターンをロールバックさせようとした時に単純なロールバックはできないためです。

• なぜならば、複数のトランザクションが関与しているので、途中で障害が発生した場合、障害が発生した以前の状態に回復させようとロールバックすると既に別のコミットが発生している可能性があります。

• そのため、Sagaパターンでは補償トランザクションと呼ばれる方法を適用します。

• 補償トランザクションとは、一連のトランザクションで実行した操作の逆向きにした取り消し操作によってロールバックを行います。

• 下記の図で示しているのが、各ローカルトランザクションとその操作で実行する責務を持つマイクロサービス例で、トランザクション実行中エラーが起き、補償トランザクションが実行された時を示しています。

• このSagaパターンを実装する時にも２つほどパターンがありますが、ここでは詳細に紹介致しません。
• もし気になる方がいれば、下記の記事をご参照ください。

---

• さて、ではSagaパターンを実際に構築しましょう。となったときのパターンとして、Choreography (コレオグラフィ)を選択したとしましょう。
• コレオグラフィのSagaパターンでは、メッセージブローカを使用し、各のマイクロサービスがイベントを交換します。
• コレオグラフィを使用すると、他のサービスでローカルトランザクションをトリガーするイベントが、各ローカルトランザクションによって発行されます。
• 下記の図で示しているのが、コレオグラフィの一例です。

• もし、この構成の時にメッセージブローカに流した変更とその更新によりデータベースへも更新が走った場合、それぞれに書き込みを実施する２重書き込みを実施するパターンと分散トランザクションにするパターンを使用しないといけません。
  • ２重書き込みの問題点: 二重書き込みではどちらかの書き込みは成功し、もう一方の書き込みは失敗するような場合がありますし、障害が発生するタイミングなどでデータの不整合が生じる可能性もあります。
  • 分散トランザクションの問題点: DBとメッセージングシステムで分散トランザクションがサポートしている必要があります。そのため、利用できる技術が限定されてしまいます。

ではどうするのか？
=> そこで登場するのが、Transactional Outboxです。

Transactional Outbox

• Transactional Outboxとは、データベースとメッセージングシステムへの分散トランザクションを用いた書き込みはせず、データベースに追加したOutboxテーブルにメッセージの内容を書き込みます。
• この時、Outboxテーブルへのメッセージの書き込みにはローカルトランザクションを用いることができます。
• 下記に示したのがTransactional Outboxの一例になります。
• こちらの例では、何かしらの注文を受け取るサービスがあった時に、そのサービスからの変更をOrderテーブルに書き込み、その際にOutboxテーブルにも変更した内容を入れています。
• この時にはデータベースがサポートするローカルトランザクションを使用することができますよね。

画像引用元

• 次にその後の処理を追ってみましょう。

• Outboxテーブルへ書き込まれたメッセージは、MessageRelayを経由し、MessageBrokerへ送信されていることがわかります。こうすることにより、DBへの書き込みとメッセージングシステムへのメッセージの書き込みをアトミックに実行できます。

• MessageRelay: Outboxテーブルにメッセージが書き込まれ更新されると、そのメッセージを読み取り、後続のメッセージブローカへ送信する役割を持ちます。

• ちなみにこのMessageRelayにもパターンがあります。

  • Mpolling publisher パターン
  • transaction log tailing パターン

これらのパターンの違いを知りたい場合は、下記の記事を見ることをオススメいたします。

Transactional OutboxをAWSで実現する

• いよいよ本題です。
• Transactional Outboxについての説明を上記で行いましたが、いざこれをどうやって実現しようとなると思います。
• 今回は、AWSの中でこのTransactional Outboxを実現する方法についてを説明していきましょう。
• AWSで実現するときに一番簡単にできるのがDynamoDBストリームを使用することです。
  • DynamoDBストリームとは、DynamoDBのテーブルに更新があった際に、その変更を暗号化してログに保存しておくことができます。
  • また、DynamoDBストリームでは更新された内容をほぼリアルタイムで書き込みます。
  • 下記の図は、DynamoDBのテーブルにOrderというサービスから更新を受けた時に、ストリームで生成されるイベントの流れを示しています。

• また、DynamoDBストリームを使用することで後続の処理(Orderサービスによって受けた変更を利用し、処理するサービス)の実装を簡単にすることができます。
• 例えば、Orderサービスによって更新された内容を別のサービスが使用したいとしましょう(加工し)
• その場合は、以下のような構成もとることができます。
• DynamoDBストリームでは、Lambdaとの統合機能があるので、そちらを使用します。
• あとはSQSに送信し、他のサービスがその内容を取得するといった形ですね。

まとめ

• いかがだったでしょうか。
• 今回は、Transactional OutboxのついてとそれをAWSで実現するにはという内容を記載させていただきました。

参考