マイクロサービスアーキテクチャとトランザクションやDB分離に関する考察 22日目
マイクロサービスアーキテクチャと分離に関する考察
記事の概要
- マイクロサービスアーキテクチャに関する考察
- トランザクションの切り分け方法（Saga）
- データベースの分割に関しての説明
はじめに
新しいサービスを構築するための基盤が整いつつあるので、現在WEBアプリケーションの作成を進めています。今回はWEBアプリケーションという特性を活かし、MVCモデルを基本に開発を進める予定ですが、マイクロサービスアーキテクチャの概念を特に重視した設計を目指しています。
これまで多くのシステム開発に携わってきましたが、同じ企業内で類似の実装が繰り返されるケースが多く見受けられます。
例えば、複数の自社アプリケーションがそれぞれ独自のログイン機能を作っている状況です。これを共通化できるのではないかと考えています。また、会員登録処理や注文処理、配達、商品購入の処理についても、共通化が可能ではないでしょうか。
これらを個々のサービス単位でAPI化し、マイクロサービスとして提供することで、情報資産として一元的に運用・保守する仕組みを構築すれば、新しいサービスを立ち上げる際には、それらのマイクロサービスを組み合わせて利用することで、新規サービスの開発を低コストかつ迅速に進めることができると考えています。
さらに、これらのマイクロサービスを他社にも提供することで、新たな収益を生み出し、価値の創造に繋げられるのではないか、と強く考えています。
マイクロサービスアーキテクチャとは
マイクロサービスアーキテクチャは、大規模なアプリケーションを小さな独立したサービスの集合体として構築する設計手法です。各サービスは特定の機能に焦点を当てており、他のサービスとは明確に分離されています。これにより、サービスごとに独立して開発、デプロイ、スケールが可能となります。
特徴
- 疎結合: サービス間の依存性を最小限に抑える。
- 独立性: 各サービスは独自のデータベースや技術スタックを持つことができる。
- スケーラビリティ: 必要なサービスだけを個別にスケールアウトできる。
マイクロサービスアーキテクチャのメリットとデメリット
メリット
- スケーラビリティの向上: サービスごとにスケーラビリティを調整できるため、リソースの最適化が可能。
- 開発速度の向上: チームがサービスごとに分かれて並行開発できる。
- 独立したデプロイ: 他のサービスに影響を与えずに、新しい機能や修正をデプロイできる。
デメリット
- 複雑性の増加: サービス間の通信やデータ整合性の管理が複雑になる。
- トランザクション管理の困難さ: 分散システムにおける一貫したトランザクション管理が難しい。
- デバッグの難しさ: 問題の原因が分散しているため、トラブルシューティングが困難。
Sagaパターンの説明
マイクロサービス環境でのトランザクション管理の課題を解決するために、Sagaパターンが用いられます。Sagaパターンは、一連のローカルトランザクションを連鎖させ、各ステップで成功か失敗かを判断します。失敗した場合は、これまでの操作を取り消すための補償トランザクションが実行されます。
※Sagaは略称ではなく長編物語を指すそうです。
仕組み
- ローカルトランザクション: 各サービスが自分のデータベース内で完結するトランザクションを実行。
- 補償トランザクション: エラー発生時にロールバックするための処理。
- 非同期通信: サービス間の連携はイベントベースで行われる。
トランザクション管理の課題とは
マイクロサービス環境では、各サービスが独立したデータベースを持つため、1つのビジネスプロセスが複数のサービスにまたがると、トランザクション管理が困難になります。例えば、在庫を減らした後に決済処理が失敗すると、データの整合性を保つための補償処理が必要になります。
また、分散トランザクションを管理する手法は、実装の複雑化やシステムのパフォーマンス低下を引き起こす可能性があります。さらに、サービスの一部で障害が発生した場合に全体へ影響が及ぶリスクがあり、迅速な回復や管理が難しい点も課題です。
このような問題により、マイクロサービス環境ではトランザクション管理の負担が増大します。
コレオグラフィベースとオーケストレーションベースについて
コレオグラフィベース
- 特徴: 各サービスがイベントを発行・購読し、自律的に動作する。
- メリット: 柔軟性が高く、サービス間の結合度が低い。
- デメリット: 全体のビジネスプロセスを把握しづらく、トランザクション管理が複雑。
例えば、注文処理を行う場合、注文サービスは購買サービスやユーザー確認サービスなど、他のサービスと連携する必要があります。コレオグラフィベースでは、各サービスが自律的に動作し、イベントを発行・購読して処理を進めます。具体的には、注文サービスが「注文作成」というイベントを発行し、それを購買サービスやユーザー確認サービスが購読して、それぞれの処理（購買の確定やユーザーの確認など）を非同期で実行します。
このように、サービス間のトランザクションは各サービスのイベントによって連携され、全体の処理が進行する方法です。これにより、サービス間の疎結合が実現されますが、トランザクション管理が複雑になることもあります。
オーケストレーションベース
- 特徴: 中央のオーケストレーターが各サービスを制御する。
- メリット: ビジネスロジックが集中管理され、全体の流れが明確。
- デメリット: オーケストレーターへの依存が高まり、単一障害点になる可能性。
例えば、注文処理を行う場合、オーケストレーションベースでは、中央に配置された「オーケストレーター」が全体の流れを制御します。注文サービスが注文を受け付けると、オーケストレーターが購買サービスに購買の確定を指示し、その結果を受け取ります。その後、オーケストレーターはユーザー確認サービスに必要なチェックを指示し、結果に応じて次の処理を進めます。
この仕組みでは、オーケストレーターが各サービスを順次呼び出し、トランザクション全体の流れを集中管理します。例えば、購買サービスが失敗した場合、オーケストレーターが補償処理（注文のキャンセルなど）を指示することで、全体の一貫性を保つことができます。
オーケストレーションベースでは、各サービスがイベントに依存せず、オーケストレーターが明示的に制御するため、ビジネスロジックが一元化され、トランザクションの管理が明確でわかりやすくなります。ただし、オーケストレーターに依存するため、単一障害点（SPOF）となるリスクもあります。
オーケストレーションベースを推奨する理由
私はオーケストレーションベースのがよいと考えています。API同士を結合するロジックは必ず必要になるため、そのロジックで中央で管理することで、トランザクションの流れを把握しやすくなり、エラー処理やリトライ機能も実装しやすくなります。
また、ビジネスプロセスの変更にも柔軟に対応できます。結果として、トランザクションを一元的に管理でき、システム全体の信頼性が向上します。
データベースの分散方法について
マイクロサービスアーキテクチャでは、各サービスが独自のデータベースを持つことが一般的です。これにより、サービス間の独立性が保たれ、データスキーマの変更も他のサービスに影響を与えません。
しかし、この場合で疑問に思うのは分散されたデータベースからどのようにデータを取得し、削除するというトランザクション処理をどうするか、です。
データ取得の方法
API Compositionパターンを利用する。こちらは、複数のマイクロサービスからデータを取得し、それを1つの統合されたレスポンスとしてクライアントに返すパターンです。この方法は、フロントエンドが必要とするデータを効率的に取得できるように設計されています。
API Compositionパターンでは、コンポジションレイヤーと呼ばれる中間レイヤーを設置します。このレイヤーが各サービスのAPIを呼び出し、結果を統合してクライアントに返します。
単純に単一SQLをマージして返す、という方法です。その他、データを複製してそれぞれのサービスで保持する方法もあります。
データ削除の方法
- ソフトデリート（Soft Delete）
ソフトデリートでは、データを物理的に削除するのではなく、「削除済み」のフラグを付けることで論理的に削除を実現します。これにより、削除処理をロールバック可能にし、一貫性を保つことができます。 - 補償トランザクション
こちらもSAGAパターンになりますが、削除操作を一連のローカルトランザクションとして扱い、一貫性を保つ方法があります。SAGAでは、削除操作が失敗した場合に補償トランザクション（Compensation Transaction）を実行します。つまり、イベント管理して、問題があったときは戻すという処理を補償するイメージです。
こちらの両方の概念を使って実装していきイメージになります。それぞれのサービスで削除の口をもち、併せてそれを戻す口も作る、一部でエラーが発生した場合は削除を戻す口から全部戻す、そんな感じです。
まとめ
今回の記事でお伝えしたかったことは、マイクロサービスアーキテクチャの重要性と、一度作ったAPIは情報資産として活用することで新しいサービスにも再活用が可能だということです。言いたかったことははじめに、に書いた通りです。
IT開発はマイクロサービスアーキテクチャ中心になればよいな、と心から思っています。
そして、そのマイクロサービス群を基に生成AIで自動アプリ生成ツールを作ってみせます。
最後までお読みいただきありがとうございました。
Discussion