Orchestration

従来のモノリシック アプリケーションでは、複数のエンティティ間でデータの一貫性を維持するのは簡単です。リレーショナル データベース エンジンは、ローカル SQL トランザクション内にラップされた ACID (原子性、一貫性、分離性、耐久性) 保証を提供します。注文の発注、支払いの差し引き、または在庫の予約が途中で失敗した場合、ROLLBACK を呼び出すと、データベースのすべての変更が即座に元に戻されます。 ただし、最新の マイクロサービス アーキテクチャ に移行すると、データ管理が根本的に変わります。ドメインの自律性と独立したスケーラビリティを確保するために、各マイクロサービスはプライベート データベースを所有します。電子商取引のチェックアウトの処理などの 1 つのビジネス操作が、複数のサービス境界とデータベース エンジン (注文の PostgreSQL、支払いの DynamoDB、在庫の Redis など) にまたがるようになりました。 分散マイクロサービスは単一のデータベース トランザクションに依存できないため、ネットワーク境界を越えてデータの一貫性を維持することは、分散システム エンジニアリングにおいて最も困難な問題の 1 つになります。 システムの可用性やパフォーマンスを犠牲にすることなくこれを解決するために、ソフトウェア アーキテクトは Saga パターン を利用します。 この詳細な説明では、従来の分散トランザクションが失敗する理由を調査し、Saga パターンの中核的な仕組みを分析し、コレオグラフィーとオーケストレーションを比較し、分離対策を分析し、Go と Java での実稼働コードの実装を調査し、実際の障害ロールバックを安全に処理する方法を学びます。 根本的な問題: マイクロサービスで 2 フェーズ コミット (2PC) が失敗する理由 Saga パターンを採用する前に、エンジニアはよく次のような質問をします: マイクロサービス全体で従来の 2 フェーズ コミット (2PC / XA)​​ を使用できないのはなぜですか? 2PC の仕組み 2 フェーズ コミットは、中央のトランザクション マネージャーを使用して、複数のデータベース ノードにわたる分散トランザクションを 2 つのフェーズで調整します。

大規模言語モデル (LLM) は、私たちがテクノロジーと対話する方法を変革し、単純な会話型チャットボットから、複雑な複数ステップのアクションを実行できる推論エンジンへと急速に移行しました。単一のプロンプト応答インタラクションは強力ですが、企業環境における生成 AI の真の価値は 自律 AI ワークフローにあります。 人間のオペレーターに依存してすべてのステップを調整するのではなく、自律型ワークフローは、長期間にわたってタスクを計画、実行、評価、自己修正する中心的な意思決定者として LLM を使用します。 この詳細な説明では、最新の設計パターン、ステート マシン、堅牢なガードレールを使用して、信頼性の高い自律型 AI ワークフローを設計、構築、展開する方法を探ります。 1. エージェントの変化: チャットボットとワークフロー LLM アプリケーションの進化は、自律性の 4 つの異なるレベルに分類できます。 レベル パラダイム 人間の役割 コアメカニズム レベル 1 会話型チャット 高 (毎ターンプロンプトが表示されます) ステートレスな 1 ターンの完了 レベル 2 ツール呼び出し / 関数呼び出し 中 (コンテキストを提供) モデルは呼び出す API を選択します。結果を返します レベル 3 指示されたワークフロー 低 (目標とグラフを定義) LLM ルーティングを備えたハードコーディングされたステート マシン レベル 4 完全自律型エージェント 最小限 (目的/予算を定義) LLM 主導の計画、実行、およびリフレクション ループ レベル 4 エージェントは柔軟性に優れていますが、運用環境での予測が難しいことで知られています。したがって、ほとんどのエンタープライズ アーキテクチャは、ソフトウェア ステート マシンの決定論的な信頼性と LLM の動的な推論を組み合わせた レベル 3: 指示されたワークフロー に基づいて構築されています。