블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'Rabbit MQ'에 해당되는 글 3

  1. 2015.01.29 분산 대용량 큐-Apache Kafka에 대한 검토
  2. 2012.11.09 AWS SQS(Simple Queue Service) 소개 (1)
  3. 2011.06.03 Message Queue Comparision
 

분산 대용량 큐-Apache Kafka에 대한 검토 내용 정리


실시간 빅데이타 분석 아키텍쳐를 검토하다가 아파치 스톰을 보다보니, 실시간 데이타 스트림은 큐를 이용해서 수집하는 경우가 많은데, 데이타의 양이 많다 보니 기존의 큐 솔루션으로는 한계가 있어서 분산 대용량 큐로 아파치 카프카(Kafka)가 많이 언급된다.

그래서, 아키텍쳐를 대략 보고, 실효성에 대해서 고민을 해봤는데, 큐의 기능은 기존의 JMS나 AMQP 기반의 RabbitMQ(데이타 기반 라우팅,페데레이션 기능등)등에 비해서는 많이 부족하지만 대용량 메세지를 지원할 수 있는 것이 가장 큰 특징이다. 특히 분산 환경에서 용량 뿐 아니라, 복사본을 다른 노드에 저장함으로써 노드 장애에 대한 장애 대응 성을 가지고 있기 때문에 용량에는 확실하게 강점을 보인다.

실제로 마이크로소프트 社의 엔지니어가 쓴 논문을 보면http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf

 


카프카의 경우 10만 TPS 이상의 성능을 RabbitMQ는 2만 TPS 정도의 성능을 내는 것으로 나와 있는데, 여기서 생각해볼 문제가 큐는 비동기 처리 솔루션이다. 즉 응답 시간에 그렇게 민감 하지 않다는 것이다.

그리고 일반적인 웹 시스템의 성능이 1500~2000 TPS (엔터프라이즈 시스템의 경우) 내외인 것이 일반적이기 때문에, Rabbit MQ의 2만 TPS의 성능은 충분하다고 볼 수 있지 않을까 한다.

물론 네이버나 해외의 대형 SNS 서비스의 경우에는 충분히 저정도의 용량이 필요하겠지만, 현재로써는 일반적인 시스템에서는 카프카의 용량과 성능은 약간 오버 디자인이 아닌가 하는 생각이 든다.


Rabbit MQ is scalable and




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 주기를 줄이면 메시지 처리 성능이 느려진다는 이야기입니다.


http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

RabitMQ가 Amazon SQS에 비해 40배 가량 빠름.
AMQ나 RabitMQ를 클라우드에서 서비스하기 위해서는
1. SQS나 Azure Queue Service와의 호환성 문제 --> jCloud등 사용
2. Multitanent 문제 --> Pending Message가 장애를 발생시켜서 다른 업무나 사용자에게 방해를 줄 수 있다.
3. Global Scale Deployment --> DR과 Data Center간 Synchroization

이거 재미는 있겠는데.... 난이도가 무지 높겠다.. ROI가 쉽지 않겠어