Sagaパターン：マイクロサービスのための分散トランザクションの実装

マイクロサービスの世界では、複数のサービスにまたがるデータの一貫性を維持することは大きな課題となり得ます。モノリシックなアプリケーションで一般的に使用される従来のACID（原子性、一貫性、分離性、永続性）トランザクションは、分散環境には適していないことが多いです。ここでSagaパターンが登場し、分散トランザクションを管理し、マイクロサービス間のデータ整合性を確保するための堅牢なソリューションを提供します。

Sagaパターンとは何か？

Sagaパターンは、複数のマイクロサービスにまたがる一連のローカルトランザクションを管理するために使用されるデザインパターンです。これは結果整合性を達成する手段を提供します。つまり、データが一時的に不整合になる可能性はあっても、最終的には一貫性のある状態に収束することを意味します。複数のサービスにまたがる単一のアトミックなトランザクションに依存する代わりに、Sagaパターンはトランザクションを、それぞれが単一のサービスによって実行される一連の小さな独立したトランザクションに分割します。

Saga内の各ローカルトランザクションは、単一のマイクロサービスのデータベースを更新します。もしトランザクションの1つが失敗した場合、Sagaは先行するトランザクションによって行われた変更を取り消すための一連の補償トランザクションを実行し、効果的に全体的な操作をロールバックします。

なぜSagaパターンを使用するのか？

いくつかの要因により、Sagaパターンはマイクロサービスアーキテクチャでトランザクションを管理するための貴重なツールとなっています：

疎結合： Sagaはマイクロサービス間の疎結合を促進し、他のサービスに影響を与えることなく独立して進化することを可能にします。これはマイクロサービスアーキテクチャの主要な利点です。
スケーラビリティ： 長時間実行される分散トランザクションを回避することで、Sagaはスケーラビリティとパフォーマンスを向上させます。各マイクロサービスは自身のトランザクションを独立して処理できるため、競合が減り、スループットが向上します。
回復力： Sagaは障害に対して回復力があるように設計されています。トランザクションが失敗した場合、Sagaをロールバックしてデータの一貫性のない状態を防ぎ、システムが一貫した状態を維持できるようにします。
柔軟性： Sagaパターンは、複数のサービスにまたがる複雑なビジネスプロセスを管理する上で柔軟性を提供します。トランザクションのシーケンスと、失敗した場合に実行される補償アクションを定義できます。

ACID vs. BASE

Sagaパターンを使用するかどうかを決定する際には、ACIDとBASE（Basically Available, Soft state, Eventually consistent）の違いを理解することが重要です。

ACID（原子性、一貫性、分離性、永続性）： トランザクションが確実に処理されることを保証します。原子性は、トランザクション内のすべての操作が成功するか、まったく成功しないかのどちらかであることを保証します。一貫性は、トランザクションがデータベースをある有効な状態から別の有効な状態に変換することを保証します。分離性は、並行するトランザクションが互いに干渉しないことを保証します。永続性は、一度コミットされたトランザクションは、システム障害が発生した場合でもそのまま残ることを保証します。
BASE（基本的に利用可能、ソフトステート、結果整合性）： これは分散システム向けに設計された異なるアプローチです。基本的に利用可能とは、システムがほとんどの時間利用可能であることを意味します。ソフトステートとは、システムの状況が入力がなくても時間とともに変化する可能性があることを意味します。結果整合性とは、システムへの入力が停止すれば、最終的に一貫性がとれる状態になることを意味します。SagaパターンはBASEの原則に沿っています。

Sagaの主な実装戦略2つ

Sagaパターンを実装するには、主にコレオグラフィとオーケストレーションの2つの方法があります。

1. コレオグラフィベースのSaga

コレオグラフィベースのSagaでは、各マイクロサービスは他のマイクロサービスによって発行されたイベントをリッスンし、それに応じて反応することでSagaに参加します。中央のオーケストレーターは存在せず、各サービスは自身の責任とアクションを実行するタイミングを把握しています。

仕組み：

Sagaは、マイクロサービスがトランザクションの開始を示すイベントを発行することで開始されます。
他のマイクロサービスはこのイベントを購読し、それを受信するとローカルトランザクションを実行します。
トランザクションを完了した後、各マイクロサービスはその操作の成功または失敗を示す別のイベントを発行します。
他のマイクロサービスはこれらのイベントをリッスンし、Sagaの次のステップに進むか、エラーが発生した場合は補償トランザクションを開始するなど、適切なアクションを実行します。

例：Eコマースの注文処理（コレオグラフィ）

注文サービス： 新規注文リクエストを受け取り、`OrderCreated`イベントを発行します。
在庫サービス： `OrderCreated`を購読します。イベントを受信すると在庫を確認します。在庫が十分であれば商品を予約し、`InventoryReserved`を発行します。不十分な場合は`InventoryReservationFailed`を発行します。
決済サービス： `InventoryReserved`を購読します。イベントを受信すると支払いを処理します。成功すれば`PaymentProcessed`を発行します。失敗した場合は`PaymentFailed`を発行します。
配送サービス： `PaymentProcessed`を購読します。イベントを受信すると出荷準備を行い、`ShipmentPrepared`を発行します。
注文サービス： `ShipmentPrepared`を購読します。イベントを受信すると注文を完了としてマークします。
補償： `PaymentFailed`または`InventoryReservationFailed`が発行された場合、他のサービスはそれをリッスンし、補償トランザクション（例：予約された在庫の解放）を実行します。

コレオグラフィの長所：

シンプルさ： シンプルなワークフローの場合、実装が容易です。
分散型： マイクロサービスの疎結合と独立した進化を促進します。

コレオグラフィの短所：

複雑性： Sagaの参加者が増えるにつれて、管理が複雑になる可能性があります。
可視性： Saga全体の進捗と状態を追跡することが困難です。
結合： 疎結合を促進するものの、サービスは他のサービスが発行するイベントを認識している必要があります。

2. オーケストレーションベースのSaga

オーケストレーションベースのSagaでは、中央のオーケストレーター（専用サービスやステートマシンとして実装されることが多い）がSagaを管理し、参加するマイクロサービスによるローカルトランザクションの実行を調整します。オーケストレーターが各サービスに何をいつ行うべきかを指示します。

仕組み：

Sagaは、クライアントがオーケストレーターにトランザクションの開始を要求することで開始されます。
オーケストレーターは、参加するマイクロサービスにローカルトランザクションを実行するようコマンドを送信します。
各マイクロサービスはトランザクションを実行し、成功または失敗をオーケストレーターに通知します。
結果に基づいて、オーケストレーターは次のステップに進むか、補償トランザクションを開始するかを決定します。

例：Eコマースの注文処理（オーケストレーション）

注文オーケストレーター： 新規注文リクエストを受け取ります。
注文オーケストレーター： 在庫サービスに商品を予約するようコマンドを送信します。
在庫サービス： 商品を予約し、注文オーケストレーターに通知します。
注文オーケストレーター： 決済サービスに支払いを処理するようコマンドを送信します。
決済サービス： 支払いを処理し、注文オーケストレーターに通知します。
注文オーケストレーター： 配送サービスに出荷準備をするようコマンドを送信します。
配送サービス： 出荷準備を行い、注文オーケストレーターに通知します。
注文オーケストレーター： 注文を完了としてマークします。
補償： いずれかのステップが失敗した場合、注文オーケストレーターは関連するサービスに補償コマンド（例：予約された在庫の解放）を送信します。

オーケストレーションの長所：

一元管理： Sagaを中央のポイントから管理および監視するのが容易です。
可視性の向上： オーケストレーターはSaga全体の進捗と状態を明確に把握できます。
結合の低減： マイクロサービスはオーケストレーターとのみ通信すればよいため、サービス間の直接的な依存関係が減少します。

オーケストレーションの短所：

複雑性： 特にシンプルなワークフローの場合、初期実装がより複雑になる可能性があります。
単一障害点： オーケストレーターが単一障害点になる可能性がありますが、これは冗長性やフォールトトレランス対策によって軽減できます。

補償トランザクションの実装

Sagaパターンの重要な側面は、補償トランザクションの実装です。これらのトランザクションは、失敗した場合に以前に完了したトランザクションの効果を取り消すために実行されます。目標は、Saga全体が完了できなくても、システムを一貫した状態に戻すことです。

補償トランザクションの主な考慮事項：

べき等性： 補償トランザクションはべき等であるべきです。つまり、複数回実行されても結果が変わらないようにする必要があります。これは、障害がいつでも発生する可能性があり、補償トランザクションが再試行される可能性があるため重要です。
障害の処理： 補償トランザクションも失敗する可能性があります。補償トランザクションの障害を処理するための戦略（再試行、エラーのロギング、管理者への警告など）が必要です。
データの一貫性： 補償トランザクションはデータの一貫性を確保する必要があります。これには、データを以前の状態に復元する、新しく作成されたデータを削除する、またはトランザクションのキャンセルを反映するようにデータを更新することが含まれる場合があります。

補償トランザクションの例：

在庫サービス： 在庫サービスが商品を予約したが支払いが失敗した場合、補償トランザクションは予約された商品を解放することです。
決済サービス： 決済サービスが支払いを処理したが配送が失敗した場合、補償トランザクションは返金を行うことかもしれません。

課題と考慮事項

Sagaパターンは大きな利点を提供しますが、いくつかの課題や考慮事項も提示します：

複雑性： Sagaパターンの実装は、特に複雑なビジネスプロセスでは複雑になる可能性があります。慎重な計画と設計が不可欠です。
結果整合性： Sagaパターンは結果整合性を提供しますが、これはデータが一時的に不整合になる可能性があることを意味します。これは、強い一貫性の保証を必要とするアプリケーションにとっては懸念事項となる可能性があります。
テスト： Sagaのテストは、その分散的な性質とさまざまな時点での障害の可能性があるため、困難になることがあります。
監視： Sagaの進捗と状態の監視は、問題を特定し解決するために不可欠です。適切な監視ツールとプロセスを整備する必要があります。
べき等性： トランザクションと補償トランザクションがべき等であることを保証することは、データの一貫性のない状態を防ぐために重要です。
分離性： Sagaは複数のローカルトランザクションを伴うため、分離性が懸念される場合があります。セマンティックロックやオプティミスティックロックのような戦略が必要になるかもしれません。

ユースケースと例

Sagaパターンは、特に分散システムやマイクロサービスアーキテクチャにおいて、さまざまなユースケースに適しています。以下は一般的な例です：

Eコマースの注文管理： 上記の例で示したように、Sagaパターンは注文作成から支払い処理、配送までの注文ライフサイクル全体を管理するために使用できます。
金融取引： Sagaパターンは、資金移動、ローン申請、保険金請求など、複数のシステムが関与する複雑な金融取引を管理するために使用できます。
サプライチェーン管理： Sagaパターンは、製造業者、流通業者、小売業者など、サプライチェーン内の複数のエンティティにまたがる活動を調整するために使用できます。
医療システム： Sagaパターンは、患者記録を管理し、異なる部門やプロバイダー間のケアを調整するために使用できます。

例：グローバルな銀行取引

異なる国に所在し、さまざまな規制やコンプライアンスチェックの対象となる2つの異なる銀行間のグローバルな銀行取引を想像してみてください。Sagaパターンは、トランザクションが定義されたステップに従うことを保証できます：

取引開始： 顧客は、銀行A（米国所在）の口座から銀行B（ドイツ所在）の受取人の口座への資金移動を開始します。
銀行A - 口座検証： 銀行Aは顧客の口座を検証し、十分な資金があるか、保留や制限がないかを確認します。
コンプライアンスチェック（銀行A）： 銀行Aは、取引がマネーロンダリング防止（AML）規制や国際制裁に違反していないかを確認するためのコンプライアンスチェックを実行します。
資金移動（銀行A）： 銀行Aは顧客の口座から引き落とし、資金をクリアリングハウスまたは仲介銀行に送金します。
クリアリングハウス処理： クリアリングハウスは取引を処理し、通貨換算（USDからEURへ）を行い、資金を銀行Bに送ります。
銀行B - 口座検証： 銀行Bは受取人の口座を検証し、アクティブで資金を受け取ることができる状態であることを確認します。
コンプライアンスチェック（銀行B）： 銀行Bは、ドイツおよびEUの規制に従って独自のコンプライアンスチェックを実行します。
口座への入金（銀行B）： 銀行Bは受取人の口座に入金します。
確認： 銀行Bは銀行Aに確認メッセージを送信し、銀行Aは顧客に取引が完了したことを通知します。

補償トランザクション：

銀行Aでのコンプライアンスチェックが失敗した場合、取引はキャンセルされ、顧客の口座は引き落とされません。
銀行Bでのコンプライアンスチェックが失敗した場合、資金は銀行Aに返還され、顧客の口座に返金されます。
クリアリングハウスでの通貨換算やルーティングに問題があった場合、取引は取り消され、資金は銀行Aに返還されます。

ツールとテクノロジー

Sagaパターンの実装を支援するいくつかのツールとテクノロジーがあります：

メッセージキュー： Apache Kafka、RabbitMQ、Amazon SQSは、コレオグラフィベースのSagaでイベントを発行および購読するために使用できます。
ワークフローエンジン： Camunda、Zeebe、Apache Airflowは、オーケストレーターを実装し、複雑なワークフローを管理するために使用できます。
イベントソーシング： イベントソーシングは、Saga内のイベントの履歴を追跡し、失敗した場合のロールバックを容易にするために使用できます。
分散トランザクションマネージャー： Atomikosなどの一部の分散トランザクションマネージャーは、複数のサービスにまたがるトランザクションを調整するために使用できます。ただし、分散環境における固有の制限のため、すべてのマイクロサービスアーキテクチャに適しているとは限りません。
Sagaフレームワーク： Sagaパターンの実装のための抽象化とツールを提供するSagaフレームワークも存在します。

Sagaパターン実装のためのベストプラクティス

Sagaパターンを効果的に実装するには、以下のベストプラクティスを考慮してください：

慎重な設計： ビジネス要件を徹底的に分析し、それに応じてSagaを設計します。参加するマイクロサービス、トランザクションのシーケンス、および補償アクションを特定します。
べき等性： すべてのトランザクションと補償トランザクションがべき等であることを保証します。
エラーハンドリング： Sagaのどの時点での障害にも対処できるように、堅牢なエラーハンドリングメカニズムを実装します。
監視とロギング： Sagaの進捗と状態を追跡するために、包括的な監視とロギングを実装します。
テスト： Sagaが正しく機能し、障害を適切に処理することを保証するために、Sagaを徹底的にテストします。
セマンティックロック： 異なるSagaによる同じデータへの同時更新を防ぐために、セマンティックロックを実装します。
オプティミスティックロック： 同時実行トランザクション間の競合を検出して防ぐために、オプティミスティックロックを使用します。
適切な実装戦略の選択： コレオグラフィとオーケストレーションのトレードオフを慎重に検討し、ニーズに最も合った戦略を選択します。
明確な補償ポリシーの定義： 補償がトリガーされる条件や実行される具体的なアクションなど、補償を処理するための明確なポリシーを確立します。

結論

Sagaパターンは、マイクロサービスアーキテクチャで分散トランザクションを管理するための強力なツールです。トランザクションを一連の小さな独立したトランザクションに分割し、障害を補償するメカニズムを提供することで、Sagaパターンはデータの一貫性を維持し、回復力があり、スケーラブルで、疎結合なシステムを構築することを可能にします。Sagaパターンの実装は複雑になる可能性がありますが、柔軟性、スケーラビリティ、回復力の面で提供される利点は、あらゆるマイクロサービスアーキテクチャにとって貴重な資産となります。

Sagaパターンのニュアンス、コレオグラフィとオーケストレーションのトレードオフ、そして補償トランザクションの重要性を理解することは、今日の複雑なビジネス環境の要求に応える堅牢な分散システムを設計および実装する力を与えてくれます。Sagaパターンを受け入れることは、最も複雑な分散トランザクションでさえも自信を持って処理できる、真に回復力がありスケーラブルなマイクロサービスアーキテクチャを構築するための一歩です。このパターンを適用する際には、特定のニーズとコンテキストを考慮し、現実世界の経験とフィードバックに基づいて実装を継続的に洗練させることを忘れないでください。