マイクロサービスとは

なぜマイクロサービスなのか？

マイクロサービスアーキテクチャを採用する最大の理由は、複雑なアプリケーションを分割してシンプルに保つことで、開発・運用サイクルを効率よく高速に回せるようにするためです。

従来のアプリケーションの多くは、複数の機能を単一のモジュールとして提供する「モノリシックなアーキテクチャ」で開発されていました。しかし、モノリシックなアーキテクチャでは、アプリケーションの機能が増えるに従って、そのコードベースも大きく、複雑化してゆくことが避けられません。複雑化したアプリケーションには「コードが複雑なため機能追加がしにくく、バグも発生しやすい」「機能が多く巨大なためテストに時間がかかる」「システム全体に影響する可能性があるため、気軽にデプロイできない」といった問題が発生しやすく、高速な開発の足枷となってしまいます。

しかし、アプリケーションを小さいサービスに分割できれば、サービスごとに独立した開発やデプロイが可能となるため、結果として開発・リリース速度の向上が期待できるのです。

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

マイクロサービスでは、分割された各サービスそれぞれが独立したアプリケーションのように振る舞います。そのため、それぞれのサービスを別々のチームで開発したり、サービスごとに異なるプログラミング言語や開発手法を採用することが可能になります。プログラミング言語には、用途によって向き不向きがあるため、サービスごとに適した言語を選択できることは、開発効率の最適化に繋がります。

マイクロサービスでは、サービスごとに負荷分散やスケールが可能です。アプリケーション全体ではなく、負荷の大きいサービスのみをスケールさせられるという柔軟性と負荷の低いサービスはスケールしなくてよいため、リソース最適化の容易さを兼ね備えています。

また、特定のサービスに障害が発生しても、その影響を局所的に抑えることができます。そのため、アプリケーション全体の耐障害性を向上させることができます。

このようにマイクロサービスには、さまざまなメリットがあります。しかし、すべてのシステムをマイクロサービス化すべきかと言えば、必ずしもそうとは言い切れないのが現実です。マイクロサービス化が、巨大なアプリケーションの複雑さを解消する有効な手段であることは間違いありません。しかし、複数のサービスが協調して動作する「正しいマイクロサービス」を設計するのは、そう簡単な事ではありません。また、マイクロサービス化によって、従来は存在しなかった「分散システム特有の複雑さ」が新たに発生することもあります。そのため小さなアプリケーションであれば、従来のモノリシックなアーキテクチャーを採用した方が、結果的にシンプルな設計に収まることも十分に考えられます。実際、「Microservices」の共同執筆者であるMartin Fowlerは、「MicroservicePremium」において「don't even consider microservices unless you have a system that's too complex to manage as a monolith.（参考訳:モノリシックとして管理できないほど複雑なシステムでない限り、マイクロサービス化は考えるな）」と述べています。

とはいえ、モノリシックなアーキテクチャーは開発・運用ともに負荷が大きく、遠からずスケールの限界が見えてくるのも事実です。大規模なシステムであれば、どこかのタイミングでアーキテクチャーを見直し「マイクロサービスに舵を切るべきか？」という判断を下す必要は出てくるでしょう。

マイクロサービス化に必要な要素

マイクロサービスとはあくまで、考え方やアーキテクチャのスタイルに過ぎません。そのため、マイクロサービスを実現するためには、さまざまな要素の新規導入が必要となります。

マイクロサービスは複数のサービスが連携して動きます。つまり、あるサービスの機能をサービス外から呼び出せるよう、機能ごとに「API」を用意して公開する事が必要不可欠です。

マイクロサービス化の目的の1つが、開発・運用サイクルを効率よく回すことである以上、古典的なウォーターフォール開発では、そのメリットを十分に引き出すことができません。「アジャイル」や「DevOps」といった開発手法の導入も必要です。これは開発プロセスそのものが大きく変化することを強いられるため、組織や企業文化がこうした変化を受け入れられるのかという点も問われてきます。

テストやデプロイを人間が手作業で行っていては、そこがボトルネックになってしまい、高速に開発・運用サイクルを回すことができません。「CI/CD」やインフラ構築の自動化といった技術も導入する必要があるでしょう。

マイクロサービスにおける注意点

開発担当と運用担当が緊密に連携して、柔軟かつスピーディーにシステム開発を行う手法である「DevOps」が定着しつつありますが、このDevOpsを実現する上でもマイクロサービスは重要な要素となっています。しかし、前述の通り、すべてのシステムを今すぐマイクロサービス化すればよいというわけではありません。そもそも巨大化したモノリシックなアプリケーションをマイクロサービスに切り出すのは、一朝一夕にできることではないため、長期的かつ段階的な取り組みが重要となるでしょう。

また、マイクロサービス化したからといって、複雑なアプリケーションが自動的にシンプルな設計になるわけではないということに注意してください。機能同士が複雑にからみ合うアプリケーションをそのままマイクロサービス化したところで、出来上がるのは「サービス同士が複雑にからみ合うマイクロサービス」になることでしょう。マイクロサービスは、アプリケーションを分割することで「シンプルな設計を作りやすくする」のであり、あくまでも大事なのはアプリケーション側の設計なのです。マイクロサービスは複雑さを解消するための「銀の弾丸」ではないということは、肝に命じておくべきです。

上手くマイクロサービス化が進むと、今度は新たに「サービスが乱立して管理が煩雑になる」という問題が発生することも考えられます。そこで、サービスを管理するためにサービスメッシュの導入なども検討するとよいでしょう。マイクロサービスの各サービスは、コンテナを利用してデプロイするのが一般的となっています。コンテナの管理もサービス同様に煩雑となりがちなため、コンテナのオーケストレーションシステムの利用は事実上必須と言えます。サービスのプラットフォームとして、デファクトスタンダードとなっている「Kubernetes(k8s)」の導入も、併せて検討するのがお勧めです。