BLOG
메시징 패턴에 대한 블로그 시리즈의 첫 번째 포스팅에서는 메시징에 대한 개요와 동기 및 비동기 서비스 통신의 장점과 문제점을 설명했습니다. 그 두번째 시리즈로 오늘은 메시징 채널 기술을 평가할 때 고려해야 할 공통적인 특성을 살펴보고, AWS 서버리스 이벤트 버스인 Amazon EventBridge를 소개해드리겠습니다.
이벤트란?
이벤트는 과거에 발생한 일을 설명하는 변경 불가능한 메시지의 발생입니다. 이벤트 데이터 페이로드에는 일반적으로 발생 및 관련 메타 데이터에 대한 세부 사항이 포함됩니다. 이 시리즈의 이전 게시물에서 정의된 대로 이벤트는 전달 채널을 통해 생산자에서 잠재 소비자에게 전달됩니다. 이 이벤트는 해당 전달 채널에 가입한 소비자 수에 따라 0, 1 또는 다수의 소비자에게 전달될 수 있으며, 특정 이벤트에 대한 가입을 필터링한 가입 소비자로 제한될 수 있습니다.
아래는 AWS 이벤트의 예입니다. AWS 이벤트는 AWS 서비스에서 생성되고 JSON 객체로 표시됩니다. 아래에 표시된 모든 최상위 메타 데이터 필드가 필요하며 “세부 사항” 필드에 소스별 페이로드가 포함됩니다.
샘플 AWS 이벤트
“version”: “0”,
“id”: “6a7e8feb-b491-4cf7-a9f1-bf3703467718”,
“detail-type”: “EC2 Instance State-change Notification”,
“source”: “aws.ec2”,
“account”: “111122223333”,
“time”: “2017-12-22T18:43:48Z”,
“region”: “us-west-1”,
“resources”: [ “arn:aws:ec2:us-west-1:123456789012:instance/ i-1234567890abcdef0” ],
“detail”: { “instance-id”: ” i-1234567890abcdef0″, “state”: “terminated”
}
}
이벤트 스키마
위의 샘플 이벤트와 AWS 이벤트 사용자 설명서를 살펴보시면, 모든 이벤트의 최상위 필드에 대한 스키마와 “세부 사항” 필드에 소스별 속성에 대한 별도의 스키마가 있음을 알 수 있습니다. 이는 여러 AWS 서비스가 Amazon EventBridge 기본 message bus 이벤트를 전송하기 때문입니다. 공개된 스키마가 종종 있고 해당 스키마에 대한 요청의 유효성을 검사하는 HTTP API와 달리, 이벤트 전송 채널은 EventBridge의 기본 버스와 같이 채널을 통해 이기종 이벤트를 허용하는 것이 일반적입니다.
Amazon EventBridge에는 이벤트 스키마를 정의, 발견 및 개발하는 경험을 단순화하기 위한 Schema Registry가 있습니다. 레지스트리는 기존 AWS 서비스의 이벤트에 대한 OpenAPI 스키마로 미리 채워져 있으며 이를 통해 고유한 스키마를 정의할 수 있습니다. 또한, 레지스트리의 스키마에 널리 사용되는 프로그래밍 언어에 대한 코드 바인딩 다운로드를 지원합니다.
이벤트 채널 특성
비즈니스 및 기술 요구 사항과 비교하여 이벤트 채널 기술을 평가할 때는 다음 공통 특성을 명심해 주십시오. 이 목록은 완전하지는 않지만 각 기술을 익히는 데 유용할 것입니다.
- Ordering: 도착한 순서대로 이벤트 전송이 보장되나요?
- Duplication: 중복 이벤트가 발생할 수 있나요? 채널의 중복 이벤트가 중복 제거될 수 있나요?
- Fanout: 각 이벤트가 여러 소비자들로부터 전송되고 처리될 수 있나요?
- Push versus pull: 이벤트가 소비자에게 전송되나요? 아니면 소비자가 이벤트를 불러와야 하나요?
- Filtering: 이벤트 소비자가 채널을 통과하는 이벤트의 필터링 된 하위 집합을 받도록 선택할 수 있나요?
- Serverless: 채널 소유자가 기본 인프라를 관리하고 조정해야 하나요?
아마존 이벤트 브리지
Amazon EventBridge는 완전 관리형 서버리스 이벤트버스입니다. 제작자는 AWS 서비스, 지원되는 SaaS(Software as a Service) 파트너 또는 JSON 메시지를 EventBridge 이벤트 버스에 쓰는 자체 애플리케이션일 수 있습니다. 메시지는 이벤트 규칙의 대상으로 구성된 소비자에게 전달됩니다. 이벤트 규칙은 JSON 페이로드의 속성을 기반으로 메시지를 필터링 할 수 있으며 단일 규칙은 이벤트를 여러 대상으로 라우팅할 수 있습니다. 이벤트 규칙은 최대 24시간 동안 지수 백 오프를 사용하여 구성된 대상에 이벤트 전달을 재시도합니다. EventBridge는 이벤트 순서가 유지되는 것을 보장하지 않으며 최소 한 번의 이벤트 전달만을 보장하기에 중복 메시지가 도입될 수 있습니다. 다양한 이벤트 필터링, 수십 명의 소비자에 대한 이벤트 팬아웃, AWS 계정 전반에 걸친 메시지 전달 또는 소비, 다양한 AWS 서비스로부터 이벤트 청취, SaaS 파트너 시스템에서 메시지 수신과 같은 상황이시라면 EventBridge를 고려해 보셔야 할 때입니다.
결론
본 게시물에서는 이벤트를 정의하고 이벤트 전송 기술을 평가할 기준을 간략히 설명했습니다. 또한 이러한 기준에 따라 Amazon EventBridge를 간단히 검토했습니다. 이벤트 기술에 대해 더욱 자세히 알고 싶으시다면 AWS의 Distinguished Engineer인 Tim Bray씨가 AWS re: Invent 2019에서 발표한 ‘Moving to Event-Driven Architectures(이벤트 주도 아키텍처를 향해)’ 세션 영상과 AWS Tech Talk의 웨비나 영상을 시청해 주시기 바랍니다. Amazon EventBridge를 서버리스 아키텍처로 통합하는 예제가 궁금하시다면 해당 링크의 AWS 블로그 글을 확인해 주십시오.
원문URL: https://aws.amazon.com/ko/blogs/architecture/event-based-processing-for-asynchronous-communication/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.