# REL 3 ワークロードサービスアーキテクチャをどのように設計すればよいですか?
サービス指向アーキテクチャ (SOA) またはマイクロサービスアーキテクチャを使用して、拡張性と信頼性の高いワークロードを構築します。サービス指向アーキテクチャ (SOA) は、サービスインターフェイスを介してソフトウェアコンポーネントを再利用できるようにする方法です。マイクロサービスアーキテクチャは、その一歩先を行き、コンポーネントをさらに小さくシンプルにしています。
**Topics**
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する](rel_service_architecture_business_domains.md)
+ [REL03-BP03 API ごとにサービス契約を提供する](rel_service_architecture_api_contracts.md)
# REL03-BP01 ワークロードをセグメント化する方法を選択する
アプリケーションの回復力要件を決定する際に、ワークロードのセグメント化は重要です。モノリシックアーキテクチャはできるだけ避ける必要があります。代わりに、どのアプリケーションコンポーネントをマイクロサービスに分けられるかを注意深く考慮します。アプリケーションの要件によっては、最終的にサービス指向アーキテクチャ (SOA) とマイクロサービスの組み合わせになることもあります。ステートレス化が可能なワークロードは、マイクロサービスとしてデプロイすることができます。
**期待される成果:** ワークロードは、サポート可能で、スケーラブルであり、可能な限り疎結合であるべきです。
ワークロードのセグメント化について選択を行う場合は、複雑さに対してどれだけメリットがあるかを考えてください。新製品のローンチ時に適しているものは、初期からスケーリングのことを考えて構築したワークロードとは異なります。既存のモノリスをリファクタリングする場合、アプリケーションがステートレスへの分解をどの程度サポートできるかを検討する必要があります。サービスを小さく分割することで、小規模で明確なチームが開発、管理することができます。しかし、サービスの規模が小さくなると、レイテンシーの増加、デバッグの複雑化、運用負荷の増大など、複雑な問題が発生する可能性があります。
**一般的なアンチパターン:**
+ 「 [マイクロサービス *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) 」とは、アトミックコンポーネントが強く依存しあっているために、1 つの失敗がより大きな失敗となり、コンポーネントがモノリスのように柔軟性が低く、壊れやすくなっている状態のことです。
**このプラクティスを活用するメリット:**
+ より特化したセグメントは、高い俊敏性、組織の柔軟性、およびスケーラビリティにつながる。
+ サービス中断の影響が小さくなる。
+ アプリケーションコンポーネントには異なる可用性要件があり、より特化したセグメント化によってサポートされることがある。
+ ワークロードをサポートするチームの責任が明確に定義される。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードをセグメント化する方法に基づいてアーキテクチャタイプを選択します。SOA またはマイクロサービスアーキテクチャ (場合によってはモノリシックアーキテクチャ) を選択します。モノリスアーキテクチャから開始する場合でも、それがモジュラー型で、ユーザーの導入に合わせて製品がスケールされるにつれて最終的に SOA またはマイクロサービスに進化できることを確認する必要があります。SOA とマイクロサービスは、それぞれより小さなセグメントを提供し、最新のスケーラブルで信頼性の高いアーキテクチャとして好まれていますが、特にマイクロサービスアーキテクチャを展開する際には、トレードオフを考慮しなければなりません。
主なトレードオフとしては、分散コンピューティングアーキテクチャを採用することになり、ユーザーのレイテンシー要件を達成するのが難しくなることと、ユーザーインタラクションのデバッグとトレースにさらなる複雑さが生じることが挙げられます。AWS X-Ray を使ってこの問題の解決に役立てることができます。また、管理するアプリケーションの数が増え、複数の独立したコンポーネントを配置する必要があるため、運用が複雑になることも考慮しなければなりません。
![\[モノリシック、サービス指向、マイクロサービスアーキテクチャの比較を表す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## 実装手順
+ アプリケーションのリファクタリングやビルドに適したアーキテクチャを決定します。SOA とマイクロサービスは、それぞれより小さなセグメンテーションを提供し、最新のスケーラブルで信頼性の高いアーキテクチャとして好まれます。SOA は、マイクロサービスの複雑さを回避しながら、より小さなセグメント化を達成するための優れた折衷案となり得ます。詳細については、 [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html).
+ ワークロードが適していて、組織がサポートできる場合は、最高の俊敏性と信頼性を実現するために、マイクロサービスアーキテクチャを使用すべきです。詳細については、 [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ モノリスを [*Strangler Fig* パターン](https://martinfowler.com/bliki/StranglerFigApplication.html) に従って、より小さいコンポーネントにリファクタリングします。これには、特定のアプリケーションコンポーネントを新しいアプリケーションとサービスに徐々に置き換えることが含まれます。[AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) は、増分リファクタリングの開始点として機能します。詳細については、「 [オンプレミスのレガシーワークロードをシームレスに移行する](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)」を参照してください。
+ マイクロサービスを実装する場合、これらの分散したサービスが互いに通信できるようにするためのサービス検出メカニズムが必要になる場合があります。[AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) をサービス指向アーキテクチャとともに使用することで、高い信頼性をもってサービスを検出し、サービスにアクセスできます。 [AWS Cloud Map](https://aws.amazon.com/cloud-map/) は、動的 DNS ベースのサービス検出にも使用できます。
+ モノリスから SOA へ移行する場合、[Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) は、レガシーアプリケーションをクラウドで再設計する際に、サービスバスとしてギャップを埋めるのに役立ちます。
+ 単一の共有されたデータベースがある既存のモノリスには、データを再編成して小さなセグメントにする方法を選択します。これは、ビジネスユニット、アクセスパターン、またはデータ構造によって行うことができます。リファクタリングプロセスのこの時点では、リレーショナルまたは非リレーショナル (NoSQL) タイプのデータベースを選択して進めていく必要があります。詳細については、「 [SQL から NoSQL へ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html)」を参照してください。
**実装計画に必要な工数レベル:** 高
## リソース
**関連するベストプラクティス:**
+ [REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する](rel_service_architecture_business_domains.md)
**関連するドキュメント:**
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [サービス指向アーキテクチャとは](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [境界付けられたコンテキスト (ドメイン駆動設計の中心的なパターン)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS でのマイクロサービス](https://aws.amazon.com/microservices/)
+ [AWS App Mesh とは](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**関連する例:**
+ [Iterative App Modernization Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**関連動画:**
+ [Delivering Excellence with Microservices on AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する
サービス指向アーキテクチャ (SOA) は、ビジネスニーズに合わせて明確に定義された機能を備えたサービスを構築します。マイクロサービスはドメインモデルと境界付けられたコンテキストを使用してこれをさらに制限し、各サービスが 1 つのことだけを実行するようにします。特定の機能に焦点を当てることで、さまざまなサービスの信頼性要件を差別化し、より具体的に的を絞って投資することができます。簡潔なビジネス上の問題と各サービスに関連付けられた小さなチームにより、組織のスケーリングも容易になります。
マイクロサービスアーキテクチャを設計する際は、ドメイン駆動設計 (DDD) を使用して、エンティティでビジネス上の問題をモデル化すると便利です。例えば、Amazon.com ウェブサイトの場合、エンティティには、パッケージ、配送、スケジュール、料金、割引、通貨などがあります。その後、モデルは [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html)、そこで類似した機能と属性を共有するエンティティがグループ化されます。したがって、Amazon.com の例で言うと、パッケージ、配送、スケジュールは発送コンテキストの一部となり、料金、割引、通貨は料金コンテキストの一部となります。モデルをコンテキストに分割したら、マイクロサービスを境界で区切る方法のテンプレートが現れます。
![\[マイクロサービスを境界で区切る方法のモデルテンプレート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/building-services.png)
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ ビジネスドメインとそれぞれの機能に基づいてワークロードを設計します。特定の機能に焦点を当てることで、さまざまなサービスの信頼性要件を差別化し、より具体的に的を絞って投資することができます。簡潔なビジネス上の問題と各サービスに関連付けられた小さなチームにより、組織のスケーリングも容易になります。
+ ドメイン分析を実行して、ワークロードのドメイン駆動型設計 (DDD) をマッピングします。次に、ワークロードのニーズを満たすアーキテクチャタイプを選択できます。
+ [モノリスをマイクロサービスに分割する方法](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [レガシーシステムに囲まれているときの DDD の使用開始](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ サービスをできるだけ小さなコンポーネントに分解します。マイクロサービスアーキテクチャを使用すると、最小限の機能でワークロードをコンポーネントに分割し、全社的なスケーリングと俊敏性を実現できます。
+ ワークロードの API とその設計目標、制約、使用に関するその他の検討事項を定義します。
+ API を定義します。
+ 拡張と追加パラメータが実現可能になるように API を定義します。
+ 設計時の可用性を定義します。
+ さまざまな機能に関して API の設計目標を複数立てることができます。
+ 制約を決める
+ テスティングを利用して、ワークロードの能力の上限を定義します。
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [境界付けられたコンテキスト (ドメイン駆動設計の中心的なパターン)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”](https://www.amazon.com/gp/product/0321125215)
+ [レガシーシステムに囲まれているときの DDD の使用開始](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [モノリスをマイクロサービスに分割する方法](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS でのマイクロサービス](https://aws.amazon.com/microservices/)
# REL03-BP03 API ごとにサービス契約を提供する
サービス契約は、サービス統合に関するチーム間で文書化した合意で、機械で読み取ることができる API 定義、レート制限、パフォーマンスの期待値が含まれます。バージョニング戦略により、クライアントは既存の API を引き続き使用し、準備ができたらアプリケーションを新しい API に移行できます。契約に違反しない限り、デプロイはいつでも行うことができます。サービスプロバイダーチームは、選択した技術スタックを使用して、API 契約の条件を満たすことができます。同様に、サービスコンシューマーは独自のテクノロジーを使用できます。
マイクロサービスはサービス指向アーキテクチャ (SOA) という概念の進化形であり、マイクロサービスでは最小限の機能を備えたサービスを構築します。各サービスでは、サービスを使用するための API、設計目標、制限、その他の考慮事項が公開されています。これにより、アプリケーションの呼び出しを備えた *契約* が確立されます。これには次のような 3 つのメリットがあります。
+ このサービスでは、対応すべきビジネスの課題が簡潔で、それを共有するチームの規模は小さくなります。これにより組織の拡大が可能となります。
+ API の要件やその他の契約条件を満たしている限り、チームはいつでもデプロイできます。
+ API の要件やその他の契約条件を満たしている限り、チームはあらゆる技術スタックを使用することができます。
Amazon API Gateway は、デベロッパーがあらゆる規模の API の作成、公開、保守、モニタリング、保護を簡単に行えるようにするためのフルマネージド型サービスです。Amazon API Gateway は、トラフィック管理、認可とアクセスコントロール、モニタリング、API バージョン管理など、最大数十万個の同時 API 呼び出しの受け入れと処理に伴うすべてのタスクを取り扱います。以前は Swagger 仕様として知られていた OpenAPI 仕様 (OAS) を使用して、API 契約を定義し、API Gateway にインポートできます。API Gateway を使用すると、API をバージョン管理してデプロイできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ API ごとにサービス契約を提供するサービス契約は、サービス統合に関するチーム間の文書化された合意であり、機械で読み取ることができる API 定義、レート制限、パフォーマンスの期待値が含まれます。
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ バージョニング戦略により、クライアントは既存の API を引き続き使用し、準備ができたらアプリケーションを新しい API に移行できます。
+ Amazon API Gateway は、開発者が規模を問わず簡単に API を作成できる完全マネージド型サービスです。以前は Swagger 仕様として知られていた OpenAPI 仕様 (OAS) を使用して、API 契約を定義し、API Gateway にインポートできます。API Gateway を使用すると、API をバージョン管理してデプロイできます。
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: OpenAPI を使用した REST API の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [境界付けられたコンテキスト (ドメイン駆動設計の中心的なパターン)](https://martinfowler.com/bliki/BoundedContext.html)
+ [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [マイクロサービスのトレードオフ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [AWS でのマイクロサービス](https://aws.amazon.com/microservices/)