記載内容は私個人の見解であり、所属する組織の公式見解ではありません。
はじめに
既存システムの老朽化への対策を怠ると2025年頃よりシステムの維持が難しくなり企業の成長が妨げられるという「2025年の崖」への懸念もあり、デジタル技術を活用して既存システムをモダナイゼーションし、新しい商品・サービス・ビジネスモデルを創出するデジタルトランスフォーメーション（DX）に取り組む企業が増えています。
このような、既存システムのモダナイゼーションやデジタル技術を活用した新たなシステムで採用するアーキテクチャ（システム設計スタイル）として「マイクロサービス」が注目されています。
マイクロサービスは機能を実装する多数の小さなサービスを疎結合で組合せてアプリケーションを構築するアーキテクチャのことですが、闇雲に小さなサービスを作るだけではシステムは複雑化するだけで効果はありません。
これを理解せず、「今後の新規システムはマイクロサービスアーキテクチャで構築するものだ」という安易にマイクロサービスアーキテクチャの採用を検討すると失敗します。実際に失敗事例も世の中には多く存在します。
マイクロサービスについて解説します。
マイクロサービスが求められる背景
マイクロサービス（Microservices）という言葉がはじめて使われたのはThoughtWorks社のJames Lewis氏が2012年3月に発表したMicro Services - Java, the Unix Wayだと言われており、その2年後の2014年5月にJames Lewis氏とMartin Fowler氏が執筆したMicroservices (martinfowler.com)というブログ（以降、”Microservicesブログ”と呼ぶ）で広く認知されるようになったと言われています。
従来のアプリケーションは1つのプロセス内で密に連携するモノリシックなアプリケーション(monolithic applications)と呼ぶのに対し、マイクロサービスは機能を小さなサービスとして実装してRESTful APIなどでサービス間をリモート呼び出しする疎結合なアプリケーションです。マイクロサービスでは機能拡張する際には対象のサービスのみを入れ替えることで他のサービスに影響を与えず素早く機能拡張や修正ができるため、顧客のニーズに素早く対応できるものとして注目されています。
サービスを組合せるアーキテクチャと聞くと、2000年頃に注目された「SOA(Service-Oriented Architecture、サービス指向アーキテクチャ)」を思い出す方もいると思います。マイクロサービスとSOAは考え方はほぼ同一です。しかし、考え方が登場した契機が異なります。
SOAはCORBA／SOAP／ESBといった技術を有効に活用できるアーキテクチャとして技術提供者側(いわゆる富士通などのICTベンダ)からの情報発信を契機として企業が導入を検討していたのに対し、マイクロサービスはMicroservicesブログで示されているように、Netflix社などのデジタル技術を活用して急速に成長した企業において、顧客ニーズに素早く対応するためのアーキテクチャとして実際に導入され、その有効性が確認されたことを契機として他企業に横展開されました。
この違いにより、急速に成長した企業で効果が出ている技術であるという信憑性以外に、以下のマイクロサービスの特徴により、現場での適用検討が急速に広まったと考えられます。
1. 軽量な技術を活用
難しい技術の活用を前提としておらず、RESTful APIのような軽量で導入しやすい通信で互いのサービスを連携することが推奨されています。このため、CORBAやSOAPといった難しい技術を習得する必要性がなく、有効性を理解しやすくなっています。
2. ビジネスを取り巻く組織の在り方にも言及
マイクロサービス化の目的は企業のビジネス拡大であるため、単なる技術の導入ではなく、ビジネスを成功に導くためにアプリケーションの開発チームをマイクロサービスの構成に合わせた体制に変更すべきだとMicroservicesブログは述べており、信憑性を増しています。
マイクロサービスとは
マイクロサービスとは小さなサービスを組合わせて一つのアプリケーションを開発するアプローチであり、独立したプロセスで運用された各サービスはRESTful APIなどの軽量なメカニズムのリモート通信で連携します。
これらのサービスはビジネス機能に焦点をあてて構築され、独立して入替え可能であるため完全に自動化された配備メカニズムを整備することで、ビジネスのニーズに合わせてアプリケーションを素早く拡張可能となります。また、各サービスは別々のプロセスで運用されるため、各サービスの開発チームやビジネスの事情に合わせて異なる開発言語・データストレージを利用でき、各サービスはビジネスの拡大に合わせて小まめにスケールアウトできます。
一方でモノリシックなアプリケーションでは、一般的にユーザーインタフェース部分／サーバ部分／データベース部分のように3階層構成で実装されます。技術要素に焦点をあてた3つの階層が別々のプロセスで運用されるため、各階層で利用される技術は集約されて品質の安定化が図りやすいという特長があります。しかし、開発チームやビジネスの事情に関係なく、階層ごとに利用技術(開発言語・ストレージ)が制限され、アプリケーションの改修が必要となった場合には他のビジネス部門との調整が必要となります。また、スケールアウトが必要な場合、各階層を丸ごとスケールアウトする必要があります。
必ずしもモノリシックなアプリケーションよりマイクロサービス化されたアプリケーションの方が良いとは限りません。しかし、利用したいときに利用したい分のリソースが素早く利用できるクラウドサービスの活用が進むにつれて、実現したいことをすぐに形にできるクラウドサービスの利点を最大限に発揮する手段としてマイクロサービスも注目されています。
上述したようにマイクロサービスは現場で有効性が確認されたものが横展開されたものなので、マイクロサービスの明確な定義がありません。Microservicesブログではマイクロサービスの有効性が確認された事例において共通の特徴を9つにまとめており、以降の説明で9つの特徴を説明します。なお、Microservicesブログは、非常に説明がシンプルで現場実践の結果として説得力のある内容となっているため、興味がある方はぜひ一読していただくことをお勧めします。
【特徴1】 コンポーネントとしてサービスを実装する
モノリシックなアプリケーションの場合、各機能はライブラリとして実装し、1つのプロセス内で各ライブラリを関数やメソッドとして呼び出してアプリケーションを実装します。一方でマイクロサービスは各機能を単独のプロセスで運用するコンポーネントとして実装し、各コンポーネントはリモート通信で呼び出します。これにより機能の修正が必要な場合、インタフェースに変更さえなければ対象のサービスのみ再配備すれば良いため、優れたマイクロサービス化されたアプリケーションでは修正によるコストが削減されます。
【特徴2】 ビジネス機能を中心に構成する
1968年にMelvin Conway氏が提言したコンウェイの法則では、組織が設計するシステムには、その組織のコミュニケーション構造がそのまま反映されると提言されています。
モノリシックなアプリケーションでは、一般的にユーザーインタフェース部分／サーバ部分／データベース部分のように3階層構成で実装されるため、ユーザーインタフェースを実装するチーム、サーバを実装するチーム、データベースを実装するチームのように階層ごとにチームを分けます。
一方でマイクロサービスでは、ビジネス機能ごとにサービスが実装されます。このため、マイクロサービスでは各サービスを開発するチームもビジネス単位に分けることが望ましいとされています。
【特徴3】 チームが製品のライフサイクル全体に責任を持つ
従来は、開発チームと保守チームを分け、開発チームが製品を開発すると、その製品を保守チームに引継ぐことが多いと思われます。しかし、マイクロサービスの開発では、開発チームが保守も担うことが望ましいとされています。
特徴2でマイクロサービスはビジネス機能ごとにサービスを開発するため、各サービスはビジネス単位にチームを分けて開発することが望ましいと説明しました。このチーム体制では開発チームのビジネス理解が深まることで、ビジネスニーズに応える機能が実装しやすくなります。このため、開発担当者が保守も担うことにより、システム稼働後の開発担当者と顧客とのつながりが強くなり、開発担当者のビジネスの理解が自然と深まり、ビジネスニーズに応える機能が素早く開発できると考えられるのです。
【特徴4】 各サービスは疎結合にする
従来のSOAでは中央集権的なハブであるESBの利用が推奨されました。しかし、マイクロサービスでは中央集権的なものを排除し、各サービスは軽量なRESTful APIや軽量メッセージングにより疎結合で連携することが推奨されます。多くのサービスを連携するマイクロサービスにおいて、中央集権的な機能を前提とすると、中央集権的な部分を担う機能が単一障害点(Single Point of Failure、SPOF)となってしまいます。ビジネス単位にサービスを分けて実装しても、中央集権的な機能がボトルネックとなり、各サービス単位での改修の阻害要因となってしまうため、なるべく中央集権的なものは排除することが推奨されます。
【特徴5】 分散型ガバナンス
モノリシックなアプリケーションではユーザーインタフェース部分／サーバ部分／データベース部分の各階層で利用する開発言語・ツールは共通のものを利用して開発(統一型ガバナンス)するのが一般的です。同一のプロセス内で機能が動くため、プロセス内で利用可能な開発言語や、その開発言語で利用可能なツールを選ぶ必要があるのです。
しかし、マイクロサービスの場合、各機能を実装するサービスは独立したプロセスで動作するため、機能に適した開発言語・ツールで開発(分散型ガバナンス)できます。開発方法の制約が少ないため、開発チームのスキルを発揮しやすい状況となります。ただし、アプリケーションで利用する開発言語・ツールが増えることにより、保守対象の技術が増えることには注意は必要です。
【特徴6】 分散型データ管理
モノリシックなアプリケーションではデータベースは一つに集約されることが好まれました。しかし、データベースが一つに集約されると、機能拡張でデータベースの変更が必要となった際に周辺関係者と調整が必要となり、素早い修正提供の妨げになります。このため、マイクロサービスでは各サービスでデータを管理すること(分散型データ管理)が好ましいとされています。
しかし、各サービスでデータを管理する場合、トランザクションの整合性を維持するのが難しくなります。このため、ドメイン駆動設計（domain-driven design, DDD）などを利用し、どのようにサービスを分割すれば良いかを注意深く設計する必要があります。
【特徴7】 インフラストラクチャの構築を自動化する
マイクロサービスによるサービスの分割による大きな目的は、アプリケーションを素早く機能拡張可能とすることですが、サービスを分割しただけでは目的は達成できません。アプリケーションの構成が機能拡張しやすい構成になっても、アプリケーションの開発で必要なビルド・検証作業や本番環境へのデリバリ作業が手作業で時間がかかれば、結局素早く機能拡張することはできません。
このため、インフラストラクチャの構築を自動化して、継続的に機能を開発し、継続的に新機能をデリバリするCI/CDを合わせて導入する必要があります。
【特徴8】 異常対処を設計する
マイクロサービスは小さなサービスに分割して各サービスはリモート通信で連携するため、通信回数や通信経路が多くなるため通信異常による異常発生リスクは高まります。このため、異常が発生しても処理が継続されるようにアプリケーションを設計するだけでなく、監視やログにより各サービスの状態を絶えず監視する必要があります。Netflixなどの企業では、システム稼働中に意図的に異常を発生させて、その異常が正しく検知されて自動的に復旧するかを確認（カオスエンジニアリングと呼ばれます）していると言われています。
【特徴9】 進化的に設計する
3階層で構築されるモノリシックなアプリケーションでは、機能拡張する場合には修正が加えられる階層の再配備が必要となります。このため、開発環境では本番環境でどのバージョンのアプリケーションが稼働しているかを管理すること(変更管理)が必要でした。
しかし、マイクロサービスは小さな機能に分割してサービスを実装するため、変更管理が負担となります。このため、一度構築したアプリケーションをアップデートするのではなく、アプリケーションのインフラストラクチャをコードで管理(Infrastructure as Code、IaC)して改修が必要となったアプリケーションを一から構築して旧アプリケーションを破棄して入れ替える(Blue-Green Deploymentなど)ことで、サービス単位で進化できるように設計することが必要です。
まとめ
ビジネスの拡大により、顧客ニーズに素早く対応することが求められる状況において、システムをマイクロサービス化することは一つの有効な手段となります。しかし、9つの特徴に示すように、ビジネスを取り巻く組織の在り方についても見直さないと本来の目的を達成できません。マイクロサービス化を検討する際には、まずは組織やビジネスの状況を考慮し、マイクロサービス化が目的に対する適切な手段であるか十分に吟味してください。