Uber의 Message Queue, Akka, Vim, Java

Uber가 만든 MQ 디자인. (task-queue 용도)

• uber가 며칠전(12/6) 아래의 제목으로 글을 썼다.
  • “Cherami: Uber Engineering’s Durable and Scalable Task Queue in Go - Uber Engineering Blog”
  • https://eng.uber.com/cherami/
• uber는 microservice-architecture(이하 MSA)로 운영하는 것으로 유명하다.
  • 이 글로 MSA에 필수인 queue를 uber는 어떤 디자인으로 만들었는지 알 수 있다.
  • 또 어떤 디자인이 실제로 어떻게 구현되고 무슨 고민이 있는지도 알 수 있다.
  • 남이 만든 디자인을 관찰하는건 재밌는 일이다.
  • 나는 주로 가용성과 확장성에 주목한다.
    • (나에게) 처리량은 확장성에 포함되고.
    • (나에게) fault-tolerance는 가용성에 포함된다.
    • (물론 엄격히 말하면 다르다.)
  • uber는 1억개/일 메시지가 오간다고 한다.
    • 계산해보면 평균 1,157개/초 메시지로 추정할 수 있다.
  • 이 메시지가 uber에서 사용되는 사례로 밝힌 것:
    • post-trip processing
    • fraud detection
    • user notification
    • incentive campaigns
    • 등
• 주요 디자인 선택.
  • 가용성을 위한 선택.
    • competing consumers.
    • replicating messages.
    • eventual consistency.
      • 이 선택은 아마도 순서를 보장하지 않는단 얘기.
  • 확장성을 위한 선택.
    • competing consumers.
    • write 처리량을 관찰하다가 확장하는 역할도 미들웨어에서 하는 듯 하다.
• 나는 새로운 솔루션을 사용 하는 일에는 보수적이다.
  • 새로운 솔루션을 선택하는 일은 많은 단점이 있다.
    • (논증 생략.)
  • 나는 둘 중 하나의 길을 선호한다.
    1. 새로운 솔루션의 “디자인”만 이해하고, 기존 기술로 요구사항에 맞춰 구현한다.
    2. 아래 조건을 만족한 경우 새로운 솔루션을 사용한다.
       • 솔루션을 아주 깊이 이해했다.
       • 동시에 전파하기 쉬운 솔루션이다.
  • 보통은 디자인을 제대로 이해하지 못하고, 유행을 쫓아 도입하는 경우가 많다.
  • 그 중 queue 시스템은 다양한 장단점의 솔루션이 있다.
    • 각 회사마다 각 팀마다 저마다의 queue를 만드는 경향도 있다.
  • 고가용성, 고확장성을 가지고.
    • 보장옵션을 선택하게 하면 좋을텐데.
    • 현재는 Amazon SQS 가 그것에 가장 가까웠다.

Akka

• 최근에 Akka와 Actor model의 디자인도 잠깐 검토할 일이 있었다.
• Akka는 해주는게 거의 없는 틀 이었다.
• 나는 이런 프레임워크를 좋아한다.
• 보통은 X를 보장하면 Y가 떨어진다.
  • 풍선을 누르면 다른 부분이 올라가는 것 처럼.
  • 세상의 일은 대부분 tradeoff 다.
  • 어떤 프레임워크가 X를 보장한다고 주장한다고 해도.
    • 사실은 그 보장의 경계를 증명하기 위해 많은 비용을 써야한다.
• Akka는 오버헤드가 없는 틀만 있고 대부분을 개발자에게 위임한다.
  • 그리고 actor model이 구조적으로 살을 붙이기 좋아 보였다.

vim

• vim 관련 링크들.
• 2016 NYC Vim talk에서 있었던 “vim 플러그인이 하는 일의 90% 를 플러그인 없이 하는 방법” 이라는 제목의 발표.
  • 영상 [1], 슬라이드 [2]
  • 재밌게 보긴 했지만, 남는건 별로 없었다.
  • 다른 내용은 좀 억지스럽고 부자연스럽게 문제를 해결하려는것 같았다.
    • 플러그인으로 하면 쉬운데 왜 이렇게까지? 하는 기분.
  • file browser는 나도 nerdtree 보다 netrw 계열을 쓰는데 동의한다.
  • 하지만 nerdtree 를 여전히 사용은 하고 있다.
  • 그리고 내장된 순수 netrw 는 문제가 좀 있다.
• vim 스크립트 칫싯. [3]
  • 스니핏으로 저장해두고 쓰기 좋다.
• 파이콘2016 에서 vim과 gnome-desktop을 사용하시는 분이 있었다. [4]
  • ruby의 byebug 같은 역할을 python에서는 pudb로 하는것 같다.
    • gdb와 매핑되는 네이밍으로 보인다.
    • 근데 저렇게 UI까지 제공하는건 좋은 선택일까?
  • nautilus 를 터미널에서 입력하시는거 보니 오래된 gnome-desktop 유저 분이시구나 하는 생각이 들었다.
  • vim에서 python 자동완성을 위해 jedi-vim [5] 을 사용하신다.
• redis를 만든 antirez가 vim을 어떻게 사용하는지 쓴 글을 읽었다. [6]
  • antirez가 쓰는 전체 vimrc 는 이것인듯. [7]
  • 특별한건 없고, vim을 최소한의 설정으로 사용한다.
    • vim을 많이 사용하는 유저는 아닌것 같다.
  • 실수방지를 위해 map 4 $ 을 한건 귀요미.
    • 나도 설정해봤는데.
    • 너무 불편하여 며칠후에 관뒀다.
  • r!date 는 나도 설정해서 쓰는데, 나같은 사람을 또 만나다니!

java

• java 생태계는 unix철학을 따르지 않고, 내가 쓰기엔 불편한 점이 많다.
  • (나와는 정말 안 맞는것 같ㄷ…)
• 예를 들어.
  • 현재 프로젝트의 dependency 목록을 보여주는 shell 함수를 만들고 싶었다.
    • 당연히 mvn help:effective-pom | xml2json | jq '...생략...' 이런식으로 간단히 되겠지. 라고 생각했다.
    • 하지만 mvn help:effective-pom 결과는 xml 외에도 info log정보를 (verbose하게) stdout에 뿌린다.
    • xml만 출력하려면 파일에 쓰고, 그 파일을 읽으면서 작업해야한다.
    • 불편하다.
    • verbose 옵션이 디폴트라니.
    • quite 옵션도 없다니.
  • remote 의존성을 shell에서 검색하고 싶었다.
    • 만약 ruby라면 gem search kafka
      • (덧, ruby kafka 라이브러리가 옛날 버전만 지원하는 것을 보고 좀 우울해졌다.)
    • 만약 python이라면 pip search kafka
    • 만약 docker라면 docker search kafka
    • 만약 apt라면 apt search kafka
    • 를 했는데. java에서는 도대체 왜 mvn search kafka 같은게 없는걸까.
    • 라고 생각했는데
      • mvn-search kafka 식으로 만들 수 있게, 누군가 savant [8] 라는 도구를 만드셨다.
  • 모든 dependency의 문자열 검색을 ag 같은 외부 툴로 하고 싶었다.
    • ruby라면 ag ~/.rvm/gems/ruby-2.3.1/gems/으로 검색하면 된다.
      • 실제로 이런 검색을 하는 vim 커맨드를 만들고, 키 하나로 찾아간다.
    • java에서도 이걸 해볼까 해서 시도했는데.
      • 일단 maven repository 에 소스를 올리지 않는 라이브러리가 많다.
      • 그리고 모두 jar로 압축된 형태로 ~/.m2/repository 아래에 저장된다.
    • jar를 풀고 class 를 decompile 해서 저장해야.
      • ag 같은 외부 툴로 검색하는 기능을 만들 수 있다.
    • 악.
    • 안 한다 안 해!
• java에도 타입추론이 제안되었다. [9]
  • 자바커뮤니티는 세계 최고의 보수적인 프로그래머 집단이기 때문에
    • 스칼라와 코틀린의 기능들을 아주 천천히 흡수하고 있다.
      • neovim 의 핵심기능을 vim8 이 흡수하면서 neovim을 죽이고.
      • coffeescript 같은 언어도 결국 흡수되면서 죽는 것 처럼.
      • kotlin 같은 언어는 (너무!) 좋지만 언젠가 죽을 운명의 기술이라 생각한다.
    • 타입추론의 문법은 아래 중 하나로 결정될 것 같다.
      • var x = expr only (like C#)
      • var, plus val for immutable locals (like Scala, Kotlin)
      • var, plus let for immutable locals (like Swift)
      • auto x = expr (like C++)
      • const x = expr (already a reserved word)
      • final x = expr (already a reserved word)
      • let x = expr
      • def x = expr (like Groovy)
      • x := expr (like Go)
    • 나는 Go 스타일의 x := expr 으로 선택되면 좋겠는데.
      • 자바스럽지 않다며 기각되었다.
        • The Go syntax (a different kind of assignment operator) seems pretty un-Javaish.
      • 자바스럽지 않다니! (하.)