のインフラストラクチャの例 AWS

このセクションでは、六角形アーキテクチャの実装に使用できる で AWS アプリケーションのインフラストラクチャを設計する例を示します。最小実行可能な製品 (MVP) を構築するためのシンプルなアーキテクチャから始めることをお勧めします。ほとんどのマイクロサービスには、クライアントリクエストを処理するための単一のエントリポイント、コードを実行するためのコンピューティングレイヤー、データを保存するための永続性レイヤーが必要です。次の AWS サービスは、六角形アーキテクチャのクライアント、プライマリアダプター、セカンダリアダプターとして使用するのに最適です。

• クライアント： Amazon API Gateway、Amazon Simple Queue Service (Amazon SQS)、Elastic Load Balancing、Amazon EventBridge

• プライマリアダプター： AWS Lambda、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Compute Cloud (Amazon EC2)

• セカンダリアダプター： Amazon DynamoDB、Amazon Relational Database Service (Amazon RDS)、Amazon Aurora、API Gateway、Amazon SQS、Elastic Load Balancing、EventBridge、Amazon Simple Notification Service (Amazon SNS)

以下のセクションでは、六角形アーキテクチャのコンテキストにおけるこれらのサービスについて詳しく説明します。

シンプルな開始

六角形アーキテクチャを使用してアプリケーションを設計するときは、簡単に開始することをお勧めします。この例では、API Gateway をクライアント (REST API) として使用し、Lambda をプライマリアダプター (コンピューティング) として使用し、DynamoDB をセカンダリアダプター (永続性) として使用します。ゲートウェイクライアントはエントリポイントを呼び出します。この場合は Lambda ハンドラーです。

このアーキテクチャは完全にサーバーレスで、アーキテクトの出発点として最適です。ドメインでコマンドパターンを使用することをお勧めします。これにより、コードの保守が容易になり、新しいビジネス要件や非機能要件に適応します。このアーキテクチャは、いくつかのオペレーションでシンプルなマイクロサービスを構築するのに十分です。

CQRS パターンを適用する

ドメインのオペレーション数がスケールする場合は、CQRS パターンに切り替えることをお勧めします。次の例を使用して、 で AWS CQRS パターンを完全にサーバーレスアーキテクチャとして適用できます。

この例では、2 つの Lambda ハンドラーを使用します。1 つはクエリ用、もう 1 つはコマンド用です。クエリは、API ゲートウェイをクライアントとして使用して同期的に実行されます。コマンドは、クライアントとして Amazon SQS を使用して非同期的に実行されます。

このアーキテクチャには、複数のクライアント (API Gateway と Amazon SQS) と複数のプライマリアダプター (Lambda) が含まれ、対応するエントリポイント (Lambda ハンドラー) によって呼び出されます。すべてのコンポーネントは同じ境界コンテキストに属するため、同じドメイン内にあります。

コンテナ、リレーショナルデータベース、外部 API を追加してアーキテクチャを進化させる

コンテナは、長時間実行されるタスクに適したオプションです。また、事前定義されたデータスキーマがあり、SQL 言語のパワーを享受したい場合は、リレーショナルデータベースを使用することもできます。さらに、ドメインは外部 APIsと通信する必要があります。次の図に示すように、これらの要件をサポートするようにアーキテクチャの例を進化させることができます。

この例では、ドメインで長時間実行されるタスクを起動するためのプライマリアダプターとして Amazon ECS を使用します。Amazon EventBridge (クライアント) は、特定のイベントが発生したときに Amazon ECS タスク (エントリポイント) を開始します。このアーキテクチャには、リレーショナルデータを保存するための別のセカンダリアダプターとして Amazon RDS が含まれています。また、外部 API コールを呼び出すためのセカンダリアダプターとして別の API ゲートウェイを追加します。その結果、アーキテクチャは、1 つのビジネスドメイン内のさまざまな基盤となるコンピューティングレイヤーに依存する複数のプライマリアダプターとセカンダリアダプターを使用します。

ドメインは常に、ポートと呼ばれる抽象化を通じて、すべてのプライマリアダプターとセカンダリアダプターと疎結合されます。ドメインは、ポートを使用して外部から必要なものを定義します。ポートを実装するのはアダプターの責任であるため、あるアダプターから別のアダプターに切り替えてもドメインには影響しません。例えば、ドメインに影響を与えずに新しいアダプターを記述することで、Amazon DynamoDB から Amazon RDS に切り替えることができます。

ドメインの追加 (ズームアウト）

六角形アーキテクチャは、マイクロサービスアーキテクチャの原則とよく一致しています。ここまでに示したアーキテクチャの例には、単一のドメイン (または境界コンテキスト) が含まれていました。アプリケーションには通常、プライマリアダプターとセカンダリアダプターを介して通信する必要がある複数のドメインが含まれます。各ドメインはマイクロサービスを表し、他のドメインと疎結合されています。

このアーキテクチャでは、各ドメインは異なるコンピューティング環境のセット (複数可) を使用します。（各ドメインには、前の例のように複数のコンピューティング環境がある場合もあります）。各ドメインは、ポートを介して他のドメインと通信するために必要なインターフェイスを定義します。ポートは、プライマリアダプターとセカンダリアダプターを使用して実装されます。これにより、アダプターに変更があってもドメインは影響を受けません。さらに、ドメインは互いに分離されます。

前の図に示すアーキテクチャの例では、Lambda、Amazon EC2、Amazon ECS、および AWS Fargate がプライマリアダプターとして使用されます。API Gateway、Elastic Load Balancing、EventBridge、および Amazon SQS がセカンダリアダプターとして使用されます。