이 지침에서는 마이크로서비스, API 우선, 클라우드 네이티브 SaaS 및 헤드리스 애플리케이션의 MACH 원칙을 사용하여 AWS에서 여러 시스템을 원활하게 통합합니다. 통합 상거래는 모든 고객 대면 접점을 포괄하여 채널과 관계없이 통일된 경험을 제공함으로써 다중 채널 접근 방식의 사일로를 허뭅니다. 이 지침을 배포하면 마케팅과 운영을 통합하여 일관된 브랜드 참여로 고객 만족도를 높이고 지지도를 높일 수 있습니다.
아키텍처 다이어그램
[아키텍처 다이어그램 설명]
1단계
프런트엔드 애플리케이션 또는 헤드는 AWS AppSync와 같은 API 계층에 추상화된 일련의 공용 마이크로서비스와 다른 애플리케이션을 사용하여 헤드리스 애플리케이션을 구축합니다.
2단계
Amazon DynamoDB와 Amazon Neptune 같은 공용 마이크로서비스는 프런트엔드 경험 애플리케이션을 지원하는 애플리케이션 로직과 데이터를 제공합니다. 프런트엔드 애플리케이션은 일반적으로 소매업체의 오퍼를 경쟁사의 오퍼와 차별화하는 서비스를 제공합니다.
3단계
서비스형 소프트웨어(SaaS) 애플리케이션은 소매업체의 서비스가 차별화되지 않은 경우 최대한 완성도 높고 상시 업데이트되는 애플리케이션 로직을 제공하는 데 사용됩니다.
4단계
기존의 상용(COTS) 애플리케이션을 Amazon Elastic Compute Cloud(Amazon EC2) 및Amazon Relational Database Service(RDS)와 같은 AWS 서비스에 배포함으로써, SaaS로 제공되지 않거나 아직 마이크로서비스로 분해되지 않은 애플리케이션 서비스를 제공할 수도 있습니다.
5단계
온프레미스 창고 관리 시스템, 전사적 자원 관리(ERP) 또는 재무 소프트웨어와 같은 기존 레코드 또는 위치 기반 시스템도 집계 API를 통해 통합됩니다.
6단계
모든 마이크로서비스와 애플리케이션은 규칙에 따라 Amazon EventBridge 사용자 지정 이벤트 버스에 게시되며 분리된 애플리케이션에서 소비됩니다.
7단계
애플리케이션 데이터와 이벤트는 실시간 및 기간별 분석 및 보고를 위해 Amazon Simple Storage Service(S3) 또는 Amazon Athena와 같은 데이터 플랫폼으로 스트리밍됩니다.
8단계
실시간 이벤트에 따라 동적 콘텐츠와 마케팅 오퍼가 개인화되고, 선택한 참여 채널을 통해 고객에게 푸시됩니다. 기계 학습은 데이터 계층을 소스로 사용하여 예측 및 지능형 인사이트를 생성합니다.
9단계
기계 학습은 데이터 계층을 소스로 사용하여 예측 및 지능형 인사이트를 생성합니다.
Well-Architected 원칙
AWS Well-Architected Framework는 클라우드에서 시스템을 구축하는 동안 사용자가 내리는 의사 결정의 장단점을 이해하는 데 도움이 됩니다. 이 프레임워크의 6가지 원칙을 통해 안정적이고 안전하며 효과적이고 비용 효율적이며 지속 가능한 시스템을 설계 및 운영하기 위한 아키텍처 모범 사례를 배울 수 있습니다. AWS Management Console에서 추가 요금 없이 사용할 수 있는 AWS Well-Architected Tool을 사용하면 각 원칙에 대한 여러 질문에 답하여 이러한 모범 사례와 비교하며 워크로드를 검토할 수 있습니다.
위의 아키텍처 다이어그램은 Well-Architected 모범 사례를 고려하여 생성된 솔루션의 예시입니다. Well-Architected를 완전히 충족하려면 가능한 많은 Well-Architected 모범 사례를 따라야 합니다.
-
운영 우수성
제안된 아키텍처는 가능한 경우 관리형 서비스를 활용하므로 대규모 운영이 가능합니다. 기존 COTS 애플리케이션은 Amazon CloudWatch 경보 및 로그와 함께 Amazon EC2 인스턴스 지표를 활용했습니다. 오토 스케일링과 관리형 Amazon RDS로 장애를 복구할 수 있습니다.
-
보안
이 아키텍처는 가능한 경우 관리형 서비스를 활용하므로, 보안 모범 사례에 따른 보안 책임의 상당 부분을 AWS가 Amazon S3의 암호화된 데이터, 축소된 IAM 역할, Amazon DynamoDB의 저장 데이터 암호화 등을 통해 처리합니다. Amazon Cognito를 통해 소비자에게, IAM 역할을 통해 운영자에게 각각 강력한 ID가 적용됩니다. 추적 기능을 제공하는 CloudWatch Logs와 AWS CloudTrail은 Amazon GuardDuty, AWS Security Hub, 중앙 SIEM 등 전사적으로 적용되는 기능과 함께 사용할 수 있습니다.
-
신뢰성
관리형 서비스를 사용하면 기본적으로 신뢰성이 확보됩니다. Amazon S3와 DynamoDB의 스토리지 이중화, Amazon SageMaker 인스턴스의 규모 조정, Amazon Redshift, Athena, Amazon SageMaker Canvas, Amazon Pinpoint, Amazon Personalize, AWS AppSync, EventBridge도 고가용성을 제공하도록 설계되었습니다. 문제가 발생할 경우 동일한 파이프라인을 사용하여 Amazon S3의 원시 이벤트에서 데이터를 재생할 수 있습니다. EventBridge 아카이브 및 응답 기능을 사용하여 이벤트를 재생할 수도 있습니다. 이 컨테이너 아키텍처는 AWS Fargate에서 실행되는 Amazon Elastic Container Service(Amazon ECS) 또는 Amazon Elastic Kubernetes Service(Amazon EKS) 중 하나를 통해 수평적으로 확장되며 용량 수요에 맞게 동적으로 조정됩니다.
-
성능 효율성
가능한 경우 AWS Lambda, DynamoDB, SageMaker 엔드포인트, Amazon Redshift 등의 AWS 서버리스 서비스를 사용하여 규모가 조정됩니다.
-
비용 최적화
사용 시에만 요금이 청구되도록 설계되었기 때문에 관리형 서비스와 서버리스 서비스를 이용하면 아키텍처 비용을 최소화할 수 있습니다.
-
지속 가능성
제안된 아키텍처는 필요할 때만 실행하는 지속 가능한 접근 방식을 따르기 위해, 가능한 경우에는 관리형 및 서버리스 서비스를 이용합니다. AWS 고객 탄소 발자국 도구를 사용하여 총 영향 수치를 얻을 수 있습니다.
구현 리소스
실험 및 사용을 위한 자세한 안내는 AWS 계정 내에서 제공됩니다. 배포, 사용, 정리를 포함한 지침 구축의 각 단계는 검토되어 배포를 위해 준비됩니다.
시작점으로서 샘플 코드를 제공합니다. 이 샘플 코드는 업계에서 검증되었고 규범적이지만 최종적인 것은 아니며, 시작하는 데 도움을 줄 것입니다.
관련 콘텐츠
고지 사항
샘플 코드, 소프트웨어 라이브러리, 명령줄 도구, 개념 증명, 템플릿 또는 기타 관련 기술(AWS 직원을 통해 제공되는 상기 항목 포함)은 AWS 이용 계약 또는 귀하와 AWS 간의 서면 계약(둘 중 해당되는 것)에 따라 AWS 콘텐츠로 제공됩니다. 이 AWS 콘텐츠를 프로덕션 계정, 프로덕션 또는 기타 중요한 데이터에 사용해서는 안 됩니다. 귀하는 특정 품질 제어 방식 및 표준에 따라 프로덕션급 사용에 적절하게 샘플 코드와 같은 AWS 콘텐츠를 테스트, 보호 및 최적화할 책임이 있습니다. AWS 콘텐츠를 배포하면 Amazon EC2 인스턴스를 실행하거나 Amazon S3 스토리지를 사용할 때와 같이 요금이 부과되는 AWS 리소스를 생성하거나 사용하는 것에 대한 AWS 요금이 발생할 수 있습니다.
본 지침에 서드 파티 서비스 또는 조직이 언급되어 있다고 해서 Amazon 또는 AWS와 서드 파티 간의 보증, 후원 또는 제휴를 의미하지는 않습니다. AWS의 지침을 기술적 시작점으로 사용할 수 있으며 아키텍처를 배포할 때 서드 파티 서비스와의 통합을 사용자 지정할 수 있습니다.