H. ガルシア-モ​​リーナと K. セーラム。1987年。サガ。1987 年のデータ管理に関する ACM SIGMOD 国際会議議事録 (SIGMOD '87)。Association for Computing Machinery、米国ニューヨーク州ニューヨーク、249–259。

キーワード:長時間実行プロセス、サーガ、トランザクション、補償、障害軽減、障害許容性、障害の透明性

サガスに関する元の論文は 35 年前に書かれましたが、この問題は今日でも同様に関連性があります。この投稿では、複数のデータベース トランザクションにまたがる長時間実行プロセスである Saga の概念の起源を探ります。

序章

ヘクター・ガルシア＝モリーナとケネス・セーラムは、 論文「サーガ」の中で、「長期にわたる」作戦を実装するためのサーガの概念を紹介しています。

Molina と Salem は、単一のステップで構成されるプロセスを「短期実行」または「短期」プロセスと呼び、複数のステップで構成されるプロセスを「長期実行」または「長期」プロセスと呼びます。したがって、短時間実行または長時間実行は、物理時間に関するステートメントではなく、各ステップがクロック ティックである論理時間に関するステートメントです (図 1)。

問題

分散トランザクションや長期間ロックを保持するという考えをほとんど拒否するエコシステムでは、長時間実行されるプロセスを単純に長時間実行の分散トランザクションにマッピングすることはできません。代わりに、短時間実行される非分散トランザクションから長時間実行されるプロセスを構成するための別のメカニズムが必要です。

この論文では、プロセス P を一連のステップ a、b などとして定義しており、各ステップはデータベース トランザクションです。より馴染みのある用語を使用すると、プロセスを関数として、一連のステップをデータベースに対する一連の API 呼び出しとして考えることができます。

一連のステップ a、b などをトレースと呼びます。

trace(P) = a • b • …

言い換えれば、一連の 2 つのトランザクションはトランザクションではありません。

当然のことですが、プロセスが単一のトランザクションで構成されている場合、そのプロセスはトランザクションのアトミック性を保証します (図 3)。

ただし、プロセスが複数のトランザクションで構成されている場合、プロセスはトランザクションのアトミック性を保証しません。プロセスは部分的に実行される可能性があります (図 4)。

ただし、他のトランザクションとは異なり、プロセスのトランザクションは関連しており、1 つの単位として実行する必要があり、プロセスの部分的な実行は望ましくありません。

この論文では、旅行が異なる航空会社の複数のフライトで構成される旅行予約アプリケーションについて説明します。ここで、旅行の予約には、旅行行程ごとに 1 つずつ、複数のトランザクションが含まれます。旅行者として、私たちはすべてのトランザクションが 1 つの単位として実行されることを望んでいます。すべてのフライトを予約するか、フライトを予約しないかのどちらかです。一部のフライトの予約は受け入れられません。

ソリューション

この論文では、長時間実行プロセスを実装するためのプロトコルである Sagas を紹介します。Saga プロトコルは、プロセスがアトミックであること、つまりプロセスが完全に実行されるか、まったく実行されないのと目に見えて同等であることを保証します。

部分的な実行を軽減するために、プロセスは前方回復または後方回復のいずれかを実装できます [2]。

前方回復

前方障害回復とは、システムを中間状態から最終状態と同等の状態に遷移させる (プロセスを前方に進める) 障害軽減戦略を指します。

逆方向回復

逆方向障害回復とは、システムを中間状態から初期状態と同等の状態に遷移させる (プロセスを逆方向に進める) 障害軽減戦略を指します。

過去の回復と補償

逆方向回復を有効にするには、各プロセスがステップごとに補償ステップを登録する必要があります (図 6)。

補償ステップは、セマンティックな観点からステップを元に戻しますが、ステップの開始時にデータベースが存在していた状態に必ずしも戻すわけではありません。補償により、ワールドはトランザクションの開始前の状態に近い、許容可能な状態に復元されます。

たとえば、旅行予約アプリケーションに戻ると、旅行が 2 つのフライトで構成されており、最初のフライトの予約は成功したが、2 番目のフライトの予約が失敗した場合、データベースを許容可能な近似値に戻すために最初の予約をキャンセルする必要があります。それは旅行の予約を開始する前でした。

実行

したがって、障害がなければ、プロセスP は目的のトレースを生成します。

trace(P) = s₁ • s₂ • … sₙ • ✔️

trace(P) = s₁ • s₂ • … sᵢ • × • cᵢ … • c₂ • c₁ • ✔️

障害によって Saga が中断された場合、Saga は現在の状態を回復し、順方向または逆方向の回復を実行できなければなりません。したがって、サーガは、サーガの開始、サーガの完了を記録し、チェックポイントと補償を記録できなければなりません。

データベースを所有している場合は、各ステップでトランザクション的にチェックポイントと補正を記録できます。各ステップでチェックポイントと補正をトランザクション的に記録できない場合は、チェックポイントの補正を確実に記録するメカニズムを考案する必要があります。

議論

この論文は 35 年以上前に書かれたものですが、この問題と提案された解決策としてのサガは今日でも有効です。ただし、注目はデータベース トランザクションの作成からサービス呼び出しの作成に移ってきています。

サービスはトランザクション特性を示さないことに注意してください。サービス呼び出し後、サービスはアトミックではない可能性があり、サービスがクラッシュした場合、サービスが有効になったかどうかがわからない場合があります。

したがって、サービスを呼び出す前に補償アクションを登録し、サービスが有効かどうかに関係なく正しく補償ロジックを設計する必要があります。

結論

この論文の出版以来、理論と実践において大きな進歩があったにもかかわらず、サーガは依然として関連性を保っています。トランザクションまたはサービスにわたる分散環境でアトミック性を実装するためのプロトコルとしての Saga の基本概念は、論文で説明されている技術であり、現在でも広く使用され続けています。

参考文献

• [1] 長時間実行トランザクションのトレース セマンティクス、M. Butler、CAR Hoare、C. Ferreira、2005 年
• [2]第一原則に基づく失敗の処理、Dominik Tornow、2022 年