Saga Pattern

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

Web 開発の初期の頃、ソフトウェア アプリケーションの構築は簡単でした。コードを記述し、それを単一の実行可能ファイルまたは展開可能なアーカイブにパッケージ化し、サーバー上で実行するだけでした。 モノリシック アーキテクチャとして知られるこのアプローチは、何十年にもわたって業界に役に立ちました。 しかし、アプリケーションが数百人の開発者と数百万人の同時ユーザーを抱える大規模なエンタープライズ プラットフォームに成長するにつれて、モノリスには限界が見え始めました。デプロイメントは遅くなり、リスクが高く、データベースがボトルネックになり、コードベースが複雑すぎて単一の開発者が理解できないようになりました。 これらのスケーリングのボトルネックを解決するために、業界は マイクロサービス アーキテクチャ に移行しました。開発者は、単一の巨大なアプリケーションを構築するのではなく、HTTP/REST、gRPC、メッセージ ブローカーなどの軽量プロトコルを介して通信する、小規模で独立した疎結合サービスのコレクションにシステムを分割します。 この記事では、マイクロサービスが最新のアプリケーションにもたらす主な利点、マイクロサービスによってもたらされる深刻な課題、そしてこのアーキテクチャが次のプロジェクトに適しているかどうかを判断する方法を分析します。 1. モノリシック アーキテクチャとマイクロサービス アーキテクチャ 詳細に入る前に、これら 2 つの設計パラダイムの基本的な違いを視覚化しましょう。 モノリスでは、すべてのモジュール (ユーザー管理、製品カタログ、注文処理など) が同じ実行スペースを共有し、単一の共有データベースに書き込みます。 マイクロサービス セットアップでは、各サービスが独自のプロセスで実行され、独自のプライベート データベースを管理し、クリーンな API を公開します。 API ゲートウェイ はクライアントの単一のエントリ ポイントとして機能し、リクエストを適切なバックエンド サービスにルーティングします。 2. マイクロサービスの利点 マイクロサービス アーキテクチャを採用すると、大規模な最新のシステムに推奨される選択肢となる、いくつかの魅力的な利点が得られます。 A. 独立した展開可能性とリリース速度 モノリスでは、チェックアウト システムに小さな変更をデプロイするには、アプリケーション全体を再構築して再デプロイする必要があります。 1 つのチームの機能が壊れると、リリース全体がブロックされます。 マイクロサービスでは、各サービスに独自の独立した CI/CD パイプラインがあります。配送サービス チームは、在庫チームや支払いチームと調整することなく、1 日に 10 回アップデートを展開できるため、機能の配信速度が大幅に向上します。