AWS SQS(Simple Queue Service) 소개

AWS SQS(Simple Queue Service)

AWS SQS(Simple Queue Service)는 말 그대로, Simple 한 message queue 서비스 이다.

전반적인 기능을 보면 message에 대한 send, receive 기능만 가능하다.

대신 AWS 클라우드 환경에서 메세지의 복제를 통해서 장애 대비 능력에 촛점이 맞춰져 있다.

JMS 처럼 XA 기반 트렌젝션 관리 능력이나, Error Queue에 대한 처리, auto retry와 같은 고급 기능도 없고

RabbitMQ 처럼, routing,pub/sub 등의 다양한 message exchange pattern도 지원하지 않는다.

단순한 enqueue/dequeue 기능의 큐이다.

몇 가지 특성을 살펴보면

1. message 크기는 max 64kb

2. Visible timeout

- message를 read하면, 메세지가 실제로 큐에서 지워지는 것이 아니라 다른 consumer에게 보이지 않는 상태가 된다.

메세지 처리가 끝나면 consumer가 delete 메서드를 사용해서 명시적으로 그 메시지를 지워야 한다. 지우지 않으면  일정 시간(Visible timeout)이 지나면 다른 consumer도 그 메세지를 볼 수 있다. 

즉 receiveMessage를 consumer가 호출한후 visible timeout내에 메세지 처리를 다 끝내고 명시적으로 delete를 해야 queue에서 삭제가 된다.

consumer가 메세지 처리중 장애가 나거나 delete를 하지 않았을 경우에는 visible time out 시간이 지난후에, 다른 consumer가 해당 메세지를 볼 수 있다. 이 메커니즘은 클라우드 환경에서 Q가 transaction등을 지원하지 않기 때문에, 메세지 처리 실패시에 다른 consumer가 fail over방식으로 메세지를 재처리할 수 있는 메커니즘을 제공하기 위함이다.

3. SOAP기반의 웹서비스나 SDK를 이용하여 접근이 가능

- 요즘 추세가 Queue 프로토콜을 JMS에서 AMQP로 옮겨가면서 성능을 우선시 하는데, HTTP를 기반으로 하고 있기 때문에, 성능을 기대하기는 어려워 보인다.

4. Delayed Timeout

메세지를 send한후에, consumer에게 보일때 까지의 시간을 조정할 수 있다.

즉 메세지를 보낸후, consumer가 직접 받아보는것이 아니라, 수초가 지난후에 consumer가 받을 수 있도록 조정할 수 있다.

이는 명시적인 delayed 처리가 필요한 경우 사용할 수 있다.

5. Batch 처리

그나마 괜찮은 기능인데, 메세지를 한건한건 보내는것이 아니라 한꺼번에 여러 메세지를 bulk로 보낼 수 있다.

마찬가지로 bulk로 메세지를 읽는 기능도 존재한다.

6. ACL

Queue에 대한 read/write 에 대한 권한 제어가 가능하다.

7. Message retantion time

Q 내의 메세지는 일정 시간동안이 지나면 자동으로 삭제된다.

AWS위에서 미들웨어의 사용은 상당한 고민 거리이다. DB를 EC2위에 배포하더라도, AWS의 제약 때문에, AZ (Amazon availible zone - 같은 지역에 있는 물리적으로 다른 데이타 센터)간의 HA(장애시 fail over)를 구성하기도 어렵다. 예전 같은 호스팅 환경이면 데이타 센터 장애가 나면 그러려니 했지만, AWS의 가용성은 99.95%이다. (http://aws.amazon.com/ko/ec2-sla/) 약 1년에 4.38시간은 장애가 난다는 것을 가정으로 한다. 즉 AWS는 장애가 날것을 전제하여 시스테을 설계해야 한다.

그래서 RabbitMQ나 ActiveMQ 같은 솔루션을 AWS 환경에서 HA로 구성하는 노력을 해야 하고, 사실 쉽지도 않다.

간단한 비동기 Queue 시나리오가 필요한 경우에는 SQS를 사용할 수 있지만, 성능이나 기능면에서 미치지 못한다.

그래서 기존 아키텍쳐와 다른 형태의 접근 방법이 필요하다.

SQS의 장점은

- AWS 인프라내에서 장애에 대한 대응성이 뛰어나다.

- 쉽다.

- 별도로 관리할 필요가 없다.

단점은

- JMS,Rabbit MQ와 같이 다양한 기능을 기대할 수 없다.

- 다른 Message Queue 대비 느리다.

- Polling 방식이기 때문에, Consumer 설계시 매번 polling하는 식의 로직을 구현해야 한다.

http://www.nsono.net/blog/?p=3 SQS vs RabbitMQ 읽어볼만 합니다.

여기의 내용중의 하나가 SQS가 polling 기반이며. 그리고 polling request때마다도 돈을 받는다는 군요. 그래서 큐가 비어 있어도 polling을 할때 돈을 내야하고, 비용 절감 차원에서 polling 주기를 늘이면 메세지 처리가 느려지고, 빨리 처리하기 위해서 polling 주기를 줄이면 메시지 처리 성능이 느려진다는 이야기입니다.