글쓰는 감자

이벤트를 사용하여 분리된 서비스를 서로 트리거하고 통신하며
마이크로 서비스로 구축된 현대적 애플리케이션에서는 일반적

이벤트: 상태의 변화 또는 업데이트, 식별자

(이벤트 생산자 → 이벤트 라우터 → 이벤트 소비자)

사용 사례

• 계정 간, 리전 간 데이터 복제
  • 이벤트 라우터를 사용하여 시스템 간에 데이터를 전송하면 다른 팀과 독립적으로 서비스를 개발하고 크기 조정하고 배포 가능
• 리소스 상태 모니터링 및 알림
• 팬아웃 및 병렬 처리
  • 이벤트에 반응하여 작동해야 하는 시스템이 많은 경우
  • 라우터가 이벤트를 시스템에 푸시하면, 각 시스템이 각각 다른 목적으로 이벤트를 병렬로 처리 가능
• 이기종 시스템의 통합
  • 시스템이 서로 다른 스택에서 실행 중인 경우 결합하지 않은 상태로 시스템 간 정보 공유 가능

고려 사항

• 이벤트 소스의 내구성. (이벤트 소스를 신뢰할 수 있어야 하며 전송이 보장되어야 함)
• 성능 제어 요구 사항. (애플리케이션이 이벤트 라우터의 비동기 특성을 처리할 수 있어야 함)
• 이벤트 흐름 추적. (모니터링 서비스를 통한 동적 추적은 가능, 코드 분석을 통한 정적 추적은 불가능)
• 이벤트 소스의 데이터. (상태를 다시 빌드해야할 경우 이벤트 소스가 중복 제거되고 순서가 지정되어야 함)

여기까지가 간단한 아키텍처 관련 내용 이였고.. 이벤트 라우터 역할의 서비스를 알아보자.

간단하게 알아보고 자세한 내용은 나중에 콘솔 뜯을 때 확인하자...😅

Amazon EventBridge

• AWS, 기존 시스템 또는 SaaS 애플리케이션에서 대규모 이벤트 기반 애플리케이션 구축
• 이벤트 수신, 필터링, 변환, 라우팅 및 전송 기능을 제공하는 serverless event bus
• 스키마
  • 전송되는 이벤트의 구조를 정의
  • 사용자 정의 스키마 생성 또는 업로드 / 이벤트 버스 이벤트에서 직접 스키마 유추
  • API를 사용해 IDE에서 직접 스키마에 대한 코드 바인딩으로 작업 및 관리 가능
• 이벤트 버스
  • 이벤트를 수신하는 파이프라인
  • 규칙을 특정 이벤트 버스와 연결(해당 이벤트 버스에서 수신한 이벤트에만 규칙이 적용됨)
    • 각 이벤트 버스에 대해 최대 300개의 규칙
  • Default event bus: AWS 서비스에서 이벤트 수신
  • Custom event bus: 다른 계정/리전으로 이벤트를 보내거나 이벤트 수신
  • Partner event bus: SaaS 파트너로부터 이벤트 수신
• 규칙
  • 들어오는 이벤트를 일치시키고 처리를 위해 대상으로 보냄
  • 이벤트 패턴(이벤트 구조와 규칙이 일치하는 필드 정의) / 일정(일정한 간격으로 작업 수행) 기반
  • 규칙에 대해 최대 5개의 대상 정의 가능
• 이벤트 아카이브 및 리플레이
  • 아카이브 생성 시 이벤트 패턴을 지정하여 아카이브로 보낼 이벤트 결정 
  • 이벤트를 리플레이하여 오류를 복구, 애플리케이션의 새 기능을 검증 가능
  • 이벤트 버스에 게시되는 이벤트와 아카이브에 도착하는 이벤트 사이에 지연 있을 수 있음
    • 모든 이벤트가 리플레이 되도록 이벤트 리플레이를 10분 동안 지연하는 것이 좋음
• 기능
  • https://aws.amazon.com/ko/eventbridge/features/

Amazon Simple Notification Service (SNS)

• 애플리케이션 간(A2A) 및 애플리케이션과 사용자 간(A2P) 통신 모두를 위한 완전 관리형 메시징 서비스
• SNS topic을 사용하여 게시자 시스템은 병렬 처리를 위해 SQS, Lambda 등 많은 구독자 시스템으로 메시지를 팬아웃
  • Pub/Sub 말고도 SMS, 모바일 푸시 가능
• 팬아웃 시나리오가 메인인 느낌.. 이는 실습과 함께 다뤄볼 예정!😁