아래 그림과 같이 다수의 디바이스들이 Amazon S3에 json 파일 형태로 디바이스의 status를 업로드 한다면, Lambda가 S3에 저장되는 신규 Object 생성 event를 trigger로 받아서, SQS에 event를 message로 쌓아놓을 수 있습니다.
아래는 예상되는 문제 케이스 입니다.
-
AWS Step Functions에서 1개의 event를 처리 할 때 1초라고 가정합니다. S3에 저장되는 데이터가 1초보다 천천히 들어온다면, Amazon SQS에 event가 쌓이지 않고 잘 처리가 됩니다.
-
Amazon S3에 저장되는 파일이 일시적으로 1초에 1개보다 더 많이 들어오더라도, SQS가 Step Functions에 전달한 이벤트를 Concurrent하게 처리하면, 역시 event가 쌓이지 않고 잘 처리가 됩니다.
-
하지만, Step Functions에서 Concurrent하게 처리 할 수 있는 용량보다 훨씬 더 많은 event가 전달되면, SQS의 메시지가 전달은 되었으나 삭제는 되지 않은 inflight 상태인 메시지가 늘어날 수 있습니다.
-
그리고, 이런한 inflight 메시지가 Standard 일때 120,000개, FIFO일때는 20,000개가 넘으면, SQS가 SQSOverLimit error를 발생시켜, 새로운 메시지를 저장하지 못하게 되므로, 이런 상태에서 새로운 event가 계속 S3로부터 trigger되어 들어오면 유실 될 수 있을 것으로 보입니다.
-
SQS에 저장된 메시지는 consumer가 가져가서 처리가 다 끝나면 영구적으로 삭제해야 합니다.
-
SQS에 저장된 메시지를 consumer가 가져갔으나 지우지 않으면(inflight), Standard 메시지는 120,000개, FIFO는 20,000개의 제한이 있습니다. 이 할당량은 AWS에 요청하여 변경 할 수 있습니다.
-
SQS에 저장된 메시지를 consumer가 가져가서 처리를 하지만 처리가 안되어서 다시 읽을 수도 있는데, 이때 MaxReceiverCount(up to 1000)가 넘으면 DLQ(Dead Letter Queue)로 전달 됩니다.
-
SQS의 메시지는 retension time(default: 4days, up to 14days)이후에는 마찬가지로 DLQ로 전달됩니다.
- SQS에 message는 제한없이 쌓일 수 있으므로, Step Functions에 전달되는 event를 제한하거나 스케줄링 할 수 있다면 문제 해결이 가능합니다.
여기서는 SQS의 신규 메시지 event를 Lambda가 받아서 처리하지 않고, Event Bridge가 주기적으로 생성한 cron job 형태의 event로 Lambda를 Trigger하여, SQS에 있는 메시지를 읽어가는 구조입니다. S3에 새로 Object 생성되더라도, Step Functions이 바로 trigger 되지 않고, 정해진 스케줄에 따라 원하는 만큼만 event를 처리할 수 있습니다.
EventBridge event로 만든 Cron job에서 다수의 event messages을 처리해야 하는 경우에는 아래와 같은 방법으로 변경도 가능합니다. 상세한 설게는 S3 Trigger Event Scheduler를 참고하십시요.
Rare 하지만 비정상 케이스에서도 message 전송을 보장하여야 한다면 아래와 같은 구조도 가능합니다.
장애등의 어떤 비정상 상황에서 SQS에 저장된 message가 삭제되어 버린 경우에도 정상적으로 데이터를 처리하고자 한다면 아래와 같이 DynamoDB와 같은 데이터베이스를 사용하여 모든 event를 logging 한 후, 순차적으로 처리하는 방법으로 접근 할 수 있을것으로 보입니다. 아래 그림에서는 S3의 object 생성 trigger 발생시 Lambda(S3)가 SQS에 event message를 push 하면서, DynamoDB에도 같은 이벤트를 put 합니다. 이때, 중복방지를 위해 UUID같은 event에 대한 unique한 ID를 생성하여 사용할 수 있습니다. SQS에 저장된 messages들은 순차적으로 Lambda(schedular)에 의해서 처리 되는데, SQS의 메시지를 삭제할때 마찬가지로 DynamoDB의 event message도 삭제합니다. (UUID 이용)
만약, 비정상적인 상황으로 인해 SQS의 메시지가 유실되었다고 하더라도, DynamoDB와 S3에는 데이터가 남아 있으므로, EventBridge를 통해 정기적으로 cron job을 생성하여, Lambda(check)가 DynamoDB에 전달되지 않은 오래된 event message가 있다면, 다시 SQS로 전송합니다. SQS에 들어온 미처리 데이터는 신규 메시지처럼 처리되고, 처리된 이후에 DynamoDB에서도 삭제가 가능합니다.
아래에서는 Amazon S3에서 생성된 신규 object event를 SQS가 아닌 DynamoDB에 저장후에, EventBridge가 생성한 Cron job으로 Lambda(schedular)가 DynamoDB를 조회한 후, SQS에 push 하는 방법입니다. 상세한 설계는 S3 Trigger Event Manager를 참고 하십시요.
Amazon Glue를 이용하여 S3 trigger event를 처리하는 방법이 있습니다. 이 방법은 기존 step functions을 glue를 통해 해결하여야 합니다.
DLQ(Dead-letter queue)를 enable하고 "Maximum receives"를 설정하면, SQS에 있는 메시지를 consumer가 visibility timeout(기본값: 30s)안에 가져간 후, 완료된 메시지가를 삭제하지 않으면 "Maximum receives"만큼 재시도 한 후에 DLQ에 실패한 메시지를 저장 할 수 있습니다. DLQ로 저장된 메시지를 2021년 12월에 출시된 Introducing Amazon Simple Queue Service dead-letter queue redrive to source queues를 이용하여 redrive 할 수 있습니다.
아래와 같이 DLQ에 저장된 메시지는 전송전(Message available)이므로 메시지 숫자의 제한이 없이 저장되므로, 실패한 모든 메시지를 저장 할 수 있습니다.
Consumer의 문제가 해결되면, 아래와 같이 DLQ에서 [Start DLQ retrieve]를 선택해서 재전송 할 수 있습니다.
이때, DLQ에 있는 메시지를 원래 Queue로 다시 보내는 속도를, Redrive configuration의 [Velocity control settings]에서 설정을 할 수 있습니다. "System optimized"를 하면, 시스템이 최적화된 속도로 가능한 빨리 다시 시도하고, "Custom max velocity"를 하면 초당 전송되는 숫자를 조정 할 수 있습니다. 아래처럼 1로 설정하면 초당 1개씩 전송하게 됩니다.
아래와 같이 DLQ redrive를 시작하면, 저장된 메시지가 원래 Queue로 보내져서 재전송됩니다.
DLQ Redrive는 일시적으로 부하가 급증한 경우에 전송에 실패한 메시지를 재전송할 수 있는 유용한 방법입니다.
How to build a fully managed scheduling mechanism for updates on Amazon S3 data lakes