マイクロサービス アーキテクチャ スタイルMicroservices architecture style

マイクロサービス アーキテクチャは、小さな自律サービスのコレクションで構成されています。A microservices architecture consists of a collection of small, autonomous services. 各サービスは自己完結型であり、1 つのビジネス機能を実装している必要があります。Each service is self-contained and should implement a single business capability. Azure でのマイクロサービス アーキテクチャの構築に関する詳細なガイダンスいついては、「Azure でのマイクロサービスの設計、構築、および操作」をご覧ください。For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.

いくつかの点で、マイクロサービスはサービス指向アーキテクチャ (SOA) の自然な進化形と言えますが、マイクロサービスと SOA にはいくつかの違いがあります。In some ways, microservices are the natural evolution of service oriented architectures (SOA), but there are differences between microservices and SOA. 次に、マイクロサービスの特徴を定義します。Here are some defining characteristics of a microservice:

  • マイクロサービス アーキテクチャでは、サービスは小さく、独立的で、疎結合しています。In a microservices architecture, services are small, independent, and loosely coupled.

  • 各サービスは個別のコードベースであり、小規模な開発チームで管理できます。Each service is a separate codebase, which can be managed by a small development team.

  • サービスは個別にデプロイできます。Services can be deployed independently. チームは、アプリケーション全体を再構築したり再デプロイしたりすることなく、既存のサービスを更新できます。A team can update an existing service without rebuilding and redeploying the entire application.

  • サービスはサービスのデータや外部の状態を保持する役割を担います。Services are responsible for persisting their own data or external state. これは、個別のデータ層でデータを保持する従来のモデルと異なる点です。This differs from the traditional model, where a separate data layer handles data persistence.

  • サービスは、明確に定義された API を使用して、互いに通信します。Services communicate with each other by using well-defined APIs. 各サービス内部の実装の詳細は、他のサービスに開示されません。Internal implementation details of each service are hidden from other services.

  • サービスは、同じテクノロジ スタック、ライブラリ、またはフレームワークを共有する必要はありません。Services don't need to share the same technology stack, libraries, or frameworks.

また、サービス自体については、いくつかの他のコンポーネントが次のような一般的なマイクロサービス アーキテクチャで使用されます。Besides for the services themselves, some other components appear in a typical microservices architecture:

管理Management. 管理コンポーネントは、ノードへのサービスの配置、障害の特定、ノード間のサービスの再調整などを行う役割を担います。The management component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth.

サービスの探索Service Discovery. サービスのリストとサービスが配置されているノードを保持します。Maintains a list of services and which nodes they are located on. サービスがサービスのためにエンドポイントを探索できるようにします。Enables service lookup to find the endpoint for a service.

API ゲートウェイAPI Gateway. API ゲートウェイは、クライアントのエントリ ポイントです。The API gateway is the entry point for clients. クライアントは直接サービスを呼び出すことはしません。Clients don't call services directly. 代わりに API ゲートウェイを呼び出し、その呼び出しをバック エンドの適切なサービスに転送します。Instead, they call the API gateway, which forwards the call to the appropriate services on the back end. API ゲートウェイは、複数のサービスからの応答を集計して、集計された応答を返すことがあります。The API gateway might aggregate the responses from several services and return the aggregated response.

API ゲートウェイを使用することには次のようなメリットがあります。The advantages of using an API gateway include:

  • サービスからクライアントを切り離します。It decouples clients from services. サービスのバージョン管理とリファクタリングを、すべてのクライアントを更新する必要なく行うことができます。Services can be versioned or refactored without needing to update all of the clients.

  • サービスは、AMQP などの Web フレンドリではないメッセージング プロトコルを使用できます。Services can use messaging protocols that are not web friendly, such as AMQP.

  • API ゲートウェイは、認証、ログ記録、SSL 終了、負荷分散などの他の横断的な関数を実行できます。The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

このアーキテクチャを使用する状況When to use this architecture

次の場合に、このアーキテクチャ スタイルを検討してください。Consider this architecture style for:

  • リリースの早さが要求される大規模アプリケーション。Large applications that require a high release velocity.

  • 高い拡張性が必要とされる複雑なアプリケーション。Complex applications that need to be highly scalable.

  • ドメインが豊富な、またはサブドメインが多いアプリケーション。Applications with rich domains or many subdomains.

  • 小規模な開発チームから構成されている組織。An organization that consists of small development teams.


  • 独立したデプロイIndependent deployments. アプリケーション全体を再デプロイしなくてもサービスを更新できたり、問題が生じた場合に更新プログラムをロールバックまたはロールフォワードできたりします。You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. バグ修正プログラムと機能のリリースがより管理しやすく、リスクが低くなります。Bug fixes and feature releases are more manageable and less risky.

  • 独立した開発Independent development. 1 つの開発チームでサービスのビルド、テスト、デプロイが可能です。A single development team can build, test, and deploy a service. その結果、イノベーションを継続し、より早い周期でリリースが可能になります。The result is continuous innovation and a faster release cadence.

  • 集中的な小規模チームSmall, focused teams. チームは 1 つのサービスに専念できます。Teams can focus on one service. 各サービスの範囲が狭いことでコード ベースが理解しやすく、新しいチーム メンバーを増員しやすくなります。The smaller scope of each service makes the code base easier to understand, and it's easier for new team members to ramp up.

  • 障害の分離Fault isolation. サービスがダウンしても、アプリケーション全体を停止することはありません。If a service goes down, it won't take out the entire application. ただし、無料で回復性を得られるという意味ではありません。However, that doesn't mean you get resiliency for free. 回復性のベスト プラクティスと設計パターンに従う必要があります。You still need to follow resiliency best practices and design patterns. Designing resilient applications for Azure (回復性に優れた Azure 用アプリケーションの設計)」をご覧ください。See Designing resilient applications for Azure.

  • 混在テクノロジ スタックMixed technology stacks. チームは、自分たちのサービスに最適なテクノロジを選択できます。Teams can pick the technology that best fits their service.

  • 詳細なスケーリングGranular scaling. サービスは個別にスケールできます。Services can be scaled independently. 同時に、VM あたりのサービスの密度が高いということは、VM リソースがフルに活用されるということです。At the same time, the higher density of services per VM means that VM resources are fully utilized. 配置の制約を使用して、サービスを VM プロファイル (高 CPU、ハイ メモリなど) に合わせることができます。Using placement constraints, a services can be matched to a VM profile (high CPU, high memory, and so on).


  • 複雑さComplexity. マイクロサービス アプリケーションは、同等のモノリシック アプリケーションよりも多くの動的パーツで構成されています。A microservices application has more moving parts than the equivalent monolithic application. 各サービスはより単純ですが、システム全体としてはより複雑です。Each service is simpler, but the entire system as a whole is more complex.

  • 開発とテストDevelopment and test. サービスの依存関係に対する開発では、別のアプローチが必要です。Developing against service dependencies requires a different approach. 既存のツールは、必ずしもサービスの依存関係を処理するようには設計されていません。Existing tools are not necessarily designed to work with service dependencies. サービス間の境界にまたがってリファクタリングを行うことは困難です。Refactoring across service boundaries can be difficult. また、アプリケーションの進化が早い場合は特に、サービスの依存関係をテストすることは困難です。It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • ガバナンスの欠如Lack of governance. マイクロサービスを構築する際に分散アプローチをとることにはメリットがありますが、問題が発生しやすくもなります。The decentralized approach to building microservices has advantages, but it can also lead to problems. 多くの異なる言語やフレームワークを使用するために、アプリケーションの維持が難しくなることがあります。You may end up with so many different languages and frameworks that the application becomes hard to maintain. プロジェクト全体に適用される標準を導入する方が役立ち、チームの柔軟性を過度に制限せずに済むということもあります。It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. これは特に、ログ記録などの横断的な機能に適用されます。This especially applies to cross-cutting functionality such as logging.

  • ネットワークの輻輳と待機時間Network congestion and latency. 多くの小さく細分化されたサービスを使用すると、よりインタラクティブな通信が可能になります。The use of many small, granular services can result in more interservice communication. また、サービスの依存関係のチェーンが長すぎる (サービス A が B を呼び出し、その B が C を呼び出すなどの) 場合、追加される待機時間が問題になることがあります。Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. API は慎重に設計する必要があります。You will need to design APIs carefully. API を過度に使用することを避け、シリアル化形式について検討し、非同期通信パターンを使用する場所を探してください。Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • データ整合性Data integrity. 独自のデータを永続化する各マイクロサービスを使用します。With each microservice responsible for its own data persistence. 結果として、データの整合性をとることが難しくなることがあります。As a result, data consistency can be a challenge. 可能であれば、最終的な整合性を優先します。Embrace eventual consistency where possible.

  • 管理Management. マイクロサービスを成功させるには、成熟した DevOps カルチャが必要です。To be successful with microservices requires a mature DevOps culture. サービス間で相互に関連付けられたログを記録することは難しい場合があります。Correlated logging across services can be challenging. 通常、ログ記録は単一のユーザー操作を要求するために複数のサービスの呼び出しを関連付ける必要があります。Typically, logging must correlate multiple service calls for a single user operation.

  • バージョン管理Versioning. サービスの更新プログラムは、依存しているサービスを中断してはいけません。Updates to a service must not break services that depend on it. 複数のサービスが特定の時点で更新される場合があるため、慎重に設計しないと下位互換性または上位互換性に問題が生じる可能性があります。Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • スキルセットSkillset. マイクロサービスは高度な分散システムです。Microservices are highly distributed systems. 成功のために必要なスキルと経験がチームにあるかどうかを慎重に評価してください。Carefully evaluate whether the team has the skills and experience to be successful.

ベスト プラクティスBest practices

  • ビジネス分野周辺のモデル サービス。Model services around the business domain.

  • すべてを分散化します。Decentralize everything. 個々のチームがサービスの設計と構築を担います。Individual teams are responsible for designing and building services. コードまたはデータのスキーマを共有しないようにします。Avoid sharing code or data schemas.

  • データ ストレージは、そのデータを所有するサービス専用にする必要があります。Data storage should be private to the service that owns the data. 各サービスとデータの種類に最適なストレージを使用します。Use the best storage for each service and data type.

  • サービスが、適切に設計された API を介して通信するようにします。Services communicate through well-designed APIs. 実装の詳細が漏えいしないようにします。Avoid leaking implementation details. API は、サービス内部の実装ではなく、ドメインをモデル化する必要があります。APIs should model the domain, not the internal implementation of the service.

  • サービス間の結合は行わないようにします。Avoid coupling between services. 結合の原因には、共有データベース スキーマや固定の通信プロトコルなどがあります。Causes of coupling include shared database schemas and rigid communication protocols.

  • 認証や SSL 終了などの横断的な懸念事項をゲートウェイにオフロードします。Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.

  • ドメインのナレッジをゲートウェイの外部で保持します。Keep domain knowledge out of the gateway. ゲートウェイは、ビジネス ルールやドメイン ロジックのナレッジを使用せずに、クライアントの要求を処理し、ルーティングする必要があります。The gateway should handle and route client requests without any knowledge of the business rules or domain logic. そうしなければ、ゲートウェイが依存関係となり、サービス間の結合が生じる可能性があります。Otherwise, the gateway becomes a dependency and can cause coupling between services.

  • サービスには、疎結合と機能の高い凝集度が必要です。Services should have loose coupling and high functional cohesion. まとめて変更される可能性がある機能は、まとめてパッケージ化してデプロイする必要があります。Functions that are likely to change together should be packaged and deployed together. それらの機能が別々のサービスに格納された場合、1 つのサービスの変更には他のサービスの更新が必要であるため、結果として密接に結合されることになります。If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. 2 つのサービス間で過度に通信が行われると、密接な結合と低い凝集度の問題が生じる可能性があります。Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

  • 障害を分離します。Isolate failures. 回復性戦略を使用して、サービス内の障害が連鎖しないようにします。Use resiliency strategies to prevent failures within a service from cascading. Resiliency patterns (回復性パターン)」と「Designing resilient applications (回復性に優れたアプリケーションの設計)」をご覧ください。See Resiliency patterns and Designing resilient applications.

Azure Container Service を使用したマイクロサービスMicroservices using Azure Container Service

Azure Container Service を使用して、Docker クラスターを構成およびプロビジョニングできます。You can use Azure Container Service to configure and provision a Docker cluster. Azure Container Service では、Kubernetes、DC/OS、Docker Swarm などのよく利用されているコンテナー オーケストレーターがサポートされています。Azure Container Services supports several popular container orchestrators, including Kubernetes, DC/OS, and Docker Swarm.

公開ノードPublic nodes. 公開ノードには、公開されたロード バランサーを使用してアクセスできます。These nodes are reachable through a public-facing load balancer. API ゲートウェイは公開ノードでホストされます。The API gateway is hosted on these nodes.

バックエンド ノードBackend nodes. バックエンド ノードは、クライアントが API ゲートウェイを経由してアクセスするサービスを実行します。These nodes run services that clients reach via the API gateway. バックエンド ノードは、インターネット トラフィックを直接は受信しません。These nodes don't receive Internet traffic directly. バックエンド ノードには、VM の 1 つ以上のプールが、それぞれ異なるハードウェア プロファイルとともに含まれる場合があります。The backend nodes might include more than one pool of VMs, each with a different hardware profile. たとえば、一般的なコンピューティング ワークロード、高 CPU ワークロード、ハイ メモリ ワークロードについて個別のプールを作成できます。For example, you could create separate pools for general compute workloads, high CPU workloads, and high memory workloads.

管理 VMManagement VMs. 管理 VM は、コンテナー オーケストレーター用のマスター ノードを実行します。These VMs run the master nodes for the container orchestrator.

ネットワークNetworking. 公開ノード、バックエンド ノード、管理 VM は、同じ仮想ネットワーク (VNet) 内の別のサブネットに配置されます。The public nodes, backend nodes, and management VMs are placed in separate subnets within the same virtual network (VNet).

ロード バランサーLoad balancers. 外部に公開されたロード バランサーは、公開ノードの前に配置されます。An externally facing load balancer sits in front of the public nodes. ロード バランサーは公開ノードにインターネット要求を配分します。It distributes internet requests to the public nodes. 別のロード バランサーは管理 VM の前に配置され、NAT ルールを使用して管理 VM への Secure Shell (ssh) トラフィックを許可します。Another load balancer is placed in front of the management VMs, to allow secure shell (ssh) traffic to the management VMs, using NAT rules.

信頼性と拡張性を確保するため、各サービスは複数の VM 間でレプリケートされます。For reliability and scalability, each service is replicated across multiple VMs. ただし、サービスは (モノリシック アプリケーションと比較して) 比較的軽量でもあるため、複数のサービスは通常 1 つの VM にまとめられます。However, because services are also relatively lightweight (compared with a monolithic application), multiple services are usually packed into a single VM. 密度が高いことで、リソース使用率が向上します。Higher density allows better resource utilization. 特定のサービスが多くのリソースを使用しない場合、そのサービスの実行に VM 全体を専念させる必要はありません。If a particular service doesn't use a lot of resources, you don't need to dedicate an entire VM to running that service.

次の図は、4 つの異なるサービスを実行する 3 つのノードを示しています (異なる形で示されています)。The following diagram shows three nodes running four different services (indicated by different shapes). 各サービスは少なくとも 2 つのインスタンスを持っていることに注目してください。Notice that each service has at least two instances.

Azure Service Fabric を使用したマイクロサービスMicroservices using Azure Service Fabric

次の図は、Azure Service Fabric を使用したマイクロサービス アーキテクチャを示しています。The following diagram shows a microservices architecture using Azure Service Fabric.

Service Fabric クラスターは、1 つ以上の VM スケール セットにデプロイされます。The Service Fabric cluster is deployed to one or more VM scale sets. さまざまな VM の種類を混在させるために、クラスター内に 1 つ以上の VM スケール セットがある場合もあります。You might have more than one VM scale set in the cluster, in order to have a mix of VM types. API ゲートウェイは、クライアント要求を受信する外部のロード バランサーとともに、Service Fabric クラスターの前に配置されます。An API Gateway is placed in front of the Service Fabric cluster, with an external load balancer to receive client requests.

Service Fabric ランタイムは、サービスの配置、ノードのフェールオーバー、正常性の監視などのクラスター管理を実行します。The Service Fabric runtime performs cluster management, including service placement, node failover, and health monitoring. このランタイムは、クラスター ノード自体にデプロイされます。The runtime is deployed on the cluster nodes themselves. 個別のクラスター管理 VM のセットはありません。There isn't a separate set of cluster management VMs.

サービスは、Service Fabric に組み込まれているリバース プロキシを使用して、相互に通信します。Services communicate with each other using the reverse proxy that is built into Service Fabric. Service Fabric は、名前付きサービスのエンドポイントを解決できる探索サービスを提供します。Service Fabric provides a discovery service that can resolve the endpoint for a named service.