マイクロサービス アーキテクチャ スタイル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.

マイクロサービス アーキテクチャ スタイルの論理図

いくつかの点で、マイクロサービスはサービス指向アーキテクチャ (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.

メリットBenefits

  • 独立したデプロイ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).

課題Challenges

  • 複雑さ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.

次の手順Next steps

Azure でのマイクロサービス アーキテクチャの構築に関する詳細なガイダンスいついては、「Azure でのマイクロサービスの設計、構築、および操作」をご覧ください。For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.