[論文レビュー] Towards a Technique for Extracting Microservices from Monolithic Enterprise Systems

Alessandra Levcovitz, Ricardo Terra+1 more|arXiv (Cornell University)|May 10, 2016

Software System Performance and Reliability参考文献 6被引用数 94

ひとこと要約

この論文は、データベーステーブルの依存関係、依存関係グラフ、ファサードテーブルへのアクセス経路を分析することで、モノリス型エンタープライズシステムにおけるマイクロサービス候補を特定する手法を提案する。750 KLOCのバンキングシステムに適用したところ、5つのサブシステムのうち4つが実用的なマイクロサービス候補として特定され、独立したデプロイや技術選択の柔軟性といった利点を伴う段階的移行が可能となった。

ABSTRACT

The idea behind microservices architecture is to develop a single large, complex application as a suite of small, cohesive, independent services. On the other way, monolithic systems get larger over the time, deviating from the intended architecture, and becoming risky and expensive to evolve. This paper describes a technique to identify and define microservices on monolithic enterprise systems. As the major contribution, our evaluation shows that our approach was able to identify relevant candidates to become microservices on a 750 KLOC banking system.

研究の動機と目的

• 時間の経過とともに保守・拡張が困難になる大規模なモノリス型エンタープライズシステムの進化に取り組むこと。
• 既存のモノリスアーキテクチャ内における実用的なマイクロサービス候補を体系的かつ系統立てて特定するアプローチを提供すること。
• 完全なアーキテクチャ刷新なしにマイクロサービスへの段階的移行を可能にすること。
• 各サービスにおける独立した開発・デプロイおよび技術選択の柔軟性を支援すること。
• 実世界のエンタープライズシステムにおけるマイクロサービス抽出の実現可能性と実用的利点を評価すること。

提案手法

• ビジネス領域に基づいてデータベーステーブルをサブシステムにマッピングし、非ビジネステーブル用に特別なコントロールサブシステムを設ける。
• ファサード、ビジネス機能、データベーステーブルを頂点とし、呼び出しやデータアクセスをエッジとする依存関係グラフを構築する。
• 依存関係グラフ内の経路を介して接続されたすべての（ファサード、テーブル）ペアを特定し、データおよび制御フローを追跡する。
• これらのペアをサブシステムごとにグループ化することで、各ビジネス領域ごとのマイクロサービス候補を分離する。
• アクセスパターン、通信パターン、独立したデプロイの可能性に基づき、各候補を評価する。
• 複数のサブシステムで共有されるテーブルがある、または高い結合度がある場合は、複雑なリファクタリングを避けるために候補から除外する。

実験結果

リサーチクエスチョン

• RQ1 大規模なモノリス型エンタープライズシステムにおいて、体系的な手法が実用的なマイクロサービス候補を特定できるか？
• RQ2 提案手法は、モノリス型コードベースから一貫性があり、独立してデプロイ可能なサービスをどれだけ的確に分離できるか？
• RQ3 特定のサブシステムをマイクロサービスに移行する際の実用的課題とトレードオフは何か？
• RQ4 完全なシステムリファクタリングなしに、マイクロサービスへの移行をどの程度段階的に実施できるか？
• RQ5 アーキテクチャ的制約により、マイクロサービス移行に不適切なサブシステムはどれか？

主な発見

• 750 KLOCのバンキングシステムにおいて、5つのサブシステムのうち4つがマイクロサービスへの移行に適した候補として明確に特定された。
• 依存関係グラフの分析により、サービス境界とデータアクセスパターンの明確な特定が可能になった。
• サービス料金、支払書、SMSチャネルといったサブシステムは、高い内集性と明確なインターフェース境界があるため、優れた候補とされた。
• クライアントサブシステムは、50以上のAPIゲートウェイと高い結合度があり、利益対作業量比が低いため、移行は推奨されなかった。
• データベーステーブルを共有するサブシステムは、データ不整合のリスクと複雑なリファクタリングの懸念があるため除外された。
• 本手法は段階的移行を支援でき、モノリス型とマイクロサービスアーキテクチャが生産環境で共存できる。