왜 메시지큐를 사용해야 하는가

대학교에서 전산 수업을 들은 사람이라면, IPC(Inter-process communication)의 방법으로서 메시지큐에 대해서 들어봤을 것이다. Win32 프로그래밍을 하던 사람이라면 마우스 이벤트 등이 메시지큐를 통해서 관리된다고 들어보았을 것이다.

여기서 다루려는 메시지큐는 위의 2가지는 아니다. OS레벨이 아니라, IT 시스템을 구성하는데 많이 사용하는 메시지 큐에 대한 것이다. 요즘에는 Rabbit MQ, Active MQ, zero MQ 등 메시지 큐등이 많이 있고 PubNub 이라는 메시지큐 서비스도 있는데 나의 의문점은.. “왜 이런 서비스들을 사용해야 하지?” 였다. 검색하다가 좋은 글이 있어서 번역을 해보려고 한다.

원문 : Queue everything and delight everyone (2008년 7월 4일 작성)


이 글은 내가 최근 1,2년 동안에 내 머릿속에서 돌아다니던 내용을 마침내 블로그에 옮긴 것이다. 이글은 내 생각을 갑자기 머리속에서 끄집어내고 싶다는 충동의 결과물이다.

From Let the microblogs bloom – RussellBeattie.com:

(앞문장에서 단순한 쿼리와 caching 등을 통한 확장성 있는 웹시스템에 대해 설명함.) 이런 시스템이 널리 퍼지고 나면 (나와 이 점에 있어서 논쟁하고 싶은 사람은 많겠지만), 시스템의 차별점은 그 사이트가 얼마나 잘 버티는지가 아니라, 사용자 입력이 얼마나 빨리 처리되고 반영되느냐가 될 것이다. 어떤 서비스들은 거의 실시간으로 입력이 반영되는데 반해 어떤 시스템은 많은 기능 등으로 인해 속도가 느린 시스템도 있을것이다. 문제의 키포인트는 입력을 그때그때 실시간으로 웹사이트에서 보이도록 하는(publishing)것이 아니라 메시징으로 해결하는 것이다.

See also: Rearchitecting Twitter: Brought to You By the 17th Letter of the Alphabet – random($foo)

많은 최신 웹앱들이 가지고 있는 문제점은 모든 것을 한꺼번에 하나의 코드에서 처리하고 사용자에게 피드백을 주려고 한다는 거이다. 그것은 유저 인터페이스를 만듦에 있어서, 같은 UI모듈(또는 라이브러리)에서 보여지는 것은 한꺼번에 처리하는 것이 구현하기 쉽기 때문이다.

누군가가 즐겨찾기를 저장하고 싶어 한다면? 또는 메시지를 보내고 싶어 한다면? 물론 당신은 사용자가 만들어낸 콘텐츠(User Generated Content)가 시스템이 지원하는 모든 태그, 수신인, 키워드, 알림 채널에 반영되기를 원할 것이다.

하지만, 그 콘텐츠를 생성한 사용자가 웹앱이 빨리 피드백을 주기를 하염없이 기다리고 있는데도, 정말 그것을 한꺼번에 해야 할까? 브라우져에서 로딩 이미지가 돌아가는 것을 지켜보고있는 사용자에게 그 모든 작업들이 당장 처리되는 것이 중요할까?

별로 중요하지 않다. 서비스 사용자는 계속 무언가를 진행하기를 원한다. 작성한 콘텐츠가 시스템에 받아들어졌다고 확인하고, 자신이 보고있는 화면에 당장 반영되기를 원한다. 이 사람에게 자신이 작성한 메시지가 지금 당장 친구의 메시지함에 나타고 공개 타임라인에 반영되고, 태깅되거나 RSS나 Atom 피드반영 되는 것이 중요할까?

다시 말하지만, 중요하지 않다. 동시에 처리되는지 별로 신경쓰지도 – 대부분의 사용자가 별로 감사해 하지도 않는다. 그대신에 그 콘텐츠가 주위 사람들에게 퍼지면서 생길 소셜 파급효과를 생각해 보자

  • 콘텐츠를 생산하고있는 사람을 행복하게 하려면, 그사람의 화면에서 피드백을 50-200 ms(milliseconds) 안에 주어야 한다.(즉, 최악의 경우에도 0.5초안에 피드백이 와야 한다는 것이다)
  • 다음으로 만족시켜야 할 사람은 콘텐츠를 생산한 사람을 팔로우하고있는 사람이다. 그에게는 수만 ms 정도는 용납이 가능하다. (즉, 최악의 경우에도 10초안에 피드백이 와야 한다는 것이다)
  • 마지막으로 콘텐츠 생산자와 전혀 상관없는 대중에게 보여지는 tag 페이지라던지, 키워드 페이지, 그리고 다른 공개된 페이지에 대해서 신경쓸 차례다. 이 곳에는 수십만 ms 정도 반영이 늦어져도 괜찮다 (즉, 최악의 경우에도 1~2분 안에는 적용되어야 한다는 것이다)

여기서 말하고자 하는것은 소셜 시스템 구조는 확장성이 있어야 하는 동시에, 사용자들이 즐겁게 사용할 수 있어야 한다는 것이다. 이런 시간의 딜레이(delay)에도 불구하고, 이런 시스템이 메신저나 이메일 보다 콘텐츠 생산자들이 다른이들에게 메시지를 전달하는데 효과적이다. 물론 그것은 대부분의 작업이 수초 이내에 처리된다는 전제하에 말이다.

어떻게 이런 시스템을 만들 수 있을까? Queue를 사용하는 것이다. 물론 콘텐츠를 작성하고 완료버튼을 누르자마자 사용자의 DB에 저장하는 것은 바로 처리되어야한다. 그리고 나서 그 이후의 일은 queue에 저장하고 사용자가 다음일을 할 수 있도록 해주어야 한다. 실제로는, 사용자 단에서는 단 하나의 작업만을 queue에 넣고 그 하나의 작업이 여러 작업들을 또 queue에 넣거나 분산처리가 필요한 작업들을 처리하도록 하는 것이다.

그동안 콘텐츠를 작성한 사용자는 작업이 처리된데에 만족하고 다른 일을 할 것이다. 어쩌면 그 일이 새로운 콘텐츠를 계속 빠르게 작성하는 일일 수도 있다. 시스템이 빠르게 반응하기 때문에 가능한 일이다.

웹 기반의 콘텐츠 작성 인터페이스의 진정한 목적이 바로 그것이다 – 사용자들의 입력을 빠르게 처리해서 다른 것을 또 입력하고 싶어하도록 만드는 것 말이다. 작성하는 화면 외에 정보를 시스템에서 읽어오는 부분은 분산되어있는 데이타를 가능하면 빠르게 읽어오도록 해야한다.

빠르게 정보를 읽어들이는 일은 또 다른 주제이다. queue를 사용해서 처리한 것을 빠르게 불러오려면 시스템의 부하를 가져오는 SQL join문을 통해서 불러오기 보다는, 이곳 저곳에 중복되어 저장되어있는 정보를 간단한 쿼리로 읽어는 것이 좋은 방법이다.


  1. 손주욱 Avatar

    좋은 글 소개 감사합니다. 국내에는 Queue를 활용한 사례가 그리 널리 홍보되지 않은 것 같은데, 인사이트가 되는 글이네요:-)

    1. tebica Avatar

      국내에서도 Queue 는 왠만한 시스템에서 쓰고있지만, 외국만큼 개발자 블로그가 덜 활성화 되어있어서 그런거 같아요. 지식 공유의 문화를 확산시켜야!

  2. 신문규 Avatar

    message queue 가 어떻게 사용 되는 것인지 궁금했었는데 좋은 설명 고맙습니다.

  3. 이상훈 Avatar
    이상훈

    좋은글 퍼갑니다 .. 이해가 확실히 됬습니다!
    만약 문제가 된다면 삭제하겠습니다

  4. ji1 Avatar
    ji1

    이해가 잘됐어요 감사합니다!

Leave a Reply to yunchiri (@yunchiri) Cancel reply

Your email address will not be published. Required fields are marked *