AWS 에서 분산 디자인패턴 구현하기

• 발표자
  - 임연옥 솔루션즈 아키텍트_AWS
  - 조현수 솔루션즈 아키텍트_AWS

모놀리식 형태로 MVP 를 먼저 배포하고 비즈니스를 성장에 따라 복잡성을 추가하기

• 모놀리식 형태에서 계속해서 서비스를 추가하다보면 → 각각의 서비스 or 비즈니스가 추가될 때 마다 시스템별 영향도와 테스트가 점점 어렵게 됩니다.
• 모놀리식을 유지할지 분산 디자인 형태로 변경할지 결정해야합니다. → 정답은 없음. 상황에 가장 알맞은 형태를 선택!
• 분산 시스템을 선택했을 때의 장단점
  - 각 서비스를 유연하게 추가/변경 할 수 있고 그에 따른 테스트도 쉬워집니다.
  - 또한 서비스의 장애 전파가 방지된다는 장점이 있습니다.
  - 초기 구현과 인프라 관리가 어려움

분산 디자인 패턴으로 구현하기

• 핵심 시스템 복잡도의 해결 방법으로 분산 시스템을 채택한 경우.
• DDD에서 바운디드 컨텍스트를 정의 → 복잡한 시스템 내에서 경계와 범위를 정리
• 서로 영향을 최소화 알 수 있도록 구성합니다.
  - 이벤트를 이용해서 컨텍스트를 연결합니다.
  

아키텍처 품질 속성

주요 품질 속성	비기능적요구사항
단순성	다른 도메인간 커뮤니케이션 구현 간소화
확장성	트래필 폭증에도 높은 QPS/TPS 제공
사용성	높은 QPS/TPS 상황에서도 평소와 같은 사용자 경험 제공
성능	거의 실시간에 가까운 포인트 발급과 사용

• 모든 프로세스를 잘게 쪼개 연결하는 것이 아닌 사용성과 성능에 대해서 고려해야 합니다.
• 프로세스 정의 → 분리
  - 리스크가 적은 쪽을 선택하는 것이 일반적입니다.
  - 모든 단계에서 발생하는 장애에 대해서 어떤것이 치명적인지 식별할 필요성이 있습니다.
• 분산 디자인 패턴에서 고려해야할 비기능적 요구사항들
  - 단계별 체크아웃 워크플로 관리
  - 로컬 트랜잭션
  - 보상 트랜잭션
  - 1,000 TPS를 지원하는 리액티브 스케일링 (예시)
  - 워크플로 각 단계는 독립적으로 확장이 필요함.
• 가장 효과적으로 사용되는 패턴은 SAGA 오케스트레이션 패턴

SAGA 패턴

SAGA 오케스트레이션

• 오케스트레이션 엔진
• 단계별 워크플로 관리
• 로컬 트랜잭션과 보상

SAGA 코레오그래피

• 중앙 제어 없이(오케스트레이션이 없음) 서비스끼리 이벤트로 통신
• 각 컴퓨팅 구성요소는 독립적으로 다음 단계를 결정함
• 단점
  - 명령 추적이 어렵기 때문에 워크플로 파악이 어려움
  - Saga 참가자 간에 순환 종속성 발생 가능
  - 통합 테스트가 어려움

AWS Step Function 을 통한 SAGA 오케스트레이션 구축

이벤트 소싱을 활용한 CQRS 패턴 이용하기

이벤트 소싱

• 비즈니스 시스템으로부터 발생하는 상태 변경 이벤트를 순차적으로 저장
• 새로운 이벤트 발생 시 이벤트 목록의 마지막에 추가

CQRS (명령 쿼리 책임분리)

• 모든 비즈니스에 대응하는 완벽한 “데이터베이스”는 없음
• 다양한 모델로 데이터 저장과 표현이 가능
• 이벤트 소싱과는 밀접한 관계

통합 아키텍쳐