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


Archive»


 

'대용량 시스템'에 해당되는 글 2

  1. 2015.01.29 분산 대용량 큐-Apache Kafka에 대한 검토
  2. 2011.10.24 분산 처리 오픈 소스 Gearman 퀵리뷰
 

분산 대용량 큐-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





정리는 아래 PPT에 잘되어 있고
쉽게 요약하면, Async Queue + Working 서버다
Request를 Queuing 했다가, 뒤의 Work Process로 넘겨줘서 작업을 비동기로 처리해주는 형식이고
예전 Tuxedo와 같은 TP 모니터와 유사한 구조를 갖는다.
Hadoop과 같은 Map & Reduce 의 분산 처리 구조와도 비슷하고
야후등의 레퍼런스도 있고
memcached나 mogileFS를 만든 danga.org의 작품이기도 하다.
일단 단순성이 높고, 사용성도 편리해서 대용량 분산 처리에 사용하기는 편할듯.
단 예전 TP 모니터에서 봤듯이, 작업 배분을 위한 Worker Process들의 Registration을 처리하는 BBL과 같은 Registration Table에 별도의 성능 문제나 Locking 문제가 없을지는 고민해봐야 할듯