REL04-BP02 緩やかに結合された依存関係を実装する - AWS Well-Architected フレームワーク
実装のガイダンスリソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

REL04-BP02 緩やかに結合された依存関係を実装する

キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの依存関係は、疎結合されています。疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、弾力性と俊敏性を高めます。

キューイングシステム、ストリーミングシステム、ワークフローなどの依存関係を疎結合化すると、システムへの変更や障害の影響を最小限に抑えることができます。疎結合化により、コンポーネントの動作が依存する他のシステムに影響を与えないように分離され、回復力と俊敏性が向上します。

密結合のシステムでは、あるコンポーネントを変更すると、そのコンポーネントに依存する他のコンポーネントも変更しなければならなくなり、結果として、すべてのコンポーネントのパフォーマンスが低下する可能性があります。疎結合はこの依存関係を壊すため、依存コンポーネントが知る必要があるのは、バージョン管理されて公開されたインターフェイスのみです。依存関係があるコンポーネント間に疎結合を実装すると、あるコンポーネントの障害が別のコンポーネントに影響を及ぼさないように隔離することができます。

疎結合では、コードの変更やコンポーネントへの機能の追加を自由にできる一方で、そのコンポーネントに依存する他のコンポーネントへのリスクを最小限に抑えることができます。また、回復力を細分化でき、コンポーネントレベルでスケールアウトしたり、依存関係の根本的な実装さえも変更したりできます。

疎結合によって弾力性をさらに向上させるには、可能な場合はコンポーネント間のやりとりを非同期にします。このモデルは、即時応答を必要とせず、リクエストが登録されていることの確認で十分な状況では、どのような対話にも最適です。イベントを生成するコンポーネントと、イベントを消費するコンポーネントがあります。この 2 つのコンポーネントは、直接 point-to-pointのやり取りではなく、通常、Amazon SQSキュー、Amazon Kinesis などのストリーミングデータプラットフォーム、 などの中間の耐久性のあるストレージレイヤーを介して統合されます AWS Step Functions。

キューイングシステムやロードバランサーなどの依存関係が疎結合されていることを示す図

図 4: 疎結合されたキューイングシステムやロードバランサーなどの依存関係

Amazon SQSキューと AWS Step Functions は、結合を緩めるために中間レイヤーを追加する 2 つの方法です。イベント駆動型アーキテクチャは、Amazon AWS クラウド を使用して に構築することもできます。Amazon は EventBridge、クライアント (イベントプロデューサー) が依存するサービス (イベントコンシューマー) からクライアント (イベントプロデューサー) を抽象化できます。Amazon Simple Notification Service (Amazon SNS) は、ハイスループット、プッシュベースの many-to-manyメッセージングが必要な場合に効果的なソリューションです。Amazon SNSトピックを使用すると、パブリッシャーシステムは並列処理のために多数のサブスクライバーエンドポイントにメッセージをファンアウトできます。

キューにはいくつかの利点がありますが、ほとんどのハードリアルタイムシステムでは、しきい値の時間 (多くの場合、数秒) よりも長時間かかっているリクエストは古くなっているとみなされ (クライアントが停止し、応答を待機しなくなる)、処理されません。このように、古くなったリクエストの代わりに、より新しい (そしておそらくまだ有効な) リクエストを処理することができます。

期待される成果: 疎結合の依存関係を実装すると、コンポーネントレベルへの障害の面積を最小限に抑えることができ、問題の診断と解決に役立ちます。また、開発サイクルが簡素化され、チームはモジュールレベルで変更を実装できるようになり、その部分に依存する他のコンポーネントのパフォーマンスに影響は及びません。このアプローチでは、リソースのニーズに基づいてコンポーネントレベルでスケールアウトできるだけでなく、コスト効率良くコンポーネントを活用できるようになります。

一般的なアンチパターン:

  • モノリシックワークロードのデプロイ。

  • フェイルオーバーやリクエストの非同期処理機能のないワークロード層APIs間で直接呼び出す。

  • 共有データを使用した密結合。疎結合のシステムでは、共有データベースや他の形で密結合されたデータストレージを介したデータの共有を避ける必要があります。そうしたデータ共有が密結合を持ち込み、スケーラビリティを妨げる可能性があります。

  • バックプレッシャーを無視する。ワークロードには、コンポーネントが同じ速度でデータを処理できない場合に、データの受信を遅らせたり停止したりする機能が必要です。

このベストプラクティスを活用するメリット: 疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから隔離するのに役立ち、弾力性と俊敏性を高めます。1 つのコンポーネントの障害は他のコンポーネントから隔離されます。

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

実装のガイダンス

疎結合の依存関係を実装します。疎結合のアプリケーションを構築するためのさまざまなソリューションがあります。これには、フルマネージドキューを実装するためのサービス、自動化されたワークフロー、イベントへの対応APIsなど、他のコンポーネントからコンポーネントの動作を分離するのに役立つサービス、耐障害性と俊敏性の向上が含まれます。

  • イベント駆動型アーキテクチャの構築： Amazon EventBridge は、疎結合型および分散型のイベント駆動型アーキテクチャの構築を支援します。

  • 分散システムにキューを実装する： Amazon Simple Queue Service (Amazon SQS） を使用して、分散システムを統合および分離できます。

  • コンポーネントをマイクロサービスとしてコンテナ化： マイクロサービスを使用すると、チームは、明確に定義された を介して通信する小さな独立したコンポーネントで構成されるアプリケーションを構築できますAPIs。Amazon Elastic Container Service (Amazon ECS） と Amazon Elastic Kubernetes Service (Amazon EKS） は、コンテナの使用をより迅速に開始するのに役立ちます。

  • Step Functions を使用してワークフローを管理する： Step Functions は、複数の AWS サービスを柔軟なワークフローに調整するのに役立ちます。

  • パブリッシュサブスクライブ (pub/sub) メッセージングアーキテクチャを活用する： Amazon Simple Notification Service (Amazon SNS) は、パブリッシャーからサブスクライバー (プロデューサーおよびコンシューマーとも呼ばれます) へのメッセージ配信を提供します。

実装手順

リソース

関連ドキュメント:

関連動画: