솔루션에 따라 아키텍처 정리해보기 - SQS&Lambda와 Fan out pattern

 

AWS에서의 이벤트 처리와 다양한 처리 방법과

각 방법의 제약사항까지 정리해보려고 한다!

#0 SQS - Lambda 사용하기 / SNS - Lambda 사용하기

<SQS - Lambda>

1. 이 방법은 SQS 대기열과 Lambda함수를 사용하는 것으로 이벤트가 SQS 대기열에 삽입되고 Lambda 서비스가 SQS 대기열을 폴링한다. 문제가 발생하면 해당 메세지를 다시 SQS 대기열에 입력하고 폴링을 재시도한다. 이 작업은 계속 반복이 되는데 어러던 중에 한 메세지레 중대한 문제가 발생하면 2. 5번의 재시도 후에는 데드 레터 대기열(DLQ)로 보내도록 SQS를 설정할 수 있다.👍

3. SQS FIFO와 Lambda를 사용하는 방법도 있다. 여기서는 Lambda함수가 대기열 메세지를 순서대로 처리를 시도하는데 순서대로 처리하기 때문에 한 메세지를 처리하지 못 하면 차단이 발생해서 처리가 끝나지 않고 결국 전체 대기열 처리가 차단된다..! 4. 이 경우에도 마찬가지로 데드 레터 대기열(DLQ)를 구성해서 SQS 대기열에서 해당 메세지를 빼내고 함수가 계속 동작하도록 할 수 있다.👍

 

<SNS - Lambda>

5. 또 다른 방법은 SNS와 Lambda를 활용하는 것으로 메세지가 통과되고 메세지는 비동기식으로 Lambda에 전송된다. 6. 이때 Lambda함수는 재시도 행동을 달리해서 처리하지 못하는 메세지가 발생하더라고 내부적으로만 재시도를 한다. 재시도는 총 3번까지 하고 메세지가 제대로 처리되지 않으면 7. 해당 메세지를 제거하거나 DLQ로 보내도록 구성할 수 있지만 여기서는 Lambda서비스 수준에서 해당 메세지를 SQS 대기열로 보내서 나중에 다시 처리할 수도 있다.👍

 

#1 Fan out pattern(팬 아웃 패턴) : 다중 SQS 대기열에 데이터를 전송하는 방식🔃

팬아웃 패턴은 다중 SQS 대기열에 데이터를 전송하는 방식이다..!

첫 번째 패턴에서는 애플리케이션과 SDK가 설치되어 있고 3개의 SQS 대기열에 메세지를 전송하고자 한다!

이럴 경우에는 간단히 애플리케이션을 구성할 때 먼저 메세지를 첫 번째 대기열에 보내고 동일한 메세지를 두 번째 대기열과 세 번째 대기열에도 보낸다.

=> 이 방식은 작은 하지만 안정성이 높지가 않다😰

왜냐하면 예를 들어 두 번째 대기열에서 메세지를 전송한 다음 애플리케이션이 오류로 종료가 되면 세 번째 대기열은 메세지를 받지 못해서 각 대기열의 콘텐츠가 달라진다..

...

그 대신에 팬아웃 패턴을 사용해서 SQS 대기열과 애플리케이션 사이에 SNS Topic을 두면 어떻게 될까??😀

이럴 경우 SQS 대기열은 SNS Topic의 구독자가 되고 SNS Topic에 메세지를 전송할 때마다 메세지가 모든 SQS 대기열에 전송되니 안정성이 상당히 높아진다.😀😀

(애플리케이션 입장에서보면 SNS 주제에 PUT요청을 전송하면 자동으로 SNS 서비스가 해당 메세지를 SQS 대기열에 팬아웃하는 것이다)

 

#2 S3 Event Notifications

S3 버킷이 특정 이벤트에만 반응하도록 설정할 수 있어

객체 생성, 삭제 복원, 복제본 생성 시 알림을 보내도록 할 수 있고 객체 이름별로 필터링도 가능하다.

사용 사례로는 S3에 업로드된 이미지의 썸네일을 생성하는 경우가 있다. S3 이벤트를 SNS, SQS 또는 Lambda함수로 보내는데 이때 S3이벤트는 원하는만큼 생성할 수 있다. 이벤트 알림은 보통 짧은 초수 내로 전송이 된다!

 

<S3 Event Notifications와 EventBridge 사용하기>

S3버킷에서 일어난 모든 이벤트를 이벤트브릿지로 전송하는 방식인데 규칙을 설정해서 18개 이상의 AWS 서비스로 전달할 수 있다.

...

왜 EventBridge를 사용할까?🤔

JSON 규칙에 고급 필터링 옵션을 사용해서 메타데이터, 객체 크기, 이름 등으로 필터링할 수 있기 때문이다.

또 여러 대상에 이벤트를 한 번에 보낼 수 있고 Kinesis Data Stream, Firehose 등이 대상이 될 수 있다.

(그리고 EventBridge 기능 중 아카이빙, 이벤트 재생 등이 있는데 이것도 활용하면 더 좋을 것이다.)

-----------------------------------------------------

EventBridge에 관해 더 설명하자면 이벤트브릿지에서 모든 API호출을 인터셉트하려면 CloudTrail를 통합해서 사용하면 된다. 가령 사용자가 DynamoDB의 테이블을 삭제하고자 DeleteTable API를 호출하는 이벤트가 발생했다면 이 API호출은 CloudTrail에 로그되고 그 외 모든 호출이 CloudTrail에 로그된다.

(이 로그는 이벤트브릿지의 이벤트를 트리거하므로 이를 이용해 경보를 생성해서 SNS에 전송할 수 있다)