Sagaパターンは、可逆的なホームAIアクションをどのように調整するのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does a Saga Pattern Coordinate Reversible Home AI Actions? - Zima Store Online

サガは、ホームAIの可逆的なアクションを調整します。1つのワークフローを順序付けられた複数のステップに分割し、後のステップが失敗した場合に補償アクションを実行します。

これは、1つのトランザクションを共有できない複数の独立したサービスにエージェントがアクセスする場合に役立ちます。ワークフローは進行状況を記録し、失敗した地点を検出して、元に戻せるステップを意図的に巻き戻します。

サガは1つのホームアクションを複数のローカルステップに分割する

サガは、各ステップをローカルトランザクションまたは副作用として扱うことで、独立したシステムにまたがるワークフローを調整します。必要なステップが完了して初めて、操作全体が成功します。

サガパターンは、メッセージまたはオーケストレーションを通じて調整されるローカルトランザクションの連続として定義されます。1つのグローバルなACIDトランザクションで、すべての参加者を包括できない場合に有用です。サガパターンは大きなトランザクションを一連のローカルトランザクションに分解します。この考え方は、サガパターンの概要にあるように、複数ステップのホームアクションに自然に対応します。

ホームAIのワークフローでは、メディアサービスを停止し、ライブラリを移動し、マウントを更新し、メタデータを更新して、サービスを再起動することがあります。

ワークフロー全体はアトミックではありませんが、各コンポーネントはローカルにコミットします。

可逆的な各ステップが補償アクションを定義する

サガでは、1つのデータベースコマンドですべてのサービスをロールバックすることはありません。元に戻せるステップでは、以前の処理を意味的に復元または相殺する補償アクションを定義します。

Microservices.ioでは、失敗が発生すると、完了済みのステップに対して補償トランザクションが実行されると説明されています。補償は履歴を消去するのではなく、一貫性を復元します。Azureは可逆的なサガのステップに対する補償アクションを説明しており、Azureサガパターンで使われる補償モデルを支えています。

MoveFileはMoveFileBackで補償でき、DisableShareはEnableShareで補償できます。一部の外部アクションには完全な逆操作が存在しない場合があるため、それに応じて記録する必要があります。

オーケストレーターは順方向と逆方向の順序を決定できる

オーケストレーションベースのサガでは、1つのワークフローコンポーネントが順序を把握し、コマンドを送信し、応答を記録して、処理を続行するか補償を開始するかを決定します。

Microservices.ioでは、サガオーケストレーターがステップと補償を呼び出す仕組みが示されています。独立したリアクションが網状に連携する構成よりも、中央のステートマシンのほうが、ホームサーバー上で監査しやすいことがよくあります。Temporalのサガに関するガイダンスでは、オーケストレーターが補償を登録し、後のステップが失敗したときに呼び出す方法が示されており、Temporalサガパターンにある逆順の調整と一致します。

後のステップが失敗した場合、通常は依存関係と逆の順序で補償を実行します。

ファイルを移動した後にマウントを変更した場合、ワークフローはデータを元に戻す前にマウントを復元する必要があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

コレオグラフィーはイベント間で調整を分散する

コレオグラフィーベースのサガでは、各参加者がイベントに反応して次のイベントを発行します。これにより中央のコーディネーターは不要になりますが、ワークフローのロジックはサブスクライバー間に分散されます。

サガパターンでは、コレオグラフィーとオーケストレーションが明確に区別されています。どちらも補償を調整できますが、可観測性は異なります。AWSはオーケストレーションとイベント駆動型コレオグラフィーを区別しており、AWSのサガオーケストレーションで説明されている調整方法のトレードオフを支えています。

小規模なセルフホスト型ワークフローでは、オーケストレーションのほうが確認しやすいことがよくあります。独立したサービスがすでにイベントバスを介して通信しているシステムでは、コレオグラフィーも適しています。

補償には冪等性と安定したアクション識別子が必要

タイムアウトやクラッシュの後に補償が再試行されることがあるため、再実行しても安全であるか、対象の状態がすでに復元されていることを検出できる必要があります。

サガモデルは、明示的なローカルトランザクションと補償トランザクションのセマンティクスを前提とします。安定したワークフローIDとステップIDは、再試行と重複実行を区別するのに役立ちます。IBMのサガに関するガイダンスは、ローカルトランザクションと補償動作を強調しており、IBMのサガ実装ガイダンスで説明されているように、再試行と補償に安定した識別子と冪等な実行が必要な理由を裏付けています。

これは、ZimaSpaceのエージェントによるツール呼び出しループの繰り返しにも関連します。復旧ワークフローは、安全に再開しているのか、それとも副作用を繰り返しているのかを把握しなければなりません。

サガですべてのアクションを完全に可逆化できるわけではない

家庭内のアクションには、外部に対して不可逆な結果をもたらすものがあります。

配信済みのメッセージ、安全に消去したファイル、第三者への購入などは、逆のAPI呼び出しだけでは常に取り消せるとは限りません。

サガは、分散ロールバックを普遍的に実行するのではなく、補償に依存します。そのため、不可逆なステップは後半に配置し、慎重にゲートする必要があります。Red Hatによる分散トランザクションパターンの解説は、補償が普遍的なロールバックではなく、ビジネスレベルの是正処理であることを強調しており、Red Hatの分散トランザクションパターンでその境界を示しています。

ZimaSpaceの読み取り専用を優先するエージェント戦略は、観察から変更へと進む、より安全な手順を提供します。サガはその後、意図的に許可された変更を調整します。