マイクロサービス: クラウドが支えるアプリケーション革命

Article
03/25/2016

執筆者: Mark Russinovich (CTO, Microsoft Azure)

このポストは、3 月 17 日に投稿された Microservices: An application revolution powered by the cloud の翻訳です。

現在、アプリケーション開発や IT システム管理の分野では、クラウドによる革命が進行しています。高速で俊敏性があり、大規模なスケーリングが可能な低コストのインフラストラクチャが、完全セルフサービス型の従量課金制サービスとして提供されているため、さまざまな業界で運用効率の向上や迅速な価値実現が可能となっています。短時間でのセットアップ、アプリケーションの標準パッケージ化、分離モデルという特性を備えたコンテナーが登場したことにより、効率性と俊敏性はいっそう高まっています。

しかしそれでも、多くの企業にとって高度な可用性やスケーラビリティ、俊敏性を持つアプリケーションの構築は困難なことです。競争の激しいビジネス環境においては、アプリケーションの継続的な進化が強く求められ、さまざまな新機能を追加しながら 24 時間 365 日体制の運用を維持する必要があります。たとえば、銀行の Web サイトの場合、数年前までは当たり前だったメンテナンス期間が今では許容されなくなっています。同様に、E コマースサイトのサービスが短時間でも停止すると、そのときにサービスを提供できている競合他社に顧客が流れてしまいます。このようなニーズに対応できるかどうかで、顧客との関係を維持できるかビジネスチャンスを失うかが変わってきます。

こうした実情を受け、開発者の間では James Lewis 氏と Martin Fowler 氏 (英語) の提唱によって広まった「マイクロサービス」と呼ばれるアプリケーションアーキテクチャモデルの採用が進んでいます。この記事では、マイクロサービスアーキテクチャが、どのように、なぜ、アプリケーション開発やライフサイクル全体のタスクにとって有用なのかを説明すると共に、このアーキテクチャをサポートするプラットフォームの機能についてご紹介します。また、Azure でサポートされているマイクロサービスアプリケーションの基盤として広く使用されているプラットフォームについても取り上げます。そして最後に、マイクロサービスのライフサイクル管理に対する包括的なサポートをすぐに利用可能な形で提供するマイクロソフトのマイクロサービスアプリケーションプラットフォーム Service Fabric について説明します。

モノリシックアプリケーションモデル

アプリケーション開発には数十年にわたって、新しいハードウェアのプロビジョニングに伴うコストや時間、複雑さが物理環境でも仮想環境でも大きな影響を与えてきました。この傾向は、ミッションクリティカルなアプリケーションの場合に特に顕著に見られます。これは、SAN やハードウェアロードバランサーなどの高価なハードウェアを含む高可用性インフラストラクチャによって高い稼働率を保つ必要があるためです。たとえ仮想環境であっても、IT インフラストラクチャが静的であるため、アプリケーションは特定のハードウェアに特化したサイズと設計で構築されてきました。全体的なハードウェア要件をできるだけ低くし、ある程度の俊敏性と独立したスケーリングを実現するためにアプリケーションを分割したとしても、下図のように Web 層、ビジネスロジック層、データ層という型どおりの 3 層モデルで構成するのが一般的でした。また、それぞれの層が独自のモノリシック構造となっており、さまざまな機能が 1 つのパッケージにまとめられ、ピーク時の負荷に合わせたスケールで事前構成されたハードウェアにデプロイされます。負荷が増大しアプリケーションがハードウェアの能力を超えた場合、ハードウェアをアップグレードして能力を高める「スケールアップ」で対応するのが通例ですが、そうでなければデータセンターの再構成とソフトウェアの再構築が必要となります。

図 1. 3 層構造のモノリシックアプリケーション

モノリシックアプリケーションモデルが生まれたのは、インフラストラクチャの俊敏性に限界があったためですが、このモデルには効率の面で問題があります。インフラストラクチャが静的で開発サイクルも長いと、アプリケーションをこれ以上多くの層に分割するメリットはあまりなく、層内のそれぞれ関連性のないアプリケーションサービスが緊密に結合されてしまいます。このため、いずれかのアプリケーションサービスに変更を加える際に、たとえ小さな変更であっても、層全体をテストしデプロイし直す必要があります。ちょっとした更新でも層内の他の部分で予想外の影響が現れる可能性があるため、変更にはリスクが伴います。さらに、厳しいテストを実施する必要がある故に開発サイクルが長期化します。静的に割り当てられたリソースと高可用性ハードウェアに依存してしまうと、アプリケーションは負荷の変化やハードウェアのパフォーマンスに影響を受けやすくなり、標準的な運用範囲からの逸脱や深刻なパフォーマンス低下を招くおそれがあります。ハードウェアに由来する障害により、アプリケーション全体が制御不能に陥る可能性もあります。

層構造型モノリシックアプリケーションのもう 1 つの問題は、バックエンド層に格納されているデータの処理速度です。通常、層構造のアプローチでは中間キャッシュを導入して演算処理とデータを分離することによる効率低下を緩和しますが、使用されないハードウェアリソースの追加でコストが上昇し、開発や更新の手間が増えます。

図 2. キャッシュを持つ 3 層構造のモノリシックアプリケーション

マイクロサービスアーキテクチャ

シンプルで限定的なスケールのアプリケーションであればモノリシックモデルでも有効ですが、最新のクラウドアプリケーションの多くで求められる俊敏性、拡張性、信頼性といった要件に十分に対応するアプリケーションの開発やデプロイメントには、マイクロサービスによるアプローチが適しています。マイクロサービスアプリケーションは「マイクロサービス」と呼ばれる複数の独立したコンポーネントで構成され、それぞれが協調して動作し、アプリケーション全体の機能を実現します。「マイクロサービス」という用語は、独立した処理に完全に対応する非常に小さなサービスでアプリケーションを構築すべきであり、それぞれのマイクロサービスは機能を 1 つだけ実装するようにすべきであるという考えを強く反映しています。また、各マイクロサービスには詳細に定義されたコントラクト (API コントラクト) が存在します。これは通常 RESTful な API であり、他のマイクロサービスと通信しデータを共有するために使用されます。マイクロサービスは、他のマイクロサービスとは独立してバージョン管理や更新ができる必要もあります。このような緩い結び付きによって、信頼性を保ちながらすばやくアプリケーションを更新できるようになっています。図 3 は、モノリシックアプリケーションをマイクロサービスに細かく分割した例です。

図 3. モノリシック型からマイクロサービス型に

マイクロサービスアプリケーションは、アプリケーションを実行する基盤インフラストラクチャから分離することも可能です。モノリシックアプリケーションの場合は、開発担当者がリソースの要件を IT 担当者に伝えます。一方マイクロサービスアプリケーションでは、「クラスターマネージャー」と呼ばれる分散型ソフトウェアシステムに対してリソースの要件を宣言します。このシステムはクラスターに割り当てられたマシンにマイクロサービスを「スケジュール」(配置) し、各マイクロサービスの高可用性やデータレプリケーションの要求に対応しながら、クラスター全体のリソースを最大限に活用します。図 4 はそれを図示したものです。通常、マイクロサービスはコンテナーとしてパッケージ化され、1 つのサーバーまたは仮想マシンに多数のサービスを実装できるため、速やかなデプロイメントが可能であり、高密度に実装してクラスターのスケール要件を最小限に抑えることもできます。

図 4. マイクロサービスがデプロイされたサーバーのクラスター

マイクロサービスモデルではほぼ瞬時のスケールアウトが可能なため、負荷の変化に対応できます。また、マイクロサービスどうしの結び付きが緩いため、それぞれを独立してスケーリングすることもできます。たとえば、受信トラフィックの増加に対処する場合、アプリケーションの中でスケールアウトするマイクロサービスは、Web に接続している部分のマイクロサービスであるパブリックエンドポイントの HTTP リスナーだけでよいのです。

個々のマイクロサービスが独立し分散されているという特性のおかげで、ローリングアップデートも可能であり、1 つのマイクロサービスに対応する一部のインスタンスのみを任意のタイミングでアップデートできます。問題が検出された場合は、そのアップデートを「ロールバック」して元に戻すことができるため、コードや構成に問題がないかどうかを確認したうえですべてのインスタンスにアップデートを適用できます。アップデートを自動化して継続的インテグレーション (CI) と継続的デリバリ (CD) のパイプラインと統合すれば、可用性への影響を避けながらアプリケーションを安全かつ頻繁に更新することが可能です。

従来のモデルでは、アプリケーションにスケーラビリティを持たせるには負荷分散されたステートレスな階層構造にし、外部のデータストアやデータベースを共有して永続的にデータを格納する必要がありましたが、ステートフルなマイクロサービスでは、より高いパフォーマンス、低レイテンシ、大規模なスケールを実現しながら、サービス更新の俊敏性を維持することができます。ステートフルなマイクロサービスでは一般的に、永続的なデータをサーバーのローカルに格納して管理するため、ネットワークへのアクセスによるオーバーヘッドが発生せず、運用が複数のサービスにまたがって複雑になることもありません。このため非常に高速な処理が可能となり、キャッシュは不要になります。また、マイクロサービスではデータを複数のインスタンスに分割することで、1 台のサーバーでサポート可能な範囲以上のデータサイズや転送スループットを管理します。さらに、スキーマのバージョン管理を実装することで、クライアントから見るバージョンは、更新中であっても、どのマイクロサービスインスタンスと通信していても、一貫性が保たれます。

マイクロサービスアプリケーションプラットフォーム

マイクロソフトは Bing、Cortana、Intune などのサービスをクラウド規模で運用してきたため、クラウド向けの大規模アプリケーションの設計、開発、デプロイメントに伴う複雑さを実体験としてよく知っています。常時稼働している大規模アプリケーションを頻繁に更新することは、アプリケーションの設計がどれほどよくても簡単ではありません。マイクロサービスという手法のメリットを存分に活用するには、マイクロサービスの概念をただ仮想マシンやコンテナーに落とし込むだけでなく、DevOps に特化したツールを備えたマイクロサービスアプリケーションプラットフォームが必要となります。

豊富な機能を備えたマイクロサービスアプリケーションプラットフォームは、コスト効率、スケーラビリティ、365 日 24 時間体制の可用性といった、前述のマイクロサービスアーキテクチャが持つあらゆるメリットを提供します。それ以外にも、先に述べたように拡張可能な正常性モデルや自動ロールバック機能によって、更新時の安全性や信頼性を確保します。さらに、ネームサービスを提供することでマイクロサービスどうしの検出を可能にし、正常性の監視や保守を行います。たとえば、スケーリングや修復の際に、更新された配置情報をマイクロサービスプラットフォームがネームサービスを介してマイクロサービスに通知することで、マイクロサービス間の通信がすばやく確立 (または再確立) されます。

マイクロサービスを実行しているソフトウェアやハードウェアで障害が発生した場合や、アップグレードで再起動が必要な場合、プラットフォームはマイクロサービスの正常性を維持するために、自動的にインスタンスを正常な VM やサーバーに移動します。また、プライベートクラウドとパブリッククラウドの両方にデプロイ可能なため、ハイブリッドシナリオにも対応します。たとえば、ワークロードの負荷が急上昇してプライベートクラウドからパブリッククラウドに処理を移したり、プライベートクラウドの運用環境デプロイメントでパブリッククラウドの開発やテストを行ったりできます。複数の種類のクラウドがサポートされることで、プラットフォームがインフラストラクチャから分離され、アプリケーションプラットフォームを選択するときのベンダーロックインも回避できます。

図 5. マイクロサービスプラットフォーム

以降のセクションでは、現在実際にマイクロサービスアプリケーションの開発やデプロイメントに使用されている一般的なプラットフォームをいくつか簡単にご紹介します。下記のプラットフォームはすべて Azure インフラストラクチャで実行可能ですので、皆様の要件に合わせてお選びいただけます。

Docker Swarm と Docker Compose

Docker コンテナーにおける標準的なパッケージ形式とリソース分離のしくみは、マイクロサービスアーキテクチャに最適です。Docker Compose では Docker でパッケージ化された複数のマイクロサービスをサポートするアプリケーションモデルを定義できます。クラスターマネージャーの役割を担う Docker Swarm (英語) では、1 ノードに Docker をインストールする場合と同じ手法でインフラストラクチャ全体を管理して、Docker の幅広いツールエコシステムと連携させることができます。Azure Container Service では Docker Swarm と Docker Compose の両方をサポートしています。Azure で実行する場合の詳細については、こちらのページ (英語) を参照してください。

Kubernetes

Kubernetes はコンテナー化されたアプリケーションのデプロイメント、運用、スケーリングを自動化するオープンソースシステムであり、コンテナーをグループ化してアプリケーションを論理ユニットにまとめ、管理や検出を容易にします。このプラットフォームはもともと Google が開発したもので、Search や Gmail などの大規模サービスを運用した経験に基づいて構築されています。Apprenda (英語) などの実績のある PaaS ソリューションでも Kubernetes を採用する動きがあります。Azure で Kubernetes を実行する場合の詳細については、こちらのページ (英語) を参照してください。

Mesosphere DCOS (Apache Mesos/Marathon を含む)

マイクロソフトは Mesosphere と提携し、Apache Mesos と Marathon を含む Mesosphere Datacenter Operating System (DCOS) (英語) のオープンソースコンポーネントを Azure に統合しています。Mesos をベースに構築された Mesosphere DCOS はスケーラブルなクラスターマネージャーで、運用環境に対応したコンテナーオーケストレーションツールの Mesosphere Marathon を含みます。Azure Container Service (英語) の一部として利用可能であり、Azure で実行可能なエンタープライズバージョンも Mesosphere から提供されています。Mesosphere DCOS では、サービス検出、負荷分散、正常性チェック、配置制限、メトリクスの集中管理などのマイクロサービスプラットフォーム機能を使用できます。また、Kafka、Chronos、Cassandra、Spark などの追加機能を提供する認定済みライブラリも Mesosphere から提供されており、いずれも 1 つのコマンドで簡単にインストールできます。Azure で実行する場合の詳細については、こちらのページを参照してください。

OpenShift

Red Hat が提供する OpenShift (英語) は、Docker コンテナーを基盤とするパッケージを活用して Kubernetes 向けのコンテナーオーケストレーションや演算管理機能をデプロイする PaaS です。コンテナー化された JBoss Middleware、複数のプログラミング言語、データベース、その他のアプリケーションランタイムを実行することができます。OpenShift Enterprise 3 で提供される DevOps エクスペリエンスでは、安全性の高いエンタープライズクラスのアプリケーションインフラストラクチャ内でアプリケーションのビルド処理やデプロイメント処理を自動化することができます。最近 Red Hat Enterprise Linux イメージが Azure でサポートされるようになったため、OpenShift も Azure でサポートされます。この件については、近日中にドキュメントを公開する予定です。

Pivotal Cloud Foundry

Pivotal Cloud Foundry は、Cloud Foundry のコンテナーのスケジュール機能とワークフローを、サービス検出、クライアント側での負荷分散、サーキットブレーカー、分散型トレースなどのマイクロサービスのパターン用の統合と組み合わせることによってマイクロサービスアーキテクチャを実現するもので、Spring Cloud と NetflixOSS を利用しています。Pivotal Cloud Foundry は、自動スケーリング、ブルーグリーンデプロイメントによる更新、正常性監視、アプリケーションメトリクス、ストリーミングログといった、デプロイメントやサービスの管理機能を通じて、継続的なマイクロサービスの運用をサポートします。Azure で Pivotal Cloud Foundry を実行する場合の詳細については、こちらのページを参照してください。

Service Fabric

マイクロソフトが社内でのオンプレミスからクラウドへの移行と、モノリシックアプリケーションからマイクロサービスアプリケーションへの変革をサポートするために Service Fabric を開発したのは 10 年以上前のことです。Service Fabric は SQL DB、DocDB、Intune、Cortana、Skype for Business などの多数のマイクロソフト製ハイパースケールクラウドサービスや、社内向けの各種 Azure インフラストラクチャサービスで使用されています。それとまったく同じテクノロジを使用して、「サービスとしての Service Fabric」を Azure でリリースし、Service Fabric アプリケーションをオンプレミスのクラスターやその他のクラウドにデプロイできるようにするスタンドアロン型の SDK を提供しています。初回のリリースでは、任意の .NET 言語による Windows 上での実行に対応しており、Linux および Java のサポートに向けて現在開発作業を進めています。Service Fabric にはライフサイクル管理、ハイブリッドデプロイメント、24 時間 365 日体制の可用性のサポートが組み込まれているほか、Visual Studio による開発エクスペリエンスが統合されています。プラットフォームにはインフラストラクチャとマイクロサービスの両方に対する拡張可能な正常性モデルが備えられているため、正常性に基づく自動アップグレードや自動ロールバックに対応しており、簡単に DevOps を進めることができます。さらに Service Fabric ではステートレスとステートフルの両方のマイクロサービスに対応しているため、リーダー選出機能によってデータの整合性をサポートし、ステートレプリケーションフレームワークによってステートフルなデータを保証するトランザクションをサポートしています。Azure で Service Fabric を実行する場合の詳細については、こちらのページを参照してください。

まとめ

コンピューティングの世界はクラウドの登場によりその形が一変しました。クラウドではほぼ無制限のスケールで、低コストかつ瞬時にインフラストラクチャを利用することができます。高可用性と俊敏性に対する現代の企業ニーズと俊敏性というクラウドの特性が相まることでモノリシックアーキテクチャの限界が見え始めた今、マイクロサービスアプリケーションの普及が進んでいます。包括的なマイクロサービスプラットフォームを使用すれば、大規模なスケールに対応したパフォーマンス、可用性、コスト効率に優れたアプリケーションを構築できるほか、独立したライフサイクル管理と、パブリッククラウドとプライベートクラウドへの対応を実現できます。マイクロサービスは、クラウドが支えるアプリケーション革命なのです。

下の Channel 9 ビデオでは Seth Juarez がマイクロサービスについて説明しています。ぜひご覧ください。

[embed]https://sec.ch9.ms/ch9/56d9/d3d93b9d-dbed-42c1-be59-b1ba622c56d9/20160310MarkRPart01_mid.mp4[/embed]