kubernetes

https://github.com 이 kubernetes 위에서 100% 돌아가도록 이전했다고 합니다. githubengineering 정확히는 rails 웹앱을 모두 kubernetes 클러스터의 컨테이너에 올렸다는 이야기입니다. 일단 kubernetes 성공 사례라서 반가웠고, 추상적인 이야기가 아니라 실용적인 내용이 많아서 더 좋았습니다. 예를 들어 커널 패닉에 대한 실패 테스트를 만들기 위해 echo c > /proc/sysrq-trigger 명령을 사용했다는 식의 구체적인 사례가 인상에 남습니다.

python

최근에는 python을 많이 사용했습니다. ruby로는 풀리지 않는 상황이었고, python을 피할 수 없는 경우를 여러 번 겪었습니다. 마침 python3.6이 나쁘지 않아서, “만약 평생 하나의 프로그래밍 언어만 배워야 한다면 python이 맞지 않을까?” 같은 이야기를 저도 하게 되었습니다.

python이 ruby보다 확실히 좋다고 느낀 점도 있습니다. built-in logging 모듈이 더 좋았고, argparse 모듈은 ruby의 optparse 보다 훨씬 더 잘 만들어져 있습니다.

반면 ','.join(['1','2']) # => '1,2' 같은 표기는 여전히 헷갈립니다. ['1','2'].join(',') # => '1,2' 처럼 Array에 join 메소드가 있는 ruby가 저에게는 더 자연스럽습니다. python은 int('1') 처럼 함수로 감싸는 형태로 코드를 작성하는 경향이 있는 것 같습니다. ruby처럼 '1'.to_i 가 커서 이동도 적고 직관적으로 느껴집니다. python 린터(autopep8, flake8)는 ruby의 린터보다 관대하다는 인상을 받았습니다. ruby가 과도하게 엄격한 것일지도 모르겠습니다.

python3.6 부터는 숫자에 밑줄을 넣을 수 있게 되었습니다. ruby는 린터에서 1000000 대신 1_000_000 을 쓰라고 안내합니다. github 1000000 은 읽기 어렵고 1_000_000 은 읽기 쉬우니까요. python은 그동안 이 기능이 안 되어서 불편함을 참아 왔는데, 최근 도저히 견디기 힘든 코드를 보고 혹시나 하고 찾아보니 pep-515로 제안되어 python3.6 부터 반영되어 있었습니다. python 그러다 이 pep 문서를 읽으며 java도 같은 문법이 가능하다는 사실을 알게 되었습니다. 그것도 꽤 오래전부터 그렇다고 합니다. oracle

python을 만든 Guido 형이 2009년에 쓴 “파이썬 함수형 기능의 기원"이라는 글도 읽었습니다. blogspot “파이썬이 함수형 언어에서 크게 영향을 받았다고 생각한 적이 없다"로 시작하는 재미있는 글입니다. 그동안 파이썬의 함수형 스타일에서 약간 어색하게 느껴졌던 부분이 있었는데, 이 글을 읽고 어느 정도 이해가 되었습니다.

python3.6 에서 추가된 syntax 중에서는 f-string을 특히 좋아합니다. 그런데 vim 기본 syntax 파일에서는 이 문법이 제대로 지원되지 않고, 숫자의 underscore 같은 것도 제대로 표시되지 않습니다. 새로운 syntax 파일을 설치하니 잘 표시됩니다. github

이미지

python3.4에 추가된 pathlib도 아주 마음에 들어서 기존 코드들을 변경했습니다. python os.path 보다 좋고, 특히 아래처럼 parent 같은 것을 자연스럽게 쓸 수 있다는 점이 좋습니다.

import pathlib
pathlib.Path('/home/sangwook/tmp/vim').parent.parent.joinpath('.vimrc').exists()

vim

ale에 java를 위한 checkstyle 지원 기능이 추가되었습니다. github checkstyle 설정 파일을 손보다가, google의 자바 스타일 가이드는 들여쓰기가 2-spaces 라는 사실을 알게 되었습니다. github 디폴트 파일을 그대로 쓰려고 했는데 결국 4-spaces 로 설정을 바꿔야 했습니다. 왜 구글은 자바 표준을 따르지 않을까 싶은 마음이 들었습니다. 저는 4-spaces 를 좋아하지 않지만, 표준은 따라야 한다고 생각합니다. 아니면 이것이 표준이 아니라 “사실상 표준"인 것일까요? 공개된 장소에 글을 쓰려면 이런 것 하나에도 사실 여부를 확인하고 근거 링크를 달아야 하겠지만, 그런 부담을 놓기로 했기 때문에 그냥 넘어가기로 합니다.

vim에서 _spec.rb 같은 rspec 파일을 편집하다가, 현재 라인이 포함된 테스트만 실행하고 싶어 방법을 찾아봤습니다. 단순히 rspec path/to/a_spec.rb:37 처럼 :줄번호 를 붙이면 된다는 것을 확인하고 vimrc 를 수정했습니다. 그 덕분에 테스트 속도가 아주 빨라졌습니다.

vim을 종료하는 방법을 물어보는 stackoverflow 질문/답변 페이지가 조회수 1백만을 돌파했다고 합니다. stackoverflow 2016년 전체 PV의 0.005% 정도이고, 평일 피크 시에는 시간당 80명 정도가 본다고 합니다.

최근 vim 업데이트는 :terminal 관련이 대부분입니다. github

이미지

판올림하고 직접 써 봤습니다. 신기하긴 한데 tmux가 편해서 결국 쓰지 않기로 했습니다.

이미지

kafka, hbase, rabbitmq

kafka, hbase, rabbitmq에 대한 성능 테스트를 했습니다. 자세히는 kafka 메시지를 소비하고, hbase에 쓰고, rabbitmq에 메시지를 생산하는 것을 하나의 트랜잭션으로 묶어, 유실 없이 초당 최대 5만 개 메시지를 처리해야 한다는 요구사항이었습니다. 유실이 없어야 하니 당연히 at-least-once 구성입니다. 이론적으로는 중복이 발생할 수 있는 구조이지만, 아주 많은 양을 오랫동안 테스트했고 몇 주간 실제 데이터로 운영도 하며 검사했는데 한 번도 발생하지 않았습니다.

성능 테스트에서는 빨리 많은 테스트 데이터를 생성하는 것이 핵심인 것 같습니다. 변수를 바꿔 가며 많은 실험을 해야 하기 때문입니다. 저에게 익숙한 것이 ruby이니 ruby-kafka 를 사용했습니다. github 스레드 수와 flush 하는 버퍼의 크기를 조정해 가며 초당 20_000 개 정도를 produce 했습니다. 그런데 kafka에 느리게라도 produce 해 두고 offset을 earliest 로 가져오면 매번 테스트 데이터를 새로 만들 필요가 없다는 사실을, 회사에서 eric이 알려 주었습니다. 저는 왜 일찍 그 생각을 하지 못했을까 싶었습니다.

이 작업을 하면서 hbase에 대해서도, kafka에 대해서도 배운 것이 많은데, 언젠가 글로 정리할 날이 있겠지 싶습니다.

기타

덩케르크를 봤습니다. 재미있게 봤습니다. 전쟁에 진정한 승자가 있을까, 결국 남는 것은 과부와 고아가 아닐까 하는 생각을 다시 한번 했습니다.

프로세스와 규칙이 많아질수록 안정성은 늘어나지만, 그만큼 혁신의 여지는 줄어드는 면이 있다고 봅니다. 촘촘한 규칙이 균일한 맛의 맥도날드 햄버거를 보장할 수는 있을 것입니다. 하지만 맥도날드에서 일하는 사람은 자신을 요리사라고 생각하지 않습니다. 좋은 요리사는 맥도날드로 모이지 않습니다.

telegram API를 써서 개인적인 메시지를 받고 있는데, 정말 좋습니다. 제가 필요한 것 이상의 모든 것이 구현되어 있고, bot을 만드는 것도 쉽습니다. 아주 만족하고 있습니다. 마크다운 형식으로 메시지를 보낼 수 있고 고정폭 글꼴로 표시되게 만들 수도 있다는 사실을 발견한 뒤로 더 좋아하게 되었습니다.

SNS에서 정적 기록자(static logger) 관련 토론을 봤습니다. wordpress facebook logger를 static으로 했을 때의 단점, 또는 static으로 하지 않을 때의 장점(생성자에 logger를 넘기는 방식 같은 것)을 각각 샘플 코드를 통해 보여 주시면 읽기 좋을 텐데, 하는 생각이 들었습니다. 하지만 이런들 어떠하고 저런들 어떠하리. 저에게는 그리 중요한 관심사가 아니라서 지나가기로 합니다.

박성철님의 글도 잘 읽었습니다. facebook 공감하는 부분이 많았습니다. 싸고 좋은 사람을 채용하려는 노력이 회사에 이익이라고 생각하기 쉬운데, 실제로는 더 많은 규칙, 더 많은 프로세스, 그리고 문제를 조금 덜 발생시키는 기술을 고민하는 쪽으로 이어지는 경우가 적지 않은 듯합니다.

책을 모두 버렸습니다. 정확히는 회사 도서관에 기증했습니다. 다시는 책을 사지 말아야겠다고 생각했습니다. 몇 년 전부터 컨퍼런스는 가지 말아야겠다고 생각한 것과 비슷한 마음입니다.

회사에서 대략 2년 x개월 만에 다시 mesos, marathon, 컨테이너 같은 클라우드 컴퓨팅 인프라를 개발하는 부서로 돌아왔습니다.