개요

이벤트브릿지는 발생한 이벤트에 따라 어떤 어플리케이션이나 프로세스를 실행할 수 있도록 설정하는 트리거 역할을 하는 리소스이다.
이벤트 드리븐 아키텍쳐를 도와주는 리소스라고 할 수 있겠다.
서버리스 서비스로서 필요할 때만 실행되고 실행된다.

가장 흔한 사용 예시는 클라우드트레일의 이벤트를 받아서 어떤 람다를 실행하는 것.
혹은 EC2의 상태 이벤트를 통해 과부하가 걸렸을 때 SNS을 통해 알람을 보낸다던가..
aws 바깥 외부에서 발생하는 이벤트(파트너 이벤트라고 함)를 통해 트리거되는 것도 가능하다.

CloudWatch와의 차이

Amazon CloudWatch 이벤트의 진화판이 바로 이벤트 브릿지로, 과거에는 Amazon CloudWatch Events라고 불렸다.
그래서 api를 보면 cloudwatch events api를 똑같이 쓴다고 한다.
이 클와 이벤트에 파트너 이벤트, 파이프 기능 등을 추가적으로 넣어 따로 리소스로 분리가 된 것이다.

구조

이벤트 브릿지는 어떤 구조를 가지고 있는가?

bus(버스)

이벤트 브릿지는 기본적으로 버스라는 것을 두고 있다.
이것은 이벤트를 받아서 타겟으로 전달하는 라우터로, 여기에 각종 규칙(rule)을 생성하면 이 규칙 조건에 걸린 이벤트들이 규칙 대상으로 날아간다.

아무런 설정을 하지 않더라도 기본 버스(default bus)가 존재한다.
이 버스는 클라우드트레일에서 발생하는 기본적인 관리 이벤트를 전부 받도록 되어 있다.
구체적으로는 트레일들이 기본적으로 기본 버스에 이벤트를 전달한다고 이야기하는 것이 맞겠다.

rule(규칙)

이것이 실질적인 이벤트 브릿지의 실체라고 할 수 있다.
이벤트 버스에 어떤 조건을 달고(최대 300개), 어떤 대상(최대 5개)을 지정한다.
그러면 이벤트 버스로 전송된 이벤트 중 이 조건을 만족하는 이벤트는 해당 대상으로 날아가게 된다.

참고로 이벤트의 조건을 명시하지 않고, 그냥 일정 시간마다 트리거되도록 하는 것도 가능하다.
(아래에 보면 [[#스케줄]]이 있는데, 조금 더 업그레이드된 기능이라고 볼 수 있어 그걸 쓰는 것을 문서에서 권장하고 있다.)

target(타겟)

규칙에 맞는 이벤트를 보낼 대상.
다음의 것들을 대상으로 삼을 수 있다.

• api
  • HTTPS 엔드포인트를 대상으로 삼을 수 있다.
  • 커스텀 웹 서버를 만들어서 이벤트를 받아볼 수 있다는 말이다.
• 이벤트 버스
  • 다른 버스를 또 타겟으로 삼을 수 있다.
  • 다른 리전, 혹은 다른 계정으로도 보내는 것도 가능하다.
• aws 서비스
  • 다양한 것을 대상으로 삼을 수 있다..
  • aws api gateway, Amazon Lambda 등등...

이벤트

그럼 이벤트들은 어떻게 이 버스로 전송이 되는가?
이것은 putEvents라는 api를 통해서 이뤄진다.

PutEventsResponse result = eventBridgeClient.putEvents(eventsRequest);

자바에서 이벤트브릿지에 이벤트를 보내는 예시 코드인데, 위처럼 putEvent라는 api를 호출하면 그대로 이벤트가 날아간다.

모종의 이유로 이벤트가 와도 이것을 룰에 명시된 타겟으로 보내지 못하는 경우가 있다고 한다.
이럴 때 기본적으로 이벤트 브릿지는 재전송을 시도한다.
최대 횟수를 지정할 수도 있는데, 기본값으로는 24시간 이내, 최대 185번까지 무작위 지연을 걸어서 시도한다고 한다.
그런 식으로 실패하게 된 이벤트에 대해서 dead-letter queue라는 것을 사용할 수 있다.

클라우드트레일에서 보내는 이벤트

이걸 많이 활용하게 될테니 따로 섹션을 분리한다.
클라우드 트레일의 트레일의(진짜 이름 짜잉나네) 경우, 관리 이벤트들에 대해 트레일이 자동으로 이 api를 호출하기에 별다른 설정 없이도 이벤트를 보내준다.

이때 각 이벤트의 detail-type은 이렇게 설정된다.

• AWS API Call via CloudTrail
  • 흔한 이벤트들
• AWS Console Signin via CloudTrail
  • 콘솔 로그인 이벤트
• AWS Console Action via CloudTrail
  • 콘솔에서 이뤄지지만 api를 호출하지는 않는 이벤트
• AWS Service Event via CloudTrail
  • 퍼블릭 api는 아니지만 아무튼 aws의 서비스에서 생성된 이벤트
• AWS Insight via CloudTrail
  • 인사이트 이벤트에 대한 이벤트

이걸 몰라서 고생했는데, 이 이벤트들은 사실 로깅이 활성화된 트레일이 있어야만 보내진다.^[2]

# ec2에서 바로 보내진 이벤트
{
    . . . 
   "detail-type":"EC2 Instance State-change Notification",
   "source":"aws.ec2",
    . . . 
   "detail":{
      "instance-id":"i-abcd1111",
      "state":"pending"
   }
}

# cloudtrail에서 보낸 이벤트
{
    . . . 
   "detail-type":"AWS API Call via CloudTrail",
   "source":"aws.ec2",
    . . . 
   ],
  "detail": {
    "eventSource": "ec2.amazonaws.com",
    "eventName": "StartInstances"
    }
}

참고로 클라우드 트레일에서 보내는 이벤트와 같은 이벤트가 aws의 다른 리소스에서 바로 들어오는 경우도 있다.

파이프

아예 파이프를 만들 수도 있다.
하나의 리소스로부터 데이터를 계속 받아 단일 타겟으로 계속 이벤트를 보내는 식으로 운용이 가능하다.
파이프는 이벤트를 타겟으로 보내기 전에 변환, 처리 작업 등을 할 수 있다.
버스와 함께 운용을 하는 경우가 많은데, 가령 다이나모디비의 이벤트를 스트림으로서 파이프로 연결한 뒤, 이것들을 커스텀 버스에 몰아넣는 것이다.

• source로 삼을 수 있는게 많지는 않다.
  • Amazon DynamoDB, aws sqs 등..
• filtering 쪽에서는 rule 만들 듯이 규칙을 지정한다.
• enrichment에선 람다나 추가 게이트웨이 등을 거쳐 조작을 가할 수 있다.
• target도 쓸 수 있는 종류가 많지는 않다.
  • 

스케줄

내가 원하는 스케줄을 조건으로 사용하도록 설정을 할 수 있다.

룰을 만들 때 스케줄을 만드는 것도 가능하지만, 따로 스케줄을 만들면 훨씬 세밀한 설정을 하는 것이 가능하다.

관련 문서

참고