ZeroMQ

ZeroMq aka ZMQ.

Message-oriented communication

기존의 BSD socket이 Stream(TCP) 혹은 Datagram(UDP) 의 2가지 서로 다른 방식을 제공하고, 각각의 socket을 사용하기 위해서는 socket을 여는 함수인 socket()을 제외하곤 서로 다른 API를 사용해야 했다. 이와 달리 ZeroMq는 Message oriented 통신 방법이라고.

ZMQ의 특징을 기술한 말을 보면

abstract some of the low-level details of different socket types, connection handling, framing or even routing
zero-copy semantics, optimized framing and no locking data structure

TCP와 달리 application에서 buffering이나 framing을 고민할 필요가 없다고.

Feature list는 여기 참고

Stream/Datagram 방식에서 message-oriented model로 변경한 것이 어떤 의미가 있는 지 실감되지 않는데… 특징을 보면 충분히 매력적으로 보인다.

특징

  • Transport agnostic sockets
  • In-process, IPC, multicast, TCP 등을 지원하고, 4가지 방식 사이에서 원하는 방식으로 간단하게 바꿀 수도 있고, 동시에 두 가지 이상의 방식을 사용할 수도 있는 듯
  • 덕분에 처음 한 가지 방식으로 구현한 후 필요에 따라 다른 방식으로 변경하는 것이 bind 명령어 옵션만 바꾸면 된다고.
    req.bind(‘tcp://127.0.0.1:80’)
    req.bind(‘inproc://some.pipe’)
    req.bind(‘ipc://another.pipe’)
  • Routing & Topology aware sockets
  • 하나의 socket이 2개 이상의 다른 port에 bind해서 메시지를 수신할 수도 있고, 하나의 API 호출로 서로 다른 여러 socket에 메시지를 보내는 것도 가능하다
  • Publisher/Subscriber – unidirectional from publisher to subscriber. 하나의 send 호출이 모든 subscriber에 메시지를 보냄.
  • Request/Reply – bidirectional. 하나의 server에 여러 client가 연결되어 있을 때는 자동으로 message는 load balancing되어 오직 하나의 client에만 전달 될 수 있다. (FIXME. 어떤 방식으로 load balancing selection되는 지 확인 필요)
  • Push/Pull – unidirectional and load balanced.
  • 별도의 message broker나 load balancer가 필요하지 않음.

ZMQ socket을 열면 library 내부에서 하나의 I/O thread를 생성하고, 이 thread가 connection setup, teardown, reconnect 등을 수행함.

활용 예) Mongrel 2

외부에서의 request를 처리하기 위해 request를 받은 후 Push/Pull 형태의 ZMQ 소켓을 이용하여 여러 client중 하나에게 보내 처리하게 함. 별도로 application에서 load balancer를 구현할 필요가 없어 간단함.

기타

출처 ZeroMQ : Modern & Fast Networking Stack

Docker on Mac

Homebrew를 이용하면 정말 간단하게 설치할 수 있는데 어디에 써먹을 수 있는 지 모르겠다. 만들어진 container 에는 gcc도 없네. 뭔가 이미지를 받아서 의미있는 놈(?)을 container에 담아야 할 듯

Mac에 Docker 설치하기
Docker 써먹기(User Guide)

NFV

Network Function Virtualization.

2012년에 전 세계 12개 대형 통신 사업자가 모여서 자신들이 사업하는데 불편한 점을 해결하기 위해 모임.
White Paper의 요약은 여길 참고.

– Do a single PoP/Site design based on commodity compute hardware;
Avoiding designs involving one-off installs of appliances that have different power, cooling and space needs simplifies planning.
– Utilize resources more effectively;
Virtualization allows providers to allocate only the necessary resources needed by each feature/function.
– Deploy network functions without having to send engineers to each site;
“Truck Rolls” are costly both from a time and money standpoint.
– Achieve Reductions in OpEX and CapEX; and,
– Achieve Reduction of system complexity.

근데 이건 단 2개의 키워드로 정리할 수 있을 듯

1. 돈
혁신의 속도가 빨라지면서 금방 네트웍 기술이 바뀌면 이를 위해 설치했던 전용 장비를 또 다른 전용 장비로 바꿔야 해서 투자 부담이 크다. 만일 이를 commodity H/W를 이용한다면 H/W의 재투자 없이 S/W 변경만으로 변경할 수 있으므로 비용 측면에서 유리하다.

2. 주도권
지금은 특정 기능을 제공하는 전용 장비를 NEP가 제공해야 가능하므로, 사업자가 요구하더라도 결국 NEP의 제품 개발 일정에 혁신의 속도가 맞춰질 수 밖에 없다. 만일 commodity H/W를 이용하고, Open Interface를 제공해서 특정 업체가 아닌 학계나 3rd party 업체가 network appliane를 개발/적용할 수 있게 한다면 ‘혁신의 주도권’이 NEP에서 자신들에게로 돌아올 것이다.

NFV와 SDN의 목적이 유사해 보이지만, 서로 상호 보완적이지, 의존적은 아니라고 언급. 즉 SDN을 사용하지 않고도 NFV에서 원하는 바를 구현할 수 있을 거라고. 예를 들어 그냥 x86서버를 이용하되 OpenFlow를 이용하지 않고도 스위치나 라우터는 만들 수 있다고.

하지만 2가지 혁신이 따로 진행되지는 않고, 결국 NFV에서 SDN을 이용해서 자신들이 원하는 바를 추구해 나가지 않을까? 참고로 SDN은 새로운 newtork architecture로, 1. control/data plane의 분리, 2. Centralized controller, 3. Standard Interface 를 특징으로 갖는다.

참고 사이트

What OpenFlow is (and more importantly, what it’s not) « Network Heresy

What OpenFlow is (and more importantly, what it’s not) « Network Heresy.

Pro git – chapter 2

  • git reset HEAD^ : 최근 1개의 commit 취소
  • git reset HEAD~2 : 최근 2개의 commit 취소
  • git push origin +master : master의 내용이 origin의 내용에 비해 fast forward가 아니더라도 push함.