Amazon EvnetBridge를 이용하여 RDS 이벤트 알림 받기

Amazon EventBridge를 이용하여 RDS의 메시지를 핸들링해보는 글입니다.
2021.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

안녕하세요 클래스메소드의 수재입니다.
저번글에서는 Amazon SNS의 구독 필터를 이용하여 RDS의 이벤트를 필터링하고 수신하였습니다.
RDS의 이벤트 구독이 SNS로 향하는 것도 편했지만 이벤트 이력 뿐만 아니라 더 많은 로그를 확인할 수 있는 방법을 찾아보았습니다.
찾아보니 EventBridge를 이용하면 더 많은 로그의 확인이 가능했습니다.
본 글에서는 EventBridge의 규칙을 활용하여 RDS의 이벤트를 수신 및 필터링하고 SNS와 무엇이 다른지 비교해보도록 하겠습니다.

사용하는 서비스

  • Amazon EventBridge
    • AWS 서비스나 자체 애플리케이션 등의 이벤트를 사용하여 이벤트 기반 애플리케이션을 대규모로 손쉽게 구축할 수 있는 서버리스 이벤트 버스

설정해보기

이번 글에서 작업할 내용은 다음과 같습니다

  • Amazon SNS 주제 및 구독 작성
  • EventBridge의 규칙 설정

SNS로 작업한 내용에 비하면 엄청 간단합니다.

  • 참고
    • [Amazon SNS의 구독 필터 정책으로 RDS 이벤트 알림 받기] (https://dev.classmethod.jp/articles/receive-rds-event-alert-with-aws-sns-subscription-filter-policy/)

Amazon SNS 주제 및 구독 작성

우선 메일로 알림을 받을 수 있도록 주제와 구독을 작성합니다.
따로 구독 필터 정책을 설정할 필요도 없기 때문에 이름만을 지정해줍니다. 주제에서 설정한 [표시 이름] 은 메일의 보낸 사람으로 설정됩니다.

이후 메일로 도착한 구독 승인 메일을 확인합니다.

EventBridge의 규칙 설정

이어서 EventBridge에서 규칙을 설정합니다.
설정하는 내용은 이름, 패턴, 대상입니다.
패턴에 정의한 내용을 토대로 발생하는 이벤트를 필터링합니다.

백업 시작과 완료에 대한 이벤트 이외에 모두 받는 패턴을 정의하였습니다.
패턴에 정의한 내용은 다음과 같습니다.

{
  "source": ["aws.rds"],
  "detail-type": ["RDS DB Instance Event"],
  "detail": {
    "SourceIdentifier": ["rds-test"],
    "Message": [{
      "anything-but": [
        "Backing up DB instance",
        "Finished DB Instance backup"
      ]
    }]
  }
}

EventBridge가 처리하는 메시지의 템플릿은 다음과 같습니다.

{
  "version": "0",
  "id": "68f6e973-1a0c-d37b-f2f2-94a7f62ffd4e",
  "detail-type": "RDS DB Instance Event",
  "source": "aws.rds",
  "account": "123456789012",
  "time": "2018-09-27T22:36:43Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:rds:us-east-1:123456789012:db:my-db-instance"
  ],
  "detail": {
    "EventCategories": [
      "failover"
    ],
    "SourceType": "DB_INSTANCE",
    "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:my-db-instance",
    "Date": "2018-09-27T22:36:43.292Z",
    "SourceIdentifier": "rds:my-db-instance",
    "Message": "A Multi-AZ failover has completed."
  }
}

SNS의 구독 필터와 마찬가지로 EventBridge도 패턴에 조건을 지정하여 메시지를 필터링할 수 있습니다.
사용할 수 있는 조건은 공식 문서를 참고해주세요.

그리고 대상 항목의 입력을 설정하지 않으면 해당 이벤트 메시지가 그대로 메일로 도착하기 때문에 필요한 내용만을 수신하기 위해선 입력을 지정해야합니다.
이 글에서 지정한 내용은 다음과 같습니다

{"Date":"$.detail.Date","EventCategories":"$.detail.EventCategories","EventID":"$.detail.EventID","Message":"$.detail.Message","SourceArn":"$.detail.SourceArn","SourceIdentifier":"$.detail.SourceIdentifier","SourceType":"$.detail.SourceType","region":"$.region"}
{
"region": <region>,
"Date":<Date>,
"EventCategories":<EventCategories>,
"SourceType":<SourceType>,
"SourceArn":<SourceArn>,
"SourceIdentifier":<SourceIdentifier>,
"EventID":<EventID>,
"Message":<Message>
}

이것으로 이벤트에 대한 설정은 끝입니다.
이후 RDS의 재시작이나 중지 후 시작을 하면 메일이 도착하지만 백업 시작 및 종료에 대해서는 메일이 도착하지 않습니다.

SNS의 구독 필터와 EventBridge는 무엇이 다른가?

우선 가장 큰 차이로는 각 서비스에 도착하는 메시지가 미묘하게 다릅니다.
특히 EventBridge에는 해당 이벤트의 EventCategories가 도착합니다.
만약 처음 어떠한 서비스의 이벤트를 핸들링해야 한다면 EventBridge로 카테고리까지 파악하는 것이 더 다양한 방향으로 메시지를 핸들링할 수 있습니다.

그리고 메일로 도착하는 메시지도 지정이 자유롭게 지정이 가능합니다.
SNS를 통해서는 지정된 템플릿으로만 내용이 전달되는 반면 EventBridge를 활용하면 도착하는 메시지에 대해 좀 더 다양한 설정이 가능합니다.

마지막으로 메시지를 제대로 핸들링하기 위해 Lambda가 필요하지 않다는 점도 EventBridge의 장점이라고 생각합니다.
결국 이메일로 전달하기 위해 SNS의 주제와 구독을 생성해야 했지만 각 서비스가 담당하는 작업이 명확히 구분되기 때문에 관리가 쉬워집니다.

마치며

이렇게 SNS와 EventBridge를 통하여 이벤트를 핸들링하는 방법을 알아보았습니다.
개인적으로는 EventBridge가 훨씬 편하다는 느낌을 받았습니다.
다양한 서비스로 필요한 기능을 구현해보고 본인에게 맡는 방법으로 작성해봅시다.

긴 글 읽어주셔서 감사합니다.
내용 및 오탈자 피드백은 언제나 환영합니다. must01940 지메일로 보내주시면 감사합니다.