Linux 게임 서버 성능 평가 (eBPF + BCC)

어제 발표에 썼던 슬라이드.
어제 발표에 와주신 분들 감사합니다.

Linux 커널의 내장 트레이싱 기능인 eBPF 와 이를 위한 BCC 툴킷을 써서 동작 중인 프로세스를 분석해서 성능 문제를 찾는 방법을 설명했다.
머지 않은 미래에 안드로이드 성능 측정도 이걸로 할 수 있을 듯하니, 서버 뿐만 아니라 안드로이드 기기에서 개발하는 분들도 한 번 보시라.

eBFP +BCC 는 간단히 요약하면, python (혹은 go, lua) 으로 통계 처리 및 초기화, 몇줄 안되는 C코드로 커널 내부에서 후킹/통계 수집을 하고, 수집할 수 있는 범위가 넓어서 (커널 함수부터 유저 함수까지) 성능 분석 / 디버깅 쪽에 유용한 툴이다.
최신 커널이 필요하긴 하지만 재시작/빌드없이 측정할 수 있다는 점에서 매우 매력적인 툴이다.

그리고 예제로는 C++ HTTP API 서버를 만들었다. 하재승 군이 만든 Crow 와 이것의 사촌쯤될 데이터베이스 래퍼 CrowDB 를 썼다. 내가 쓴건 아직 비공개 버전.
덕분에 C++ 1y 로 매우 편안하게 짰다.

iPhone 배터리 교체

지난 설에 양가 방문하고 나니 도저히 이대로는 못 버티겠다 싶어서, 3월 초에 배터리 교체를 받았다. 사용 중인 아이폰 6S는 특정 시기 생산품에 대해서 무상 교체를 하는데, 그 대상이라 공짜로 교체 받긴 했다.

가장 가까운 서비스 센터가 판교 일렉트로 마트 안에 있어서 휴일에 판교역에 갔다와야 했다. Orz.

배터리 교체는 생각보다 얼마 안걸렸고 — 대략 20분 내외? — 잠시 대기 줄에서 기다린 시간이 한 15분 정도였던듯. 근데 이건 문열자 마자 뛰어가서 그렇고, 실제로는 이보다야 더 걸리겠지.

교체하고나니 배터리가 좀 더 오래 가기는 하는데, 체감 상으로 더 컸던 부분은 트위터 실행 속도가 빨라졌다 정도? 배터리 충전량 줄면 성능 줄이는게 생각보다 더 컸던 듯 싶다.

코코넛 배터리에도 이제 충전 잔량이 크게 나온다 신난다(?).

Screen Shot 2018-03-17 at 09.27.39

리뷰: 콘클라베

로버트 해리스 의 장편 소설. 흔히 팩션 이라고 말하는 장르의 소설이다. 내가 본 상당 수의 팩션은 로버트 해리스 작인듯 – 이니그마, 당신들의 조국, 고스트 라이터, 아크엔젤, 어느 물리학자의 비행 등등. 덤으로 키케로 3부작 (이 이름이 맞나?) 도 있고.

제목에서 바로 알 수 있듯이, “교황 선종” – “새 교황 선출” 까지의 짧은 기간을 배경으로 한 소설이다.
직전 몇 대 교황 실명이 나오긴하지만 소설 자체는 정말로 픽션. 배경과 이전 교황이름만 현실에서 가져왔다.

콘클라베 관해서는 뉴스 단신에 나온 정도만 알고 있었는데 — 투표 결과 선출하지 못하면 검은 연기, 선출하면 흰 연기가 난다 정도? — 여러모로 궁금증을 충족시켜주는 스토리라인이었다.
읽다보면, 내가 왜 종교가 없는지도 되새김질 좀 하고, 현실 의 천주교회가 끌고가고 있는 추문들도 한 번 들춰보고. 그리고 로버트 해리스 소설의 결말들을 그다지 맘에들어하지 않는데 – 이니그마 정도만 맘에 들었음 – 이건 꽤 괜찮았다.

다만 이거 전자책으로 나오는 줄 모르고 종이책 나오자마자 사서 책장 공간이 처치 곤란 Orz.

Jenkins 2.x DSL 적용기

설 직전에 사용 중인 jenkins 서버가 버전이 올라갔다. 그리고 악몽(?)의 시작…

대략,

  • 플랫폼 별 병렬 빌드를 위해 사용하던 buildflow 플러그인 결과물이 사라지는 현상
  • 프로젝트 설정에서 buildflow 스크립트를 확인하거나 편집할 수 없는 현상

이 생겼다.

근데 최악의 문제는 아니었던게, 결과물이 보이지만 않고 서버 머신의 디스크에는 남아있더란; 비슷하게, buildflow 스크립트도 display: none 로 처리하고 있어서 스타일 수정하고나니 보이긴하더라.

Jenkins wiki에서는 새 DSL인 pipeline plugin으로 넘어가라고 한다. 그래서 이전 작업을 시작;

  • Buildflow 의 병렬 빌드에 해당하는 parallel 태스크는 있다.
  • Parameter 넘기는게 미묘하게 다르긴한데 — 어차피 groovy 이긴 함 — 약간의 삽질 후에는 성공
  • Artifact 복사해올 때 이전에는 buildflow toolbox 를 썼는데, “Copy Artifact Plugin” 을 설치하고야 처리할 수 있었다.
  • Gerrit trigger 메뉴가 없어서 당황; Gerrit trigger 를 클릭하고, 추가로 뜨는 gerrit 주소 설정을 추가하고 나서야 동작한다.
  • Artifact archive 관련해서, 패턴 매칭에 실패하면 오류 처리한다. [이건 이미 해결된 이슈로 있더라. 오류 처리 끄는 플래그가 있음](https://issues.jenkins-ci.org/browse/JENKINS-38005)
  • Downstream 프로젝트들을 빌드 성공 후 트리거해야하는데, 트리거하고 종료하는게 없어서 ?! 했는데, build job 패러미터로 wait: false 를 주면 되긴하더라.

이렇게 작업일 1일+를 날리면서 느낀 좋은 점을 요약해보자면.

  • 새 DSL 로 모든 플러그인 / 작업 기능을 내보내고 있어서 설정 백업이나 신규 버전으로의 이전 작업은 어느 정도 편하게 할 수 있을 듯 하다.
  • 심지어, DSL 을 Jenkinsfile 이란 이름으로 저장소에 포함하는 것도 가능하다.
  • 새로운 선언형 (declarative) 와 기존의 스크립트스러운 빌드 방식을 모두 포함한다.
  • 이 기반으로 작성하면 기존보다 훨씬 나은 시각화를 제공한다.

물론 좋기만 할리가.

  • 새 DSL은 만들었는데, jenkins 없이 이걸 시험해볼 방법은 없다. 다만 replay 기능을 쓰면 점진적으로 문제를 찾는건 가능하다. 빌드 시간이 길다면야 이걸로 나아지는게 많지 않긴 한데;
  • 선언형과 절차형 모두 지원하는데, 양쪽을 동시에 쓰면 애로사항이 꽃핀다. 특히나 모르고 문서 뒤지던 초기에 이 차이를 모르고 튀어나오는 groovy / JVM exception 에 많이 당함.
  • Jenkins 2.x + pipeline 으로 넘어가면 과거로 돌아갈 수 없다. 아주 간단한 예로, 설정 파일을 **XML 1.1** 로 바꾼다. …대체 왜? 1.1 쓰는거 처음 봄. 다운그레이드했다가 잠시 지옥을 봤다.

여하튼; 새 DSL 부터 쓰는 사람은 꽤 편할지도? 나는 크게 당했지만.

Docker 로 Linux 없이 Linux 개발하기

지난 달 말 — 이미 10월 말인 것 같지만 다 기분탓 — 발표에 썼던 슬라이드.

Windows + VisualStudio / macOS + Nuclide 환경에서 내부에 같이 띄운 docker container에 접근해서 C++ 프로그래밍을 디버깅 하는 내용을 다뤘다. 기록 차원에서 블로그 글로도 남긴다.

리뷰: “코스믹코믹: 빅뱅을 발견한 사람들”

cosmiccomic

대략파인만이나로지코믹스같은 느낌의 책이다. 로지코믹스 때는 좀 덜했는데, 이 책과 파인만은 내용이 좀 비어있는 기분. (아래 사진이 두 책)

feynman-logicomics

그리고 전자책으로 구매했는데 폰으로 보기엔 좀 불편해서 결국 데스크탑으로 옮겨서 봄 — 종이책 살걸 ㅠㅠ.

개략적인 얼개는 빅뱅이론의 나오기까지의 이론적/실험적 증거를 찾아가는 여러 사람의 얘기를 좀 가볍게 다룬다. 예를 들어

같은 얘기를 모아서 빅뱅 이론이 성립되어간 과정을 이론/실험적 증거로 얘기한다. 잘 읽히고 내용도 꽤 흥미롭다.

근데 전개를 단편적인 에피소드 나열에 의존하는 거 + 너무 짧고 얕게 쓴 건 좀 불만이다. 여러모로 미묘한 책. 로지코믹스에는 만족하고 + 파인만 책에는 만족하지 못했다면 비추. (파인만 책 보다도 내용이 없어…)

Docker + C++ IDE 개발환경 꾸려보기

Windows / macOS 용 docker를 이용하면 VM을 따로 띄우지 않아도 로컬 환경을 리눅스 개발 환경처럼 쓸 수 있다.
전에도 한 얘기지만, 툴은 가능하면 해당 OS 용의 GUI 도구를 활용하고 싶은게 내 심정.

그래서 (?) 요즘 나오는 좋을 툴들을 써서 Windows / macOS를 쓰는 기기에서 docker + linux 개발환경을 해당 OS 용 IDE 로 개발하게 꾸려보았다. (컴파일은 linux 컨테이너, 디버거 UI는 호스트 OS의 IDE를 쓴단 소리)

Windows

Widows 의 VisualStudio 확장 기능으로 linux  개발을 지원하는 Visual C++ Tools for Linux 라는게 있다. 지난 2016-09-06 에 업데이트.

이걸 써서 같은 컴퓨터에 띄운 docker 컨테이너에 접근하면, 디버거까지 붙여서 돌려볼 수 있다.
하재승 군의 crow 예제 하나를 디버거 붙여보면 잘 돈다.

vs-debugging

다만 고칠게 좀 많다:

  • Docker for Windows 의 volume 설정이 좀 이상한 것
  • 권한을 추가로 주지 않으면 잘 안 도는 것 (디버깅)
  • 빌드/디버깅/빌드 결과물을 한땀한땀 입력해야하는 것 (…)

macOS

macOS 용으론 Facebook 의 Nuclide 가 있다. 여기서도 crow 예제를 돌려보았다.mac-nuclide-io

macOS 에 띄운 docker 컨테이너에서 프로세스를 띄우고, lldb (GDB가 아니라…) 를 띄워 디버깅하는게 가능하다. 다만 의존성 걸린게 많아서 내가 만들어본 역대 최대 크기 (1.1 GiB) 짜리 docker 이미지가 나오더라; 용량은 차치하고, Docker for macOS 쪽이 volume 지원같은게 낫긴하지만 이쪽도 문제는 한 바가지긴 하다.

  • 설정을 한땀한땀 넣어야한다. (VS 쪽보다 아주 약간 편함)
  • 깔아야하는게 한 가득 (atom, nuclide, npm, clang, llvm, lldb, … 그리고 clang, llvm, lldb 에 대한 python 래퍼)
  • 테스트 한다고 썼던 ubuntu 16.04 에선 라이브러리 내의 경로가 잘못 박힌게 많아서 고쳐써야할 부분도 많다 (ubuntu 14.04 쪽도 크게 다르지 않으리라 생각)

이런 내용을 포함해서 이번 주 수요일 (2016-09-28) 에 넥슨 코리아 지하에서 기술 세미나를 합니다. 궁금하신 분은 와서 보시길.

Linux 용 데스크탑 앱 훑어보기

요즘은 web 대신 app 으로 나오는게 유행인 것 같기도 하다. 모바일만 그런게 아니고 데스크탑도 약간 그런 것 같은데, 내가 쓰는 툴 중에 자주 쓰는 것 몇 가지도 이런 식.

이 중 두 가지가 내게 익숙한 .deb 1 형식이길래 두 가지를 뜯어봤다. 하나는 slack 이고, 나머지 하나는 WordPress.com 이다.

dpkg-deb -R 명령으로 아카이브된 것을 까보면, 대략 다음과 같은 파일들이 있다:

  • desktop 앱을 위한 파일들 (wpcom.desktop, slack.desktop)
  • node_modules (와 .asar 파일들)
  • elctron
  • libffmpeg.so

특이하게도 slack 쪽엔 cron.d 룰이 있었는데, 여기서 apt 저장소를 설정한다. 이건 좀 이상한듯. 왜 설치 후 스크립트 (postinst) 를 쓰거나, 다른 오픈소스 도구처럼 저장소 자체를 안내하는게 더 좋아보이는데 대체 왜 이럴까. 여담으로, package cloud 란 서비스를 쓰더라. 미리 알았다면 나라도 쓸 것 같이 생겼다 (apt, yum, pypi 저장소랑 몇 가지 더를 지원하는듯)

리눅스 데스트탑이니, GNOME desktop app 형식을 쓴다. 그리고 리눅스 전용으로 만들진 않을테니 electron 을 이용해서 만든다. 자연스럽게 (?) 묶는 것도 electron archive 형식 으로 처리한다.

Atom/Electron 기반의 앱들은 이제 정말 주류가 된 것 같다. MS의 Visual Studio Code나 Facebook 의 nuclide.io 도 그렇고. WordPress 는 PHP를 탈피해서 API 기반 + JavaScript 로 관리자 페이지 다시 만든다고 시작한 Calypso 프로젝트 결과물로 데스크탑 앱을 내놓기 시작했던 것 같다. Slack 쪽도 이번 데스크탑 앱 베타부터 프레임웍을 바꾼 모양…

플랫폼이 파편화되면서 오픈소스 도구나 프로그램들 — 특히 기업이 직접 개발하거나 지원하는 — 쪽이 크로스 플랫폼 라이브러리/프레임웍을 더 많이 쓰다보니 역으로 Mac/linux 데스크탑 환경 쓰는 나같은 사람에겐 더 편한 세상이 되어가는듯.

Update: libffmpeg.so 관련 – @lqez 님 제보로 업데이트 electron 이 chromium에 의존하고, chromium 이 proprietary codec 처리 때문에 libffmpeg 에 의존해서 그렇다 합니다.

 


  1. 데비안 패키지의 파일 형식; 회사에서 해당 형식으로 패키징 할 일이 잦아서 익숙하다. 

Interop Madness

클라이언트 서버간 암호화  관련해서 개념 증명 + 몇 가지 성능 측정을 해야해서 몇 가지 언어 + 플랫폼에서 libsodium 1 을 호출해봤다. 그 와중에 겪은 일 정리.

C++

이쪽은 평범한 C/C++ 인터페이스니 문제 없이 끝.

Python

위에서 구현한 부분을 클라이언트 쪽 구현을 (빨리) 만들어서 테스트하는 작업을 했다.

여기서부터 문제가 생기기 시작. Ubuntu 16.04 (xenial) 이 제공하는 libsodium 래퍼가 python-nacl 2 인데, 써보니 내가 쓰려는 함수가 여럿 없다. 특히 crypto_stream* 류 함수가 없더라. 그래서 다른 래퍼가 있나하고 PyPI 에서 몇 가지 써보고는 빠른 포기.

이제 cffi 를 쓸 타이밍. C 코드로 정의한 함수를 변환해서 만든  .py 파일로 동적 라이브러리 (.so, .dll, .dylib) 에서 가져오는 방식을 썼다. 3 예~전에 ctypes 로 로딩할 때 괴로웠던 부분이 확실히 줄어들었다. ABI 대신 API 수준에서 접근하는 차이는 정말 컸다. cdata의 buffer 인터페이스도 쓸만했다.

cffi 로 libsodium 에서 필요한 함수들을 가져다 쓰기 시작한 이후로는 금방 일이 정리.

…하지만 이 시점에선 어떤 비참한 미래가 기다리는지 모르고 있었다. (?)

C#

(나로써는) 슬프게도, 클라이언트 쪽 구현 중 하나는 C#으로 해야한다. (Unity3d + mono) 게다가 이건 여러 플랫폼을 지원해야 한다:

  • Unity Editor: Windows, MacOS
  • Android: 다행히도 ARMv7만. Unity가 ARMv6는 지원하지 않는다 (?)
  • iOS: 기기 + 시뮬레이터에서 모두 돌아야 한다.

Windows는 (내가) 당장 쓸 머신이 없어서 일단 미뤄두고, 나머지에 대해서 잘 도는지 시험하기 시작. 꼬박 2일 걸린 것 같다 — 생각해보니 절반은 C++ 기반인 cocos2d 랑 같이 처리하는 것 때문이었던 것 같기도?

우선 각 플랫폼 별로 크로스 빌드를 시도…해야하나 했는데, libsoidum 저장소에 플랫폼 별 빌드 스크립트가 있다. 4 iOS/Android 쪽에 내가 쓰려던 함수 중 몇 개가 빠져서 컴파일 플래그를 조금 고친 것 말고는 별 일 없이 진행. 그리고 Unity 에서 (native) 동적 라이브러리를 어떻게 가져가나 고민했는데 경험 많은 동료분이 설명해주셔서 매우 간단한게 통과.

대략,

  • DllImport 로  C에 있는 함수들을 CLR 쪽에 노출하고
  • C# 코드로 이 함수들을 래핑하고
  • 다시 이 함수들을 써서 실제 개발자가 쓸 고수준 API로 바꾸자

라는 방향으로 진행했다. 에디터(=랩탑 위)에서 잘 도는걸 보고 android  기기에 올리기 시작. 왠걸, 초기화 (=sodium_init()) 은 성공했고 몇몇 초기화도 했는데, 그 이후에 호출하는 함수에서 크래시 (SIGSEGV).  (당연하게도) 콜 스택은 native code에서 죽는 것.

원인을 추측하기 시작:

  • C 함수 원형을 잘못보고 옮겼는지 확인 시작. C는 타입 무시하고 심볼 이름만 보니 내가 잘못 옮겼다면 크래시할 수도 있으니 우선 여길 의심하고 C 함수 원형과 하나씩 대조. 별 이상 없어 보였다 (불행의 단초)
  • 크로스 컴파일을 잘못했는가 확인: 생각해보니 C/C++ 로 올렸을 때는 잘 돌았다 (…)

…대략 정신이 멍해져오는데 다시 함수 원형을 보다가 불현듯 깨달은 사실:

C 쪽의 size_t 를 C#의 ulong 으로 지정했는데 Unity + ARMv7 은 32bit ABI를 쓰니 uint 여야하는 것. Orz.

그래서 이걸 iOS / Android 플래그로 ulong / uint 처리하게 했다가, iOS도 아직 32bit인게 남아있는 걸 보고는 (iPhone 5 및 그 이전 + iPhone 5C) UIntPtr 로 처리하고 강제 캐스팅하게 수정해서 마무리했다. 그러고나니 잘 돌더라.

 

3줄 요약

  • ABI 맞추기는 삽질이다. 어떻게든 API 수준으로 해결할 수 있는 법을 찾자 — python의 cffi 처럼. 아니면 기계적으로 처리할 방법을 찾아야?
  • (부득이하게) ABI를 맞춰야 한다면 가능한 arch 목록을 잘 확인하자. C/C++에서 편했던 platform dependent type들이 대재앙
  • 여러 플랫폼 지원하는 라이브러리는 정말 인생에 도움이 된다. 잘 쓰고나면 널리 알려줍시다 (?)

 


  1. libsodium 페이지. 현 시점에 적합한 대칭키 암호화 + AEAD, ECC 함수들, system random source 를 래핑한 함수, side channel 공격을 피하는 비교, 해시, … 등등을 제공하는 잘 만든 라이브러리. 인터페이스도 보고 바로 쓰는게 그다지 어렵지 않다. 
  2. GitHub 저장소. libsodium 이 fork(?)한 NaCl 을 래핑한 것 같은 이름이지만 libsodium 을 래핑한다. 
  3. API 수준에서, 소스 코드 밖에서 정의 부분을 참고해서 작성했다. 
  4. 저장소의 dist-build 디렉터리 의 스크립트들이 이에 해당한다. 

Docker for Mac 베타 사용기

연휴 내내 하루 빼고 일하다가 드디어 짬이 났다. 그래서 한 달 반쯤 전에 공개된 Docker for Mac 을 써보기 시작. 베타용 토큰도 지난 주에 받아서 사실 그 전엔 시간 났어도 못 써봤겠지만.

일단 내 희망 사항인 linux 툴들과 Mac 용 GUI 툴을 같이 쓰는 걸 시도해봤다. 대략 docker volume 으로 로컬 디렉터리를 컨테이너에 마운트해서,

  • MacOSX 환경에서 GUI 툴을 가져다 쓸 수 있을 것: 예를 들어 git mergetoolp4merge 를 쓴다거나
  • linux 몇 가지 distro. — 특히 ubuntu 14.04/16.04, CentOS 6/7 — 에 대해서 빌드 환경을 쉽게 불러내서 사용할 수 있을 것: 예를 들어 ubuntu 14.04 gcc4 에서 빌드 + 테스트해보고 + centos 6 (w/ devtoolset) 에서 빌드 + 테스트해보기 등.

이었다.

VirtualBOX 를 중간에 껴 넣는 대신, xhyve 를 써서 상대적으로 더 빠를 것 + volume 이 제대로 동작할 걸 기대했다. 대략 기대한대로 돌았는데 …

CentOS 7 컨테이너에서 빌드를 시작했더니 끝나질 않아서 activity monitor 를 열어보니 상태가 심각하다:

something-wrong

Docker volume 을 위한 구현체인 com.docker.osxfs 가 CPU 를 다 잡아먹고 있다. Docker volume 아닌 곳에서 빌드해보면 그 차이가 더 뚜렷함. (com.docker.xhyve 가 CPU를 다 쓴다)

something-acceptable

VMware Fusion 도 그러던데, Docker for Mac 도 CPU core 수 최대 값을 4개로 잡는다 — 12″ 맥북에서 무슨 만행을… 이것도 2개로 설정. (기본 값이 2개였는데, 메모리 늘리면서 생각없이 늘려서 Orz)

docker-setting-cpu-cores

설정 자체는 원하는 방향으로 가능해졌지만, docker volume (=osxfs) 관련은 앞으로 더 패치된 후에 성능이 나아지길 기대해야. 아니면 지금처럼 build 디렉터리를 docker volume 외부에 두는 식으로 해야할 것 같다;;;

요약

  • GUI 는 Mac에서, 개발툴은 linux 에서 이용하는 (내가 생각하는) 이상적인 휴대 작업 환경이 가능해 짐
  • boot2docker 등과 달리 정식으로 docker volume 을 지원하고, OSX 에서 직접 hypervisor 를 제어하는건 좋음 (메모리, 디스크, …)
  • osxfs 를 이용한 docker volume 의 성능 문제는 개선되지 않으면 못 쓸 정도