ZeroMQ 잡담

zeroMQ 의 공식 가이드에 보면 스스로 'switch-and-bait'란 표현을 사용하고 있다. switch-and-bait 는 우리 말로 '미끼 상품'이라고 보통 번역되는데 다들 알다시피 이런 식 - 초저가로 매장 앞에서 상품 홍보해서 매장에 고객을 끌어들인 뒤 고가의 상품을 사게 만드는 -  의 마켓팅 기법이다. 0MQ 가이드 1장에 나와 있는 샘플들을 이용해서 코딩 해보면 이 미끼를 안 물기 힘들다. 몇 년 전 0MQ 를 회사 게시판을 통해 소개할 때 내가 그랬고, 잊고 지내다 여기 슬랙에  요근래 다시 언급하던 내가 또 역시 그랬다. 그런데 일단 매장에 들어서서 실제 제품 구매를 고민하기 시작하는 순간 보이기 시작한다. 몇 개 예를 들어보자.

1. 0MQ 의 req-rep 패턴의 코딩 짜서 client 단을 먼저 뛰운 후 서버를 실행해보자. 에러 없이 잘 동작한다. 특별한게 없어 보이지만 기존 소켓 통신의 경우에는 어땠을지 생각해보면 뭔가 다르다. 소켓 통신에서는 이 경우 접속할 서버가 없다고 에러를 뱉어냈겠죠. 추가적인 코딩을 통해 이걸 해결할 수 있을텐데, 서버로 접속을 몇 번(보통 재연결 설정 횟수값으로 제한하겠죠)  더 시도하게 하다가 설정 한계값을 넘어가면 클라이언트 프로그램을 중단 시키는 식으로. 0MQ 는 이 과정을 숨겨버립니다. 접속이 끊기거나 해도 자동으로 재연결을 시도합니다. 심지어는 간단한 몇 줄 추가로 멀티 포트로 접속을 할 수 있게 할 수도 있죠. 문제는 접속 장애를 프로그램 내에서 직접 제어해야할 경우가 있게 마련, 아니 실전에서는 거의 필수적으로 ...
2. 0MQ 의 pub-sub 패턴을 기본 샘플을 응용해서 짜봅시다. 아주, 무지 잘 됩니다. 이걸 실전에 적용해봅시다. 잘 됩니다. 아 그런데 종종 초반 메시지 일부가 사라집니다. 어? 어?  ... 거칠게 표현하면 이런 상황이 발생하죠. sub 쪽에서 접속되는 순간pub 쪽에서 그냥 밀어넣어 주기 시작합니다. sub 입장에서 접속 후 데이터 받을 준비하는 그 짧은 사이의 데이터가 사라지는 경우가 생기는 경우가 발생합니다.
3. 이러저러한 이유로 결국 일단 미끼 물면 가이드 2장의 Reliable 패턴들을 공부하지 않을 수 없게 됩니다. 0MQ 가이드에서는 이런 상황들을 역설적으로  '익숙한 BSD 소켓 API가 있지만, 이것은 분산 소프트웨어를 설계하고 작성하는 방법에 대한 여러분의 안목을 형성하는데 느리게 할 것이며 메시지 처리 기계 부분을 숨깁니다.'라고 이야기하며 주요 문제들을 여러 개의 패턴으로 정리해서 해법을 제시하고 있습니다.

처음으로 돌아가봅시다. 스스로 'switch-and-bait'라고 미리 스스로 선언하고 있습니다. 여기서 이 미끼를 물고 더 나아갈건지 미끼 맛만 보고 매장 안들어가고 다른 매장으로 넘어갈지는 이제 우리 선택의 문제입니다.