[Project] 프로젝트 삽질기37 (feat AWS SQS)

들어가며

리팩터링 하면서 AWS SQS를 활용한 기능을 개발하고 있습니다. 개발하는 과정에서, AWS SQS를 어떻게 사용할 수 있는지를 정리해보고 싶었습니다. AWS SQS에 대한 특징과 설정할 때 참고할 점을 정리하고자 합니다.

 

 

 

 

---

 

왜 AWS SQS인가?

저는 POG 서비스에서 bull.js를 활용해서 Redis 기반의 Queue를 활용했던 경험이 있습니다. 하지만 특정 개발을 진행하면서 Bull.js보다 AWS SQS를 활용해서 큐 서비스를 활용하면 좋겠다고 생각했습니다. 

 

 

 

[Project] 푸시 알림 프로젝트 삽질기9 (feat Queue, bull)

 

 

POG 서비스에서는 많은 사용자에게 푸시 서비스를 안정적으로 보내야 했는데, AWS SQS를 사용하면 비용적인 문제가 들어갈 것이라 판단했었고, 결국 Bull.js를 활용했습니다. 하지만 이번 과제에서는 AWS SQS를 사용하는 것이 좋겠다고 생각했습니다.

 

AWS SQS를 활용하면 비용적인 문제를 당장은 고려하지 않아도 된다고 생각했습니다. 그리고 메시지 브로커를 별도로 설정할 필요가 없었기에 쉽고 빠르게 큐 서비스를 사용할 수 있다고 생각했습니다. 그리고 마지막으로 AWS SQS를 활용하면 포인트 적립을 안정적으로 진행할 수 있다고 생각했습니다.

 

만약 Redis 기반의 Bull.js를 활용하다가 Redis에 장애가 발생할 시 Queue 서비스를 안정적으로 사용할 수 없다는 문제점이 있습니다. 심지어 Redis에 장애가 발생한다면, 큐에서 미처 처리하지 못한 작업이 제거가 될 수 있습니다. 사용자가 포인트를 적립해야 하는데 포인트 적립과 관련된 큐 작업이 사라지게 된다면, 큰 문제가 될 수 있습니다. 물론 Redis의 데이터를 저장해서 활용할 수 있지만 과제에서 이를 진행하기엔 오버스펙이 될 수 있다고 판단했습니다. 그래서 과제에서 AWS SQS를 활용하기로 판단했습니다. 

 

 

 

 

 

 

---

 

 

 

 

AWS SQS란?

그럼 본격적으로 AWS SQS에 대해 알아보겠습니다. AWS SQS는 Message Queue 서비스입니다. Queue라는 임시 저장소에 메시지를 보관하고, 때가 되면 큐를 처리합니다. 모든 정보는 하나의 메시지로 압축되어 메시지가 SQS로 전달됩니다. 서버는 새로운 메시지가 Queue에 들어왔는지 계속 확인하며, 새로운 리소스를 처리하고 기타 일들을 처리합니다.

 

AWS SQS는 애플리케이션의 컴포넌트를 분리하는 역할을 합니다. 컴포넌트 분리로 인해 애플리케이션을 독립적으로 실행할 수 있고, 컴포넌트 사이에서 매우 용이한 메시지 운용이 가능합니다. 메시지는 최대 256KB에 해당하는 text 포맷 메시지 보관이 가능합니다. XML, JSON, TXT 형태로 보관이 가능하며, 메시지는 AWS SQS API를 통해 메시지를 꺼내올 수 있습니다. 

 

이런 AWS SQS에는 크게 2가지 종류로 나뉩니다. 지금부터 Queue의 종류에 대해 알아보겠습니다.

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

AWS SQS 종류

AWS SQS는 Standard Queue와 FIFO로 나뉩니다. 그럼 각 Queue의 특징에 대해 알아보겠습니다.

 

 

 

Standard Queue

초당 메시지를 주고받는 횟수가 거의 무제한입니다. 또한 최소 한 번은 꼭 메시지를 전달시키며, 최대한 메시지가 들어온 순서대로 메시지가 나갈 수 있도록 합니다. 하지만 가끔 중복 메시지가 전달될 수 있고, 순서가 어긋날 수 있는 문제점이 있습니다. 

 

 

 

FIFO Queue

FIFO는 메시지가 들어온 순서대로 메시지가 밖으로 나갑니다. 또한 한 번만 메시지를 전달합니다. 그렇기에 메시지 중복을 허용하지 않고, Consumer가 다시 요청할 때까지 특정 시간 동안 Queue에 들어있습니다. 초당 3,000개의 메시지를 지원한다는 특징이 있습니다. 3,000개의 메시지는 300개의 API 호출을 나타내며, 각각 10개의 메시지를 일괄 처리합니다. 

 

 

 

어떤 Queue를 선택할 것인가?

여기서 과제를 수행하면서 어떤 Queue를 선택해야 할지 고민했을 때, FIFO Queue를 활용해야 한다고 생각했습니다. 사용자 포인트 정보를 저장, 삭제, 수정해야 하는 데이터가 Queue에 담겨 있을 때, 중복되거나 순서가 어긋난다면 예를 들어 사용자가 보너스 점수를 받을 때 두 번 보너스 점수가 저장될 수 있는 문제가 생길 수 있습니다. 그렇기에 메시지 중복을 허용하지 않는 FIFO Queue를 활용해야 한다고 생각했습니다. 하지만 초당 메시지를 주고받는 횟수가 정해져 있다 보니 Standard Queue보다는 성능이 좋지 못할 수 있지만, 데이터의 무결성을 지키기 위해서는 FIFO Queue를 활용해야 한다고 생각했습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

AWS SQS 설정

활용하고자 하는 Queue를 선택했다면, 이제 Queue를 어떻게 설정해야 할지 자세히 알아보겠습니다.

 

 

 

AWS SQS Queue 옵션

AWS SQS 옵션 구성에는 크게 5가지가 있습니다. 하나씩 알아보겠습니다.

 

표시 제한 시간

표시 제한 시간은 queue에서 빠져나간 메시지를 Consumer가 읽은 후 Queue 안에서 그 메시지가 invisible 상태로 유지되는 시간을 뜻합니다. 만약 Queue 안에 메시지가 들어있다고 가정했을 때, 메시지들은 애플리케이션 서버로 전달됩니다. 따라서 앱 서버는 메시지를 읽습니다. 만약 메시지 한 개가 서버에 도착했을 때, 그럼 Queue안의 메시지는 invisible 상태가 됩니다. 은닉 상태를 유지함으로써 다른 서버가 같은 메시지를 픽업하지 못하게 막습니다.

 

default 설정으로 Invisible은 30초간 지속됩니다. 30초 안에 앱 서버는 메시지 처리를 끝내야 합니다. 만약 성공적으로 처리된 메시지는 Queue에서 삭제됩니다. 하지만 30초 안에 메시지 처리를 못할 수 있습니다. 예를 들어 앱 서버 속도가 특정 이유 때문에 느려질 경우, 메시지를 처리할 수 없는 경우가 발생하는데, 그럼 메시지는 다시 visible 한 상태가 되며 다른 서버에 의해 픽업되길 기다려야 합니다.

 

만약 앱 서버에 문제가 없음에도 메시지가 30초 안에 처리되지 못할 경우, visible Timeout을 변경해야 합니다. 기본 값은 30초이지만, 최대 최대 12시간까지 시간을 조절할 수 있습니다.  

 

메시지 보존 기간

큐에 들어온 메시지를 언제까지 보관할 건지에 대한 설정입니다. 설정한 일자만큼만 보관하고, 기간이 지나면 메시지를 삭제합니다. 

 

전송 지연

큐에 추가된 메시지가 얼마 동안 다른 곳에 전송되지 못하도록 할 것인지에 대한 설정입니다.

 

최대 메시지 크기

전송할 수 있는 메시지의 최대 크기를 설정합니다.

 

메시지 수신 대기 시간

SQS에 수신 메시지를 가져올 때 얼마 동안 SQS에 수신 대기할지 결정하는 설정입니다. 

 

 

 

 

 

Polling

Polling이란 Customer가 Queue에 새로운 메시지가 들어왔는지 정기적으로 체크한다는 것입니다. 메시지를 가져오는 것과는 다릅니다. Polling에도 두 가지, short와 long Polling 방식이 있습니다. 

 

 

short polling

short polling은 Queue가 비어있어도 즉시 Response를 반환하는 특징이 있습니다. 만약 Queue가 비어있을 때 빈 Response가 반환되며 빈 Response에 대해서도 비용을 지불해야 하는 특징이 있습니다. 

 

long polling

long polling은 정기적으로 Customer가 Queue를 검사합니다. 만약 long poll timeout이 되거나 queue에 메시지가 들어가면 Response를 반환합니다. long polling 방식을 활용하는 것이 비용을 절감할 수 있으므로 short polling 방식보다 선호되는 방식입니다. 

 

 

 

 

 

 

DLQ

Dead-Letter Queue는 하나 이상의 Queue가 성공적으로 소비되지 못한 메시지들을 재전송하기 위해 사용하는 별도의 큐입니다. SQS는 DLQ를 자동으로 생성하지 않기에, 활용하려면 미리 생성해둬야 합니다. 만약 큐에서 최대 수신 수 값을 설정하면 이 횟수 안에 성공적으로 소비되지 못한 메시지들이 DLQ로 전송됩니다. 

 

 

최대 수신 수

애플리케이션에서 최대 몇 번 동안 수신 가능하도록 할 것인지에 대한 설정입니다. 예를 들어 최대 수신수를 3으로 지정한다면, Worker에서 3번 메시지를 수신했는데 3번 전부 처리 실패하여 삭제요청을 안 날린 경우 해당 메시지는 DLQ에 저장됩니다. SQS는 이러한 옵션으로 사용하기 쉽고 실시간으로 응답할 필요가 없는 작업들을 Queue에 넣어두고 처리 가능한 양만큼 꺼내서 처리하므로, 더 많은 트래픽을 받을 수 있는 비동기 모델을 완성시킬 수 있습니다. 

 

 

 

Redrive

컨슈머의 로직 문제를 해결하고 DLQ에 있던 메시지들을 다시 소스 큐로 보내는 것을 redrive라고 합니다. redrive 된 메시지들은 새로운 메시지로 인식됩니다. redrive를 하면 보통 원래의 소스 큐로 메시지를 보내는 것이 일반적이지만 다른 큐를 설정해서 redrive를 할 수도 있습니다. 그리고 redrive를 할 때 그 속도 또한 정할 수 있습니다.

 

 

 

지금까지 SQS에 대해 간략하게 알아봤습니다. 그럼 어떻게 SQS를 적용할 수 있는지에 대해서는 다음 글에서 작성하겠습니다.

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

마치며

앞으로도 팀의 발전을 돕는 개발자가 되기 위해 노력하려 합니다. 팀에 필요한 부분이 무엇일지 고민하면서, 팀에 도움이 된다면, 열심히 공부해서 실무에 적용할 수 있는 개발자가 되기 위해 노력하고 싶습니다. 팀의 성장에 기여할 수 있는 개발자가 되겠습니다. 

 

 

 

 

 

---

 

 

 

 

 

 

참고 및 출처

Amazon Simple Queue 서비스란 무엇입니까 - Amazon Simple Queue Service

Amazon SQS에서 대기열 사용 - AWS SDK for JavaScript

AWS SQS (Simple Queue Service) 정리 (연재#1)

[AWS] SNS vs SQS 차이점

Using Amazon SQS in Nest.

Amazon MQ vs Amazon SQS

Simple Queue Service 소개 및 사용법(1/3)

Dead-Letter Queue(DLQ)