ISUCON4 お疲れ様でした
今回の ISUCON 、みんなはどうだったかな?楽しかったかな?ベンチマーカーについての文句?いいよ、こいよ、俺がベンチマーカー実装者だ。
ということで、まずはお詫びを。今回、過去の ISUCON に比べて本当にトラブルが多くて申し訳なかったです。次の出題者になれる機会があるならば、本当にもっとしっかりしたいと強く思っています。本当に、申し訳なかった。
あとは後悔を。正直当日まで実感なかったし、朝の方も徹夜明けであんまわかってなかったんだけど、昼飯が喉を通らないところでストレス過多で死にそうになってることに気づいた。いやーだって考えてみたら今まさに僕よりすごいエンジニアが僕のベンチマーカーを叩き潰すために全神経を注いでるわけですよ。そりゃ胃痛もするわ。もう二度と出題者になんてなりたくないね。
問題についての詳しい解説や、講評なんかは後日 ISUCON 公式ブログの方に乗せてもらえると思うので、そこは省略。
覚えてる限りの今回の大変どころを書いておく。
2つのベンチマーカー
どちらもメイン実装者としてコーディングした。ベンチマーカー実装者は大変なのだが、それ以上に様々なボトルネックを用意した問題の考案、参考実装の用意に注力してくれた mirakui と sorah には頭が上がらない。
予選用と本戦用では設計思想がことなり、ベンチマーカーは違うペルソナを抱えている。予選用ではすでに言うようにリスト攻撃してくるアタッカー、本戦用は無自覚な攻撃者としてのユーザー群、という具合。
予選では対 ISUCON 向けチューニングが火を噴くぜ!状態になっていたので、本戦では『いつもやることを、あたりまえにやる』が僕の中のキャッチコピーとしてずっとあって、いつもやっていることをやればやるだけスコアが伸びる状態にしたかった。Cache-Control のヒントが少なすぎたのは反省しています。ちょっとベンチマーカーブラックボックスすぎましたね。
この先のこと
まぁ振り返りばっかやってもしゃーないので、この先の話をすると、来年は参加者側としてみんなと戦いたい気持ちがある。ていうか優勝経験一切ないどころか、僕は ISUCON3 で Fail 出して終わった経験しかないのになぜ出題側なんだ!!!!と思わなくもない。明らかに参加者より弱い出題者ってのはどうなんだ!いや、お話お受けできて光栄です。
それで、多分次に ISUCON の話をがっつりやるのは moris さんがいっているこのイベント。
また ISUCON Makers Casual Talks というイベントを近々やろうかなと思います。いろいろ話したいことがあるんですよ! 出題をやった側にしかわかんない苦労とかがですね! そういうのをビールを飲みながら赤裸々に話したい! http://d.hatena.ne.jp/tagomoris/20141110/1415592196
ここでもっといろいろ言えたらいいなと思ってます。そんで、そのイベントに向けて一つ約束しておこうと思う。
この Tweet が 50 リツイートされたら各位が社内 ISUCON をできるようになるベンチマーカー FW とベンチマーカーの作り方記事併せて作って公開する #ISUCON
— ハト (@rosylilly) November 10, 2014
おみやげ持ってくよ。
なにはともあれ
すげぇ疲れた。いや、まだやること残ってまして全然終わったわけではないのですが、一応一つの区切りとして。
みなさん、お疲れ様でした。ありがとう。
git-set-mtime を Docker のためにリリースした
Docker のキャッシュは mtime ベースっぽい - 鳩舎 って話は前にしたんだけど、そんでじゃあどうするのっていう解決策がなかったので、 CI サーバー上で都度ソースをひっぱってくるような場合でも Docker のキャッシュを効かせるために、 git-set-mtime を作った。
インストールは rubygems から gem install git-set-mtime
でもいいし、go の場合は go get github.com/rosylilly/git-set-mtime
でもよい。
インストールしたら git set-mtime
を実行すればカレントディレクトリ以下のファイルの mtime をそのファイルが最後にコミットされた時刻にしてくれます。
なんかあったら Twitter で @rosylilly に言うとかしてください。
追記
主に僕が Circle.CI 上で使いたいというのにインストールがだるすぎて萎えたので drone.io からビルド済みのバイナリを落とせるようにした。
ここから Windows, Mac, Linux 向けのバイナリが落とせます。全部 64-bit 環境向け。32-bit は要望来たらやる。
SSHKit within as 順序 意味なし
ruby の SSHKit というのがあって、まぁいろいろ端折ると
on "10.0.0.1" do as :root do within "/tmp" do execute :echo "Hello > log" end end end
みたいなのが書けて、『あー 10.0.0.1
に入って root
に sudo
して /tmp
に cd
して echo
するんだなー』みたいな感じの見た目になるが そんなことは一切ない 。
上記の記述で行われる処理の流れは
cd /tmp
sudo -u root echo Hello > log
の順に行われる。今回の場合は /tmp
なので問題にならないけど、コレが特定ユーザーのホームディレクトリで何かしたいとかの時になると途端に破綻する。
SSHKit は便利で最高!
Docker のキャッシュは mtime ベースっぽい
タイトルそのまんま。
Dockerfile
ではすでに ADD
したファイルの追加なんかはキャッシュされるのでスキップされる
# Dockerfile FROM ubuntu ADD text text
こんな感じの Dockerfile
があったとして、これを2回ビルドすると、2回めの時には
Step 1 : ADD text text ---> Using cache ---> 9839a3ce35ab
みたいな表示になって、キャッシュの内容が使われる。
この後に touch text
をすると
Step 1 : ADD text text ---> a4f64ca64ba7
てな具合に Using Cache
がなくなって、またビルドが実行される。
ローカルだとほぼ問題ない挙動なんだけど、 CI 上でコンフィグを書き出してたりとかするとハマることがおおい(僕は s3cmd の sync ではまった)。
お気をつけて。
github.com のソースコードプレビューでタブ幅8で困っている人向け
.code-body .line, .file-diff .file-diff-line { tab-size: 2; -moz-tab-size: 2; -o-tab-size: 2; }
何らかの方法で上記の CSS を読み込むと2タブになります。4タブがいい人は2を4にしましょう。
go fmt は基本的に問答無用でタブインデントにするので、こういう設定が必要になるけど、考えてみたら各個人の環境で幅を設定出来るタブという選択肢は割とありなのかもしれないと思う。
適当に CLI から pushover に通知送る go app 書いた
https://github.com/rosylilly/pprocess
~/.pprocess.json
に
{ "token": "application token", "user": "user token" }
てな具合で設定を保存して、
$ go get github.com/rosylilly/pprocess $ pprocess -m "通知"
とか送ると、 Pushover 経由で通知が飛ぶ。設定は device
とか sound
も設定できるけど、僕の需要にないので多分動かない。
何はともあれこれのお陰で packer で AMI を作ってる間に洗い物してても終わったら通知が iPhone に来るようになった。なんでもかんでも無差別につながっていくの最高だと思う。