2 種類のロールバック、2 種類の考え方
Agent プロジェクトでは、ロールバックは単純な「元に戻す」ではありません。実行に失敗したバックグラウンド タスクを処理する必要がある場合、またはワークフロー例外を復元する必要がある場合、バックグラウンド モード ロールバックとエージェント ワークフロー監査ログ ロールバックという 2 つの主流のソリューションが目の前にあります。名前は似ていますが、適用される境界と故障モードはまったく異なります。
適用可能なオブジェクト: 誰が使っても恩恵を受けます
バックグラウンド モードのロールバックは誰に適していますか?
タスクが、通知の送信、ファイル形式の変換、キャッシュの定期的なクリーニングなど、ステートレスで再入可能な短期のバックグラウンド操作である場合は、バックグラウンド モードのロールバックが適しています。通常、タスク キューの再試行メカニズムに依存します。失敗後は、成功するか再試行回数を超えるまで、事前に設定された戦略 (指数バックオフなど) に従って再実行されます。
典型的なシナリオ: バッチ画像圧縮のバックグラウンド ジョブ。特定のイメージの圧縮に失敗した場合、ロールバックでは、すべての圧縮イメージを元に戻すのではなく、このイメージを再圧縮します。
エージェント ワークフロー監査ログのロールバックは誰に適していますか?
ワークフローに複数のステップの操作、状態の変更、リソースの割り当てが含まれており、各ステップがログに記録される場合は、監査ログのロールバックがより適切な選択です。操作ログを再生または反転することにより、システム状態を特定のチェックポイントまで復元します。
一般的なシナリオ: 在庫控除、支払控除、物流注文の生成などの注文処理ワークフロー。支払いが失敗した後は、在庫と支払いをロールバックする必要があります。監査ログには各ステップの入力と出力が記録され、実行されたステップを正確に元に戻すことができます。
比較の次元: 主要な違い
| 寸法 | バックグラウンド モードのロールバック | エージェント ワークフロー監査ログのロールバック |
|---|---|---|
| ロールバックの粒度 | タスク レベル: タスク全体を再実行またはスキップできます。ステップ レベル: 任意のログ チェックポイントにロールバックできます。 | |
| 状態の依存関係 | ステートレスまたはべき等 | 依存性の高いログ内の状態スナップショット |
| 障害対応 | 再試行または破棄 | 逆操作またはトランザクションの補正 |
| 実装の複雑さ | 低: メッセージ キュー + 再試行戦略 | 高: 監査ログ ストレージ + ロールバック エンジン |
| 一貫性の保証 | 最終的な整合性 | 強力または最終的に一貫性がある (補償ロジックに応じて) |
| 代表的なツール | Celery、Sidekiq、AWS SQS + Lambda | Temporal、Camunda、カスタム イベント ソーシング |
最も簡単な落とし穴: 障害シナリオの分析
バックグラウンド モードのロールバックの罠
- 非冪等操作は安全に再試行できません: バックグラウンド タスクが「ユーザー残高を 10 元増やす」を実行するとします。リトライ時に実行したかどうかを確認しないと増加を繰り返すことになります。現時点では、バックグラウンド モードのロールバックを直接再試行することはまったくできないため、追加の冪等キーまたは重複排除ロジックを設計する必要があります。
- 再試行によるリソースの枯渇: 依存するサービス (データベースなど) が利用できないためにタスクが繰り返し再試行されると、雪崩のようにダウンストリームがクラッシュする可能性があります。適切な再試行ウィンドウとサーキット ブレーカーを設定する必要があります。
実際の失敗例: チームはバックグラウンド モードのロールバックを使用して支払いコールバック通知を処理しました。支払いゲートウェイがタイムアウトした後、3 回再試行されましたが、実際には 1 回目で成功しました。その結果、再試行により出荷が繰り返されることになりました。
エージェント ワークフロー監査ログ ロールバックのトラップ
- ログ拡張とロールバック遅延: ログはすべてのステップで書き込まれます。長時間実行されるワークフローでは、大量のデータが生成されます。ロールバック中の再生または逆方向の操作には、予想よりも時間がかかる場合があります。チェックポイントを定期的に圧縮する必要があります。
- 補正操作の副作用: ステップが外部電子メールを送信し、ロールバック時に送信された電子メールを「元に戻す」ことができないとします。補償ロジックは「キャンセルメールを送信する」だけですが、ユーザーエクスペリエンスは損なわれています。
実際の失敗例: 複数ステップの承認ワークフローで、管理者が前のステップにロールバックしましたが、承認の意見が監査ログに記録されました。ロールバック後、承認意見が消失し、承認履歴に一貫性がなくなりました。
実行可能プラクティス: 選択および実装する方法
ステップ 1: タスクの特性を決定する
- タスクが副作用なしで繰り返し実行でき (冪等)、正確なステップ ロールバックが必要ない場合は、バックグラウンド モード ロールバックを選択します。
- タスクに順次依存関係、ステータス変更、外部副作用があり、正確なリカバリが必要な場合は、監査ログのロールバックを選択します。
ステップ 2: 混合溶液
実際のプロジェクトでは、これらを混在させることができます。バックグラウンド モードを使用して独立したサブタスクを処理し、監査ログを使用してプロセス全体を調整します。たとえば、データ処理ワークフローでは、バックグラウンド再試行はデータ クリーニングのサブタスクに使用され、監査ログのロールバックはデータの保存と通知に使用されます。
ステップ 3: 失敗に備える
- どちらを選択する場合でも、「手動バックアップ」メカニズムを設計する必要があります。自動ロールバックが失敗した場合、運用および保守担当者が介入できるように CLI またはバックグラウンド インターフェイスを提供します。
- ロールバックの頻度と失敗の理由を監視して、ロールバック自体が新たな失敗の原因になることを回避します。
次の決断
これで、2 つのロールバックの違いと適用可能な境界がわかりました。チームがエージェント ワークフローのロールバック機能を設計している場合、または通常のバックグラウンド タスクからワークフロー オーケストレーションに移行している場合、次のリソースは、エージェント エンジニアリングの核となるパターンを深く理解するのに役立ちます。
コメントはまだありません