EventBridge는 EDA(Event Driven Architecture)를 구성하는데 도움을 주는 AWS의 서버리스 서비스이다. AWS 서비스 뿐만 아니라 SaaS 서비스, 개인 어플리케이션에서 보내는 이벤트(데이터)를 받아, 원하는 SNS나 lambda와 같은 타겟으로 보내주는 역할을 한다.

서비스 등장 배경

AWS에서 설명하는 EventBridge 서비스가 생긴 배경에는 EDA를 서버리스 형태로 제공한다기 위해서라 말하면서, EDA가 복잡한 서비스 구조에서는 더 좋은 서비스간 통신 방식이라 이야기 한다.

왜 EDA가 더 좋은가? 항상 그렇지는 않지만...

마이크로서비스 기반의 아키텍처에서 Direct Command 방식의 서비스간 통신을 할 경우, 전체 서비스 규모가 작을 때는 문제가 되지 않지만, 연결된 서비스 종류가 많아지고, 서비스간 종속 관계가 되는 깊이가 깊어지는 경우, 다음 두가지 문제가 발생한다.

• 서비스가 많아질 수록 통신의 복잡성이 기하 급수적으로 높아진다. 단순히 서비스간 연결 구조가 복잡해지는 문제 뿐만 아니라, 서비스 API의 버저닝 문제까지 엮이면 훨씬 복잡해지단.
• 서버 to 서버 통신이 synchronous 하게 이루어질 경우, upstream의 서비스에 문제가 발생하면, downstream의 서비스에도 영향을 주어 더 넓은 장애를 유발할 수 있다.

EDA의 경우는 서비스가 생성하는 이벤트를 다른 서비스가 구독하는 형태이기 때문에, 위에서 거론된 두가지 문제가 발생하지 않는다는 장점이 있다.

EventBridge의 구성 요소

Event

이벤트소스에서 부터오는 이벤트라 보면 된다. AWS 서비스를 예를 들면 EC2의 상태가 변경된다던지, Auto Scaling Group에 인스턴스가 추가될 때, event가 발생한다. 만약 내가 개발하고 있는 커머스 어플리케이션이라 하면, 사용자가 특정 상품을 구매한 경우, 상품을 구매했다는 이벤트를 생성할 수 있다.

Event Rule

Event가 발생한 경우, Event Rule과 매칭되는 이벤트만 Event Rule에 연결된 Event Target으로 라우팅 된다. EDA에서 보면 구독을 할 수 있는 대상이라 보면 된다. 만약 Auto Scaling Group의 인스턴스가 추가되어 이벤트가 발생되었다고 하면, 해당 이벤트의 패턴과 매칭되는 Event Rule은 모두 이 이벤트를 통과시킬 것이다. 이 이벤트의 패턴을 Event Pattern이라 부르고, 이 패턴을 만족하는 이벤트는 이벤트 패턴을 가지는 모든 Rule의 Target에 라우팅 된다.

EC2 인스턴스가 종료 되었을 때 다음과 같은 이벤트가 생성된다.

{
  "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"
  }
}

만약 Event rule의 이벤트 패턴을 다음과 같이 입력한 경우, 위 이벤트는 이 Event Rule의 필터링을 통과하고, Event Target까지 이벤트가 전달된다.

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["terminated"]
  }
}

만약 terminated를 포함한 EC2 status change에 대한 모든 이벤트를 필터링하고 싶다면 다음과 같이 event pattern을 구성하면 된다.

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["pending", "running", "shutting-down", "stopped", "stopping", "terminated"]
  }
}

다양한 AWS 서비스의 이벤트 패턴 예제는 이 문서에서 확인 가능하다.

*주의: 처음에는 혼동이 올수도 있는데, 이벤트가 Event Rule을 선택하는 것이 아니다. Event Rule과 연결된 Event Bus를 통과하는 모든 이벤트를 Event Rule이 필터링하여, 매칭되는 이벤트만 Event Target으로 이동시키는 구조임에 유의하자.

Event Target

event rule의 필터링을 통과한 이벤트가 도착하는 대상이다. 하나의 event rule에 여러개의 event target 등록이 가능하다. 즉, 해당 event rule의 이벤트 패턴을 만족하는 이벤트를 구독한다는 개념으로 생각하면 된다. Event Target으로 등록 가능한 AWS 서비스 또는 대상은 다음과 같다.

• API destination
• API Gateway
• AWS Batch job queue
• Amazon CloudWatch Logs group
• AWS CodeBuild project
• AWS CodePipeline
• Amazon Elastic Compute Cloud (Amazon EC2) CreateSnapshot API call
• Amazon EC2 RebootInstances API call
• Amazon EC2 StopInstances API call
• Amazon EC2 TerminateInstances API call
• Amazon ECS task
• Event bus in a different AWS account or AWS Region
• Firehose delivery stream (Amazon Kinesis Data Firehose)
• Incident Manager response plan
• Inspector assessment template (Amazon Kinesis Data Streams)
• Kinesis stream (Kinesis Data Streams)
• AWS Lambda function
• Amazon Redshift cluster (Data API statement execution)
• SageMaker Pipeline
• Amazon SNS topic
• Amazon SQS queue (including a FIFO queue)
• Amazon EC2 Systems Manager (SSM) Automation
• SSM OpsItem
• SSM Run Command
• AWS Step Functions state machine

예를 들어, 인스턴스가 종료 되었을 때 slack 등에 알림을 보내고 싶을 때, 슬랙의 incoming-hook API를 사용해 lambda function에 슬랙 알림을 구현해 놓고, event target으로 이 lambda function을 등록하면 인스턴스 종료 케이스에 대한 모니터링을 쉽게 할 수 있다.

Event Bus

이벤트를 받는 역할을 한다. Event Rule을 생성할 때, 하나의 Event Bus에 연결을 해야 한다. 이 Event Bus로 들어오는 이벤트만 Event Rule에서 필터링을 하게 된다. AWS 어카운트 마다 기본적으로 생성하는 Event Bus가 있는데, Default Event Bus라 부르고, AWS 서비스로 부터 생성된 이벤트는 모두 이 이벤트 버스로 들어온다.
목적에 따라 커스텀한 이벤트버스를 만들어 사용할 수 있다. 예를 들어 커머스 어플리케이션을 만드는데 Orders 라는 이벤트버스를 만들고, 주문 관련 이벤트 소스를 Orders Event Bus로 연결하면, 관련 이벤트가 발생하면 Orders Event Bus로 이벤트가 전달되고, 이 안에 존재하는 Event Rule이 필터링하여 Event Target으로 라우팅 할 것이다.

CloudWatch Events와 관계는?

EventBridge가 나오기 전에는 CloudWatch Events가 비슷한 역할을 담당하고 있었다. EventBridge에서 사용하는 API는 CloudWatch Events의 API와 동일하다. 즉, 기존의 CloudWatch Event에서 생성한 리소스가 EventBridge에서도 100% 호환된다고 보면 된다. 현재 AWS console에도 CloudWatch Events, EventBridge 메뉴가 모두 존재하는데 한쪽에서 Event Rule을 생성을 하면 다른쪽에서도 조회가 가능하다.

EventBridge가 CloudWatch Events에 비해 우수한 점은 CloudWatch Events는 AWS 서비스가 생성한 이벤트만 사용이 가능한 반면, EventBridge는 AWS 서비스 뿐만 아니라 SaaS나 개인 어플리케이션으로부터 생성된 이벤트도 사용이 가능하단 점이다.

그럼 무엇을 사용해야 할까? 개인적으로는 API 상으로는 100% 호환이 되고, EventBridge가 더 넓은 범위의 기능을 제공하므로 AWS EventBridge를 사용하는게 좋을 것 같다는 의견을 내며 글을 마무리 하고자 한다.