「マイクロサービス」の構成や特徴を、図とテキストで学ぼう：ビジネスパーソンのためのIT用語基礎解説

IT用語の基礎の基礎を、初学者や非エンジニアにも分かりやすく解説する本連載、第21回は「マイクロサービス」です。ITエンジニアの学習、エンジニアと協業する業務部門の仲間や経営層への解説にご活用ください。

[古閑俊廣（BFT），＠IT]

1　マイクロサービスとは

　マイクロサービスは、小規模なサービス（機能）を疎結合で組み合わせて1つのアプリケーションを構成するアーキテクチャ（システムの構造）です。各機能はそれぞれ独立して動作し、ネットワークを介してタスクを処理します。

　マイクロサービスはクラウド技術と相性が良く、機能変更や拡張に対する柔軟性の高さ、またユーザーのニーズに迅速に対応できる開発スピードの速さから、採用するシステムが増えています。

図1 マイクロサービス構成イメージ

2　マイクロサービスの特徴

　マイクロサービスには以下のような特徴があります。

2.1　サービスの自律性

　各サービスはそれぞれ機能とデータを持っていて、他のサービスから独立して動作します。これにより、システム全体を小さな部品として分けて管理しやすくなります。

2.2　疎結合

　サービス間の依存関係を最小限に抑えるように各サービスを設計することで、特定のサービスに対する変更や更新が他のサービスに影響を与えないように構成できます。

2.3　分散システム

　マイクロサービスアーキテクチャは、アプリケーションを分散システム（※1）として構築します。このような構成とすることにより、システム全体の可用性と拡張性を向上させる一方、ネットワークの信頼性やデータの整合性など分散システム特有の課題も存在します。

※1 分散システム：複数の独立したコンピュータがネットワークを介して連携し、全体として1つのシステムのように機能するシステム構成のこと。

2.4　API連携

　各サービスはAPI（※2）を経由して他のサービスやクライアントと通信します。サービス間のインタフェースが明確になるようAPIを設計することで、開発効率が向上します。

※2 API（Application Programming Interface）：ソフトウェア同士でデータのやりとりをする際に使用する仕組みのこと。APIを利用する際は、APIの提供者が定めたルールに従ってリクエストすることでレスポンスを得られる。

2.5　コンテナ化とオーケストレーション

　マイクロサービスは「Docker」などのコンテナ技術（※3）を使用することが多く、「Kubernetes」などのオーケストレーションツール（※4）を使用して管理されます。これにより、サービスの増減や障害対応が容易になります。一般的な仮想マシンと比較すると、コンテナは軽量で起動が速く、アプリケーションをさまざまな環境で稼働させられる点に優れています。

図2 仮想マシンとコンテナの比較イメージ

※3 コンテナ技術：アプリケーションやサービスを、独立した軽量な仮想環境で実行する技術のこと。各コンテナは必要なライブラリ（部品群）や設定を含んでいるため、異なる実行環境でも同じように動作する。

※4 オーケストレーションツール：複数のソフトウェアやサービスを自動的に管理し、効率的に動作させるためのソフトウェアのこと。マイクロサービスアーキテクチャなど複雑な構成に有効とされている。例えば、仮想マシンの停止や起動、負荷の分散、アプリケーションの起動などを制御する。

3　モノリシックアーキテクチャとの違い

　マイクロサービスはモノリシックな構造と比較されます。

図3 モノリシックとマイクロサービスの比較イメージ

　モノリシックアーキテクチャはアプリケーション全体を1つの大きなまとまりとして構築する従来型のアーキテクチャです。全ての機能や部品が密接に結合され、単一のアプリケーションとして実行されます。

　マイクロサービスは複数のサービスを組み合わせることから複雑化しやすい一方、モノリシックはシンプルである点にメリットがあります。しかし、全ての機能が密接に結合しているため、変更や機能拡張の影響が大きく、大規模なアプリケーションでは柔軟性に欠けることが大きな課題として存在します。

　モノリシックは小規模でシンプルなアプリケーションに適していますが、マイクロサービスは構成が複雑な分、小規模でシンプルなシステムではメリットが享受できず、大規模なシステムに適しているといえます。

図4 モノリシックとマイクロサービスの特徴

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

　マイクロサービスアーキテクチャを採用するとさまざまなメリットを得られます。代表的なものを以下に挙げます。

4.1　拡張性

　各サービスは独立して拡張、または縮小できます。例えば特定の機能に対する負荷が高まった場合、その機能だけを拡張できるため、リソースの無駄を防ぎ、効率的な運用が可能です。

4.2　障害範囲の限定

　各サービスが独立して動作するため、特定のサービスに障害が発生しても、他のサービスへの影響を最小限に抑えられます。これにより、システム全体の可用性が向上します。

4.3　柔軟性の高さ

　サービスごとに最適な技術を選択できます。例えば、サービスごとに異なる開発言語を使用することや、異なる製品を採用することができます。また、部分的に新しい技術を採用できるなど、技術的な進化に柔軟に対応できます。

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

　マイクロサービスの大きなデメリットは、システムの開発や運用における難易度の高さです。具体的には以下の点が挙げられます。

5.1　複雑な運用管理

　マイクロサービスでは複数のサービスが独立して動作するため、運用するサービスの数が増加します。これにより、アプリケーションの停止起動や監視、リソースの拡張や縮小などの運用が複雑化します。

　また、Dockerなどのコンテナ技術やKubernetesなどのオーケストレーションツールの使用が一般的ですが、これらの管理と設定には専門的な知識が必要です。運用チームはこれらのツールに精通する必要があります。

5.2　分散システムの課題

　マイクロサービスはサービス間をネットワークでつないでやりとりするため、ネットワークの遅延や障害による影響を受けやすくなります。ネットワークの信頼性を確保するためには、監視やサービスメッシュ（※5）などの仕組みが必要です。

　また、各サービスが独自にデータを管理していることから、データの一貫性を保つことが難しくなります。処理に失敗した際のリトライの制御など、システムの整合性を保つ仕組みを検討する必要があります。

※5 サービスメッシュ：マイクロサービスアーキテクチャなどにおいて、各サービス間の通信を管理、制御する仕組みのこと。通信の安全性や信頼性を高められる。

5.3　セキュリティの課題

　各サービスが独自のセキュリティ設定を持つため、システム全体のセキュリティを一貫して管理することが難しくなります。サービス間通信の保護や認証、認可の仕組みの統一が必要です。

6　今後の展望

　マイクロサービスは特に大規模なシステムでは大きなメリットがあり、拡張性や可用性、開発スピード向上などの成功事例がある一方、サービス間の通信の信頼性やシステム構成の複雑化に伴う開発、運用難易度の高さが課題となり、導入に失敗した事例も多く存在します。

　このため、まずは実現しようとするビジネスや解決しようとしている課題に対して、マイクロサービスでの実現が適切かどうか見極めることが重要です。例えば、サーバの負荷を分散したいという目的であれば、難易度の高いマイクロサービスを選択するのではなく別の方法を取れるはずです。

　今後、大規模システムにおいてマイクロサービスの選択が一般化していくためには、効果的な設計パターンやベストプラクティスが広く共有され、標準化することが必要となるでしょう。

古閑俊廣

BFT インフラエンジニア

主に金融系、公共系情報システムの設計、構築、運用、チームマネジメントを経験。

現在はこれまでのエンジニア経験を生かし、ITインフラ教育サービス「BFT道場」を運営。

「現場で使える技術」をテーマに、インフラエンジニアの育成に力を注いでいる。

実践型ITインフラ研修 BFT道場