マイクロサービス（Microservices）採用時の注意事項
クラウドネイティブNow

はじめに

マイクロサービス（Microservices）は、2014年にJames Lewis氏とMartin Fowler氏が書いた「Microservices（martinfowler.com）」のブログで世の中に広く知られるようになりました。以降ではこのブログをMicroservicesブログと呼びます。
マイクロサービスはNetflixやAmazonといったデジタル技術の活用で急速に成長した企業で採用されているアーキテクチャーと言われており、デジタルトランスフォーメーション（DX）で新たなビジネス創出を目指す企業で採用を検討され始めています。
しかし、マイクロサービスアーキテクチャーの活用には注意が必要です。ここでは、マイクロサービスアーキテクチャーの採用時における注意事項を紹介します。
以降の説明では、Microservicesブログと同様に従来のような1つのプロセス内で密に連携するアプリケーションを「モノリシックなアプリケーション（monolithic applications）」と呼び、機能を小さなサービスとして実装してRESTful APIなどでサービス間をリモート呼び出しする疎結合なアプリケーションを「マイクロサービス（Microservices）」と呼び、比較して説明します。
マイクロサービス自体の解説については、以前に私が投稿した『今注目される「マイクロサービス（Microservices）」とは』で説明しているため、そちらも併せて参照ください。

マイクロサービス化は手段であり目的では無い

マイクロサービスはNetflixやAmazonといった急成長した企業で採用されたことから、レガシーなシステムに課題を抱える企業では「システムのマイクロサービス化」を目的に検討が進められる場合があります。
しかし、「マイクロサービス化」を目的としてしまうとシステムが複雑化するだけで効果が得られず失敗します。まずはマイクロサービス化する目的を明確化し、投資対効果を事前に評価することをお勧めします。
システムをマイクロサービス化する目的として以下が考えられます。

システムの修正・拡張スピードの向上

モノリシックなアプリケーションは1つのプロセス内で複数業務が稼働するため、特定の業務のために機能を修正・拡張する場合、別業務への影響を調整する必要があります。例えば修正を適用する際にシステムを一時的に停止する必要がある場合、他の業務担当者にシステムを停止しても良い時間帯を確認し、適用時期を決める必要があります。仮に無停止リリースが可能となるようにシステムを構築していた場合でも、システム全体で無停止リリースが実現できているかすべての業務担当者で検証して適用する必要があります。
一方でマイクロサービスの場合、業務ごとにプロセスを分けて運用するため、入れ替えるマイクロサービスが無停止リリース可能であれば、他の業務担当者と調整せず修正・拡張できます。影響の確認範囲が小さいため、修正・拡張スピードの向上が見込まれます。
例えば、多様な顧客要件に合わせてシステムを拡張するようなシステムではマイクロサービス化は有効ですが、社内の定型業務用のシステムでは修正頻度が少ないためマイクロサービス化はシステムを複雑化するだけでデメリットの方が多いかもしれません。

可用性の向上

モノリシックなアプリケーションは1つのプロセス内で複数業務が稼働するため、仮に1つの業務処理が原因でプロセスが異常終了すると、他業務の処理も終了します。
一方でマイクロサービスの場合、業務ごとにプロセスを分けて運用するため、1つの業務処理が異常終了しても、他のプロセスで運用された業務は継続されます。
例えば、システムが密に連携しており、1つの業務処理の異常が他業務にも影響するようなシステムでは、マイクロサービス化しても意味が無いかもしれません。

柔軟なスケーリングが可能

モノリシックなアプリケーションは1つのプロセス内で複数業務が稼働するため、プロセスが必要とするリソースが大きくなります。このため、負荷が増加した場合にプロセスをスケールアウトする場合、リソースが大きいプロセスを多重化する必要があり影響が大きい状態となります。
一方でマイクロサービスの場合、業務ごとにプロセスを分けて運用するため、負荷が増大した業務のプロセスのみスケールアウトすることができます。これにより、スパイクと呼ばれる短時間で急激なトラフィックが発生するような場合にも特定のサービスのみスケールアウトして柔軟に対応できます。
例えば、急激なトラフィックが発生した場合、すべてのサービスをスケールアウトする必要があるならマイクロサービス化する必要は無いかもしれません。

モノリスファースト

新規システムを開発する場合にマイクロサービスアーキテクチャーを採用するのは注意が必要です。Martin Fowler氏はMicroservicesブログを公開した次の年である2015年に「MonolithFirst（martinfowler.com）」というブログを公開しています。このブログでは新規システムはモノリシック型システムで作ることが推奨されており、マイクロサービスを採用した多くの新規プロジェクトは失敗していると紹介されています。
新規システムで重要視すべきはスピード（speed（and thus cycle time for feedback））であり、早くシステムをリリースして有用性を確認することが重要である状況において、マイクロサービス化する単位の設計に時間をかけるべきではないと述べています。そもそも、まだシステムの有用性が確認されていない状況においては、どのようにシステムをドメイン分割すべきかの判断が難しくなります。仮に綺麗に分割できても顧客のニーズに合わずにシステムをすぐに作り替えることになると、時間をかけて検討したドメイン駆動設計が無駄になります。このため、最初はモノリシック型アーキテクチャーでシステムを構築し、十分にシステムの有用性が確認でき、システムが対象とするビジネス領域の理解が深まったらドメイン駆動設計により、どのようにシステムを分割するかを検討してリファクタリングによりマイクロサービス化することが推奨されます。
システムをマイクロサービス化する際には、ストラングラーアプリケーションというテクニックが推奨されます。これはストラングラー・フィグ（Strangler Fig）と呼ばれる締め殺しの木が名前の由来です。ストラングラー・フィグの果実を食べた鳥などが別の木の上に種を落とすと、ホストの木の幹に絡みつきながら成長してホストの木を覆いつくし、最後にはホストの木は枯れてしまいますが、ストラングラー・フィグはあたかもホストの木のような姿で立っている様から締め殺しの木と呼ばれます。
このように既存システムとマイクロサービスを共存させて、マイクロサービスが徐々に成長する時間を与え、最終的に既存システムをマイクロサービスに完全に置き換えていくという方法がもっとも好ましいプロセスとされています。

マイクロサービスの分割単位

Microservicesブログではマイクロサービスとは、システムをコンポーネントに分解し、各コンポーネントはウェブサービスやリモートプロシージャコールで通信し合うアウトプロセスコンポーネント（独立したプロセスで運用されるコンポーネント）だとしています。
独立したプロセスで運用することにより、機能の修正や追加に伴うコンポーネントの交換およびアップグレードする際の影響はコンポーネント間のインターフェイス部分に集約され、機能の修正や追加を素早く実施できるというものです。
しかし、マイクロサービスの分割単位には注意が必要です。細かく分割し過ぎると、管理すべきプロセスが増え、運用コストが増大します。
機能の修正や追加を素早く実施する目的のためにマイクロサービス化を考えた場合、機能の修正や追加をする際に複数のマイクロサービスに対して同時に修正が必要となるような分割では意味がありません。
システムをどのようなマイクロサービスに分割するべきかを検討する方法については、ドメイン駆動設計（domain-driven design：DDD）により分割単位を検討するのが一つの方法と言われています。ドメインとはアプリケーションが対象とするビジネス領域のことを指しており、ドメインごとにマイクロサービスを実装することで効果的な単位でマイクロサービス化が可能となるという考え方です。

ミニサービスやモジュラーモノリス

Microservicesブログではデータベースもマイクロサービスごとに用意するのが好ましいとされています。データベースをマイクロサービス間で共通化してしまうと、特定のコンポーネントに対して機能追加や修正を行う際に、データベースのテーブルに修正が必要になった場合に、他のコンポーネントに影響を及ぼしてしまうためです。
各マイクロサービスでデータベースも含めて別々に持つことにより、マイクロサービスを開発するプロジェクトで自由にデータベースへの修正も行うことができるため、開発のしやすさも向上します。
しかし、実際にデータベースをマイクロサービスごとに分割した場合、データの整合性を保つための設計は容易ではありません。この点において、マイクロサービスは理想像ではあるものの、理想を追い求めた極端な考え方であると述べる技術者も少なくありません。このため、データベースを分割できる範囲でサービスを分割するミニサービスや、独立したプロセスに分割せずにプロセス内でモジュールを分割するモジュラーモノリスという考え方が議論されはじめています。
ミニサービスやモジュラーモノリスで目的が達成できるのではあれば、それは正しい選択となります。更にモノリシックなシステムは変更せず、煩雑な開発プロセスを見直し、CI/CDを導入するだけでも目的を達成できるかもしれません。

今後に向けて

マイクロサービス化することが目的化して、結局失敗するケースも少なくありません。マイクロサービスアーキテクチャーを採用する目的を明確化し、その目的と照らし合わせてマイクロサービス化するのが本当に適切なのか、マイクロサービス化する時期が適切なのか十分に検討することをお勧めします。

関連情報

当社が提供するデジタルトランスフォーメーションを支えるアプリケーションサーバー「FUJITSU Software Enterprise Application Platform」の詳細は下記ページをご覧ください。

• FUJITSU Software Enterprise Application Platform

既存システムのモダナイゼーションやデジタル技術を活用した新たなシステムで採用するアーキテクチャーとして注目されるマイクロサービスの解説は下記ページをご覧ください。

• 今注目される「マイクロサービス（Microservices）」とは