マイクロサービスは、クラウド アプリケーションを作成するアーキテクチャ アプローチです。各アプリケーションは一連のサービスとして構築され、各サービスは独自のプロセスで実行され、 API を通じて通信します。クラウド マイクロサービス アーキテクチャに至るまでの進化は、20年以上前に始まりました。サービス構造の概念はコンテナよりも古く、現代のWebアプリケーションの時代以前から存在しています。マイクロサービス アーキテクチャは、時間の経過とともにベスト プラクティスに成熟したアプリケーションを開発する方法です。
現在利用されているマイクロサービス アーキテクチャのメリットを理解するには、まずその起源について理解することが重要です。
モノリシック アプリケーション
もともとは、各アプリケーションが単一のサーバ上に存在し、次の3つのレイヤで構成されていました。
これらのレイヤは、データセンター内の単一のモノリシック サーバ上に配置された単一の連結スタック内に構築されていました。このパターンは、業界のあらゆる業種やテクノロジ アーキテクチャで一般的に使用されていました。一般にアプリケーションとは、たとえば、データベース、さまざまなタイプのビジネス ロジック、グラフィック レンダリング コード、ロギングなど、特定の機能を提供するコード モジュールの集合体です。
このようなモノリシック アーキテクチャでは、ユーザはプレゼンテーション レイヤにアクセスし、プレゼンテーション レイヤはビジネス ロジック レイヤとデータベース レイヤにアクセスし、情報はスタックをバックアップしてエンド ユーザに送信されます。これはアプリケーションを整理するには効率的でしたが、多くの単一点障害が発生し、ハードウェア障害やコード バグが発生した場合にシステムが長時間停止する可能性がありました。残念ながら、この構造には「自己回復機能」が存在しなかったため、システムの一部が破損した場合は、ハードウェアまたはソフトウェアを人間の手によって修復する必要がありました。
さらに、これらのレイヤのいずれかを拡張するには、新しいサーバ全体を購入する必要がありました。単一のサーバで実行されているモノリシック アプリケーションを購入し、ユーザの一部を新しいシステムに分割する必要がありました。このセグメント化により、ユーザ データがサイロ化し、夜間に実行されるバッチ レポートで調整する必要が生じました。ありがたいことに、Webページやモバイル アプリケーションが普及するにつれて、クライアントのニーズは減少し、アプリケーション開発の新しい手法が出現してきました。
サービス指向アーキテクチャ（SOA）
2000年代半ばまでにアーキテクチャは変化し始め、さまざまなレイヤが単一サーバの外で独立したサービス サイロとして存在していました。アプリケーションは、通信にエンタープライズ サービス バスを使用してこれらのサービスを統合できるよう設計されました。このアプローチにより、管理者はプロキシ機能を使用してサーバを集約し、これらのサービスを個別に拡張できるようになりました。また、エンジニアがアプリケーション サービス構造の一部だけに集中できるので、開発サイクルを短縮することもできました。サービスを分離し、独立した開発を可能にするには、サービスが相互通信できるように一連の構文規則であるAPIを使用する必要がありました。
また、仮想マシン（VM）の登場に伴い、物理サーバ リソースの効率が向上しました。ベアメタル サーバ上にある従来のモノリシック アプリケーションよりも小規模なVMに対して、はるかに迅速にサービスを導入できるようになりました。このようなテクノロジの組み合わせにより、サービス アーキテクチャと関連するインフラ テクノロジの両方で、優れた高可用性（HA）ソリューションが開発されました。
マイクロサービス
今日のクラウド マイクロサービスでは、SOA戦略をさらに細かく機能的なサービスの集合体として分類しています。マイクロサービスの集合は大規模なマクロ サービスに結合されるため、サービス全体または大規模なエンドユーザ アプリケーションで単一の関数のコードを迅速に更新する機能がさらに向上します。マイクロサービスは、データ検索、ロギング機能、Webサービス機能など、個別の問題に対処します。このアプローチでは、柔軟性が向上します。たとえば、マイクロサービス アーキテクチャの残りの部分をリファクタリングしたり再導入したりすることなく、単一の機能のコードを更新できます。障害ポイントはそれぞれ独立しているため、アプリケーション アーキテクチャ全体の安定性が向上します。
このアプローチでは、マイクロサービスが自己回復型となる場合もあります。たとえば、1つのクラスタ内のマイクロサービスに3つのサブ機能が含まれているとします。これらのサブ機能の1つに障害が発生した場合、自動的に修復されます。Kubernetesなどのオーケストレーション ツールを使用すると、手動操作なしで自己修復を実行できます。自己修復はバックグラウンドで自動的に実行され、エンドユーザに対して透過的に実行されます。
マイクロサービス アーキテクチャは、パッケージ化と導入の構成要素であるDockerコンテナとともに使用されるようになりました。VMイメージは、長年にわたって導入メカニズムとして使用されてきましたが、コンテナはVMよりも効率的で、コード（および必要なコードライブラリ）を任意のLinuxシステム（またはDockerコンテナをサポートする任意のOS）に導入できます。コンテナはマイクロサービスへの導入に最適です。数秒で導入できるため、障害や移行後に迅速に再導入でき、ニーズに合わせてすばやく拡張できます。コンテナはLinuxにネイティブであるため、コモディティ ハードウェアは、任意のデータセンター、プライベート クラウド、ハイブリッド マルチクラウド内のマイクロサービスの大規模ファームに適用できます。
マイクロサービスは当初からクラウド ネイティブ アーキテクチャと連携されていたため、多くの点で区別がつかなくなっています。マイクロサービスとコンテナは抽象化されているため、互換性のあるOS（通常はLinux）で実行できます。このOSは、パブリック クラウド、オンプレミス、仮想ハイパーバイザー、ベア メタルなど、あらゆる場所に配置できます。クラウドでの開発が進むにつれて、クラウドネイティブのアーキテクチャと手法はオンプレミスのデータセンターにも採用されるようになりました。多くの組織では、クラウドの基本特性を共有できるようにローカル環境を構築することで、場所を問わず、またはクラウドネイティブな環境で単一の開発プラクティスを実現しています。このクラウドネイティブなアプローチは、マイクロサービス アーキテクチャとコンテナ テクノロジを採用することで実現される必須のアプローチです。
マイクロサービスは分散化されており、さまざまな種類のサーバ上で実行されますが、アプリケーションに対しては連携して機能します。理想的には、各マイクロサービスが単一の機能を提供し、API通信によるサービス間のシンプルなルーティングを可能にします。マイクロサービスにはその他にも、次のようなメリットがあります。
コンテナ
コンテナは書き換え不可なため、導入後は変更できません。新しいバージョンのコードが利用可能になると、コンテナは破棄され、最新のコードを持つ新しいコンテナがその場所に導入されます。コンテナは数秒または数ミリ秒で起動できるため、必要なときに必要な場所に追加のサービス コンポーネントをすぐに導入できます。VMやベアメタルに比べてリソースのフットプリントが小さいため、コンテナはマイクロサービスに最適な導入メカニズムといえます。VMにはすべてのOSコンポーネントが含まれていますが、 コンテナはマイクロサービス コード自体とサポート コード ライブラリのみで構成されます。その他の必要な機能は、コンテナ内で実行される他のマイクロサービスと共通のOS上で共有されます。
オーケストレーション
コンテナ オーケストレーション ツールは、コンテナとほぼ同じくらい長く使用されてきました。数千ものマイクロサービスが連携してサービスやアプリケーションを形成しているため、管理者が数多くいる場合でも手動で管理することはほぼ不可能です。IT担当者の予算はほぼ横ばいで、自動化の普及やDevOps手法の採用が進んでいることから、優れたオーケストレーション ツールの必要性が何よりも重要視されています。
Dockerコンテナの台頭直後の2015年に、最初のバージョンのKubernetes（K8s）がリリースされ、すぐにコンテナ環境の主要なオーケストレーション ツールになりました。Kubernetesを使用すると、開発者はコンテナベースのアプリケーションまたはマイクロサービスを共通ライブラリに登録し、Kubernetesコントローラにマニフェスト ファイルを提供できます。Kubernetesは共通レジストリ内のコンテナ イメージを使用して、マニフェスト ファイルの仕様に従ってアプリケーションをワーカー ノードに導入します。
Kubernetes の主要な概念である「Desired State（理想の状態）」は、自己回復機能と自動アップグレード機能をソリューションに組み込むことを可能にします。たとえば、バージョン1.1の特定のマイクロサービス（コンテナ ポッド内）のインスタンスが常に10個実行されている必要があるとします。Kubernetesは、理想の状態を維持できるよう環境を監視します。コンテナの1つに障害が発生し、9つしか実行されていない場合、Kubernetesは別のコンテナを導入して起動し、バージョン1.1で10個のインスタンスが実行されている「理想の状態」を実現します。マニフェストがバージョン1.2を指定するように変更された場合、Kubernetesは理想の状態の条件が満たされていないとみなし、10個すべてのインスタンスをバージョン1.2にローリング アップグレードします（バージョン1.2がコンテナ レジストリで使用可能なイメージであると仮定）。
このように、Kubernetesが急速に拡大してコンテナ オーケストレーション分野で主要なツールとなり、すべての主要なパブリック クラウド プロバイダ（Amazon Web Services、Microsoft Azure、Google Cloud Platform）で独自のバージョンのKubernetesが使用されているのには、納得できる理由があります。