マイクロサービスアーキテクチャへの期待
「システムの保守性が低く、開発に時間がかかる。」「システムを改修しようにも影響範囲が大きすぎて、どこから着手したらよいか分からない。」既存システムに対して、こんなお悩みを抱える人はいないでしょうか?特に長く運用されてきたレガシーシステムの開発現場では、こういった悩みをよく聞きます。既存システムの多くは単一の巨大なシステムであり、このようなシステムをモノリシックシステムと言います。このモノリシックシステムの保守性を改善するニーズは、2025年の崖に向けてますます高まっています。
このようなモノリシックシステムを改善する方法として、マイクロサービスアーキテクチャへの期待が高まっています。マイクロサービスとは小さい疎結合なサービスのことです。そして、複数のマイクロサービスが連携して動くシステムのアーキテクチャをマイクロサービスアーキテクチャといいます。疎結合なマイクロサービスは独立して動くため、あるマイクロサービス内の変更が他のマイクロサービスに与える影響が抑えられます。そのため、マイクロサービスアーキテクチャへ移行することでシステム改修の影響範囲が小さくなります。さらに、システム改修の影響範囲が小さくなるとシステムが保守しやすくなり、開発速度も向上するという期待からマイクロサービスアーキテクチャに注目が集まっています。
図1:モノリシックシステムからマイクロサービスアーキテクチャに移行するイメージ図
アプリケーション分割の難しさ
このように期待と注目度の高いマイクロサービスアーキテクチャですが、モノリシックシステムからマイクロサービスアーキテクチャへの移行の道のりは決して平たんではありません。代表的な課題としてアプリケーション分割の難しさについて説明します。
単一で巨大なモノリシックシステムを疎結合で小さなマイクロサービスに移行するためには、アプリケーションを分割する必要があります。しかし、アプリケーション上で分割境界をどのように設定するのかは難しい問題です。システム特性や利用するビジネス状況、また開発組織によって適切な分割境界は異なります。適切な分割境界を設定できない場合、トランザクションの整合性が取れなかったり通信遅延が発生したりといった問題が発生します。
図2:アプリケーション分割の難しさのイメージ図
アプリケーション分割は職人技の色合が濃い作業であると言われてきました。しかし分割に役立つ考え方をパターンにまとめることで、繰り返し使える解決方法として整理しようという試みが、近年行われています。本稿では、アカデミックで提案されている7つのアプリケーション分割パターンを紹介します
(https://arxiv.org/abs/2201.05825)。
アプリケーション分割パターン
サブドメインによる分割 | ドメイン駆動設計のサブドメインに対応する単位で分割する。 |
ビジネスケーパビリティによる分割 | ビジネスケーパビリティに対応する単位で分割する。 |
チーム単位の分割 | チーム単位でアプリケーションを管理しやすいように分割する。 |
トランザクションによる分割 | ひとつのビジネストランザクションがひとつのアプリケーションで完結できるように分割する。 |
シナリオ分析による分割 | 誰が、何をするのか?ビジネスシナリオを分析して分割する。 |
グラフ理論に基づく分割 | 既存のシステムの情報をグラフ構造に置き換え、クラスタリング手法によりマイクロサービスに分割する。 |
データフローに基づく分割 | ビジネス要件が含まれているデータフロー図に分析して分割する。 |
この中で「サブドメインによる分割」は比較的よく知られるパターンです。このパターン内で用いるドメイン駆動設計(※)はマイクロサービスの設計と相性が良いと言われており、アプリケーション分割における有力なアプローチのひとつです。ビジネスドメインや要件、目的を分析してサブドメインを識別し、サブドメインに対応する単位で分割境界を決定します。このパターンを利用するには、システムを利用する側のビジネスを十分に理解している必要があります。そのためビジネスを理解している有識者がプロジェクト内にいない場合、このパターンの利用は困難です。また、このパターンは既存システムの構造を考慮せずにビジネス観点から分割境界を決定します。そのため導き出した分割境界が実際のシステム構造と大きく異なる場合、既存システムの資産を流用できずに再実装コストが発生する可能性があります。
本稿では分量の都合上すべてのパターンを詳細に説明できませんが、7つのパターンの多くはビジネスの分析が必要となってきます。そこで、次の章ではビジネスの分析とは異なり、システム情報を分析して分割境界を決める「グラフ理論に基づく分割」パターンについて説明します。
https://docs.microsoft.com/ja-jp/azure/architecture/microservices/model/domain-analysis
グラフ理論に基づく分割
私たちのチームでは、7つのアプリケーション分割パターンの中で「グラフ理論に基づく分割」パターンに着目しています。
ここで簡単にグラフ理論について説明します。“グラフ”という単語から、“棒グラフ”や“折れ線グラフ”を想像する人も多いかもしれません。しかしここでいう“グラフ”とは頂点と辺の集まりのことを意味します。例えば東京の駅を頂点、駅を結ぶ路線を辺とした場合、東京の路線図をグラフとして表すことができます。グラフ理論とはグラフの持つ性質を数学的に解明する学問です。カーナビのルート計算やSNS上のつながり分析など、実社会のさまざまな場面でグラフ理論が応用されています。
図3:グラフ理論で用いるグラフの説明図
今回ご紹介する「グラフ理論に基づく分割」ではシステム情報をグラフ構造に置き換えます。例えばプログラムやデータベーステーブル、ファイルなどがグラフの頂点に、また関数呼び出しや継承、データベースアクセス(CRUD)などの関係性がグラフの辺となります。そして、クラスタリングというデータ間の類似度に基づいてデータをグループ分けする機械学習の手法を使ってグラフ構造を分割します。グラフ構造の分割結果はマイクロサービスの単位として対応させることができます。このように、グラフ理論を用いてアプリケーションの分割境界を決定する手法が「グラフ理論に基づく分割」パターンです。
図4:「グラフ理論に基づく分割」のイメージ図
「グラフ理論に基づく分割」を用いることで機械的にアプリケーションを分割でき、マイクロサービスアーキテクチャへの移行ハードルが低くなると考えています。このパターンはソースコードなどのシステム情報を解析するため、ビジネス有識者が不在のシステムでも分割境界を決定できるメリットがあります。また既存システムの構造を考慮して分割するため、「サブドメインによる分割」にあったような再実装コストの発生を抑えられるメリットもあります。このパターンの具体的な手法として、ソースコード解析を用いる手法やアプリケーションの実行ログを用いる手法などがあります。アプリケーション分割の難しさを解決し、マイクロサービスアーキテクチャへの移行を加速する手段として、近年グラフ理論に基づくさまざまな分割手法が提案されています
(https://arxiv.org/abs/1807.10059)。
さいごに
本稿では、マイクロサービス移行におけるアプリケーション分割の難しさと、その解決策としてグラフ理論に基づくアプリケーション分割手法について紹介しました。我々NTTデータの研究チームでも、レガシーシステムからの脱却に向けてマイクロサービス移行の研究開発を行っています。最近の研究成果として、ソフトウェア工学の学会である「ソフトウェアエンジニアリングシンポジウム2021」にて、グラフ理論に基づいた新たな分割手法のコンセプトを発表しました。
研究開発はまだ初期段階ですが、今後も引き続きアカデミックな研究動向をウォッチしつつ、実用的なソフトウェア技術の研究開発を続けていきます。ソフトウェア研究に関する情報交換や、共同研究など、ご興味のある方はお気軽に「お問い合わせ」ボタンよりご一報ください。