マイクロサービスとは

マイクロサービスは、アプリケーション構築のアーキテクチャ・スタイルです。アーキテクチャのフレームワークとして、マイクロサービスは分散されており、疎結合であるため、あるチームの変更によってアプリケーション全体が破損することはありません。変化するビジネスニーズに対応するためには、開発チームが新しいアプリケーションのコンポーネントを迅速に構築できることが必要です。

マイクロサービス・アーキテクチャが従来のモノリシックなアプローチと異なるのは、アプリケーションをコア機能ごとに細分化するという点です。各機能はサービスと呼ばれ、独立して構築およびデプロイすることができます。つまり、個々のサービスが正常に機能してもしなくても、他のサービスに悪影響を及ぼすことはありません。これにより、DevOps のテクノロジー面を取り入れやすくなり、継続的なイテレーションとデリバリー (CI/CD) がさらにシームレスになり、達成が容易になります。

オンラインのショッピングサイトに最近アクセスしたときの状況を思い出してみてください。サイトの検索バーを使用して商品をブラウズしたのではないでしょうか。この検索がサービスです。また、お勧めの関連商品が表示されたかもしれません。こうしたお勧め商品は、買い物客の好みが蓄積されたデータベースをもとに表示されます。これもまた、サービスです。商品を購入しようとオンラインカートに追加しましたか？もちろん、これもサービスです。

つまり、1 つのマイクロサービスはアプリケーションの 1 つのコア機能であり、他のサービスとは独立して動作します。とはいえ、マイクロサービス・アーキテクチャは、アプリケーションのコア機能の単なる疎結合というわけではありません。不可避の障害や、今後のスケーラビリティ、新たな機能統合に備え、開発チームとサービス間のコミュニケーションを再構築することでもあります。

これを実現するには、マイクロサービスをデプロイできるように、サービス指向アーキテクチャ (SOA) の基本を適応させる必要があります。

アプリケーションをコア機能に細分化し、モノリスのリスクを回避するという手法に聞き覚えがあるとしたら、それは、マイクロサービスのアーキテクチャ・スタイルが、すでに確立されたソフトウェア設計スタイルであるサービス指向アーキテクチャ (SOA) と似ているからです。

当初アプリケーション開発では、既存のアプリケーションに最小限の変更を加えるだけでも、独自の品質保証 (QA) サイクルで大規模なアップデートが必要となり、多くのサブチームの作業が滞ってしまう場合がありました。このアプローチは、アプリケーション全体のソースコードが 1 つのデプロイメントユニット (.war または .ear など) に組み込まれていたことから、多くの場合「モノリシック」と呼ばれます。アプリケーションの一部のアップデートが原因でエラーが発生した場合は、全体をオフラインにして、規模を縮小し、修正する必要がありました。このアプローチは小規模なアプリケーションならそれでも有効ですが、成長する企業にはダウンタイムを生じさせる余裕はありません。

そこで、サービス指向アーキテクチャが注目されるようになります。これは、エンタープライズ・サービス・バス (ESB) を介してやり取りする、個別の再利用可能なサービスの集合としてアプリケーションを構築する手法です。このアーキテクチャでは、特定のビジネスプロセスを中心に編成された個々のサービスが、SOAP、ActiveMQ、Apache Thrift などの通信プロトコルに準拠し、ESB を介して共有されます。つまり、ESB を介して統合されるこの一連のサービスが、アプリケーションを構成するのです。

これによりサービスの構築、テスト、調整を同時に行うことができるため、モノリシックな開発サイクルに頼ることはなくなります。しかし、ESB はシステム全体の単一障害点となるため、モノリスを排除する努力が新たなモノリスを生み出しただけという見方もあります。ESB は、組織全体のボトルネックとなる可能性があります。

その違いとはマイクロサービスは、通常はステートレスに相互通信できるため、この手法で構築されたアプリケーションはフォールトトレラント性が高まり、単一の ESB への依存度は低くなります。これにより、マイクロサービスは言語に依存しないアプリケーション・プログラミング・インタフェース (API) を介して通信できるため、開発チームは独自のツールを使用することができます。

SOA が利用されてきたため、マイクロサービスは実際には、まったく新しい考え方とは言えません。しかし、コンテナ化テクノロジーの進歩に伴い、マイクロサービスの実用性は高まってきています。Linux コンテナでは、同じハードウェア上でアプリケーションの複数の部分を個別に実行し、各部分やライフサイクルをより詳細に制御できるようになりました。API と DevOps チームに加えて、コンテナ化されたマイクロサービスもクラウドネイティブ・アプリケーションの基盤となります。

マイクロサービスは、分散開発によりチームの作業やルーチン化を後押しします。複数のマイクロサービスを同時に開発することもできます。つまり、同じアプリケーションを同時に開発する開発者の数を増やすことができ、開発期間が短縮されます。

組織でマイクロサービス・アーキテクチャへの移行を考えている場合は、アプリケーションだけでなく、従業員の働き方も変化することを想定しておく必要があります。各チームがデプロイメントを実施する頻度はそれぞれ異なり、独自の顧客層に対する固有のサービスを担当するため、組織的な変更と文化的な変更は、ある意味で課題となります。これは開発者が見落としがちな点ですが、マイクロサービス・アーキテクチャを成功させるために不可欠な要素です。

マイクロサービス・ベースのアーキテクチャにおいて、文化やプロセスよりもさらに大きな課題となるのは、複雑さと効率性です。Red Hat Mobile のプラットフォーム・アーキテクト、John Frizelle は、2017 年の Red Hat Summit での講演で、次の 8 つの課題カテゴリを提示しました。

1. 構築：時間をかけてサービス間の依存関係を特定する必要があります。1 つの構築を完了すると、依存関係により、他の構築も必要になる可能性があります。また、マイクロサービスがデータに及ぼす影響についても考慮する必要があります。
2. テスト：統合テストとエンドツーエンド・テストは、これまで以上に複雑かつ重要になります。アーキテクチャの一部で障害が起きると、サービス間のサポートをどのように構築したかに応じて、少し離れた部分で障害が発生することもあります。
3. バージョン管理：新しいバージョンに更新すると、下位互換性が失われる可能性があります。下位互換性に対応する条件付きロジックを使用して構築することもできますが、扱いが困難になります。あるいは、各クライアント向けに複数のライブバージョンを立ち上げることもできますが、メンテナンスや管理が複雑化するおそれがあります。
4. デプロイメント：これもまた、少なくとも初期セットアップの段階では課題となります。マイクロサービスの複雑さから、手動でのデプロイメントは困難であるため、デプロイメントを容易にするために、まずは多くの自動化に投資しなければなりません。サービスを導入する方法と順序を考える必要があります。
5. ロギング：分散システムでは、すべてのログを一元化する必要があります。これがなければ、スケーリングを管理することができません。
6. 監視：問題の原因を突き止めるために、システムを一元的に把握することが重要です。
7. デバッグ：ローカルの統合開発環境 (IDE) を通じてリモートデバッグを行うことはできず、数十、数百のサービスに対しては機能しません。残念ながら、現時点ではデバッグ方法はありません。
8. 接続性：一元型または統合型を問わず、サービスディスカバリーを検討する必要があります。