Azure でのマイクロサービスの構築Building microservices on Azure

マイクロサービスは、回復性があり、単独でのデプロイが可能で、迅速に展開できる非常にスケーラブルなアプリケーションを構築するための一般的なアーキテクチャ スタイルです。Microservices are a popular architectural style for building applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. しかし、マイクロサービス アーキテクチャが成功するには、アプリケーションを設計および構築するのためのさまざまなアプローチが必要です。But a successful microservices architecture requires a different approach to designing and building applications.

マイクロサービス アーキテクチャは、小さな自律サービスのコレクションで構成されています。A microservices architecture consists of a collection of small, autonomous services. 各サービスは自己完結型であり、1 つのビジネス機能を実装している必要があります。Each service is self-contained and should implement a single business capability.

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

マイクロサービスとはWhat are microservices?

  • マイクロサービスは小さく、独立的で、疎結合しています。Microservices are small, independent, and loosely coupled. 小規模な 1 つの開発者チームでサービスを作成および管理できます。A single small team of developers can write and maintain a service.

  • 各サービスは個別のコードベースであり、小規模な開発チームで管理できます。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/orchestration. このコンポーネントは、ノードへのサービスの配置、障害の特定、ノード間のサービスの再調整などを行う役割を担います。This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. 通常、このコンポーネントは、カスタム ビルドではなく、Kubernetes などの既製テクノロジです。Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

API ゲートウェイAPI Gateway. API ゲートウェイは、クライアントのエントリ ポイントです。The API gateway is the entry point for clients. サービスを直接呼出す代わりに、クライアントは API ゲートウェイを呼び出し、それがその呼び出しをバック エンドの適切なサービスに転送します。Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

API ゲートウェイを使用することには次のようなメリットがあります。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.

メリットBenefits

  • 機敏性。Agility. マイクロサービスは個別にデプロイされるため、バグ修正や機能リリースが管理しやすくなります。Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. アプリケーション全体を再デプロイしなくてもサービスを更新できるほか、問題が発生したときに更新プログラムをロールバックできます。You can update a service without redeploying the entire application, and roll back an update if something goes wrong. 多くの従来のアプリケーションでは、アプリケーションの 1 つの部分でバグが見つかった場合、リリース プロセス全体が中止になる可能性があります。In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. バグ修正が統合、テスト、発行されるのを待つために、新しい機能が保留される場合があります。New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • 集中的な小規模チームSmall, focused teams. マイクロサービスの規模は小さく、1 つの機能チームによって構築、テスト、およびデプロイできます。A microservice should be small enough that a single feature team can build, test, and deploy it. 小規模なチーム編成により、機敏性が向上します。Small team sizes promote greater agility. 大規模なチームでは、コミュニケーションに時間がかかり、管理オーバーヘッドが増大し、機敏性も低下するため、生産性が低くなる傾向があります。Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • 小さなコード ベースSmall code base. モノリシック アプリケーションでは、時間の経過に伴ってコードの依存関係が複雑になる傾向があります。新しい機能を追加しようとすると、多くの場所でコード変更が必要です。In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. マイクロサービス アーキテクチャでは、コードまたはデータ ストアが共有されないため、依存関係を最小限に抑え、新しい機能を簡単に追加できます。By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • テクノロジの組み合わせMix of technologies. 必要に応じて、チームがテクノロジ スタックを組み合わせて、サービスに最適なテクノロジを選択できます。Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • 障害の分離Fault isolation. 個々のマイクロサービスが使用できなくなっても、上流マイクロサービスが障害を正しく処理するように設計されている限り (サーキット ブレークの実装など)、アプリケーション全体が中断されることはありません。If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • スケーラビリティ:Scalability. サービスは独立して拡大縮小できるため、アプリケーション全体をスケールアウトせずに、追加のリソースが必要なサブシステムをスケールアウトできます。Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. Kubernetes や Service Fabric などのオーケストレーターを使用すると、マイクロサービスを高密度で 1 つのホストに圧縮できるため、リソースをより効率的に使用できます。Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • データの分離Data isolation. 影響を受けるのは 1 つのマイクロサービスだけであるため、スキーマ更新がはるかに実行しやすくなります。It is much easier to perform schema updates, because only a single microservice is affected. モノリシック アプリケーションでは、アプリケーションのさまざまな部分すべてが同じデータに影響する可能性があり、スキーマの変更にはリスクが伴うため、スキーマ更新は非常に困難になる可能性があります。In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

課題Challenges

マイクロサービスの利点は、何もせずに手に入るものではありません。The benefits of microservices don't come for free. マイクロサービス アーキテクチャに着手する前に考慮すべき課題の一部を示します。Here are some of the challenges to consider before embarking on a microservices architecture.

  • 複雑さ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 testing. 他の依存サービスに依存する小さいサービスを作成するには、従来のモノリシックまたは階層化アプリケーションを作成するのとは異なるアプローチが求められます。Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. 既存のツールは、サービスの依存関係を処理するように設計されているとは限りません。Existing tools are not always 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.

マイクロサービス アーキテクチャの構築プロセスProcess for building a microservices architecture

ここに記載されている記事では、マイクロサービス アーキテクチャを設計、構築、運用するための構造手法を説明しています。The articles listed here present a structured approach for designing, building, and operating a microservices architecture.

ドメイン分析。Domain analysis. マイクロサービスの設計時によくあるいくつかの問題を回避するために、ドメイン分析を使用してマイクロサービス境界を定義します。To avoid some common pitfalls when designing microservices, use domain analysis to define your microservice boundaries. 次の手順に従います。Follow these steps:

  1. ドメイン分析を使用したマイクロサービスのモデル化Use domain analysis to model microservices.
  2. 戦術的 DDD を使用したマイクロサービスの設計Use tactical DDD to design microservices.
  3. マイクロサービス境界の特定Identify microservice boundaries.

サービスの設計Design the services. マイクロサービスには、アプリケーションを設計およびビルドするのためのさまざまなアプローチが必要です。Microservices require a different approach to designing and building applications. 詳細については、「マイクロサービス アーキテクチャの設計」を参照してください。For more information, see Designing a microservices architecture.

運用環境における運用Operate in production. マイクロサービス アーキテクチャは分散しているため、デプロイと監視のための堅牢な運用が必要です。Because microservices architectures are distributed, you must have robust operations for deployment and monitoring.