- 5RE5 백엔드의 SQS 서비스의 worker 역할을 하는 프로젝트입니다.
- AWS Lambda를 사용하여 SQS 메시지를 받아 처리합니다.
- 프로젝트를 jar 파일로 빌드합니다.
- SQS 에 연결된 Lambda 함수를 생성합니다.
- Lambda 함수에 jar 파일을 업로드합니다.
오디오 관련 작업을 하기 위해서 요구되는 메모리 공간에 대한 요구사항이 높아서 백엔드 서버가 아닌 다른 서버에서 처리할 필요가 있었습니다.
그리하여 AWS Lambda를 사용하여 오디오 파일 관련 작업을 하는 것으로 결정하였습니다.
AWS Lambda 가 오디오 관련 작업(오디오 병합, 오디오 변환)을 처리함과 동시에 외부 서버 API 호출(TTS API 호출, VC API 호출)도 담당하게 됩니다.
물론 AWS Lambda 가 고가용성이 있지만, 작업 자체의 안정성을 위하여 Messaging 을 사용하는 것으로 결정하였습니다.
메시지 큐 서비스는 RabbitMQ, Kafka, AWS SQS, AWS SNS 등이 있습니다.
이 중에서 Kafka 는 대용량 데이터 처리에 적합하나, 복잡한 설정이 필요하고, RabbitMQ 는 복잡한 설정이 필요하다는 단점이 있습니다.
그리하여 AWS 에서 제공하는 AWS SNS, AWS SQS 를 비교하여 고려하였습니다.
AWS SNS 는 메시지를 발행하고 구독하는 방식으로 동작하며, AWS SQS 는 메시지를 저장하고 전달하는 방식으로 동작합니다.
이 중에서 SQS 를 선택한 이유는 SNS 는 소규모 애플리케이션에서 사용하기 적합하지 않다고 생각하였기 때문입니다. (발행/구독 모델이 브로드 캐스팅 방식으로 동작하기 때문)
SQS 는 AWS 에서 제공하는 메시지 큐 서비스로, Lambda 함수가 처리할 메시지를 저장하고 전달하는 역할을 합니다.
SQS 를 사용하면, Lambda 함수가 작업을 처리하지 못할 경우, 다시 큐에 넣어서 다른 Lambda 함수가 처리할 수 있도록 합니다. (DLQ 설정)
하나의 SQS 와 하나의 Lambda로 구성한 이유는 다음과 같습니다.
기본적으로 하나의 SQS에는 하나의 Lambda 함수가 연결되는 것이 좋습니다.
SQS 는 메시지를 저장하고 전달하는 역할을 하며, Lambda 함수는 메시지를 받아 처리하는 역할을 합니다.
Event Source Mapping 을 사용하여 SQS 와 Lambda 를 연결하면, 서로 다른 Lambda 함수가 SQS 메시지를 받아 처리할 수 있습니다.
이러한 경우에는 Event Bridge 를 통해서 Filtering 을 해야 하며, 이는 복잡한 설정이 필요합니다. 또한 해당 설정에 대한 비용이 발생할 수 있습니다.
그리하여 하나의 SQS 와 하나의 Lambda 함수로 구성하고 메시지의 내용으로 분기처리하는 것으로 설정하였습니다.