AWS 메시지 및 이벤트 - 이벤트 버스 결합 응용 프로그램 사용

며칠 전에 나는 제임스의 강연을 듣고 있었는데, 이 쪽지는 내가 그의 강연에서 정리한 것이다.이렇게 훌륭한 회의는 모두 그의 덕분이다.

이벤트 버스는 무엇입니까?

위키백과의 표준 정의는'사건 버스는 하나의 메커니즘으로 서로 다른 구성 요소가 서로를 알지 못하는 상황에서 서로 통신할 수 있도록 허용한다. 구성 요소는 사건 버스의 사건을 감청할 수 있고 누가 사건을 보냈는지 알 수 없다'는 것이다.
이벤트 구동 체계 구조 모델은 분포식 비동기 체계 구조 모델로 고도로 확장 가능한 반응식 응용 프로그램을 만드는 데 도움이 된다.생산자와 소비자에 의존하지 않고 사건을 이차적으로 교부하고 처리하는 것이 주요 사상이다.
이점:

생산자와 소비자의 연결

필터 및 라우팅 이벤트

단편 마이크로 서비스 통합이란 무엇입니까

통합 아키텍처를 살펴보겠습니다.좋은 점은 여기서 우리가 사용하는 것은 마이크로 서비스 방법이지만, 나쁜 점은 그것이 이미 단편적인 구조 방법이 되었다는 것이다.
이제 우리는 다음과 같은 내용을 더욱 깊이 이해하고 침강물 관리가 어떻게 발생할지 이해하자.만약에 우리가 마이크로 서비스를 이행할 때 약간의 오류가 발생했다면, 지금 우리는 지불 마이크로 서비스와 통신을 해서, 롤백/대출 기록으로 지불한 다음에 그것을 영수증, 예측 마이크로 서비스에 보고해야 한다.

이런 체계 구조는 여전히 우리의 모든 표준 마이크로 서비스 체계 구조의 장점을 가지고 있다

솔리드 결합

확장성

확장성

여러 마이크로서비스를 통해 복잡성 감소

고가용성

내결함성

이벤트 버스와의 통합 모드

따라서 위에서 보여준 상술한 단편 체계 구조는 다음과 같은 체계 구조와 더욱 결합할 수 있다. 그 중에서 주문 서비스(생산자)와 다른 서비스(소비자)는 사건 버스를 통해 분리된다.따라서 모든 하위 서비스는 이벤트 버스에서 읽을 수 있고 우리는 상응하는 규칙을 가지고 필터를 한다.따라서 주문 서비스는 이벤트 버스와 대화만 하고 주문 서비스 팀은 다른 관련 서비스에 대해 고민할 필요가 없다.

AWS EventBridge와의 통합 모드

이것은 서버가 없는 세계에서 결합을 해소하는 서비스를 만드는 데 도움이 되는 혁명적인 서비스이다.이것은 AWS에서 관리하는 서버 이벤트 버스 서비스가 아닙니다.AWS SDK 및 AWS 서비스를 통해 자체 로컬 애플리케이션과 통합할 수 있습니다.
항상 내구성을 위해 EventBridge와 Lambda 사이에 SQS를 사용하는 것이 좋습니다.
Amazon Cloudwatch 이벤트에서 시작된 이 서비스는 여러 AWS 서비스에서 이벤트 로드를 처리합니다.
또 다른 흥미로운 점은 SQS, SNS, 이벤트브릿지가 통합되어 있다는 점이다.그래서 어떤 것을 사용해야 할지, 언제 사용해야 할지 곤혹스럽다.

SQS는 하나의 대기열로 생산자가 사건을 대기열로 보내고 소비자가 대기열에서 읽는다.대기열에 메시지가 계속 존재합니다.

상기 모델은 SNS와 매우 비슷하여 SNS에서 게시자는 주제가 있는 메시지를 보내고 소비자들은 그들이 선택한 주제에 따라 읽는다.

SNS와 EventBridge의 주요 차이점은 서비스의 라우팅 능력과 사용자 유형입니다.

SNS는 대형 방송국에 적합하고 수천 명의 소비자를 보유하고 있다

그러나 다양한 라우팅 기능이 필요할 때 EventBridge가 더 적합합니다.그 밖에 대량의 소비자 서비스와 이런 풍부한 루트 기능을 결합시킬 수 있다.

이외에 이벤트브릿지는 매우 독특한 다(생산자)대다(소비자) 관계를 가질 수 있다.

EventBridge에도 재시도 기능이 있습니다. 만약 우리가 어떤 이유로 사용할 수 없는 하위 시스템이 있다면, EventBridge는 24시간 동안 재시도를 계속할 것입니다.그런 다음 DLQ와 Event Bridge를 연결하여 여러 번 시도한 후에 메시지가 전달되지 않으면 메시지를 이동할 수 있습니다.
기본 이벤트 버스는 항상 계정과 함께 제공됩니다. 필요하면 다른 종류의 이벤트 버스를 만들어야 합니다.일단 우리가 이 버스들을 정의한 다음에 규칙을 정의하면, 그것들은 때때로 매우 복잡해진다. 이것은 루트의 요구에 달려 있다.규칙은'지불 유형 속성의 이벤트를 지불 서비스로 옮겨야 한다'고 정의할 수 있다.

EventBridge 규칙이란?

이벤트Bridge에서 이벤트는 JSON 구조일 뿐입니다.AWS 서비스에서 생성된 이벤트는 항상 여러 개의 설명 필드를 포함하고 원본 속성 접두사인 "AWS"를 통해 식별할 수 있습니다.사용자 정의 응용 프로그램의 일반적인 이벤트 구조는 다음과 같습니다.
AWS SDK Event Bridge Put Event API는 규칙과 일치하도록 사용자 정의 이벤트를 Amazon Event Bridge에 보냅니다.
요청 구문:

{
   "Entries": [ 
      { 
         "Detail": "string",
         "DetailType": "string",
         "EventBusName": "string",
         "Resources": [ "string" ],
         "Source": "string",
         "Time": number,
         "TraceHeader": "string"
      }
   ]
}

EventBridge의 응답 구조

작업이 성공하면 서비스가 HTTP 200 응답을 반환합니다.

{
   "Entries": [ 
      { 
         "ErrorCode": "string",
         "ErrorMessage": "string",
         "EventId": "string"
      }
   ],
   "FailedEntryCount": number
}

EventBridge는 수신 이벤트를 확인하고 이 규칙과 비교합니다.이 규칙은 이벤트에 존재하기 때문에 패턴이 일치하도록 원본 값 custom.myown 을 지정합니다.그런 다음 이벤트를 규칙의 대상으로 라우팅합니다.

위의 예는 정적, 정확한 일치 패턴을 보여 줍니다. 속성이 존재하거나 존재하지 않습니다.
다음은 또 다른 구조 모델로 규칙에 따라 여러 소비자를 촉발하는 방법을 보여준다.

신축 가능 웹훅

다음 예에서는 API 끝점이 Event Bridge와 연결되는 확장 가능한 아키텍처를 보여 줍니다.그런 다음 EventBridge는 특정 이벤트를 SQS로 라우팅하고 메시지가 SQS에 도착하면 SQS가 lambda를 트리거합니다.따라서 일부 애플리케이션 코드 문제로 인해 Lambda가 종료되더라도 SQS는 일정 시간 동안 메시지를 유지할 수 있습니다.그래서 여기서 API 게이트웨이가 29초의 동기화 시간 초과가 있어도 API 게이트웨이에서 뭔가를 보내고 응답을 얻는 것은 (위조 응답일 수도 있음) 백엔드에서 비동기 처리를 하는 것이 좋은 방법이다.그래서 이 구조에서 API 게이트웨이는 Event Bridge에서 응답을 받고 막후의 Event Bridge는 모든 비동기적인 작업을 완성하여 임무를 완성한다.

AWS Step 기능 워크플로우에 응답

위의 전자상거래 응용 프로그램 마이크로 서비스 응용 프로그램 구조를 참고하고 결제 마이크로 서비스를 예로 들겠습니다.지불 서비스는 지불 유형 수표, 신용카드 등에 따라 매우 복잡한 논리가 있을 수 있다. 때로는 은행 청산 등의 원인으로 인해 수표 지불은 며칠의 시간이 걸릴 수도 있고, 지불이 실패할 때 지불을 취소해야 할 수도 있다.중요한 점은 AWS Event Bridge가 가격에 영향을 받지 않는다는 것이다. 왜냐하면 AWS 서비스가 Event Bridge에 보내는 모든 이벤트는 무료로 처리되기 때문이다.
여기서, lambda 함수는 상태 함수 결과가 성공했는지에 따라 일부 조작을 실행합니다.

Cloudtrail 통합

AWS 계정을 만들면 AWS 계정에서 CloudTrail이 활성화됩니다.AWS 계정에서 이벤트를 지속적으로 기록하려면 이벤트 브릿지의 이벤트를 포함하여 추적을 만듭니다.Trail 을 사용하면 클라우드 트레일에서 로그 파일을 Amazon S3 저장소 통에 전달할 수 있습니다.

이것은 상기 구조 모드의 확장입니다. 클라우드 트레이일은 모든 이벤트를 포착하여 이벤트Bridge에 전달합니다.이벤트 소스가 "aws.s3"이고 BucketName이 "mysales Jan", "mysales Feb", "mysales March"인 경우에만 lambda 함수가 트리거됩니다.

여기서 관건은 우리의 버킷 이름이 하드코딩이라는 것입니다. 이것은 새로운 버킷을 만들 때마다 같은 lambda를 사용해야 한다면 규칙을 변경해야 한다는 것을 의미합니다.따라서 Bucket prefix를 사용하여 동적 규칙을 만들 수 있습니다. 아래와 같습니다.

다중 Lambda 함수가 있는 다중 bucket

위의 표준 S3 및 Lambda 통합에서 단일 Lambda 함수는 규칙의 bucket name prefix에서만 호출할 수 있습니다.EventBridge 통합은 동일한 접두사나 중첩된 접두사를 사용하여 여러 함수를 호출해야 할 때 이 문제를 처리할 수 있습니다.
이벤트Bridge는 규칙당 최대 5개의 대상을 허용하므로 이벤트를 수신할 별도의 Lambda 함수를 최대 5개까지 지정할 수 있습니다.이벤트 모드가 일치할 때, 모든 다섯 함수가 병렬로 호출됩니다.이를 사용하려면 이벤트 모드를 변경하지 않고 규칙에 대상을 추가합니다.
다음 예는 세 개의 버킷과 세 개의 람다 함수를 보여 줍니다. 모두 같은 이벤트 모드를 구독합니다.

EventBridge를 사용하여 대형 no 응용 프로그램 결합

다음 구조 모드는 S3 대상에 전송된 모든 서비스를 처리하는 데 이벤트를 사용합니다.이벤트 원본으로 하나 이상의 버킷을 사용할 수 있으며, 필요에 따라 동적으로 버킷을 변경할 수 있습니다.가장 중요한 것은 응용 프로그램이monorepo로 배치되지 않기 때문에 변경과 새로운 기능을 도입하는 것이 더욱 쉽다는 것이다.인덱스와 검색 능력을 얻기 위해 Elasticsearch 서비스에 메타데이터를 보냅니다.

도구책

이 문장의 모든 공로는 제임스 베스비크에게 돌아갔다.