REL 3: どのようにワークロードサービスアーキテクチャを設計すればよいですか?
サービス指向アーキテクチャ (SOA) またはマイクロサービスアーキテクチャを使用して、拡張性と信頼性の高いワークロードを構築します。サービス指向アーキテクチャ (SOA) は、サービスインターフェイスを介してソフトウェアコンポーネントを再利用できるようにする方法です。マイクロサービスアーキテクチャは、その一歩先を行き、コンポーネントをさらに小さくシンプルにしています。
リソース
Amazon API Gateway: Configuring a REST API Using OpenAPI
Implementing Microservices on AWS
Microservices on AWS
Microservices - a definition of this new architectural term
Microservice Trade-Offs
Bounded Context (a central pattern in Domain-Driven Design)
ベストプラクティス:
-
ワークロードをセグメント化する方法を選択する: モノリシックアーキテクチャは避ける必要があります。モノリシックアーキテクチャではなく、SOA とマイクロサービスのどちらかを選択する必要があります。どちらかの選択を行うときは、複雑さに比してどれだけメリットがあるかを考えてください。新製品のローンチ時に適しているものは、初期にスケーリングのことを考えて構築したワークロードが要するものとは異なります。小さなセグメントを使用する利点には、俊敏性、組織の柔軟性、スケーラビリティが高い点などがあります。複雑さにより、潜在的にレイテンシーが増加したり、デバッグが複雑化したり、運用上の負担が増加したりします
-
特定のビジネスドメインと機能に重点を置いたサービスを構築する: SOA は、ビジネスニーズに合わせて明確に定義された機能を備えたサービスを構築します。マイクロサービスはドメインモデルと境界付けられたコンテキストを使用してこれをさらに制限し、各サービスが 1 つのことだけを実行するようにします。特定の機能に焦点を当てることで、さまざまなサービスの信頼性要件を差別化し、より具体的に的を絞って投資することができます。簡潔なビジネス上の問題と各サービスに関連付けられた小さなチームにより、組織のスケーリングも容易になります。
-
API ごとにサービス契約を提供する: サービス契約は、サービス統合に関するチーム間で文書化した合意で、機械で読み取ることができる API 定義、レート制限、パフォーマンスの期待値が含まれます。バージョニング戦略により、クライアントは既存の API を引き続き使用し、準備ができたらアプリケーションを新しい API に移行できます。契約に違反しない限り、デプロイはいつでも行うことができます。サービスプロバイダーチームは、選択したテクノロジースタックを使用して、API 契約の条件を満たすことができます。同様に、サービスコンシューマーは独自のテクノロジーを使用できます。
改善計画
ワークロードをセグメント化する方法を選択する
- SOA とマイクロサービスは、それぞれより小さなセグメンテーションを提供し、最新のスケーラブルで信頼性の高いアーキテクチャとして好まれます。ただし、モノリシックアーキテクチャを選択する正当な理由がある場合は、それがモジュラー型であり、ユーザーの導入に際して製品がスケールされるにつれて、最終的に SOA またはマイクロサービスに進化できることを確認する必要があります。
- SOA は、マイクロサービスの複雑さを回避しながら、より小さなセグメント化を達成するための優れた折衷案となり得ます。
Microservice Trade-Offs - ワークロードが適していて、組織がサポートできる場合は、最高の俊敏性と信頼性を実現するために、マイクロサービスアーキテクチャを使用すべきです。
Implementing Microservices on AWS - AWS App Mesh をサービス指向アーキテクチャとともに使用することで、高い信頼性をもってサービスを検出し、サービスにアクセスできます。
What is AWS App Mesh?
特定のビジネスドメインと機能に重点を置いたサービスを構築する
- ドメイン分析を実行して、ワークロードのドメイン駆動型設計 (DDD) をマッピングします。次に、ワークロードのニーズを満たすアーキテクチャタイプを選択できます
How to break a Monolith into Microservices
Getting Started with DDD when Surrounded by Legacy Systems
Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”
Implementing Microservices on AWS
- ワークロードの API とその設計目標、制約、使用に関するその他の検討事項を定義します。
- API を定義します。
- 拡張と追加パラメータが実現可能になるように API を定義します。
- 設計時の可用性を定義します。
- さまざまな機能に関して API の設計目標を複数立てることができます。
- 制約を決める
- テスティングを利用して、ワークロードの能力の上限を定義します。
- API を定義します。
API ごとにサービス契約を提供する
Amazon API Gateway: Configuring a REST API Using OpenAPI
- バージョニング戦略により、クライアントは既存の API を引き続き使用し、準備ができたらアプリケーションを新しい API に移行できます。
- Amazon API Gateway は、開発者が規模を問わず簡単に API を作成できるようにする、完全マネージド型サービスです。以前は Swagger 仕様として知られていた OpenAPI 仕様 (OAS) を使用して、API 契約を定義し、初心者向け API Gateway にインポートできます。API Gateway を使用すると、API をバージョン管理してデプロイできます。