AWS SQS 와 Lambda 두 개를 조합해 서버 없이 작업 대기열(task queue)을 만드는 튜토리얼이다. 큐와 컴퓨팅 리소스가 왜 둘 다 필요한지부터, 콘솔에서 큐를 만들고 Lambda 두 벌을 붙이는 절차까지 이어진다.
핵심 포인트- 작업 대기열은 수행할 작업을 저장했다가 컴퓨팅 리소스가 허용되면 실행하고 큐에서 지우는 구조이며, 오류가 나면 성공할 때까지 큐에 남아 재시도된다.
- 쓰임새는 순서대로 실행해야 하는 작업, long-run 작업, cron 작업이다. 가입 후 인증 메일 발송, 주기적 크롤링, 대량 푸시 발송 같은 것들이다.
- SQS 는 삭제 명령이 있기 전까지 메시지를 유지하고, 한 번 전달된 메시지는 일정 시간 다시 처리되지 않게 한다(inflight).
- 당시 SQS 는 Lambda 를 직접 실행시킬 수 없어 Lambda 가 두 벌 필요하다. CloudWatch cron 이 Consumer 를 주기적으로 돌리고, Consumer 가 메시지를 읽어 Worker 를 실행한다.
- 주의점으로 일반 Queue 는 고가용성 구조 때문에 하나의 메시지가 여러 번 호출될 수 있다는 점을 짚는다.
상세 정리- serverless architecture 의 이점을 먼저 정리한다. 소스코드와 몇 번의 클릭으로 REST API 를 만들 수 있고, 확장성을 고민할 필요가 없으며, 로그와 모니터링을 추가 작업 없이 쓸 수 있다.
- SQS 제약: 메시지는 최대 256KB 텍스트, 최대 14일 보관, 최대 10개 또는 256KB 배치로 송수신·삭제된다. 배치를 쓰면 비용을 아낄 수 있다.
- Lambda 는 요청량과 무관하게 자동으로 프로비저닝·오토스케일링되며 당시 Node.js·Java·C#·Python 을 지원했다. API Gateway 와 붙이면 REST API 가, CloudWatch 와 붙이면 cron job 이 된다.
- 큐 생성 옵션을 하나씩 설명한다. `DefaultVisibleTimeout` 은 전달된 메시지가 다시 전달되지 않는 시간으로, 중복 수신을 막는 장치다.
- `MessageRetentionPeriod` 는 1분에서 최대 14일까지의 메시지 생명주기, `Maximum Message Size` 는 최대 256KB 이며 비용과 연결된다.
- `Delivery Delay` 는 새 메시지의 초기 지연 시간으로 0~900초(15분)까지 설정한다.
- Long Polling 은 0~20초로 설정하며, 메시지가 없을 때 일정 시간 기다렸다가 도착하는 즉시 반환해 empty response 비용을 줄인다. 기본값은 Short polling 이다.
- Dead Letter Queue 는 처리 실패 조건을 정해 실패 메시지를 따로 다루게 해 준다. 원본 큐와 같은 형태(FIFO/Standard)이고 같은 리전이어야 한다.
- 큐 검증은 콘솔의 Queue Actions 에서 sendMessage 로 Message body 와 Attributes 를 넣어 보내고, View/Delete Messages 로 확인하는 흐름이다.
- Lambda 생성은 blueprint 선택 화면에서 런타임 Node.js 6.10, Blank Function 으로 시작한다. trigger 로 쓸 CloudWatch cron 은 Lambda 가 있어야 설정되므로 일단 비워 두고 진행한다.
- Consumer 코드는 SQS URL 을 넣고 메시지를 읽는 형태이며, `receiveMessage` 는 1~10개를 반환한다.
- 반환 메시지에 담기는 것은 body 의 MD5 digest, 전송 시 사용된 MessageId, 삭제 시 식별자로 쓰는 Receipt handle, attributes 의 MD5 digest 다.
- 마지막으로 이 코드가 동작하려면 Lambda function 에 권한을 추가해야 한다고 짚는다.
왜 읽나서버를 따로 두지 않고 백그라운드 작업을 돌려야 하는 개발자에게 SQS·Lambda 조합의 구조와 각 설정값의 의미를 정리해 준다.