AWS로 구성하는 Cloud-native Microservice Architectures
안녕하세요. 오늘은 목요일에 진행된 AWS Summit Seoul 을 참가하고 나서 참가했던 "12가지 디자인 패턴으로 알아보는 클라우드 네이티브 마이크로서비스 아키텍처"를 보고난 후 해당 정리하고자 합니다.
해당 세션은 이 전 세션이 끝나자 마자 갔음에도 불구하고 상당한 인파가 몰려서 뒷편에 서서 들었는데요.
발표 자료를 모두 찍었지만, 너무 뒷편이라 흐려서 해당 포스팅에 추가를 하지는 못했습니다. AWS Summit Seoul 자료가 6월 중에 공개된다고 하니, 그 때 다시 업데이트 하고자 합니다.
소개해주신 패턴 12가지는 아래의 구성 중 ✔️ 표시된 패턴들인데요.
| #1. API Management and Consumption Patterns | #2. Migration Patterns | #3. Data Management Patterns |
| ✔️ API Gateway Pattern API Microgateway Pattern ✔️ Backend for Frontends |
✔️ Strangler Fig Pattern Anti-corruption Layer Pattern Parallel Run Pattern Change Data Capture Pattern |
✔️ Database Per Service pattern Data Locality Pattern ✔️ CQRS Pattern ✔️ Materialized View Pattern |
| #4. Event-Driven Architecture Patterns | #5. Connectivity and Composition Patterns | #6. Communication Patterns |
| ✔️ Publish-Subscribe Pattern Producer-Consumer Pattern ✔️ Event Sourcing Pattem Pipe and Filter pattern |
✔️ Sidecar Pattem ✔️ Service Mesh Pattern ✔️ Service Choreography Pattern ✔️ Service Orchestration Pattern |
Request-Response Pattern Asynchronous Request-Reply Pattern Single-Receiver Pattern Multiple-Receiver Pattern |
해당 포스팅은 각 패턴의 자세한 설명보다는 각 패턴을 구성할 수 있는 AWS 서비스를 소개하고자, 아래와 같은 구성으로 정리했습니다.
해당 패턴이 속한 상위 패턴 분류 (위 표의 #N. <패턴 분류>)
Pattern Name
: 정의
📌 기존의 문제점
✔️ 해결 방식
해당 패턴을 적용 가능할 수 있는 AWS Services
API Management and Consumption Patterns
API Gateway Pattern
: Microservices의 비즈니스 기능을 API 소비자(Consumer)에게 통합된 API 엔드포인트로 노출
기존의 문제점
📌 Backend Microservices의 복잡성과 보안, 라우팅 정책 등을 적용 및 관리하는 단일 엔드포인트 필요
해결
✔️ 라우팅, 보안, Trottling, Caching 버전 관리 및 기타 정책 등 Cross Cutting Concern을 수행하는 중개자인 API Gateway 제공
AWS Service
Amazon API Gateway
API Management and Consumption Patterns
Backend for Frontends
: 특정 Frontend 애플리케이션의 요구사항에 맞는 API 구현을 위해 Frontend 만의 Backend API 서비스 추가
기존의 문제점
📌 모바일, 데스크톱, 웹 등 클라이언트 환경 별 상이한 요구사항을 충족하기 위한 Frontend의 변경 필요
해결
✔️ 특정 Frontend Application을 위한 맞춤 API를 BFF API로 제공하여 서비스 제공 유연성과 안정성 향상
AWS Service
Amazon API Gateway, AWS Lambda, AWS AppSync
Migration Patterns
Strangler Fig Pattern
: 모놀로식 애플리케이션 기능을 새로운 아키텍처에서 마이크로 서비스로 점진적인 현대화와 정환하는 패턴
기존의 문제점
📌 기존 레거시의 애플리케이션 기능들을 운영환경의 영향없이 연속성을 유지하면서 새로운 아키텍처로 이전 필요
해결
✔️ 새로운 마이크로서비스를 클라우드 환경에 구현하고 Reverse Proxy를 사용해서 전환하며 점진적으로 이전
AWS Service
Amazon API Gateway, AWS Application Load Balancer
Data Management Patterns
Database Per Service pattern
: 마이크로서비스 별로 독립적인 데이터 저장소를 사용하여 데이터베이스의 변경 가능성과 확장성을 제공
기존의 문제점
📌 마이크로서비스 별로 다른 요구사항을 만족시키면서 데이터베이스 변경이 타 서비스의 영향을 최소화할 필요
해결
✔️ 접근 패턴과 규모 등 목적에 맞는 데이터베이스를 독립적으로 사용하고 API를 통한 공유만 외부에 제공
AWS Service
Amazon Purpose-built Databases
Data Management Patterns
CQRS Pattern
: 읽기(Query)와 쓰기(Command) 저장소를 분리하고 이벤트 전달 방식을 사용하여 데이터 일관성을 유지
기존의 문제점
📌 단일 데이터베이스가 갖고 있는 유연성과 확장성의 한계로 인한 쓰기와 읽기 성능의 구조적인 제한
해결
✔️ 읽기와 쓰기 별 성능과 데이터 모델 요구에 맞는 별도 저장소를 사용하고 이벤트 저장소를 통해 동기화
AWS Service
Amazon Purpose-built Databases, Amazon MSK
Data Management Patterns
Materialized View Pattern
: 계산된 결과 데이터를 Materialized View로 미리 구성해서 실행부에 가깝게 배치하는 방법
기존의 문제점
📌 복잡한 조인이나 의존적인 외부 데이터 서비스 영향으로 데이터 조회 성능 저하가 발생
해결
✔️ 요구되는 데이터를 로컬 데이터 저장소나 캐시에 미리 최적의 형식으로 저장하여 조회 성능 향상
AWS Service
Amazon Purpose-built Databases, Amazon Lambda
Event-Driven Architecture Patterns
Publish-Subscribe Pattern
: 메시지 발행자가 메시지를 토픽에 발행하면 모든 구독자가 수신. 비동기 메시지 전달 패턴
기존의 문제점
📌 대규모 분산 시스템의 병렬성과 확장성 요구와 동기식 이벤트 전달이 가지는 대기시간 문제
해결
✔️ 복수의 발행자가 메시지 브로커의 토픽으로 전송한 메시지를 복수의 구독자가 모두 수신
AWS Service
Amazon SNS, Amazon EventBridge, Amazon Kinesis Data Stream, Amazon MSK
Connectivity and Composition Patterns
Sidecar Patten
: 애플리케이션 컨테이너의 기능을 확장하고 강화하는 용도로 사이드카 컨테이너를 추가하는 방식
기존의 문제점
📌 애플리케이션 컨테이너의 변경없이 통신, 모니터링, 보안 등의 공통적인 기능을 확장
해결
✔️ 주 컨테이너와 함께 스케줄링 및 동작하는 사이드카 컨테이너를 추가해 재사용 가능한 부가 기능 구현
AWS Service
Amazon EKS (Pod), Amazon ECS(Task)
Connectivity and Composition Patterns
Service Mesh Pattern
: 분산 애플리케이션에서 서비스 간 통신과 보안, 로깅, 로드밸런싱, 모니터링 등의 기능을 중앙에서 관리
기존의 문제점
📌 마이크로서비스들과 시스템들 간의 통신에서 연결성 로직을 마이크로서비스가 직접 관리해야 하는 문제
해결
✔️ 서비스 간 통신 로직 처리는 Sidecar Proxy (Data Plane)를 사용하고 제어하는 Control Plane이 담당
AWS Service
Amazon App Mesh, Amazon ECS service Connect
Connectivity and Composition Patterns
Service Choreography Pattern
: 여러 마이크로 서비스를 조합하는 비즈니스 기능의 구현을 이벤트 기반의 비동기 통신으로 합성하는 패턴
Choreography의 사전적 의미는 '안무' 입니다.
서비스 안무 패턴의 핵심은, 메세지 브로커(혹은 이벤트 허브)를 사용하는 비동기 Event-driven 통신 링크를 생성함으로써, 여러 마이크로서비스들과 다른 시스템들 사이에서의 상호작용을 요구하는 비즈니스 사용 사례를 구축할 수 있습니다.
상호작용 로직은 여러 마이크로서비스에 분산되어 있으며 마이크로서비스 간에 직접적인 결합이 발생하지 않습니다.
따라서 서비스 안무에서 사용하는 마이크로서비스를 reactive microservices라고도 합니다.
서비스 안무의 일부 핵심 개념은 Event Driven Architecture 패턴과 밀접한 관련이 있습니다.
마이크로서비스는 브로커로부터 들어오는 이벤트와 브로커에게 게시되는 이벤트를 통해 서로 상호 작용합니다.
기존의 문제점
📌 유연성과 확장성, 변경 비용을 고려해서 서비스들 간의 낮은 결합도 (Decoupled)와 비동기 통신이 필요
해결
✔️ 다른 마이크로 서비스를 능동적으로 직접 호출하지 않고 이벤트와 메시지를 기반으로 반응 모드로 작동
AWS Service
Amazon EventBridge, Amazon MSK, Amazon Kinesis Data Streams, Amazon SQS, Amazon SNS
Connectivity and Composition Patterns
Service Orchestration Pattern
: 중앙 컨트롤러 서비스(Orchestration)가 서비스 흐름 제어, 서비스 상호작용 조정하여 프로세스 관리
기존의 문제점
📌 단일 마이크로서비스의 분산에 따른 한계 존재
해결
✔️ 여러 마이크로 서비스에 분산되어 있는 상호작용을 중앙의 단일 서비스를 통해 비즈니스 로직 구현
AWS Service
AWS Step Functions
Connectivity and Composition Patterns
Saga Pattern
: 여러 트랜잭션을 그룹으로 관리 및 조정하여 일관성을 유지하도록하는 분산 트랜잭션의 장애 관리 패턴
기존의 문제점
📌 마이크로서비스 구조에서 긴밀한 결합없이 여러 마이크로서비스에 걸친 트랜잭션 처리의 복잡성
해결
✔️ 모든 트랜잭션 이벤트를 게시하고 결과에 따라 다음 트랜잭션을 시작, 혹은 실패할 경우 보상 트랜잭션 실행
AWS Service
AWS Step Functions