翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
REL03-BP01 ワークロードをセグメント化する方法を選択する
アプリケーションの回復力要件を決定する際に、ワークロードのセグメント化は重要です。モノリシックアーキテクチャはできるだけ避ける必要があります。代わりに、どのアプリケーションコンポーネントをマイクロサービスに分けられるかを注意深く検討します。アプリケーションの要件によっては、可能であれば、サービス指向アーキテクチャ (SOA) とマイクロサービスの組み合わせになる場合があります。ステートレス化が可能なワークロードは、マイクロサービスとしてデプロイすることができます。
期待できる成果:ワークロードは、サポート可能でスケーラブルであり、可能な限り疎結合である必要があります。
ワークロードのセグメント化方法を選択する場合は、複雑さとメリットのバランスを考慮してください。新製品のローンチ時に適しているものは、最初からスケールするように構築されたワークロードが必要とするものとは異なります。既存のモノリスをリファクタリングする場合、アプリケーションがステートレスへの分解をどの程度サポートできるかを検討する必要があります。サービスをより細かく分割すると、明確に定義された小規模なチームがサービスを開発し、管理できるようになります。ただし、サービスが細かくなると、レイテンシーの増加、デバッグの複雑化、運用負荷の増大など、複雑な問題が発生する可能性があります。
一般的なアンチパターン:
-
マイクロサービス Death Star
とは、アトミックコンポーネントが強く依存しあっているために、1 つの失敗がより大きな失敗となり、コンポーネントがモノリスのように柔軟性が低く、壊れやすくなっている状態のことです。
このベストプラクティスを活用するメリット:
-
より特化したセグメントは、高い俊敏性、組織の柔軟性、およびスケーラビリティにつながります。
-
サービス中断の影響が小さくなります。
-
アプリケーションコンポーネントには異なる可用性要件があり、より特化したセグメント化によってサポートすることができます。
-
ワークロードをサポートするチームの責任が明確に定義されます。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
ワークロードをセグメント化する方法に基づいて、アーキテクチャタイプを選択します。SOA またはマイクロサービスアーキテクチャ (またはまれにモノリシックアーキテクチャ) を選択します。モノリスアーキテクチャから始めることを選択した場合でも、それがモジュール式であり、最終的にはユーザーの採用に合わせて製品がスケールアップされるにつれて SOAまたは マイクロサービスに進化できることを確認する必要があります。SOA マイクロサービスは、最新のスケーラブルで信頼性の高いアーキテクチャとして推奨されているセグメンテーションをそれぞれ小さくしますが、特にマイクロサービスアーキテクチャをデプロイする場合は、考慮すべきトレードオフがあります。
主なトレードオフとしては、分散コンピューティングアーキテクチャを採用することになり、ユーザーのレイテンシー要件を達成するのが難しくなることと、ユーザーインタラクションのデバッグとトレースがさらに複雑になることが挙げられます。 AWS X-Ray をこの問題の解決に役立てることができます。管理するアプリケーションの数が増え、複数の独立したコンポーネントをデプロイする必要があるため、運用が複雑になることも考慮する必要があります。
モノリシック、サービス指向、マイクロサービスアーキテクチャ
実装手順
-
アプリケーションのリファクタリングやビルドに適したアーキテクチャを決定します。SOA マイクロサービスは、それぞれより小さなセグメンテーションを提供します。これは、最新のスケーラブルで信頼性の高いアーキテクチャとして推奨されます。SOA は、マイクロサービスの複雑さの一部を回避しながら、より小さなセグメンテーションを実現するための良い妥協点となる可能性があります。詳細については、マイクロサービスのトレードオフ
を参照してください。 -
ワークロードが適していて、組織がサポートできる場合は、最高の俊敏性と信頼性を実現するために、マイクロサービスアーキテクチャを使用する必要があります。詳細については、「 でのマイクロサービスの実装」を参照してください AWS。
-
モノリスを細かなコンポーネントにリファクタリングするには、Strangler Fig のパターン
に従うことを検討してください。これには、特定のアプリケーションコンポーネントを新しいアプリケーションやサービスに徐々に置き換えることが含まれます。AWS Migration Hub Refactor Spaces は、増分リファクタリングの開始点として機能します。詳細については、ストラングラーパターンを使用してオンプレミスのレガシーワークロードをシームレスに移行する を参照してください。 -
マイクロサービスを実装するには、これらの分散サービスと相互に通信するためのサービス検出メカニズムが必要になる場合があります。 は、サービス指向アーキテクチャで使用して、サービスの信頼性の高い検出とアクセスを提供AWS App Meshできます。 は、動的でDNSベースのサービス検出AWS Cloud Map
にも使用できます。 -
モノリスから に移行する場合SOA、Amazon MQ はクラウドでレガシーアプリケーションを再設計する際に、サービスバスとしてのギャップを埋めるのに役立ちます。
-
単一の共有されたデータベースがある既存のモノリスには、データを再編成して細かなセグメントにする方法を選択します。これは、ビジネスユニット、アクセスパターン、またはデータ構造によって行うことができます。リファクタリングプロセスのこの時点で、リレーショナルまたは非リレーショナル (いいえSQL) タイプのデータベースを先に進めることを選択する必要があります。詳細については、「 から SQLなしSQL」を参照してください。
実装計画に必要な工数レベル: 高
リソース
関連するベストプラクティス:
関連ドキュメント:
関連する例:
関連動画:
