기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
이 섹션에서는 육각형 아키텍처를 구현하는 데 사용할 수 있는의 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 패턴을 완전 서버리스 아키텍처로 적용할 수 있습니다.

이 예제에서는 쿼리용과 명령용의 두 Lambda 핸들러를 사용합니다. 쿼리는 API 게이트웨이를 클라이언트로 사용하여 동기적으로 실행됩니다. 명령은 Amazon SQS를 클라이언트로 사용하여 비동기적으로 실행됩니다.
이 아키텍처에는 여러 클라이언트(API Gateway 및 Amazon SQS)와 해당 진입점(Lambda 핸들러)에서 호출하는 여러 프라이머리 어댑터(Lambda)가 포함됩니다. 모든 구성 요소는 동일한 경계 컨텍스트에 속하므로 동일한 도메인 내에 있습니다.
컨테이너, 관계형 데이터베이스 및 외부 API를 추가하여 아키텍처 개선
컨테이너는 장기 실행 작업에 적합한 옵션입니다. 사전 정의된 데이터 스키마가 있고 SQL 언어의 기능을 활용하려는 경우 관계형 데이터베이스를 사용할 수도 있습니다. 또한 도메인은 외부 APIs. 다음 다이어그램과 같이 아키텍처 예제를 발전시켜 이러한 요구 사항을 지원할 수 있습니다.

이 예제에서는 Amazon ECS를 도메인에서 장기 실행 작업을 시작하기 위한 기본 어댑터로 사용합니다. Amazon EventBridge(클라이언트)는 특정 이벤트가 발생할 때 Amazon ECS 작업(입력 지점)을 시작합니다. 아키텍처에는 관계형 데이터를 저장하기 위한 또 다른 보조 어댑터로 Amazon RDS가 포함되어 있습니다. 또한 외부 API 호출을 호출하기 위한 보조 어댑터로 다른 API 게이트웨이를 추가합니다. 따라서 아키텍처는 하나의 비즈니스 도메인에서 서로 다른 기본 컴퓨팅 계층에 의존하는 여러 기본 및 보조 어댑터를 사용합니다.
도메인은 항상 포트라는 추상화를 통해 모든 기본 및 보조 어댑터와 느슨하게 연결됩니다. 도메인은 포트를 사용하여 외부 세계에서 필요한 사항을 정의합니다. 포트를 구현하는 것은 어댑터의 책임이므로 한 어댑터에서 다른 어댑터로 전환하는 것은 도메인에 영향을 주지 않습니다. 예를 들어 도메인에 영향을 주지 않고 새 어댑터를 작성하여 Amazon DynamoDB에서 Amazon RDS로 전환할 수 있습니다.
도메인 추가(줌아웃)
육각형 아키텍처는 마이크로서비스 아키텍처의 원칙에 잘 부합합니다. 지금까지 표시된 아키텍처 예제에는 단일 도메인(또는 경계 컨텍스트)이 포함되어 있습니다. 애플리케이션에는 일반적으로 기본 및 보조 어댑터를 통해 통신해야 하는 여러 도메인이 포함됩니다. 각 도메인은 마이크로서비스를 나타내며 다른 도메인과 느슨하게 연결됩니다.

이 아키텍처에서 각 도메인은 서로 다른 컴퓨팅 환경(들) 세트를 사용합니다. (이전 예제와 같이 각 도메인에는 여러 컴퓨팅 환경이 있을 수도 있습니다.) 각 도메인은 포트를 통해 다른 도메인과 통신하는 데 필요한 인터페이스를 정의합니다. 포트는 기본 및 보조 어댑터를 사용하여 구현됩니다. 이렇게 하면 어댑터가 변경되더라도 도메인은 영향을 받지 않습니다. 또한 도메인은 서로 분리됩니다.
이전 다이어그램에 표시된 아키텍처 예제에서는 Lambda, Amazon EC2, Amazon ECS 및 AWS Fargate 가 기본 어댑터로 사용됩니다. API Gateway, Elastic Load Balancing, EventBridge 및 Amazon SQS가 보조 어댑터로 사용됩니다.