BLOG
Amazon EventBridge를 사용하면 AWS 서비스, 통합 소프트웨어 SaaS(Software as a Service) 애플리케이션 및 자체 애플리케이션 간에 이벤트를 라우팅할 수 있습니다. 이벤트 생산자는 이벤트를 이벤트 버스에 공개합니다. 이 이벤트 버스는 규칙을 사용하여 해당 이벤트를 보낼 위치를 결정합니다. 규칙은 하나 이상의 다른 AWS 서비스나 Lambda 함수과 같은 대상을 지정할 수 있습니다. 이 모델을 사용하면 이벤트 라우팅 및 필터링을 처리하여 확장 가능한 분산 서버리스 응용 프로그램을 쉽게 개발할 수 있습니다.
EventBridge는 최근 추가 컨텐츠 필터링 기능을 도입하여 정교한 규칙을 구축할 수 있는 새로운 가능성을 제시했습니다. 오늘 블로그 포스팅으로는 이벤트 패턴을 사용하여 사용자 지정 코드 없이 해당 라우팅 프로세스를 보다 강력하게 만들도록 규칙을 작성하는 방법에 대해 다루어 보겠습니다. 또한 AWS 서비스에 통합된 샘플 ATM 뱅킹 애플리케이션에서 어떻게 작동하는지 보여드리겠습니다.
이벤트, 규칙 및 필터링
EventBridge에서 이벤트는 단순히 JSON 구조입니다. 여기에는 소스, 이벤트 및 타임 스탬프와 같은 최상위 레벨 인벨롭 필드와 이벤트 본문을 포함하는 세부 사항 필드가 포함됩니다. AWS 서비스에서 생성된 이벤트는 항상 많은 설명 필드를 포함하며 소스 속성 접두사 “aws”로 식별할 수 있습니다.
자신의 애플리케이션에서 이벤트를 생성할 수도 있습니다. EventBridge에는 특정 인벨롭 필드가 필요하지만, 필요에 따라 추가 속성을 자유롭게 추가할 수 있습니다. 사용자 지정 응용 프로그램의 일반적인 이벤트 구조는 다음과 같습니다.
{
“Source”: string,
“EventBusName”: string,
“DetailType”: string,
“Detail”: string
}
애플리케이션이 중첩 속성을 사용하는 경우 Detail속성을 문자열로 변환해야 합니다. Node.js와 같은 프로그래밍 언어에서 이벤트를 보낼 때 JSON.stringify를 사용하고, 이벤트를 받을 때 JSON.parse를 수행할 수 있습니다. 예를 들어 ATM 애플리케이션이 EventBridge로 이벤트를 보내는 뱅킹 애플리케이션인 경우 현금 인출 이벤트는 다음과 같습니다.
{
“Source”: “custom.myATMapp”,
“EventBusName”: “default”,
“DetailType”: “transaction”,
“Detail”: “{\”action\”:\”withdrawal”,\”amount\”:300}“
}
EventBridge 규칙은 JSON 구조인 이벤트 패턴을 사용합니다. 이는 이벤트의 속성과 일치합니다. 규칙에서 필터링 논리를 적용할 필드만 지정하십시오.
이벤트 버스를 사용하여 단일 애플리케이션에 대한 모든 이벤트를 보려면 소스별로 필터링할 수 있습니다. 이 소스로 들어오는 모든 이벤트는 다른 필드의 내용과 관계없이 일치합니다. ATM 애플리케이션 예제에서 모든 이벤트를 승인하는 규칙은 다음과 같습니다.
{
“source”: [ “custom.myATMapp” ]
}
EventBridge는 들어오는 이벤트를 검사하여 이 규칙과 비교합니다. 규칙은 소스값을 지정하며 custom.myATMapp이벤트에 존재하는 경우 패턴과 일치합니다. 그런 다음 이벤트를 규칙의 타겟으로 라우팅합니다.
위의 예는 정적 일치 패턴을 보여줍니다. 속성이 존재하거나 존재하지 않습니다. 특정 비교 조건에 따라 동적 매칭에 사용할 수 있는 추가 연산자가 있습니다. 데이터베이스의 레코드를 필터링하기 위해 SQL where 절에서 사용하는 것과 유사한 기능을 제공합니다.
다음은 EventBridge에서 사용 가능한 모든 비교 연산자에 대한 요약입니다.
| 비교 | 예 | 규칙 구문 |
| Null | UserID가 null | “UserID”: [null] |
| Empty | 성은 비어 있습니다 | “성”: [“”] |
| Equals | 이름은 “앨리스”입니다 | “이름”: [“앨리스”] |
| And | 위치는 “New York”이고 Day는 “Monday”입니다. | “위치”: [“뉴욕”],“일”: [“월요일”] |
| Or | PaymentType은“신용”또는“직불”입니다. | “지급 유형”: [“신용”,“직불”] |
| Not | 날씨는“비가 내린다” | “날씨”: [{ “아무것도”: [ “비가 내림”]}] |
| Numeric (equals) | 가격은 100입니다 | “가격”: [{ “숫자”: [ “=”, 100]}] |
| Numeric (range) | 가격이 10보다 크고 20보다 작거나 같습니다 | “가격”: [{ “숫자”: [ “>”, 10, “<=”, 20]}] |
| Exists | 제품 이름이 존재합니다 | “ProductName”: [{“exists”: true}] |
| Does not exist | ProductName이 없습니다 | “ProductName”: [{ “존재”: false}] |
| Begins with | 지역은 미국에 있습니다 | “지역”: [{ “접두사”: “us-“}] |
사용자 지정 응용 프로그램에서 이벤트 필터링
본 예제에서 은행은 트랜잭션 정보를 EventBridge로 전달하는 ATM 네트워크에서 소프트웨어를 실행합니다. 이 소프트웨어는 모든 이벤트를 EventBridge로 전송하지만 다운 스트림 시스템은 ATM 이벤트의 서브 세트만 수신하고자 합니다.
ATM의 이벤트는 다음 구조를 갖습니다.
{
“Source”: “custom.myATMapp”,
“EventBusName”: “default”,
“DetailType”: “transaction”,
“Time”: “Wed Jan 29 2020 08:03:18 GMT-0500”,
“Detail”:{
“action”: “withdrawal”,
“location”: “NY-NYC-001”,
“amount”: 300,
“result”: “approved”,
“transactionId”: “123456”,
“cardPresent”: true,
“partnerBank”: “Example Bank”,
“remainingFunds”: 722.34
}
}
다운 스트림 서비스는 EventBridge 규칙의 이벤트 패턴을 사용하여 특정 이벤트만 수신할 수 있습니다.
- 금액이 $ 300 이상인 거래
다음 이벤트 패턴은 300달러가 넘는 ATM 거래를 필터링합니다.
{
“source”: [ “custom.myATMapp” ],
“detail-type”: [ “transaction” ],
“detail”: {
“amount”: [ { “numeric”: [ “>”, 300 ] } ]
}
}
- 뉴욕시의 모든 ATM
ATM 위치 속성은 state-city-id 형식을 사용하므로 NY-NYC-001은 기기가 뉴욕 주 뉴욕시에 있음을 나타냅니다. 뉴욕시 지역의 ATM에서만 이벤트를 필터링하기 위해 필터에 접두사를 사용합니다.
{
“source”: [ “custom.myATMapp” ],
“detail-type”: [ “transaction” ],
“detail”: {
“location”: [ { “prefix”: “NY-NYC-“ } ]
}
}
- 타사 은행 계좌를 사용하는 ATM 고객
PartnerBank 속성을 표시하는 트랜잭션을 필터링하기 위해 다음 이벤트 패턴은 이 속성이 있는지 확인합니다.
{
“source”: [ “custom.myATMapp” ],
“detail-type”: [ “transaction” ],
“detail”: {
“partnerBank”: [ { “exists”: true } ]
}
}
- 결합 필터
필터를 단일 이벤트 패턴으로 결합하여 더욱 복잡한 사용 사례를 만들 수 있습니다. 예를 들어, 이것은 partnerBank 속성이 없는 승인된 트랜잭션을 필터링하여 NY-NYC-002와 다른 위치의 ATM에서 보고합니다.
{
“source”: [ “custom.myATMapp” ],
“detail-type”: [ “transaction” ],
“detail”: {
“result”: [ “approved” ],
“partnerBank”: [ { “exists”: false } ],
“location”: [ { “anything-but”: “NY-NYC-002” }]
}
}
이러한 각 경우에 EventBridge는 들어오는 이벤트를 이 규칙의 이벤트 패턴과 일치시킵니다. 일치하는 것이 없으면 이벤트를 라우팅하지 않습니다. 이렇게 하면 들어오는 이벤트를 필터링하고 필요한 경우 종료하기 위해 존재하는 사용자 지정 코드가 제거됩니다.
사용자 지정 S3-to-Lambda 통합을 생성하기 위해 AWS 이벤트 필터링
EventBridge는 다양한 AWS 서비스를 기본 이벤트 소스로 사용합니다. Amazon S3와 같은 다른 AWS 서비스의 경우 AWS CloudTrail을 통해 이벤트를 사용합니다. EventBridge와 함께 사용하려는 서비스에 대해 먼저 CloudTrail로깅을 활성화해야 합니다. 활성화되면 AWS 이벤트에서 사용 가능한 속성을 필터링할 수 있습니다. 이를 통해 이벤트 중심 애플리케이션에서 동적이고 유연한 통합을 만들 수 있습니다.
Standard S3 – to – Lamda Trigger는 개발자가 하나의 버킷의 이벤트에 람다 함수를 구독할 수 있습니다. 이러한 이벤트가 S3에서 객체 키의 접두사 및 접미사를 필터링할 수 있지만 중복되는 여러 구성을 사용할 수 없습니다. 키 이름의 접두사 및 접미사 외에 Lambda 함수를 호출하기 전에 이벤트의 다른 속성을 추가로 필터링할 수 없습니다. S3 이벤트를 추가로 조사하려면 함수 자체의 코드 내에서 이를 수행해야 합니다.
EventBridge를 사용하면 사용 가능한 속성에 따라 하나 이상의 S3 버킷과 하나 이상의 Lambda 함수 간에 규칙을 구성할 수 있습니다. 이를 통해 이벤트를 다운 스트림 소비자에게 라우팅하기 위해 훨씬 더 세분된 필터를 만들 수 있습니다. 선언적 접근 방식을 사용하면 유연성이 향상되고 사용자 지정 코드가 줄어듭니다. 이 섹션에서는 이를 유용하게 사용할 수 있는 네 가지 사용 사례를 보여줍니다.
(a) 여러 버킷의 이벤트에서 단일 Lambda 함수 호출
이 예에서는 버킷 이름에 공통 접두사가 있는 여러 버킷을 사용합니다. (예 : 이름이 “myApp-images”, “myApp-uploads”및 “myApp-archive”인 버킷). 이러한 버킷을 모두 이벤트 소스로 사용하여 같은 Lambda 함수를 트리거할 수 있습니다. 이 이벤트 패턴은 해당 버킷의 모든 풋 이벤트와 일치합니다.
{
“source”: [ “aws.s3” ],
“detail-type”: [ “AWS API Call via CloudTrail” ],
“detail”: {
“eventSource”: [ “s3.amazonaws.com” ],
“eventName”: [ “PutObject” ],
“requestParameters”: {
“bucketName”: [ { “prefix”: “myApp-“ } ]
}
}
}
(b) 여러 소비자를 대상으로 호출
EventBridge는 규칙당 최대 5개의 대상을 허용하므로 이벤트를 수신하기 위해 최대 5개의 개별 Lambda 함수를 지정할 수 있습니다. 이벤트 패턴이 일치하면 5 개의 함수가 모두 동시에 호출됩니다. 이를 사용하려면 규칙에 대상을 추가하십시오. 이벤트 패턴을 변경할 필요가 없습니다.
5개 이상의 대상이 필요한 경우 Amazon Simple Notification Service (SNS)를 사용하십시오. SNS 주제를 EventBridge 규칙 대상으로 정의한 다음 SNS에서 훨씬 더 많은 구독자로 팬 아웃할 수 있습니다.
{
“source”: [ “aws.s3” ],
“detail-type”: [ “AWS API Call via CloudTrail” ],
“detail”: {
“eventSource”: [ “s3.amazonaws.com” ],
“eventName”: [ “GetObject” ],
“userAgent”: [ “userAgent” ],
“requestParameters”: {
“bucketName”: [ “mybucket” ]
}
}
}
결론
EventBridge의 새로운 컨텐츠 필터링 구문을 사용하면 비교 연산자 및 값 범위를 사용하여 이벤트를 정확하게 필터링할 수 있습니다. 이를 통해 사용자 정의 코드를 사용하여 다운 스트림을 필터링하지 않고 이벤트 버스에서 선언적으로 필터링할 수 있습니다. ATM 예제와 같은 사용자 지정 애플리케이션의 경우 특정 사용 사례에 대한 정확한 규칙을 작성하여 대상에 대한 호출 수를 줄일 수 있습니다.
이 방법을 사용하면 이벤트에 보고된 속성을 기반으로 이벤트를 보다 정확하게 라우팅할 수 있습니다. 따라서 EventBridge 수준에서 복잡한 라우팅을 보다 쉽게 처리할 수 있으며 애플리케이션 전체에서 사용자 지정 코드의 필요성이 줄어듭니다.
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 개제하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달드리도록 하겠습니다.