本サイトは広告により収益を得ています

分散システムとトランザクション管理(CAP定理、Sagaパターン)

分散システムとトランザクション管理(CAP定理、Sagaパターン)

2025年11月10日
フリー検定
広告

目次

現在: 2 / 12

バックエンドエンジニアに関する検定はこちら

面倒な会員登録も不要!すぐに受験!

無料で受験する

エキスパートエンジニアにとって、複数のコンピューターやサービスが連携して動作する分散システムの設計は必須のスキルです。分散システムでは、モノリシックなシステムでは存在しなかった、一貫性や信頼性に関する根本的なトレードオフに直面します。この章では、その理論的限界を示すCAP定理と、複数のサービスにまたがる処理の整合性を保証するためのSagaパターンについて解説します。


1. 分散システムの根本的な課題:CAP定理

CAP定理は、分散システムにおいて、以下の3つの特性のうち、同時に3つ全てを完全に満たすことは不可能であり、最大で2つまでしか選択できないという理論的限界を示すものです。

A. 3つの特性

  1. 一貫性 (Consistency: C):

    • システムに対する全ての読み取り操作が、最新の書き込みデータまたはエラーを返すことを保証します。

    • どのノード(サーバー)にアクセスしても、同じデータ(最新の値)が見える状態です。

  2. 可用性 (Availability: A):

    • システムに障害が発生したノードが存在しても、常にリクエストに対する応答(成功または失敗の応答)を返すことを保証します。

    • システムがダウンすることなく、常に動作し続ける能力です。

  3. 分断耐性 (Partition Tolerance: P):

    • 分散システム内のノード間がネットワークの障害(分断)によって通信できなくなった状態でも、システムが動作し続けることを保証します。

B. トレードオフの現実

現実のインターネット環境ではネットワーク障害(分断)は避けられないため、分断耐性 (P) を放棄することは事実上不可能です。したがって、分散システム設計では、一貫性 (C)可用性 (A) のどちらを優先するかというトレードオフを選択することになります。

  • CP (一貫性優先):

    • ネットワークが分断された際、データの一貫性を保つため、古いデータを保持している可能性があるノードへのアクセスを拒否します。その結果、利用できなくなるノードが発生し、可用性が損なわれます。(例: 厳密な金融取引システム)

  • AP (可用性優先):

    • ネットワークが分断されても、システムは応答を続けます。その結果、ノード間でデータが同期されず、一時的に古いデータが読み込まれる可能性が生じ、一貫性が損なわれます。(例: SNSのいいね!カウンター、ECサイトの商品情報)


2. 分散トランザクション管理の必要性

モノリシックシステムでは、単一のデータベースに対するローカルトランザクション(ACID特性)によってデータの整合性が保証されます。しかし、マイクロサービスでは、一つのビジネス処理が複数のサービスと、それぞれの独立したデータベースにまたがって実行されます。

この**「複数の独立したデータベースにまたがる処理」の整合性を保証するメカニズムが、分散トランザクション管理です。従来の二相コミット (2PC)** は、ネットワーク障害に弱く、長時間ロックが発生するため、マイクロサービスでは一般に採用されません。


3. Sagaパターンによる整合性の確保

マイクロサービスアーキテクチャでは、結果整合性 (Eventual Consistency) を許容し、Sagaパターンを用いて分散トランザクションを実現することが主流です。Sagaパターンは、一連のローカルトランザクションと、それに対応する補償トランザクションで構成されます。

A. Sagaパターンの仕組み

Sagaは、ビジネス処理全体を構成する複数のステップを定義し、各ステップが個々のサービス内でローカルトランザクションを実行します。

  1. 処理の開始: 最初のサービスがローカルトランザクションを実行し、イベント(メッセージ)を発行して次のサービスをトリガーします。

  2. 連鎖: イベントを受け取った次のサービスがローカルトランザクションを実行し、さらに次のイベントを発行します。これを処理が完了するまで繰り返します。

B. 失敗時の対応:補償トランザクション

Sagaの途中のステップで失敗が発生した場合、それまでに完了したすべてのローカルトランザクションを元に戻す必要があります。

  • 補償トランザクション (Compensating Transaction): 各ローカルトランザクションには、その効果を取り消すための補償処理が定義されています。(例: 注文サービスでの「注文作成」の補償処理は、在庫サービスでの「在庫確保」を取り消す「在庫解放」です。)

  • 失敗が検知されると、Sagaは開始サービスから逆順に補償トランザクションを実行し、システムをビジネス上整合の取れた状態に戻します。

C. Sagaの調整方式

Sagaを管理する方法には、主に以下の2種類があります。

  1. オーケストレーション (Orchestration):

    • 中央集権型: 専用のSagaオーケストレーターサービスが、トランザクションの流れと参加サービスへの指示を集中管理します。

    • メリット: 制御ロジックが単一箇所にまとまるため、複雑なワークフローを管理しやすいです。

  2. コレオグラフィ (Choreography):

    • 分散型: 各サービスが**イベントブローカー(メッセージキュー)**を介してイベントを購読・発行し、自律的に次のステップを判断します。サービス間に直接的な依存関係がありません。

    • メリット: サービス間の結合度が最も低く、柔軟性と拡張性に優れます。

エキスパートエンジニアは、CAP定理に基づきシステムの要件に合った一貫性と可用性のバランスを選択し、特に複数の独立したデータストアを持つマイクロサービス環境において、Sagaパターンなどの高度な手法を用いてデータの整合性を保証する設計を行う必要があります。

バックエンドエンジニアに関する検定はこちら

面倒な会員登録も不要!すぐに受験!

無料で受験する
広告

検定一覧はこちらから

様々なジャンルの検定から選んで、あなたの知識を試してみましょう。

検定一覧を見る

関連記事

広告