프로그래밍의 특급 비밀

coolspeed

This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren’t aware that they know.
– Eric S. Raymond, “The Art Of UNIX Programming”

벤처캐피탈 업계에는 이런 역학이 존재합니다: 최고로 잘한 투자는 수익이 나머지 모든 투자 수익의 합보다 많다. 나머지중 최고로 잘한 투자는 나머지 모든 투자 수익의 합보다 많다.

프로그래밍에도 비슷한 역학이 존재합니다.
프로그램은 90%의 실행시간을 10%의 코드 실행에 소모합니다.[1]

이것을 통해 우리는 놀라운 추론을 해낼 수 있습니다.
시스템을 성능이 낮지만 생산성이 좋은 언어로 짜고, 그중 10% 의 핫스팟만 찾아내 C++ 로 짜면 끝.

실제로 (일부) 천재 프로그래머들은 시스템을 어떻게 설계했을까요?

1. YouTube

검색창은 Go 프로그램. 웹 애플리케이션 서버는 느린 Python 으로 짰습니다.

2. GitHub

“GitHub” 의 “Hub” 은 느린 Ruby on Rails 이고, “Git” 은 C.

3. Instagram

사진 저장은 Amazon S3 (네이티브 코드 예상). 웹 프런트는 C코드 (NginX). 데이터베이스는 C (PostgreSQL).
웹 애플리케이션 서버는 Django (Python).

4. Uber

DB: C++(MySQL)
Index: C (Redis)
애플리케이션: Javascript

Continue reading

Python 을 사용하는 대기업들 지금은 어떻게 됐을까?

Google

Google 얘기는 빼놓을 수 없다. Python 언어의 발명자 Guido van Rossum 도 구글에 계시기 때문이다.

Google 은 Python 을 좋아하다가, Go 언어를 만들었다.

특히 Python 언어의 플래그쉽같은 존재였던 YouTube, 아직도 Python 인걸로 알고 있다. 하지만 YouTube 의 검색창의 모든 검색은 Go 언어로 구현된 프로그램을 통해 일어난다고 한다. (프록시만 하는지, 구현까지 하는지는 잘 모르겠지만, 구현이야 당연히 구글의 기존 C++ 프로그램이겠지 싶다) [1]

dl.google.com 이 Go 언어로 만들어졌다고 한다. Chrome 의 압축 프록시가 Go 언어로 구현되었다고 한다. [1]

Dropbox

Dropbox 는 빠른 Python 구현인 Pyston 을 개발하다가, 이미 구현된 빠른 Python 인 PyPy 를 만지작거리다가.. 결국 Go 언어로 갈아탔다. [7]

Uber

오래되진 않았지만, 요즘은 Uber 이야말로 핫하다고 할 수 있지 않은가. 성능 크리티클한 부분을 Go 로 만들었다. (Node.js 를 고려하다가 Go 를 선택했다고 함.) [2]

Pinterest

Gevent 로 Python 을 빠르게 하다가 [3], Elixir 로 갈아탔다. [4]

참고로 Pinterest 는 MAU (Monthly Active Users) 가 1 억에 달한다고 한다. [5]

Alexa 에 의하면 Pinterest 는 Netflix.com 보다 트래픽이 많다고 한다. [6]

여담

여담으로 Ruby on Rails 로 시작한걸로 유명한 Twitter 는 Scala 로 갈아탔고, GitHub 은 음 잘 모르겠는데 아직도 Ruby on Rails 인가..?

여담중의 여담으로 Elixir 은 Ruby on Rails 핵심 커미터였던 개발자가 Ruby 로 컨커런시 처리하는 것에 지쳐서 Erlang 으로 돌아선 것이라고 한다.

결론

결론은 반전이다. YouTube 도 Python 으로 만드는데, Python 이 너무 느리게 느껴질 정도로 성공하는 서비스부터 만들고 보자. 그때까지 언어 성능은 별로 중요하지 않다.

Continue reading

오픈소스 네트워크 라이브러리 일람

1. Century

coolspeed 가 만든 Go 언어 네트워크 라이브러리 입니다:
https://github.com/coolspeed/century

이것이 1등입니다. 그냥 말이 필요 없습니다 ( __ __)

2. Skynet

https://github.com/cloudwu/skynet/graphs/contributors

C 언어와 lua 로 된 네트워크 라이브러리.
중국 게임 업계 제일 유명한 스타 개발자인 cloudwu 가 개발한 네트워크 라이브러리 입니다.
아직도 활발하게 개발 중이네요. Pull Request 도 활발하나 봅니다.

천하의 netty 가 github 에서 별표 7000개인데, Skynet 이 무려 4000개.

3. Netty

Java 네트워크 라이브러리.
한국인이 개발하고 (게임 업계 포함하여) 전 세계 개발자들이 추앙하는 네트워크 라이브러리인데  정작 한국에서는 많이 안쓰이는?

https://github.com/netty/netty

4. SuperSocket

C# 네트워크 라이브러리.
중국인이 만들었는데 한국 게임 업계에 많이 쓰이는..

https://supersocket.codeplex.com

5. Boost.ASIO

C++ 슈퍼천재(괴짜)들이 만든거라 워낙 웰메이드. 사용도 쉽고.
언뜻만 보기에도 탑 솔루션인데, C++ 17 표준에 포함된다는게 거의 확정이라 (개인적으로 80%확률일거라 봄) 가장 핫하다고 볼 수 있지 않을까요.

Continue reading

싱글스레드 모델이 액터 모델(Actor-Model)보다 나은 X가지 이유

1. 액션(동작) 순서 컨트롤이 된다. 액션의 페이스를 컨트롤할 수 있다. 예를 들어 30fps 로 모든 몹의 x좌표 더하기 1. 액터 모델에서는 비동기라서 그 액션이 어느 프레임에 들어갈찌 모른다.

2. 디버깅이 쉽다.
2.1 액터 모델에서는 글로벌 상태에 브레이크 포인트를 찍은 후에 매개인의 메일박스를 검사해야 하는 번거로움이..
서버의 경우 클라와 달리 브포보다 로그가 더 유용할 경우가 많다. 예를 들어서 Joe Armstrong 과 Richard Stallman 등 분들이 모두 printf 디버깅 방식을 더 선호한다는 소문이… 하지만 서버가 클라만큼 상태가 복잡할 경우, 브포(==시간정지) 를 통한 글로벌 상태 파악이 극히 중요해질 때가 있다.
2.2 그리고 액터 모델은 비결정론적이라서 어떤 버그들이 어떤때는 재현되고 어떤 때는 재현되지 않을 수 있다. (그러고보니 2.2 항목은 LMAX 의 장점만 말하면 다 나오네.)

3. 반경 10메터안 모든 몹들에게 범위공격. 액터모델의 경우 남의 좌표를 알 수 없어서 일일이 물어야 한다. “님 좌표 얼마임?” (그렇지 않으면 좌표를 좌표테이블에 등록해야 하는데, 그러면 액터모델이 아니게 됨) (IO 오버헤드, 코딩 코스트)

4. 로드밸런싱따위 필요없다. 액터모델의 경우 (스케쥴러에 따라 다르지만) (어차피 스케쥴러 연구하는 사람은 없으니) 액터 로드밸런싱이 필요한 경우가 있다(Skynet 역사 참조). 반면 싱글스레드 모델에서 프로그래머는 신이고, 로드밸런싱따위 필요없다.

5. 트랜잭션?

6. 클라도 싱글스레드 모델이잖아.

7. CPU 성능에 좋다 (동일언어) (사실 이건 가장 중요하지 않은 원인이다) (늘여쓰면 글한편감이라 자세한 내용은 생략한다).

결론: 두 모델이 서로 다른 문제 도메인 (Problem Domain) 에 적합할 것 같다는거다:

  • 액터모델은 격리성, 분산성과 faul-tolerance 가 골(goal)에서 제일 중요한 경우 또는 message-passing 자체가 문제를 잘 모델링할 경우 (IM, Instant Messenger: e.g. Facebook Messenger, Whatsapp, etc.)
  • 싱글스레드 모델은 글로벌 상태 컨트롤이 중요한 경우. 예를 들어 게임. (시뮬레이팅 문제?)

적재적소(適材適所).

길게 쓰면 아무도 안읽으니 이번에도 후딱 끝내는 미덕을 발양하겠다.

(끝)

[번역] ZeroMQ설계자: 세계를 구원하라

  • 번역: coolspeed

이 글은 ZeroMQ설계자가 지은 책이며 ZeroMQ의 “바이블”이라 불리는 ZGuide 의 머리말이다.

이 책은 다양한 프로그래밍 언어 예시 버전의  PDF, epub 등 이북 포맷으로 다운로드도 가능하고[1], 한글 번역도 온라인에서 읽을 수 있다. 당연히 그속에는 이 머리말의 한글번역도 포함되어 있었다. 다만 번역이 만족스럽지 못해 필자가 직접 번역했다.


ZeroMQ 100 자 요약

ZeroMQ (ØMQ, 0MQ, or zmq 라고도 표기함) 는 임베드블 네트워킹 라이브러리처럼 생겼는데 실제론 컨커런시 프레임웤처럼 작동한다. ZeroMQ 는 원자적으로 메시지를 배송하는 소켓을 제공하는데 그 배송수단으로는 스레드간 통신, 프로세스간 통신, TCP 그리고 multicast 등 다양하다. 당신은 ZeroMQ 소켓을 N-to-N 방식으로, fan-out, pub-sub, task distribution, 그리고 request-reply 등 패턴으로 사용할 수 있다. 이것은 클러스터 제품들의 뼈대로 사용하기에 전혀 문제 없는 높은 성능을 가지고 있다. 이것의 비동기 I/O 모델은 당신이 message-passing task처럼 짜여진, 확장성 있는 멀티코어 애플리케이션을 만들 수 있게 해준다. 언어 API 만큼 고득점을 갖고 있으면서 거의 모든 OS에서 돌아간다. ZeroMQ 는 iMatix 에서 개발했으며 LGPLv3 라이센스로 소스가 오픈되어있다.

 

세상을 구원하다

ZeroMQ 요놈은 정말 좋은데. 어떻게 말로 표현할 방법이 없네.  ZeroMQ의 가치를 설명하기 위해, 일부 사람들은 요놈이 제공하는 모든 훌륭한 기능들을 나열하는 것으로 부터 시작하려고 한다:

  • 이놈은 스테로이드를 처먹은 소켓이야.
  • 이놈은 라우팅 기능이 있는 우편함으로 비유할 수 있지.
  • 존나 빠름.

Continue reading

한눈에 보는 MQ

  • coolspeed

요즘 MQ에 빠져 MQ덕질 좀 했습니다.
길게 쓰면 아무도 안읽고, 쓰는 사람도 귀찮아지니 알맹이만 적겠습니다.

ActiveMQ – 정통 MQ, 기능 많음, 트랜잭션 지원.

RocketMQ – 알리바바에서 오픈한 MQ. 지구상 가장 분주한 전자상거래 시스템중 하나인 알리바바의 인프라로 매일 높은 워크로드에서 사용되고 검증되고 있음. 세계 기록을 갱신한 쇼핑몰 오더 처리 성능.

Java로 개발됨. 활발한 개발과 (중국내) 활발한 커뮤니티. 트랜잭션 지원(그러니 전자상거래에 쓰일 수 있지).

단점: 클라이언트 언어는 Java 와 C++ 만 지원.

Apache Kafka – LinkedIn 에서 오픈. Scala 언어로 개발됨. 개발팀은 나가서 새로 회사를 차렸다는데 현재는 개발과 커뮤니티가 모두 그다지 활발하지 않음.
최대 장점은 성능. 특히 batch 모드를 켰을 때 (redis pipeline모드랑 유사).
단점: 트랜잭션 지원하지 않음.

RabbitMQ – Erlang 으로 개발됨. 성능 좋음. (거의) 모든 언어 클라이언트 제공.
AMQP의 여러 기능을 지원하는 만큼 ActiveMQ에 버금가는 다양한 피쳐.
Erlang으로 개발된 만큼 fault-tolerance 가 짱임.

ZeroMQ – 사실은 MQ가 아님. Zero * MQ == zero != MQ?
네트워크 라이브러리? 네트워크 프로토콜 스택상의 새로운 레이어? Linux커널에 들어가는 것을 목표로 한다.
끊기면 자동 재연결하는 고급 소켓. Listen 과 accept 순서 무관인 고급 소켓.

(거의) 모든 언어 클라이언트 제공. 라이트한 만큼 성능이 장점.

“ZeroMQ” 에서 “Zero”는 broker가 없음을 의미. 그만큼 분산식 차원에서 더욱 철저하다.

(무엇보다 얘는 정말 MQ가 아니기에 MQ리스트 안에 넣어서 비교하는 자체가 어색하다. MQ같은 네트워크 라이브러리.)