AWS SQS 사용기(feat. SNS)

AWS SQS 사용하면서 느낀점 생각나는대로 글 남깁니다.

Simple Queue Service 말 그대로 심플해서 간단히 사용하기에 편하고 좋았다.
하지만, 카프카, MQ와 같은 메시지 큐를 생각하고 쓰기엔 무리가 있어보인다.

SQS 내에서 topic(주제)을 나누고 싶었으나, 그런 기능은 없음. 좀 더 알아보니, AWS 공식문서에서 SNS(Amazon Simple Notification Service)를 이용하여 topic을 나눌 수 있고, SNS-SQS를 같이 사용해야한다고 되어있다.

SNS에 대해서 좀더 말하자면, SNS 는 topic 별로 Lambda, SQS, mail 등으로 동시에 publish 할 수 있어, 여러 시스템의 확장성 면에서 좋다.

하지만, 이 프로젝트에 Queue 를 사용하는 것이 주 목적이였으며, topic 기능이 현재로선 필요하지 않아, 연동 테스트까지 한 후 제거 하였다.(추후에 Lambda나 서비스 확장할 일이 있으면 다시 사용할 예정이지만, 개인적인 생각으로는 SQS Queue 대기열 추가해서 쓰는게 나을 거 같다.)

다시 본론으로 돌아와서, SQS는 Springboot 프레임워크와 nodeJS 사이에 Queue를 사용하였으며, 각 프레임워크에 연동하는 것은 이미 많은 사례들이 있어 참고 해서 연동 개발 하였다.(다만 Springboot 경우, 버전이 맞지 않으면 maven build 시 SQS policy error가 발생하니, springboot 버전에 맞는 SQS 버전의 library를 사용해야한다.)

또한, Queue에 들어가있는 메시지를 꺼내올 때(receiveMessage) 메시지 수를 1~10사이의 값으로 설정하여 가져 올수 있다고 한다. 하지만, 어떠한 방법으로도 최대 값인 10개의 메시지를 한번에 가져오진 못하였다. 대용량으로 메시지를 수신 처리를 해야 했으므르 난감했다.

AWS 공식 문서에서도 최대가 10개 이지만, 최대 값으로 가져오는 것을 보장 하진 않는다고 되어있으며, stackoverflow에도 이런 내용의 글들이 많이 올라와있어, 추천한 방법대로(long polling 방식, MaxNuberOfMessages 값 조정 등) 여러가지 하였지만, 효과가 없었다.

결국에는 프레임워크에서 스케쥴링에 의해 멀티 스레드 형식으로 비동기로 계속 호출하여 메시지를 꺼내오도록 처리하였다.(참고사항으로, SQS 의 장점 중에 표시 제한 기능이란 것이 있다. 한 사용자가 메시지를 꺼내는 동안, 해당 메시지를 다른 사용자가 접근하지 못하도록 제한하는 기능으로 중복 수신에 대한 문제를 방지해주며, 시간 설정으로 제한할 수 있다. )

나중에 찾아보니, AWS SQS 를 병렬로 연결하여 메시지를 꺼내오는 오픈 소스가 있어서, 그 오픈 소스를 기반으로 만들게 되었다.

추가적으로, SQS 를 사용하면서 느낀 것은, 아직까지 AWS SQS 의 국내 사용률이 많지 않다고 느꼈다. 구글링 하면서 개발을 진행하였으나, 국내 블로그는 SQS를 제일 기초적인 설치 및 연동들에 대한 사례들이 많았고, 상용하기 위한 심화된 내용이라던지 이슈들에 대해서 찾기 어려웠다.(stackoverflow 나, 외국인들이 남긴 글들 참고하면서 이슈 해결을 하였다.)