マイクロサービス入門

NGINX | 2015年5月19日

Microservices March 2023の参加登録を受け付けています。アジェンダを確認し、こちらからお申し込みください。

編集部 – 全7回の記事シリーズが完結しました：

一連の記事に加え、NGINX Plusを使用したマイクロサービスの実装に関する情報を収録した電子書籍「マイクロサービス：設計からデプロイまで」もダウンロードできます。

F5の「Microservices」ソリューションページもご覧ください。

現在、マイクロサービスは、記事、ブログ、ソーシャルメディアでの議論、カンファレンスでの講演などで大きな注目を集めています。マイクロサービスは、Gartnerのハイプ・サイクルにおける「過度な期待」のピークへと急速に近づいています。一方、ソフトウェアコミュニティには、マイクロサービスには目新しさがないと一蹴する懐疑的な見方もあります。否定的な人々は、この考え方はSOAの名称を変えただけだと主張しています。しかし、こうした過熱した期待や懐疑論があるにもかかわらず、マイクロサービスアーキテクチャパターンには大きなメリットがあります。特に、複雑なエンタープライズアプリケーションのアジャイルな開発とデリバリーを可能にする点で有効です。

このブログ記事は、マイクロサービスの設計、構築、デプロイについて解説する全7回シリーズの第1回です。このアプローチと、より従来型のモノリシックアーキテクチャパターンとの違いを説明します。本シリーズでは、マイクロサービスアーキテクチャを構成するさまざまな要素を取り上げます。マイクロサービスアーキテクチャパターンのメリットとデメリット、プロジェクトに適しているかどうか、適用方法について解説します。

まず、マイクロサービスの利用を検討すべき理由を見ていきましょう。

モノリシックアプリケーションの構築

UberやHailoに対抗する、まったく新しいタクシー配車アプリケーションの構築を始めるとします。事前の打ち合わせと要件収集を終えたら、手動で、またはRails、Spring Boot、Play、Mavenに付属するジェネレーターを使用して、新しいプロジェクトを作成します。この新しいアプリケーションは、次の図のようなモジュール式の「ヘキサゴナルアーキテクチャ」を採用します。

サンプルのマイクロサービスアプリケーションの基盤として使用される、モジュール化されているものの依然としてモノリシックなアーキテクチャ

アプリケーションの中核にはビジネスロジックがあり、サービス、ドメインオブジェクト、イベントを定義するモジュールによって実装されています。その中核を取り囲むのは、外部と連携するアダプターです。アダプターの例としては、データベースアクセスコンポーネント、メッセージを生成および受信するメッセージングコンポーネント、APIを公開する、またはUIを実装するWebコンポーネントなどがあります。

論理的にはモジュール型のアーキテクチャを採用していますが、アプリケーションはモノリスとしてパッケージ化され、デプロイされます。実際の形式は、アプリケーションの言語とフレームワークによって異なります。たとえば、多くのJavaアプリケーションはWARファイルとしてパッケージ化され、TomcatやJettyなどのアプリケーションサーバーにデプロイされます。ほかのJavaアプリケーションは、自己完結型の実行可能JARとしてパッケージ化されます。同様に、RailsおよびNode.jsアプリケーションは、ディレクトリ階層としてパッケージ化されます。

このスタイルで作成されたアプリケーションは非常に一般的です。IDEをはじめとする各種ツールは単一のアプリケーションの構築を前提としているため、開発も容易です。この種のアプリケーションはテストも簡単です。アプリケーションを起動し、SeleniumでUIをテストするだけで、エンドツーエンドテストを実施できます。モノリシックアプリケーションはデプロイも容易です。パッケージ化したアプリケーションをサーバーにコピーするだけです。また、ロードバランサーの背後で複数のインスタンスを実行することで、アプリケーションをスケールできます。プロジェクトの初期段階では、この方式がうまく機能します。

モノリシック地獄への道

残念ながら、このシンプルなアプローチには大きな制約があります。成功したアプリケーションは時間とともに成長し、やがて巨大化する傾向があります。開発チームはスプリントのたびにいくつかのストーリーを追加で実装します。当然、それに伴ってコードの行数も大幅に増えていきます。数年後には、小規模でシンプルだったアプリケーションが、巨大で手に負えないモノリスへと成長しているでしょう。極端な例ですが、先日、数百万行のコード（LOC）で構成されたアプリケーション内にある数千ものJAR間の依存関係を分析するツールを開発している方と話す機会がありました。このような怪物を生み出すには、多数の開発者が長年にわたって力を合わせる必要があったに違いありません。

アプリケーションが大規模で複雑なモノリスになると、開発組織は深刻な問題に直面する可能性があります。アジャイルな開発とデリバリーを試みても、うまくいかなくなります。大きな問題の1つは、アプリケーションがあまりにも複雑になることです。規模が大きすぎて、1人の開発者が全体を完全に理解することはできません。その結果、バグを修正し、新機能を正しく実装することが難しくなり、多くの時間を要します。さらに、これは悪循環に陥りがちです。コードベースを理解するのが難しければ、変更も正しく行われません。最終的には、巨大で理解不能な「泥団子」のようなシステムになってしまいます。

アプリケーションの規模が大きいこと自体も、開発の遅れにつながります。アプリケーションが大きくなるほど、起動時間も長くなります。たとえば、最近の調査では、起動に最長12分かかると回答した開発者もいました。また、起動に最長40分かかるアプリケーションがあるという話も耳にしています。開発者がアプリケーションサーバーを頻繁に再起動しなければならない場合、1日の多くを待ち時間に費やすことになり、生産性が低下します。

大規模で複雑なモノリシックアプリケーションには、継続的デプロイの妨げになるという問題もあります。現在、SaaSアプリケーションでは、変更を1日に何度も本番環境へ反映することが最先端の手法となっています。しかし、複雑なモノリスでは、一部を更新するだけでもアプリケーション全体を再デプロイする必要があるため、これは極めて困難です。前述した起動時間の長さも、その妨げになります。また、変更による影響を十分に把握できないことが多いため、大規模な手動テストが必要になる可能性があります。その結果、継続的デプロイはほぼ不可能になります。

モノリシックアプリケーションでは、モジュールごとに必要なリソースが競合する場合、スケーリングが難しくなることもあります。たとえば、あるモジュールにCPU負荷の高い画像処理ロジックが実装されている場合、Amazon EC2 Compute Optimized instancesへのデプロイが最適です。一方、別のモジュールがインメモリデータベースである場合は、EC2 Memory-optimized instancesが最適です。しかし、これらのモジュールはまとめてデプロイされるため、ハードウェアの選択で妥協せざるを得ません。

モノリシックアプリケーションには、信頼性の問題もあります。すべてのモジュールが同じプロセス内で実行されるため、いずれかのモジュールにメモリリークなどのバグがあると、プロセス全体が停止する可能性があります。さらに、アプリケーションのすべてのインスタンスが同一であるため、そのバグはアプリケーション全体の可用性に影響します。

最後に、モノリシックアプリケーションでは、新しいフレームワークや言語の採用が極めて困難です。たとえば、XYZフレームワークを使用して記述されたコードが200万行あるとします。新しいABCフレームワークの方が大幅に優れていたとしても、アプリケーション全体をそのフレームワーク向けに書き直すには、膨大な時間とコストがかかります。そのため、新しいテクノロジーの採用には非常に高い障壁があります。結果として、プロジェクト開始時に選択したテクノロジーを使い続けざるを得ません。

要約すると、成功を収めたビジネスクリティカルなアプリケーションが、理解できる開発者がほとんど、あるいはまったくいないほど巨大なモノリスへと成長してしまったということです。時代遅れで生産性の低いテクノロジーを使用しているため、優秀な開発者の採用も困難です。また、アプリケーションはスケーリングが難しく、信頼性にも欠けます。その結果、アプリケーションをアジャイルに開発し、デリバリーすることができません。

では、どう対処すればよいのでしょうか？

マイクロサービスの複雑さに対処する

Amazon、eBay、Netflixなど、多くの組織は、現在「マイクロサービスアーキテクチャパターン」として知られる手法を採用することで、この問題を解決してきました。巨大な単一のモノリシックアプリケーションを構築するのではなく、アプリケーションを相互接続された小規模なサービス群に分割するという考え方です。

通常、サービスには、注文管理や顧客管理など、明確に区別された一連の機能が実装されます。各マイクロサービスは、ビジネスロジックと各種アダプターで構成される独自のヘキサゴナルアーキテクチャを備えたミニアプリケーションです。一部のマイクロサービスは、他のマイクロサービスやアプリケーションのクライアントが利用するAPIを公開します。また、Web UIを実装するマイクロサービスもあります。実行時には、各インスタンスは多くの場合、クラウドVMまたはDockerコンテナとして稼働します。

たとえば、前述のシステムを分割する方法の一例を次の図に示します。

各マイクロサービスがRESTful APIを提供する、配車アプリのサンプル用マイクロサービスアーキテクチャ

アプリケーションの各機能領域は、それぞれ独立したマイクロサービスとして実装されるようになりました。さらに、Webアプリケーションは、よりシンプルな複数のWebアプリケーションに分割されます（配車サービスの例では、乗客向けとドライバー向けなど）。これにより、特定のユーザー、デバイス、または専門的なユースケースに応じて、個別のエクスペリエンスを容易に展開できます。

各バックエンドサービスはREST APIを公開しており、ほとんどのサービスは他のサービスが提供するAPIを利用します。たとえば、Driver ManagementはNotificationサーバーを使用して、対応可能なドライバーに配車候補を通知します。UIサービスは、Webページをレンダリングするために他のサービスを呼び出します。また、サービス間で非同期のメッセージベース通信を使用する場合もあります。サービス間通信については、本シリーズの後半で詳しく説明します。

一部のREST APIは、ドライバーと乗客が使用するモバイルアプリにも公開されています。ただし、これらのアプリはバックエンドサービスに直接アクセスしません。代わりに、通信はAPI Gatewayと呼ばれる仲介機能を介して行われます。API Gatewayは、負荷分散、キャッシュ、アクセス制御、API使用量の計測、監視などを担い、NGINXを使用して効果的に実装できます。このシリーズの後続記事では、API Gatewayについて説明します。

マイクロサービスアーキテクチャパターンは、Scale CubeのY軸スケーリングに相当します。Scale Cubeは、優れた書籍『The Art of Scalability』で紹介されている、スケーラビリティの3次元モデルです。ほかの2つのスケーリング軸は、ロードバランサーの背後でアプリケーションの同一コピーを複数実行するX軸スケーリングと、リクエストの属性（行の主キーや顧客IDなど）を使用して特定のサーバーにリクエストをルーティングするZ軸スケーリング（データパーティショニング）です。

通常、アプリケーションでは3種類のスケーリングを組み合わせて使用します。Y軸スケーリングでは、このセクションの最初の図に示すように、アプリケーションをマイクロサービスに分割します。実行時には、X軸スケーリングにより、スループットと可用性を確保するため、各サービスの複数のインスタンスをロードバランサーの背後で実行します。アプリケーションによっては、Z軸スケーリングを使用してサービスを分割する場合もあります。次の図は、Amazon EC2上で実行されるDockerを使用してTrip Managementサービスをデプロイする方法の一例を示しています。

配車サービス向けのサンプルマイクロサービスアプリ。Dockerコンテナにデプロイされ、前段にロードバランサーが配置されています

実行時、Trip Managementサービスは複数のサービスインスタンスで構成されます。各サービスインスタンスはDockerコンテナです。高可用性を確保するため、これらのコンテナは複数のクラウドVM上で稼働します。サービスインスタンスの前段には、NGINXなどのロードバランサーが配置され、各インスタンスにリクエストを分散します。ロードバランサーは、キャッシュ、アクセス制御、APIメータリング、監視などの処理も担う場合があります。

マイクロサービスアーキテクチャパターンは、アプリケーションとデータベースの関係に大きな影響を与えます。各サービスは、他のサービスと単一のデータベーススキーマを共有するのではなく、独自のデータベーススキーマを持ちます。このアプローチは、全社共通のデータモデルという考え方とは相いれない面があり、一部のデータが重複することも少なくありません。しかし、疎結合を確保できるため、マイクロサービスのメリットを得るには、サービスごとにデータベーススキーマを持つことが不可欠です。次の図は、サンプルアプリケーションのデータベースアーキテクチャを示しています。

配車サービスのサンプルマイクロサービスアプリケーションにおけるデータベースアーキテクチャ

各サービスには、それぞれ専用のデータベースがあります。さらに、各サービスは、そのニーズに最適な種類のデータベースを使用できます。これは、いわゆるポリグロット永続化アーキテクチャです。たとえば、乗車希望者の近くにいるドライバーを検索するDriver Managementでは、効率的な地理空間クエリをサポートするデータベースを使用する必要があります。

表面的には、マイクロサービスアーキテクチャパターンはSOAに似ています。どちらのアプローチでも、アーキテクチャは一連のサービスで構成されます。しかし、マイクロサービスアーキテクチャパターンは、Webサービス仕様（WS‑*）とエンタープライズサービスバス（ESB）の商業化や、それらに付随すると見なされる負の側面を取り除いたSOAと捉えることもできます。マイクロサービスベースのアプリケーションでは、WS‑*ではなく、RESTなどのよりシンプルで軽量なプロトコルが好まれます。また、ESBの使用を極力避け、代わりにESBに相当する機能をマイクロサービス自体に実装します。マイクロサービスアーキテクチャパターンでは、標準スキーマの概念など、SOAのほかの要素も採用しません。

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

マイクロサービスアーキテクチャパターンには、重要なメリットがいくつもあります。まず、複雑性の問題に対処できます。本来なら巨大なモノリシックアプリケーションになるものを、複数のサービスに分割します。機能の総量は変わりませんが、アプリケーションは管理しやすい単位、つまりサービスに分割されます。各サービスには、RPC駆動型またはメッセージ駆動型APIという形で明確な境界があります。マイクロサービスアーキテクチャパターンでは、モノリシックなコードベースでは実際には実現が極めて難しいレベルのモジュール性を確保できます。その結果、個々のサービスをはるかに迅速に開発でき、理解や保守も大幅に容易になります。

第2に、このアーキテクチャでは、各サービスに専念するチームが、それぞれのサービスを独立して開発できます。サービスがAPIコントラクトに準拠している限り、開発者は目的に適したテクノロジーを自由に選択できます。もちろん、ほとんどの組織では、完全な無秩序を避けるため、選択できるテクノロジーを制限するでしょう。しかし、この自由度により、開発者は新規プロジェクトの開始時点で採用されていた、すでに時代遅れになっている可能性のあるテクノロジーを使い続ける必要がなくなります。新しいサービスを作成する際には、最新のテクノロジーを選択できます。さらに、サービスは比較的小規模であるため、古いサービスを最新のテクノロジーで書き直すことも現実的になります。

第3に、マイクロサービスアーキテクチャパターンでは、各マイクロサービスを個別にデプロイできます。開発者は、自分たちのサービス内に限定される変更のデプロイについて、調整する必要がありません。このような変更は、テストが完了次第デプロイできます。たとえば、UIチームはA/Bテストを実施し、UIの変更を迅速に繰り返すことができます。マイクロサービスアーキテクチャパターンにより、継続的デプロイが可能になります。

最後に、Microservices Architectureパターンでは、各サービスを個別にスケーリングできます。各サービスの容量と可用性の制約を満たす数のインスタンスだけをデプロイできます。さらに、サービスのリソース要件に最適なハードウェアを使用できます。たとえば、CPU負荷の高い画像処理サービスはEC2 Compute Optimizedインスタンスに、インメモリデータベースサービスはEC2 Memory-optimizedインスタンスにデプロイできます。

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

Fred Brooksが約30年前に記したように、万能の解決策はありません。ほかのあらゆるテクノロジーと同様に、マイクロサービスアーキテクチャにも欠点があります。その1つは、名称そのものです。「マイクロサービス」という用語は、サービスの規模を過度に重視しています。実際、極めて粒度の細かい10～100 LOCのサービスを構築すべきだと主張する開発者もいます。小規模なサービスが望ましいとはいえ、それは目的を達成するための手段であり、それ自体が主目的ではないことを忘れてはなりません。マイクロサービスの目的は、アジャイルなアプリケーション開発とデプロイを促進できるよう、アプリケーションを十分に分割することです。

マイクロサービスのもう1つの大きな欠点は、マイクロサービスアプリケーションが分散システムであることに起因する複雑さです。開発者は、メッセージングまたはRPCに基づくプロセス間通信メカニズムを選択し、実装する必要があります。さらに、リクエストの送信先で応答が遅延したり、利用できなかったりする可能性があるため、部分的な障害を処理するコードも記述しなければなりません。いずれも極端に難しいものではありませんが、モジュール同士が言語レベルのメソッド／プロシージャ呼び出しを介して相互に呼び出すモノリシックアプリケーションと比べると、はるかに複雑です。

マイクロサービスには、データベースが分割されるアーキテクチャという別の課題もあります。複数のビジネスエンティティを更新するビジネストランザクションは、決して珍しくありません。モノリシックアプリケーションではデータベースが1つしかないため、この種のトランザクションは簡単に実装できます。しかし、マイクロサービスベースのアプリケーションでは、異なるサービスが所有する複数のデータベースを更新する必要があります。通常、分散トランザクションは選択肢になりません。その理由は、CAP定理だけではありません。現在の拡張性に優れたNoSQLデータベースやメッセージブローカーの多くは、そもそも分散トランザクションをサポートしていません。そのため、結果整合性に基づくアプローチを採用せざるを得ず、開発者にとって実装の難易度が高くなります。

マイクロサービスアプリケーションのテストも、はるかに複雑です。たとえば、Spring Bootのような最新のフレームワークを使用すれば、モノリシックなWebアプリケーションを起動して、そのREST APIをテストするテストクラスを簡単に作成できます。一方、サービス用の同様のテストクラスでは、そのサービスと依存先のすべてのサービスを起動する（または少なくとも、それらのサービスのスタブを構成する）必要があります。これも極端に難しいわけではありませんが、実装の複雑さを過小評価しないことが重要です。

マイクロサービスアーキテクチャパターンにおけるもう1つの大きな課題は、複数のサービスにまたがる変更の実装です。たとえば、サービスA、B、Cの変更を必要とするストーリーを実装し、AがBに、BがCに依存しているとします。モノリシックアプリケーションであれば、該当するモジュールを変更して統合し、一度にデプロイできます。一方、マイクロサービスアーキテクチャパターンでは、各サービスへの変更の展開を慎重に計画し、調整する必要があります。たとえば、まずサービスC、次にサービスB、最後にサービスAの順で更新します。幸い、通常、ほとんどの変更が影響するのは1つのサービスだけであり、調整を要する複数サービスへの変更は比較的まれです。

マイクロサービスベースのアプリケーションは、デプロイもはるかに複雑です。モノリシックアプリケーションであれば、従来型のロードバランサーの背後にある、同一構成の複数のサーバーにデプロイするだけです。各アプリケーションインスタンスには、データベースやメッセージブローカーなどのインフラストラクチャサービスの場所（ホストとポート）を設定します。一方、マイクロサービスアプリケーションは通常、多数のサービスで構成されます。たとえば、Hailoには160種類のサービスがあり、Adrian Cockcroft氏によると、Netflixには600を超えるサービスがあります。［編集者注 – HailoはMyTaxiに買収されました。］各サービスには複数のランタイムインスタンスがあります。そのため、構成、デプロイ、スケーリング、監視が必要な構成要素が大幅に増えます。さらに、サービスが通信先となる他のサービスの場所（ホストとポート）を検出できるようにする、サービスディスカバリの仕組み（後の記事で説明）も実装する必要があります。従来のトラブルチケットベースの手法や手作業による運用では、このレベルの複雑さに対応できません。したがって、マイクロサービスアプリケーションを適切にデプロイするには、開発者がデプロイ方法をより細かく制御できることと、高度な自動化が必要です。

自動化のアプローチの1つは、Cloud Foundryなどの既製のPaaSを利用することです。PaaSを利用すると、開発者はマイクロサービスを容易にデプロイし、管理できます。また、ITリソースの調達や構成などを意識する必要がなくなります。同時に、PaaSを構成するシステムおよびネットワークの担当者は、ベストプラクティスや社内ポリシーへの準拠を確保できます。マイクロサービスのデプロイを自動化するもう1つの方法は、実質的に独自のPaaSを開発することです。一般的な出発点の1つは、KubernetesなどのクラスタリングソリューションをDockerなどのテクノロジーと組み合わせて使用することです。このシリーズの後半では、マイクロサービスレベルでキャッシュ、アクセス制御、APIメータリング、監視を容易に処理できるNGINX Plusのようなソフトウェアベースのアプリケーションデリバリーのアプローチが、この問題の解決にどのように役立つかを見ていきます。

まとめ

複雑なアプリケーションの構築は、本質的に困難です。モノリシックアーキテクチャが適しているのは、シンプルで軽量なアプリケーションに限られます。複雑なアプリケーションに採用すると、多大な苦労を伴うことになります。マイクロサービスアーキテクチャパターンには欠点や実装上の課題があるものの、複雑で進化し続けるアプリケーションには、より適した選択肢です。

今後のブログ記事では、マイクロサービスアーキテクチャパターンのさまざまな側面を詳しく掘り下げ、サービスディスカバリ、サービスのデプロイ方法、モノリシックアプリケーションを複数のサービスへリファクタリングする戦略などについて解説します。

今後の投稿にご期待ください……

編集者 – 全7回の記事シリーズが完結しました：

一連の記事に加え、NGINX Plusを使用したマイクロサービスの実装に関する情報をまとめた電子書籍「マイクロサービス：設計からデプロイまで」もダウンロードできます。

ゲストブロガーのChris Richardson氏は、初期のAmazon EC2向けJava PaaS（Platform as a Service）である、当初の「CloudFoundry.com」の創設者です。現在は、アプリケーションの開発およびデプロイ方法の改善に向けて、組織にコンサルティングを提供しています。

注目のブログ記事

クラウドネイティブ技術、プラットフォームエンジニアリング、AIの最新トレンド

F5 NGINX OneによるアプリとAPIデリバリーのライフサイクル全体の管理

モダンアプリケーションデリバリをシンプルに：F5 NGINX Oneの9か月