# REL03-BP01 ワークロードをセグメント化する方法を選択する
<a name="rel_service_architecture_monolith_soa_microservice"></a>

 アプリケーションの回復力要件を決定する際に、ワークロードのセグメント化は重要です。モノリシックアーキテクチャはできるだけ避ける必要があります。代わりに、どのアプリケーションコンポーネントをマイクロサービスに分けられるかを注意深く検討します。アプリケーションの要件によっては、最終的にサービス指向アーキテクチャ (SOA) とマイクロサービスの組み合わせになることもあります。ステートレス化が可能なワークロードは、マイクロサービスとしてデプロイすることができます。

 **期待できる成果:**ワークロードは、サポート可能でスケーラブルであり、可能な限り疎結合である必要があります。

 ワークロードのセグメント化方法を選択する場合は、複雑さとメリットのバランスを考慮してください。新製品のローンチ時に適しているものは、最初からスケールするように構築されたワークロードが必要とするものとは異なります。既存のモノリスをリファクタリングする場合、アプリケーションがステートレスへの分解をどの程度サポートできるかを検討する必要があります。サービスをより細かく分割すると、明確に定義された小規模なチームがサービスを開発し、管理できるようになります。ただし、サービスが細かくなると、レイテンシーの増加、デバッグの複雑化、運用負荷の増大など、複雑な問題が発生する可能性があります。

 **一般的なアンチパターン:** 
+  [マイクロサービス Death Star](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) とは、アトミックコンポーネントが強く依存しあっているために、1 つの失敗がより大きな失敗となり、コンポーネントがモノリスのように柔軟性が低く、壊れやすくなっている状態のことです。

 **このベストプラクティスを活用するメリット:** 
+  より特化したセグメントは、高い俊敏性、組織の柔軟性、およびスケーラビリティにつながります。
+  サービス中断の影響が小さくなります。
+  アプリケーションコンポーネントには異なる可用性要件があり、より特化したセグメント化によってサポートすることができます。
+  ワークロードをサポートするチームの責任が明確に定義されます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ワークロードをセグメント化する方法に基づいて、アーキテクチャタイプを選択します。SOA またはマイクロサービスアーキテクチャ (まれにモノリシックアーキテクチャ) を選択します。モノリシックアーキテクチャから開始する場合でも、それがモジュラー型で、ユーザーの導入に合わせて製品がスケールされるにつれて最終的に SOA またはマイクロサービスに進化できることを確認する必要があります。SOA とマイクロサービスは、それぞれより細かなセグメントを提供し、最新のスケーラブルで信頼性の高いアーキテクチャとして好まれていますが、特にマイクロサービスアーキテクチャをデプロイする際は、トレードオフを考慮しなければなりません。

 主なトレードオフとしては、分散コンピューティングアーキテクチャを採用することになり、ユーザーのレイテンシー要件を達成するのが難しくなることと、ユーザーインタラクションのデバッグとトレースがさらに複雑になることが挙げられます。AWS X-Ray をこの問題の解決に役立てることができます。管理するアプリケーションの数が増え、複数の独立したコンポーネントをデプロイする必要があるため、運用が複雑になることも考慮する必要があります。

![\[モノリシック、サービス指向、マイクロサービスアーキテクチャの比較を示した図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/monolith-soa-microservices-comparison.png)


## 実装手順
<a name="implementation-steps"></a>
+  アプリケーションのリファクタリングやビルドに適したアーキテクチャを決定します。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)を参照してください。

 **実装計画に必要な工数レベル:** 高 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [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) 

 **関連する例:** 
+  [イテレーティブアプリモダナイゼーションワークショップ](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)