출처
https://www.infoq.com/jp/news/2010/09/introduction-zero-mq/

PostRank의 설립자이자 CTO인 Ilya Grigorik씨가 지난주 ZeroMQ의 소개 기사를 썻다 .

버클리 소켓(BSD)는 모든 네트워크 통신의 기본 API이다. 1980년대 초로 기원을 가진 TCP/IP 스윗의 원래 구현이기도 한 BSD 소켓이 오늘 날 모든 운영체제에서 가장 널리 지원 되는 중요한 요소인 것은 틀림 없을 것이다. BSD 소켓을 이용한 통신으로 일반적인 것은 피어 투 피어 연결이지만, 여기에는 명시적인 설정과 티어 다운, 트랜스 포트(TCP, UDP)의 선택, 오류 처리 등이 필요하다. 문제가 모두 해결하면 다음에 기다리는 것이 응용 프로그램 프로토콜(HTTP)의 세계이다. 거기에서는 또 프레임 처리 및 버퍼링 처리 로직이 필요하다. 즉 고성능 네트워크 애플리케이션을 작성하는 것은 지루한 작업 이외의 아무것도 아니다.

또한,

다른 소켓 유형, 연결 처리, 프레임, 심지어 라우팅과 같은 낮은 수준의 세부 사항을 다소라도 추상화 할 수 있으면 좋은 생각 아닐까요? ZeroMQ(ØMQ / ZMQ) 네트워크 라이브러리는 바로 이를 위한 것이다. “이 라이브러리는 전체 메시지를 인 프로세스와 IPC, TCP 멀티 캐스트 등 다양한 전송을 통해 전송 할 수 있는 소켓을 제공한다. 팬 아웃, PubSub, 작업 분산, 요청/응답 등의 패턴에 의한 N 대 N 연결 소켓을 사용하여 가능하게 될 것이다.”

ZeroMQ의 Web 사이트에는 다음과 같은 설명이 있다.

ØMQ는 네트워크 스택의 새로운 레이어 - 확장 레이어이다. 분산 시스템의 부하를 분산함으로써 매우 큰 응용 프로그램도 지원 가능하다. 간단한 지점 간 통신 대신 분산 시스템 전체의 토폴로지를 정의한다. ØMQ 응용 프로그램은 잠금이 없는 병렬성을 가지고 임의의 수의 스레드 코어 시스템에 유연하게 대응한다.

ZeroMQ는 커뮤니티에 의해 주도 되고 있다.

ØMQ (일명 ZeroMQ 또는 0MQ)를 자유 소프트웨어로 개발하기 위해 많은 사람들이 3년 간 작업을 계속했니다.

Ilya의 설명에 의하면,

• ZeroMQ 통신은 메시지 지향이고, 응용 프로그램마다 반복되는 일상적이고 정형적인 복잡성을 많이 숨긴다. 예를 들어 클라이언트 소켓에서 150kb 메시지를 보낼 때 서버 소켓이 명시적 버퍼링이나 프레임을 하지 않고도 완전히 동일한 메시지를 받을 수 있다.
• ZeroMQ 소켓은 전송에 대해서도 인식 할 필요가 없다. 모든 프로토콜 상에서 메시지를 보내지 않고, 수신하기 위한 하나의 통합된 API가 존재하고 있기 때문이다. 기본적으로 인 프로세스, IPC 멀티 캐스트, TCP를 지원하고 있다. 전환에는 단순히 연결 문자열의 접두사를 변경하면 된다.
• ZeroMQ 소켓은 라우팅과 네트워크 토폴로지를 인식한다. 피어 투 피어 연결 상태를 명시적으로 관리 할 필요가 없다 - 전술 한 바와 같이 모든 라이브러리를 추상화 하고 있기 때문에 - 때문에 인바운드를 listen 하기 위해 두 개의 서로 다른 포트에 바인딩하여도, 혹은 반대로 한번의 API 콜에서 두 개의 다른 소켓에 데이터를 보내도 문제가 되는 것은 아무것도 없다.

또한,

ZeroMQ 통신은 기본적으로 비동기식으로 실행된다. 이 비동기 처리 모델이 통신의 확립과 개방, 재접속 논리를 모든 추상화 하고, 메시지 전달 지연 시간(대기 시간)의 최소화를 실현한다. 블로킹이 없다는 것은 메시지의 발송 및 배달, 큐 처리(송신자, 수신자 모두)와 응용 프로그램의 정상적인 처리가 병렬적으로 실행 된다는 것이다. 물론 사용되는 메모리 제한이나 심지어 소켓 당 스왑 크기를 설정하고, ZeroMQ 소켓의 큐 동작을 제어 할 수 있다. 따라서 필요하다면 블럭킹 API를 시뮬레이션 할 수 있지만, 기본은 비동기 I/O 이다.

Mongrel2는 ZeroMQ를 채용한 Web 서버이다. Ilya의 설명에 의하면,

Mongrel2는 ZeqoMQ의 Web 서버 적용에 관한 흥미로운 사례 연구를 제공한다. 인바운드 요청이 Mongrel2 의해 요청을 자동으로 로드 밸런싱 하는 “Push” 소켓을 통해 여러 연결된 핸들러에 루트된다. 핸들러는(Pull 소켓을 통해) 도착 요청을 순차적으로 처리하여 그 내용을 “Pub” 소켓에 발행(Publish) 한다. Pub 소켓에 Mongrel2 서버 자신이 등록(subscribe) 되고, 이 프로세스 ID에 대한 요청을 (토픽 필터를 통해) listen 하고 있는 것이다.

ZeroMQ의 Web 사이트에서는 다른 통신 장치와의 비교를 간결하게 소개 하고 있다

• TCP 같은 바이트 스트림이 아닌 메시지 기반이며, 메시지 패턴에 기초하고 있다.
• XMPP 보다 간편하고 빠르고, 낮은 수준의 처리가 가능하다. Jabber도 ØMQ에서 얻을 수 있다.
• 같은 처리를 AMQP 보다 100 배 빠르게 실행하면서 브로커가 필요 없다 (사양도 278 페이지로 적다).
• IPC처럼 단일 시스템뿐만 아니라 여러 기기에 걸친 추상화를 한다.
• CORBA처럼 무서운 복잡한 메시지 형식을 사용자에게 강요하지 않는다.
• RPC와 달리 ØMQ는 완전히 비동기이다. 또한 기기를 언제든지 추가 · 삭제할 수 있다.
• RFC 1149 보다 훨씬 빠르다!
• 29west LBM과 달리 무료 소프트웨어이다!
• IBM Low-latency와 달리 무료 소프트웨어이다!
• Tibco와는 달리, 지금도 무료 소프트웨어이다!

Ilya 결론은

ZeroMQ는 야심찬 프로젝트이다. 이 짧은 문장으로 소개한 것이 기능 전체의 극히 일부분에 불과하다 ZeroMQ의 목표는 “표준 네트워크 스택의 일부가 되는 것과, 심지어는 Linux 커널의 일부가 되는 것”이다. 이것이 성공할지 여부는 미지수이지만, “전통적인” BSD 소켓에서 추상화 계층으로서 매우 유망하고 많은 사람들에게 요구 되고 있는 것임에 의심의 여지가 없다. ZeroMQ는 고성능 네트워크 애플리케이션의 개발을 믿을 수 없을 정도로 쉽고 즐겁게 만들 것이다.

Antonio Garrote 씨도 Ilya에 동감한다.

ZeroMQ는 매우 강력하다. 빠르고 효율이 좋은뿐만 아니라 어떤 응용 프로그램에서도 네트워크 계층의 설계를 매우 단순화 해주는 것이다. 또한 다른 상황이라도 동일한 통신 패턴의 재사용을 가능하게한다. 그럼에도 불구하고 ZeroMQ는 내 의견으로는, RabbitMQ 같은 큐 시스템에 대한 즉각적인 대체 수단이라기 보다는 이것을 보완하는 것으로 간주 할 수 있다. 다른 소프트웨어 시스템과 마찬가지로 애플리케이션의 요구 사항을 주의 깊게 봄으로써 해결해야 할 문제에 대해 어떤 통신기구가 더 적당한가는 분명하다.