LASSIC Media らしくメディア

マイクロサービスでシステムを分割すると、注文・在庫・決済といった処理はそれぞれ別のサービスと別のデータベースに分かれます。ひとつの注文を仕上げるには、複数のサービスをまたいで処理を進める必要があります。途中のどこかが失敗したときに、全体のつじつまをどう合わせるかが設計上の悩みどころになりがちです。1つのデータベースで完結していた頃のような、単純なロールバックが使えなくなる点が、この悩みの根っこにあります。

この記事では、発注担当者やプロジェクトマネージャーの方に向けて、分散環境で整合性を保つ進め方のひとつであるサーガパターンを取り上げます。二相コミットとの違いや実装スタイル、開発会社とのレビューで押さえておきたい点を整理してお伝えします。すでにマイクロサービスへの移行を検討している、あるいは移行の途中にあるプロジェクトも少なくないでしょう。そうした現場では、注文や予約のように複数のサービスをまたぐ処理の整合性をどう設計するかが、遅かれ早かれ論点になるはずです。

サーガパターンとは

サーガパターンとは、複数のサービスにまたがる一連の処理を、小さな処理の連なりとして進め、途中で失敗したら、それまでの処理を打ち消す補償処理を実行して全体のつじつまを合わせる進め方です。

マイクロサービスでは、サービスごとに専用のデータベースを持つ構成が一般的で、各サービスは自分のデータを自分だけで管理します^*1。注文・在庫・決済のように複数のサービスをまたぐ処理では、ひとつのデータベース内で完結する通常のトランザクションが使えません。

1つのデータベースを全サービスでロックしてから一斉に確定するのが、二相コミット（2PC）です。サーガパターンはこれとは対照的に、各サービスの処理をその都度ローカルに確定させながら進める考え方になります^*2。二相コミットの詳細な仕組みは別記事に譲り、ここではマイクロサービスに向いた結果整合の進め方を中心に見ていきます。

具体例で考えてみましょう。ECサイトの注文処理を例に考えます。注文サービスが受注データを登録し、在庫サービスが商品を確保し、決済サービスが代金を確定し、配送サービスが出荷を手配する、という流れが一般的です。1つのデータベースで完結する従来型のシステムであれば、これらの更新をひとつのトランザクションでまとめて確定できます。

ところが、サービスごとにデータベースが分かれていると、複数のデータベースをまたいで一括に確定する手段を、通常のトランザクション機能だけでは用意できません。もともとマイクロサービスは、サービスごとに開発チームを分け、それぞれが独立してリリースできる体制を目指して採り入れられる構成です。データベースも分けることでその独立性を保っている以上、整合性の保ち方も、単一のデータベース前提の発想から切り替える必要が出てくるのです。

二相コミットとの違い

二相コミットとサーガパターンの違いは、整合性の保ち方とロックの有無に表れます。二相コミットは、全参加者の準備が整うまで待ってから一斉に確定する同期的な仕組みです。サーガパターンは各処理をそのつど確定し、失敗したときだけ補償処理で取り消す仕組みになります。

二相コミットでは、コーディネーター役が参加する全サービスに準備の可否を問い合わせ、全員が準備できて初めて確定を指示します。準備が整うまでの間は、対象のデータがロックされたままになります。参加するサービスの数が増えるほど、あるいはネットワーク越しのやり取りに時間がかかるほど、ロック待ちが長引きやすくなるのです。

サーガパターンはこのロックを避け、各サービスがそれぞれの持ち場でいったん処理を確定させてしまいます。その代わり、後から失敗が判明した場合は、確定済みの処理を打ち消す補償処理を自分たちで用意しておく必要があります^*1。従来のトランザクションモデルに依存するアーキテクチャは、サービス間の結合が強くなりやすい傾向があります。そのため、マイクロサービスの構成ではサーガパターンのほうが選ばれやすくなります^*1。設計の重心が、ロックによる待ち合わせから、補償処理という後始末の設計へ移る、と捉えるとイメージしやすいでしょう。

どちらが優れているという単純な話ではありません。強い整合性を優先するか、サービスの独立性と可用性を優先するかという、設計方針の選び方の違いだと捉えておくとよいでしょう。マイクロサービスでシステムを分割する時点で、後者の考え方に寄せるプロジェクトが少なくありません。

たとえば、複数の口座間で資金を移動する勘定系のように、ひとつでも不整合が許されない処理では、強い整合性を優先して二相コミットに近い仕組みを選ぶ判断が成立します。一方、ECサイトの注文処理のように、一時的な不整合を許容しつつ止まらずに動かし続けることを優先する場面では、サーガパターンのほうが実務に合いやすいでしょう。どちらを選ぶかは、業務がどこまで整合性のずれを許容できるかという要件と表裏一体の判断になります。

サーガの2つの実装スタイル

サーガパターンを組み立てるやり方には、コレオグラフィとオーケストレーションという2つの実装スタイルがあります^*1。どちらを選ぶかによって、処理の流れの追いやすさや、実装・保守にかかる手間が変わってきます。以下の図は、注文受付から在庫確保、決済処理へと進む流れの途中で決済が失敗し、在庫確保を打ち消す補償処理が逆向きに走る様子を表したものです。

図のように、決済に失敗した場合の補償処理は、失敗した決済そのものを戻すのではなく、その手前で確定していた在庫確保を打ち消す形で実行されます。どの範囲まで補償処理を連鎖させるかは、コレオグラフィとオーケストレーションのどちらを選ぶ場合でも、サーガの設計時にあらかじめ決めておく必要があります。

コレオグラフィ｜サービス同士がイベントで連鎖する

コレオグラフィは、中心となる調整役を置かず、各サービスがイベントを発行・購読しながら連鎖して動くやり方です。あるサービスが処理を終えるとイベントを発行し、それを受け取った次のサービスが自分の処理を始めます。

関わるサービスの数が少なく、流れがシンプルなワークフローに向いており、調整のための余分な仕組みを持たずに済む点が利点です^*1。一方で、新しい手順を追加するたびに複数のサービスの実装を見直すことになりやすいのが難点です。どのサービスがどのイベントに応答するのかを追いにくくなる、という点にも注意が要ります。サービス同士が互いのイベントに反応し合う構成になりやすいため、循環した依存関係が生まれるおそれもあります。

実装にあたっては、サービス間でイベントをやり取りするメッセージング基盤をあらかじめ用意しておく必要があります。どのサービスがどのイベントを発行し、どのサービスがそれを受け取るのかを一覧にして管理しておくことも欠かせません。そうしないと、サービスの数が増えたときに全体像を把握しづらくなるのです。

オーケストレーション｜調整役が手順を指示する

オーケストレーションは、オーケストレーターと呼ぶ調整役のサービスを置き、各サービスに実行すべき処理を順番に指示するやり方です。オーケストレーターは各ステップの状態を保持し、失敗が起きたときの補償処理の呼び出しもあわせて受け持ちます^*1。

関わるサービスが増え、処理の分岐が複雑になるワークフローほど、オーケストレーションのほうが流れを追いやすくなります。責任がオーケストレーターに集まる分、各サービスの実装はシンプルに保てるでしょう。その代わり、調整ロジック自体の実装が新たに必要になり、オーケストレーターが止まればワークフロー全体の指示役が失われる点には注意が要ります。

実装にあたっては、オーケストレーターの状態をどこに永続化するかを決めておく必要があります。オーケストレーター自体に障害が起きた場合に、どこから処理を再開するかもあわせて設計しておきましょう。オーケストレーター自体を二重化するなど、指示役が単一障害点にならないための工夫も検討したいところです。

選び方の目安

実務では、関わるサービスの数がおおむね2〜3程度にとどまり、チームの持ち場もはっきり分かれているなら、コレオグラフィで様子を見る選択が現実的です。サービスが4つ以上に増えたり、分岐条件や再試行のルールが複雑になったりする場合もあるでしょう。そうした場合は、オーケストレーションを軸に据えて調整ロジックを一箇所にまとめておくほうが、後からの変更に耐えやすくなります。

途中で実装スタイルを乗り換えるのは容易ではないため、システムの育ち方を見込んだうえで、はじめの設計段階でどちらに寄せるかを決めておくことが大切です。

補償処理の難所

サーガパターンの運用で労力がかかりやすいのは、補償処理の設計そのものです。実装スタイルをコレオグラフィとオーケストレーションのどちらにしても、この難所は共通して立ちはだかります。ここでは、レビューの際につまずきやすい3つの難所を挙げます。

取り消せない処理への対処

確認メールの送信や商品の出荷のように、一度実行すると取り消せない処理が途中に含まれると、単純な巻き戻しでは対応できません。こうした処理はピボットトランザクション（それを境に取り消しがきかなくなる、サーガの分岐点となる処理）と呼ばれます^*1。そこを過ぎた後に失敗が起きた場合、後続のすべての処理を完了させる方向でしか収拾がつかなくなるのです。

在庫確保の補償処理に漏れがあると、実際には売り切れている商品が販売可能な状態のまま残ってしまい、後続の注文で二重販売や過剰な出荷につながりかねません。取り消せない処理には、巻き戻しではなくキャンセル通知や返品対応のような是正の手続きをセットで設計しておく必要があります。

たとえば、出荷指示をすでに配送業者へ送信した後で決済が失敗した場合、出荷指示そのものを取り消すことはできません。この場合は、配送を止める追加の連絡や、届いた商品を返品してもらう手続きなど、後追いで収拾をつける設計をあらかじめ用意しておく必要があります。

二重実行を防ぐ冪等性

ネットワークの瞬断などでメッセージの再送が起きると、同じ処理が二度呼び出されることがあります。冪等性（同じ処理を何度実行しても結果が変わらない性質）を、各サービスの処理と補償処理の両方に持たせておく必要があります^*1。持たせていないと、同じ注文が二重に確定したり、同じ補償処理が重ねて実行されて在庫数がずれたりするおそれがあるのです。

対応としては、それぞれの処理に一意の識別子を持たせ、同じ識別子の処理は二度目以降を素通りさせる仕組みを組み込むのが一般的です。決済のように金銭が絡む処理では、この冪等性の担保が運用の安定を左右する要になります。

途中状態が一時的に見えてしまう点

サーガパターンは、各ローカルトランザクションを順番に確定させながら進みます。そのため処理の途中では、一部のサービスだけ更新が終わった状態が一時的に外から見えることがあるのです。これは結果整合性（処理の途中では一時的にずれが生じても、最終的にはつじつまが合う状態に落ち着くという考え方）の裏返しでもあります。

在庫が確保されたのに決済がまだ終わっていない状態を、別の処理が読み取ってしまう、いわゆるダーティリードが起きる余地も残ります^*1。対策としては、在庫確保の段階で「確保済みだが決済は未完了」という中間の状態を明示的に持たせる設計が考えられます。決済が終わるまでは、この状態を他の処理から見えにくくしておくとよいでしょう。アプリケーションレベルの排他制御や、更新の順序を工夫する対策とあわせて検討することが求められます。

発注・レビューで押さえる点

サーガパターンそのものを一から作り込む場面は、実のところ多くはありません。開発会社に実装を任せる場合も、発注担当者やプロジェクトマネージャーがレビューで押さえておきたい観点を挙げます。設計書だけを眺めていても難所は見えにくいため、次の4つの観点を軸に、具体的な処理名を挙げながら確認していくとよいでしょう。

本当に分散トランザクションが要るか

まず疑うべきは、そもそも複数のサービスをまたぐ処理そのものが避けられないか、という点です。1つのサービス内で処理が完結する設計に見直せるなら、サーガパターンの補償処理を組み立てる手間そのものが要らなくなります。

補償処理を漏れなく設計できているか

設計書やRFPのレビューでは、各処理ステップに対応する取り消し・是正の手順が、もれなく用意されているかを確認したいところです。取り消せない処理が含まれる場合は、その処理に対する是正手続きが個別に設計されているかもあわせて見ておくとよいでしょう。

途中状態をどこまで許容できるか

結果整合性を前提にする以上、処理の途中でデータの整合が一時的に崩れる時間帯が生じます。この時間帯をどこまで業務として許容できるかは、開発会社だけで決められる話ではなく、現場や経営を含めた事前の合意が欠かせません。

監視・追跡の体制

サーガの各ステップがどこまで進み、どこで止まっているかを追跡できる仕組みは、運用に入ってからの実務を左右します^*1。障害発生時にどのサービスで補償処理が止まっているかをすぐに把握できるかどうかは、監視の設計段階で決まってしまいます。サーガの各ステップに共通の識別子を持たせてログをたどれるようにしておくと、障害発生時にどこで処理が止まっているかを追跡しやすくなるでしょう。

契約・体制で確認したい点

サーガパターンを採用したシステムでは、要件定義の段階で対象となる処理をすべて洗い出しておく必要があります。どの処理に補償処理が要るかを一覧にしておくことが、後工程の手戻りを減らします。開発会社に実装を任せる場合も、この一覧を発注者側でも把握しておくと、レビューの精度が上がるはずです。運用に入った後の保守も見据え、補償処理の追加や見直しをどちらの体制で担うのかを、契約の段階で明確にしておくとよいでしょう。サービスの追加や仕様変更のたびに、この一覧を更新し続ける運用ルールも、契約時にあわせて決めておくと後々の抜け漏れを防げます。

サーガパターンを内製で組み立てるには、各サービスのトランザクション設計に加えて、補償処理のロジックが要ります。冪等性を担保する仕組みや、失敗を追跡する監視の仕組みといった知識もそろって、初めて形になるのです。内製で対応する場合は、これらを1つずつ設計・実装し、サービスが増えるたびに保守し続ける体制を自社の中に置くことになるでしょう。設計段階から開発パートナーに加わってもらう場合は、実装パターンの知見を活かせます。補償処理の漏れや冪等性の担保といった、詰めが甘くなりやすい部分を、要件定義の段階から具体化しやすくなるでしょう。

まとめ

本稿では、サーガパターンの基本的な考え方から、二相コミットとの違い、2つの実装スタイル、補償処理の難所、発注・レビューで押さえたい点までを整理しました。要点を3つに集約すると、次の通りです。第一に、サーガパターンはロックを使わず各処理をその場で確定させながら整合を合わせる進め方だという点です。第二に、コレオグラフィとオーケストレーションという実装スタイルの選択は、関わるサービスの数と流れの複雑さで判断するという点になります。第三に、補償処理の設計漏れと冪等性の担保が、運用に入ってからの安定を左右する点でしょう。

• サーガパターンは、複数のサービスにまたがる処理を小さく分けて進め、失敗時は補償処理で打ち消して整合を合わせる進め方である。全体を一括で確定する仕組みは持たない。
• 全参加者を一斉にロックして確定する二相コミットとは異なり、各サービスの処理をその場でローカルに確定させながら進める。
• コレオグラフィとオーケストレーションという2つの実装スタイルがあり、関わるサービスの数や流れの複雑さで選び方が変わる。
• 取り消せない処理への対処、冪等性の担保、途中状態の許容が、補償処理の設計における難所になる。設計の早い段階で洗い出しておきたい。
• 発注・レビューでは、分散トランザクションが本当に要るか、補償処理に漏れがないかを起点に確認するのが実務的である。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• Microsoft Learn「Saga のデザイン パターン」（Azure Architecture Center）
• microservices.io「Saga」パターン解説
• Wikipedia「Compensating transaction」

Tweet