AWS SQS의 활용

마이크로 서비스의 경우 마이크로 서비스 간의 통신이거나 어떠한 이유에서 이든 메시지큐를 사용하여야 하는 환경이 구성되곤 한다. AWS SQS가 나오기 이전에는 기업의 상용시스템에서는 IBM MQ가 많이 사용되었고, 지금도 사용되고 있을 것이다. 오픈 소스로 구현할 경우 레빗 MQ를 많이 사용하였을 것이나, 이제 대세는 AWS의 메시지큐인 SQS이다. SQS를 사용하려면, 일단 SQS에는 두 가지 타입이 존재하고 자신의 비즈니스 요구에 따라 어떤 것을 선택해야 하는지가 상당히 중요한 의사 결정이 될 수 있다. TLDR; SQS에는 Standard와 FIFO 큐가 있고 각 특성에 대해 알아보도록 하자.

	Standard Queue	FIFO Queue
Message Order	메시지큐에 들어온 순서에 따라 딜리버리를 제공하기 위해 최선을 다하지만, 절대 그것이 보장될 수 없다.	큐에 들어온 순서대로 딜리버리 된다.
Delivery	최소한 1번 이상의 딜리버리를 보장하며, 같은 메시지가 들어오는 것을 허용한다.	딱 한 번만 메시지 전송을 허용하며 명시적으로 삭제하기 전까지 큐에 메시지가 남아 있다.
Transaction Per Second	거의 무제한	초당 3000 메시지 프로세스만 허용된다.
Region	모든 AWS Region	제한된 지역에 대해서만
Use Case	메시지 순서가 중요하지 않은 대부분의 유즈케이스에서 사용될 수 있다.	메시지 순서가 크리티컬한 경우에 사용하여야 한다. 예를 들어 가격 변경과 같은 메시지의 경우 사용
Price	FIFO 큐에 비해 저렴

가장 중요한 특성의 차이는 Message Order이다. 딜리버리가 순서대로 되느냐 아니면 랜덤 하게 메시지가 딜리버리 되느냐. 예를 들어, A 상품의 가격이 100원이었는데 300원으로 변경되었다. 근데 알고 보니 마케팅 담당자가 가격을 잘못 입력한 것이어서 다시 200원으로 변경되었다. 이럴 경우 최종 가격은 200원이 되어야 한다. 하지만 데이터 프로세싱 입장에서 메시지를 가져올 때 스탠다드 큐의 경우 메시지 순서가 보장되지 않으므로 200원 메시지가 먼저 나오고, 그다음 300원 메시지가 나올 수 있다. 이럴 경우 A 상품의 최종 가격은 300원으로 비즈니스를 요구사항을 충적시키지 못한다.

우리 팀에서는 모든 것을 Standard 큐로 사용하고 있다. 개인적으로 FIFO 큐가 사용하기 편하나, 다들 퍼포먼스 관점에서 Standard 큐를 선호한다. 개인적 경험으로 봤을 때 메모리만으로 비즈니스 로직을 처리하는 것이 아니라면 성능 차이는 그렇게 크지 않다. 가격도 아주 약간 저렴한 편이므로, 가능하면 모든 프로세스에 FIFO 큐를 적용하라고 충고하고 싶다. 하지만, 정말 Standard 큐를 사용해야 한다면 Message Order의 문제를 해결할 수 있는 방법이 전혀 없는 것일까? 물론 있다. 이것은 다음 포스트에서 다뤄볼 예정.