ソフトウェア開発の世界に関わる人なら、間接的はであっても、「マイクロサービス」という言葉を聞いたことがあるはずだ。しかし、これは一体どのようなものなのだろうか。
かつて、アプリケーションはモノリシックアーキテクチャーで開発されていた。つまり、すべての依存関係、サブルーチン、ライブラリー、必要なコードスニペットを、アプリに直接組み込む必要があったということだ。これらの要素のどれか1つに問題が発生すると、アプリケーション全体がクラッシュして停止する場合もある。
モノリシックなソフトウェアの問題は、それだけではない。単純なアップデートのために、ITチームが何時間もかけてデータソースを再接続し、クライアントへのアップデート適用を確認して、少量の新しいコードが予期せぬ場所で引き起こす不測の問題に対処しなければならない場合がある。
要するに、ソフトウェア開発で長らく問題となっていたのは、すべてを1カ所でプログラミングしなければならないという点であり、そのためのソフトウェアアーキテクチャーのスタイルは、現代のクラウドベースのコンピューティングのニーズに対応しない。これに代わる開発手法が、マイクロサービスアーキテクチャーだ。
どんなものなのか
マイクロサービスアーキテクチャーは複雑だ。IBMなどの企業がマイクロサービスについて説明した記事やブログ投稿の多くでは、マイクロサービスの単一の定義を決めるのは難しい、という主張がなされている。
筆者が見た中で最も納得できた定義の1つは、ソフトウェア開発者のMartin Fowler氏による定義だ。Fowler氏はマイクロサービスアーキテクチャーを次のように説明している。「単一のアプリケーションを小さなサービスのスイートとして開発するアプローチのこと。各サービスは独自のプロセスで実行され、軽量のメカニズム（多くの場合、HTTPリソースAPI）と通信する」
コンピューティングのクラウド移行が進む今、マイクロサービスは特に有用であり、モノリシックなアプリケーションの維持は困難で時代遅れになっている。すべてを1つのクラウドに集中させてしまうと、スケーリングや変更の能力が制限され、安定性が低下することになりかねない。
モノリシックなアプリケーションをスケーリングするには新しいサーバー上に完全な複製を作成しなければならず、コンピューティングリソースが大量に消費される、とFowler氏は指摘した。一方、マイクロサービスアーキテクチャーの場合は、独立した小規模のコンポーネントをさまざまなサーバーに展開して、そこで必要に応じてスケーリングや複製が可能だ。
IBMは、マイクロサービスの仕組みをさらに踏み込んで説明している。同社の定義では、「緩く結合され、独立して展開可能な小さなコンポーネントやサービス」からアプリケーションを構築するクラウドネイティブのアプローチであり、こうした構成要素には以下のような特徴があるという。
独自のスタックを持つ。
REST APIなどの通信方法を使用して他のサービスに接続する。
ビジネス機能別に分類され、境界づけられたコンテキストによって「知る必要のある」塊に分割される。
モノリシックのアプローチの代わりにマイクロサービスのアプローチを選択する利点は、モノリシック設計との対比から推測可能なものもあるが、説明しておく価値はある。
各コンポーネントは独立して機能するため、そのコンポーネントの開発者が好む言語で構築することができる。
個々のコンポーネントの内部での動作は、アプリ全体にとっては重要でないため、コンポーネントを個別にアップデートできる。コンポーネントが正しいデータを返す限り、アプリは機能し続ける。
スケーリングをコンポーネント別に実行可能。単一のコンポーネントの負荷に対応するために、時間とコンピューティングリソースを費やしてアプリケーション全体を複製する必要はない。
アプリケーションのニーズに対応できなくなったコンポーネントは、アプリ全体に影響を与えずに置き換えることができる。
アプリケーションは、複数のクラウドプロバイダー、サーバー、その他のローカルとリモートのサービスの間で分散させることができる。
