精読「マイクロサービスアーキテクチャ 第2版」(第二部 実装 - 第6章 ワークフロー)
マイクロサービスアーキテクチャ 第2版
マイクロサービスの設計、実装、運用に必要なベストプラクティスや最新技術を解説した、実践的なガイドブックです。これを読めば、マイクロサービスに関してそれっぽい会話もできますよ。
関連記事
データベーストランザクション
データベーストランザクションは、複数の操作を単一のユニットとして扱い、すべての変更が正常に行われたかを確認し、エラー時にはクリーンアップを行うもの。
ACIDトランザクション
リレーショナルデータベースでは、ACID(原子性、一貫性、独立性、永続性)を保証することで、データの整合性と信頼性を確保する。
特性 | 説明 |
---|---|
原子性 (Atomicity) | トランザクション内の操作は全て成功するか、全て失敗するかのいずれか。 |
一貫性 (Consistency) | トランザクション後のデータベースが有効で一貫性のある状態を保つ。 |
独立性 (Isolation) | 複数のトランザクションが互いに干渉せず並行して動作できる。 |
永続性 (Durability) | トランザクション後のデータは、システム障害があっても失われない。 |
ACIDでも、原子性に欠けるのか
マイクロサービス環境では、トランザクションはローカルなデータベース内でACIDを適用できるが、複数のサービスをまたいだ場合、ACID保証が難しくなることがある。
この場合、分散トランザクションを利用する選択肢があるが、分散トランザクションは実装が難しく、問題を引き起こす可能性があるため注意が必要。
分散トランザクション:2フェーズコミット
**2フェーズコミット(2PC)**は、分散システムで複数プロセスを更新するためのアルゴリズム。
主に以下の2段階で行われる
- 投票フェーズ: コーディネータが各ワーカーに変更可能か確認し、全員が同意すれば次へ進む。
- コミットフェーズ: 全員が合意すれば変更を実施し、ロックを解放する。
分散データベースにおける2相コミットの仕組みを理解しよう!より
課題として、遅延や一貫性の欠如、ロック調整が難しく、長時間の操作や大規模なトランザクションではパフォーマンス問題が生じることがある。
分散トランザクションはお断り
2フェーズコミットのような分散トランザクションは、マイクロサービスでの状態変更調整には適していない。
代わりに、以下のアプローチが考えられる
- データを分割しない: ACIDトランザクションが必要な状態がある場合、その状態を単一データベースで管理し、モノリスとして保持する。
- サーガパターン: 分散トランザクションを避けつつ、複数のサービスでの操作を調整する方法としてサーガを検討する。
サーガ
サーガ (Saga) は、複数の状態変更を調整するアルゴリズムで、長時間リソースをロックせず、個別のトランザクションを処理する。これにより、複数のサービスにまたがる変更を管理でき、各サービス内ではACIDトランザクションが使用される。サーガ全体の原子性は保証されないが、個々のトランザクションには原子性がある。
サーガの障害モード
サーガパターンでは、障害が発生した場合に復旧方法として「後方復旧(ロールバック)」と「前方復旧(リトライ)」がある。後方復旧は、コミットされたトランザクションを取り消す補正アクションが必要。前方復旧は、処理を再試行できる情報が必要です。
サーガでは、ロールバックは全体の操作を元に戻すのではなく、補正トランザクションを使用する。補正トランザクションは、以前のトランザクションをキャンセルする処理であり、完全に元に戻すことはできないが、代わりに訂正処理を行う。
Sagaパターンについてより
サーガの実装
サーガパターンにおける「オーケストレーションベース」と「コレオグラフィベース」の実装方法について
-
オーケストレーションベースのサーガ:
- 中央のオーケストレータが全体のフローを制御。
- サービス間でリクエスト/レスポンスのやり取りが行われ、オーケストレータが失敗時の補正アクションを決定。
- メリットは、プロセスの可視化と理解がしやすいが、デメリットとしてドメイン結合度が高く、サービスがオーケストレータの命令を受けるだけになりがち。
-
コレオグラフィベースのサーガ:
- サービス間の調整がイベントを通じて分散され、疎結合なシステムを構築。
- 各サービスは、必要なイベントを受け取って処理を実行する。
- メリットは、結合度が低く、ロジックが分散されること。
- デメリットとして、サーガの状態を追跡するのが難しく、補正アクションの実行機会を逃す可能性がある。
【図解】コレ1枚でわかるオーケストレーションとコレオグラフィより
コレオグラフィとオーケストレーションの選択は、チームの規模や構成に依存する。オーケストレーションは1チームで実装が管理しやすく、コレオグラフィは複数チームが独立して作業でき、疎結合アーキテクチャに適している。コレオグラフィはイベント駆動型で難しく感じることもあり、理解できれば有効ですが、そうでなければ適さないかもしれない。
サーガと分散トランザクションの比較
分散トランザクションには重大な課題があり、特に単一ノードの障害でトランザクションが停止する問題がある。この問題はシステムの規模が大きくなるほど深刻化する。
一方、ビジネスプロセスをサーガとして明示的にモデル化することで、分散トランザクションの課題を回避し、プロセスを明確で理解しやすくする利点がある。サーガを使うことで、システムの可用性やビジネスプロセスの明確化が進む。
Discussion