マイクロサービスでのトランザクションモデルについてメモ20240320

モノリシックなアプリケーションなら、RDBMSの機能でシンプルにトランザクションの整合性を保つことができるが、マイクロサービスの場合はサービス間のトランザクションの整合性を保つことが難しくなる。

wakatchi.dev

qiita.com

engineering.mercari.com

上記の記事を少し読んだ感じ、TCCやSagaなどトランザクション管理のためのパターンがいろいろあるようだが、理解するには時間がかかりそうなのでまずはそういうパターンがあるんだな程度の認識をしておく。

ChatGPTにも質問してみた。

質問

マイクロサービスにおけるトランザクション管理について簡単に教えてください。

ChatGPT

マイクロサービスアーキテクチャにおけるトランザクション管理は、伝統的なモノリシックアプリケーションでのトランザクション管理とは異なります。
マイクロサービスは独立してデプロイされる小さなサービスで構成されており、それぞれが独自のデータベースを持つことが多いです。このため、複数のマイクロサービスを跨いで一貫性を保ちながらデータを更新することが挑戦的になります。
主な戦略としては、分散トランザクションパターンとイベント駆動アーキテクチャがあります。

分散トランザクションパターン

2フェーズコミット (2PC):

• 2フェーズコミットは、分散システムにおけるトランザクションのアトミック性を保証するためのプロトコルです。
  しかし、ロックやリソースの保持によるパフォーマンスの低下、システム障害時の複雑な回復処理など、マイクロサービスの環境には適していない場合が多いです。

Sagaパターン:

• Sagaパターンは、分散トランザクションを複数のローカルトランザクションに分割し、それぞれを独立して実行します。
  各トランザクションは成功した場合は次のトランザクションをトリガーし、失敗した場合は補償トランザクション（コンペンセーショントランザクション）を実行して、既に行われた変更をロールバックします。Sagaパターンは、イベント駆動アーキテクチャと組み合わせて使用されることが多いです。

イベント駆動アーキテクチャ

• イベント駆動アーキテクチャでは、サービス間のやり取りはイベント（メッセージ）を介して非同期に行われます。サービスはイベントを発行し、他のサービスがそのイベントを購読して反応します。
  このアプローチにより、サービス間の疎結合が促進され、システム全体のスケーラビリティと回復力が向上します。
  トランザクションのコンテキストでは、イベントはトランザクションの結果を他のサービスに通知する手段として使用されます。

トランザクション管理の考慮事項

一貫性:

• システムの一貫性要件に基づいて、強一貫性が必要か、最終的な一貫性で十分かを検討します。

コンペンセーションロジック:

• Sagaパターンでは、失敗した操作を補償するロジックの実装が重要です。これにより、システムの整合性を維持できます。

パフォーマンスとスケーラビリティ:

• 分散トランザクションはパフォーマンスに影響を与える可能性があるため、アプリケーションのパフォーマンスとスケーラビリティの要件を考慮する必要があります。

マイクロサービスアーキテクチャにおけるトランザクション管理は複雑であり、適切な戦略の選択はアプリケーションの特定の要件と制約に依存します。
Sagaパターンやイベント駆動アーキテクチャのようなパターンを適用することで、分散システム内での一貫性と信頼性を高めることができます。

イベント駆動アーキテクチャの説明で「サービス間のやりとりはイベント（メッセージ）を介して非同期に行われる」とあったので、AWSならSQSなどが該当するかと思って検索すると以下の記事があった。

www.softbank.jp

マイクロサービスでは非同期処理に対する理解やそれらを実現するマネージドサービスを使いこなすことが重要になりそう。

ChatGPTにも質問してみた。

質問

サービス間で非同期にメッセージをやりとりするにはどういった方法がありますか？

ChatGPT

サービス間で非同期にメッセージをやり取りする方法は、システムのスケーラビリティ、信頼性、メンテナンス性を高めるのに役立ちます。非同期通信を実現するためには、メッセージキュー、イベントバス、ストリーミングデータプラットフォームなど、さまざまなテクノロジーが利用可能です。以下に、主要な非同期通信方法とその使用例を紹介します。

メッセージキュー (Message Queues)

• RabbitMQ, ActiveMQ: これらのメッセージキューシステムは、メッセージの送受信を仲介するための強力なツールです。
  プロデューサーはメッセージをキューに送信し、コンシューマーはキューからメッセージを非同期に受信します。
  これにより、サービス間での耦合を減らし、信頼性の高いメッセージ配信を実現できます。

イベントストリーム (Event Streams)

• Kafka, Amazon Kinesis: 大量のイベントやメッセージをリアルタイムに処理する必要がある場合、KafkaやKinesisのようなイベントストリームプラットフォームが適しています。これらのシステムは、高スループットかつ耐久性のあるイベントの配信を可能にし、大規模なデータパイプラインの構築に適しています。

メッセージブローカー (Message Brokers)

• Amazon SQS, Google Cloud Pub/Sub: クラウドプロバイダーが提供するメッセージブローカーサービスは、設定や管理が容易で、スケーラブルなメッセージングソリューションを求める場合に便利です。これらのサービスは、メッセージのバッファリング、配信試行、デッドレターキューなど、高度なメッセージング機能を提供します。

イベントバス (Event Buses)

• EventBridge (AWS), CloudEvents (CNCF): イベント駆動型アーキテクチャにおいて、イベントバスはサービス間でイベントを非同期に転送する中心的な役割を果たします。イベントバスを使用すると、イベントの生産者と消費者を疎結合に保ちながら、システム全体でイベントを効率的に配信できます。

Webhooks

• Webhooks: よりシンプルな非同期通信メカニズムとして、Webhooksを使用することもできます。Webhookは、特定のイベントが発生したときに、登録されたURLにHTTP POSTリクエストを送信する仕組みです。これにより、システム外部のサービスやアプリケーションに対して、イベントの通知を簡単に行うことができます。 これらの非同期メッセージング方法を選択する際は、システムの要件、スケーラビリティ、耐久性、メンテナンスのしやすさなどを考慮することが重要です。また、使用するテクノロジーに応じて、適切なエラーハンドリングやメッセージ配信の保証レベル（例えば、最大一回配信、少なくとも一回配信、正確に一回配信）を実装することが求められます。

RabbitMQやKafkaなどは名前は聞いたことがあるが、まだ使ったことがないので少しずつ触ってみたい。