インフラ部⾨で働くC プログラマの話
2016.10.18 KLab勉強会#7
⼭本 雅也 / KLab Inc.
⾃⼰紹介
⼭本 雅也 @pandax381
・2012年5⽉〜
・Kラボラトリー、インフラマネジメント部(兼務)
・C⾔語でネットワークプログラムがちょっと書けます

https://github.com/pandax381
経歴
・前職は⼩さなソフトハウスで7年くらい
・いわゆる「受託開発」をやっていました
・その後、製品事業を⽴ち上げて売り歩いて
・軌道に乗って忙しくなったけど気づいたら営業の⼈
・プログラミングに没頭したくてKLabに転職
絶版!
Q. インフラエンジニアですか?
A. いいえ、プログラマです
本⽇お話しする内容
・⽇常業務
・こんなもの作ってます
・OSSヘのコントリビュート
⽇常業務
⽇常業務
警察活動
・システムコール警察
・シグナルハンドラ警察
・未定義動作警察
・IPv6対応警察
職⼈活動
・tcpdump職⼈
・strace職⼈
⽼害活動
⽇常業務
インフラ部員ですがあまりオペレーションしてません
はじめの頃は環境構築などもやりましたが、最近はほとんどオペレーションしていません。
ひたすら、なんらかのコードを書いたり解析したりしてます。
だいたい⼀⼈で仕事してます
あまり規模の⼤きなプログラムを書かないからかもしれませんが、基本的に⼀⼈で黙々と
コードを書いています。なので、同じ部署の同僚に「最近なにやってるの?」と聞かれるこ
とがよくあります。あと、朝が弱いです。
どんなものを作るのか
⾃分たちが楽をするための便利ツールや監視プログラム、ファイル転送やサービス⽤のデー
モンなど幅広いです。たまに expect で⿊魔術を使ったりもします。⾯⽩そうならなんでも
作りますが、ネットワークが絡まないとあまり興味を⽰さないです。
こんなもの作ってます
こんなもの作っています
・tcpeek
・miruo
・tkhttpd
・AccelTCP
・PackDrop
・rlogd
こんなもの作っています
・tcpeek
・miruo
・tkhttpd
・AccelTCP
・PackDrop
・rlogd
miruo
Pretty-Print TCP session monitor/analizer
miruo を⼀⾔で説明するなら「⾒やすい tcpdump」です。当社⽐10倍です、ISUCON 勢に
オススメです。TCPセッション毎にパケットをまとめて出⼒するため、パケットの流れが格
段に追いやすくなります。また、問題のなさそうなパケットはあえて省略して表⽰しないの
で、興味のありそうなパケットだけが出⼒されます。
$	./miruo	--all	-i	en0	-m	http	tcp	port	80

listening	on	en0,	link-type	EN10MB	(Ethernet),	capture	size	1522	bytes

0001													0.048	|				10.0.0.100:62511	==	125.6.190.6:80								|	Total	21	segments,	13397	bytes

0001:0000	17:27:30.093	|										SYN_SENT	>----S->	SYN_RECV										|	1B5B2031/00000000			78	-	<mss=1460,

0001:0001	17:27:30.099	|							ESTABLISHED	<-A--S-<	SYN_RECV										|	5F9DC421/1B5B2032			78	-	<mss=1460,

0001:0002	17:27:30.099	|							ESTABLISHED	>-A---->	ESTABLISHED							|	1B5B2032/5F9DC422			66	-	<timestamp

0001:0003	17:27:30.099	|							ESTABLISHED	>-AP--->	ESTABLISHED							|	1B5B2032/5F9DC422		572	-	<timestamp

DPI:HTTP:RequestLine	>>>>	GET	/archives/51977201.html	HTTP/1.1

DPI:HTTP:Header	>>>>>>>>>	Host:	dsas.blog.klab.org

0001:0004	17:27:30.125	|							ESTABLISHED	<-AP---<	ESTABLISHED							|	5F9DC422/1B5B222C	1514	-	<timestamp

DPI:HTTP:ResponseLine	>>>	HTTP/1.1	200	OK

0001:****														|																																														|

0001:0016	17:27:30.136	|							ESTABLISHED	<-A---F<	FIN_WAIT1									|	5F9DF149/1B5B222C			66	-	<timestamp

0001:0017	17:27:30.136	|								CLOSE_WAIT	>-A---->	FIN_WAIT2									|	1B5B222C/5F9DF149			66	-	<timestamp

0001:****														|																																														|

0001:0019	17:27:30.136	|										LAST_ACK	>-A---F>	FIN_WAIT2									|	1B5B222C/5F9DF14A			66	-	<timestamp

0001:0020	17:27:30.142	|												CLOSED	<-A----<	TIME_WAIT									|	5F9DF14A/1B5B222D			66	-	<timestamp
PackDrop
インフラ部⾨のプログラマはハードも作ります
通信状態の悪いモバイルネットワークを再現したいという話を聞きつけ「PackDrop」という
ネットワークエミュレータを作成しました。通過するパケットに対し任意の「遅延」と「パ
ケットロス」を発⽣させることで、品質の悪いネットワークを再現することができます。
PackDrop
プロトタイプ 量産型
PackDrop
_人人人人人人人_
> 突然のデモ <
 ̄Y^Y^Y^Y^Y^Y ̄
PackDrop
ラズパイで作るネットワークエミュレータ(前編)
ラズパイで作るネットワークエミュレータ(後編)
rlogd
ログの収集に syslog(syslog-ng)を使ってきたが、コンフィグの⿊魔術化などいろいろつ
らかった。候補として fluentd を検証したが、諸々の事情で導⼊を⾒送ったので欲しいもの
を⾃分で作った。
Better syslog を求めて開発したログ収集システム
fluentd を使わなかった諸々の事情
・”ruby: command not found”
・メモリリークと思われる挙動に遭遇(当時バージョン)
・アプリケーションレイヤで ACK のやり取りをしていない(当時バージョン)
 → 絶妙なタイミングで TCP が切断されるとログが消失してしまう可能性があった
rlogd
参考にした部分
・タグベースでのログ振り分け
・input / output のプラグイン機構
・バッファリングと再送機構
・コンフィグ構⽂
その他の特徴
・省メモリ(10MB程度)
・書き出し側をブロックさせない
・ログを消失したら切腹 😇
fluentd を参考にC⾔語で実装
<source>
type forward
bind unix:///var/run/rlogd/rlogd.sock
</source>
<source>
type forward
bind 0.0.0.0:10381
label forwarded
</source>
<match example.**>
type forward
target 127.0.0.1:10381
buffer_path /var/run/rlogd/buf/
</match>
<label forwarded>
<match example.acc.**>
type file
# time_format %s
# format $time $tag: $record
path /var/run/rlogd/logs/example/%Y-%m-%d/acc_%H%M.log
</match>
<match example.err.**>
type file
path /var/run/rlogd/logs/example/%Y-%m-%d/err_%H%M.log
</match>
<match example.app.**>
type file
path /var/run/rlogd/logs/example/%Y-%m-%d/app_%H%M.log
</match>
</label>
rlogd
app1
app2 rlogger
rloggerd
rlogd
rlogd
app1.log
app2.log
PIPE
UNIX
SOCKET
UNIX
SOCKET
UNIX
SOCKET
TCP
HOST A
HOST B
OSSへのコントリビュート
OSSへのコントリビュート
インフラに限らず、KLab では多数の OSS を利⽤しています。KLabが開発して公開してい
るものもありますが、他のプロジェクトの成果を利⽤させてもらっているケースが圧倒的に
多いです。トラブルに⾒舞われた場合にはコードを解析して修正することも珍しくなく、開
発元へのフィードバックを積極的に⾏っています。
他にも、⾃分が興味を持ったプロダクトへのコントリビュートを業務として⾏っています。
OSSへのコントリビュート
雑に⾔うと、組み込みや IoT デバイス向けに C で実装された fluentd のサブセット
・IPv6 対応と BSD 系 OS への移植
・プラグインの実装(in_mem / out_stdout)
Linux を NAT64 ゲートウェイとして機能させるためのカーネルモジュール
・Netfilter の API が Kernel 4.1 で変更になっていたので対応させた
・namespace 周りの処理でクラッシュしそうな箇所があったので修正
Linux でロードバランサ(LVS)を構築する際に IPVS と組み合わせて使う
KLabでは keepalived-extcheck.patch という独⾃パッチを作って運⽤中
・この独⾃パッチを全⾯的に書き直して本家へ統合を提案(マージ済み)
・別件で、keepalived のプロセスが増殖してしまう問題を修正中(WIP)
まとめ
まとめ?
ネタはたくさんある
「誰かやってくれないかなぁ(チラッ)」という依頼のようなものはありますが「これをや
てください」と何かを指⽰されたことはありません。常にネタには困らないくらい、インフ
ラ部⾨にはCプログラマの活躍出来るネタが転がっています。
英語はできた⽅がいい
有名なプロジェクトはだいたい英語圏の⼈達が開発しているのでやりとりは当然、英語にな
ります。僕は英語が絶望的にできないので、プルリクエストのメッセージを書くのに⼀番苦
労しました。
アウトプットは⼤切
好き勝⼿やらせてもらってるけど、アウトプットをちゃんと出せないとおそらく評価が最低
な感じになると思います。業務と関連薄いことやったら必死にブログ書いてはてぶを稼いで
アリバイを作りましょう。この発表もアリバイ作りです。
ありがとうございました

インフラ部門で働くCプログラマの話