既存システムのマイクロサービス化

既存DXシステムをモダンなアーキテクチャーに改編

既存の業務管理DXシステムである Playth（プレイス）を、小さな独立した複数のサービス（機能ごとのアプリケーションやデータベース）に分割することで、運用性、カスタマイズ性、外部システム連携など柔軟性の向上を実現しました。

マイクロサービスとは？

マイクロサービスとは、大規模なアプリケーションを小さな独立したサービス（機能ごとのアプリケーションやデータベース）に分割し、それぞれを個別に開発・運用するソフトウェアアーキテクチャのスタイル（システム設計方法）です。

各サービスは特定の機能を担当し、疎結合で連携（主にAPIなどで連携）します。これにより、開発効率の向上、柔軟性の向上、障害時の影響範囲の局所化（全体に影響を与えず可用性を向上）などのメリットがあります。

Playth（プレイス）とは？

Playth は株式会社スパイスワークスが運営する業務DXシステムで、プロジェクトの受注管理や発注管理、顧客・外部パートナー管理などのアプリケーションを内包しています。

今までは日報管理を中心とする一つの大きなアプリケーションでしたが、今回のマイクロサービス化により、各コンテナ（サーバー上の隔離環境）に収納された、機能単位での複数のアプリケーションやデータベースに分割されました。

マイクロサービス化による運用性の向上

従来のモノリシック（一枚岩）なアプリケーションは、全ての機能が単一のソフトウェアにまとめられていました。

この構造により、一部の新機能を反映するために、システム全体をデプロイ（システムの更新・公開）する必要がありました。

対照的にマイクロサービスでは、各サービス（アプリケーションやデータベース）が独立しているため、開発、テスト、デプロイをマイクロサービス単位で実行することができます。

これにより、小規模短期間での頻繁なアップデートの運用を実現できます。

マイクロサービス化によるカスタマイズ性の向上

これまでのモノリシックなアプリケーションでは、一か所のカスタマイズでもアプリケーション全体への影響を配慮し、既存システムの調査や設計に多くの時間を要しました。

しかしマイクロサービスアーキテクチャでは、各サービスが小さな単位で独立しているため、一部のマイクロサービスを改修することで、きめ細かなニーズに合ったカスタマイズが可能です。

マイクロサービス化で外部アプリケーションや基幹システムと連携

マイクロサービス化することによって、外部システムとの連携も柔軟になります。

たとえば社員情報についてのみ、既存の基幹システム内の社員情報データベースと連携することも可能です。

新しい技術やフレームワークへの対応

マイクロサービスアーキテクチャは、各アプリケーションやデータベースが独立して、APIなどで連携されています。

それぞれのアプリケーションが個別の言語やフレームワークで開発されていても、互いに連携することが可能です。

具体的には、追加開発するアプリケーションを別の言語や最新のフレームワークで開発しても、既存のサービスと連携することができます。

逆にモノリシックなアプリケーションでは、初期開発当時の言語やフレームワークで機能の追加を続けることになります。

年月が経つにつれてアプリケーションが徐々に巨大化しますが、全体が同じ言語やフレームワークで書かれているため、言語やフレームワークのサポートが終了した場合、システム全体がサポートの対象範囲外となってしまいます。

実際に Playth も初期に開発していたフレームワークのサポートが終了しており、マイクロサービス化するアプリケーションから、徐々に最新のフレームワークに切り替えていきました。

マイクロサービスのデメリット

上記のように多くのメリットがあるマイクロサービスアーキテクチャですが、デメリットもありますので、導入前にメリット・デメリットを踏まえて検討する必要があります。

◆設計やマネジメントの難易度

そもそもの設計思想が誤っていると、マイクロサービスとしてのメリットを享受できません。マイクロサービスとしてのメリットを最大限に享受できる設計にはノウハウが求められます。

また設計だけでなく、システム全体を統括するマネジメントの難易度が向上します。

◆サーバーの負荷向上

マイクロサービスの数が増えるほどアプリケーションやデータベースの通信が増えるため、サーバーの負荷が上がり、コストに影響する可能性があります。

ただしモノリシックなシステムでは、システム全体のスケーリング（処理能力の増減）が必要でしたが、マイクロサービスの場合は高負荷のサービスのみスケーリングできるというメリットがあります。

◆データの一貫性

マイクロサービスではそれぞれのサービスごとに、アプリケーションとデータベースが紐づいています。各サービスがそれぞれデータを処理しており、時には非同期の処理を活用するケースもあります。これにより一時的なタイミングで、データの一貫性が下がる可能性があります。

◆UIの一貫性

各サービスごとにチームが独立して運用を行う場合、新たな機能の追加などでUIの一貫性が崩れることがあります。全体を統括してUIを管理するマネジメントには、より高度なスキルが求められます。

マイクロサービス化におけるシステム開発の流れ

既存のモノリシックなアプリケーションをマイクロサービス化するには、大きく2通りの方法があります。

一つは既存サービスの一部の機能から、徐々に切り出してマイクロサービス化する手法（ストラングラーパターン）。もう一つはシステム全体を一挙にマイクロサービス化する手法です。

Playth の場合は前者のストラングラーパターンを選択し、既存のシステムからユーザー情報、プロジェクト情報など、徐々にサービスを切り出してゆく手法をとりました。

一挙に全体を分割する手法は全体の期間を短縮できる可能性がありますが、システム全体を一挙に入れ替えることになるので、不具合などのリスクが高まります。一部ずつの機能をマイクロサービス化する方法であれば、不具合があっても一部にとどまり、全体に影響しづらいというメリットがあります。

また、実際に巨大なシステムのマイクロサービス化において、当初の段階で細部まで完璧な設計をするのはかなり難易度が高いでしょう。もちろん、徐々にマイクロサービス化するストラングラーパターンにおいても、当初の段階で最終的なゴールの設計を詳細まで詰めることは変わりません。しかし、その設計をもとにアジャイルでマイクロサービス化を進める中で、よりよい分割方法の発見や、新しい技術・フレームワークが出現することもあります。

アジャイル開発で徐々にマイクロサービス化する手法であれば、時間の経過とともに発生した最善の方法を取り込むことができます。これもマイクロサービス化のメリットを最大限に享受することにつながります。

モノリシックなアプリケーション開発やウォーターフォール型の開発モデルのように、当初に設計したプランを貫き通すという思想を変える必要があります。

システムのマイクロサービス化のご相談について

株式会社スパイスワークスでは、システムのマイクロサービス化において、システムの受託開発やコンサルティングサービスでの対応を行っています。

「システムの運用効率が悪く、改善したい。」「古いシステムのサポートが切れる前にリニューアルを進めたい」「自社のクラウドサービスや教育ICTサービス（デジタル教材や LMS 等）を、マイクロサービス化したい」などのお悩みがあれば、オンライン無料相談をお申込みください。