Isucon2 参戦記（破）
決戦、渋谷ヒカリエ
当日寝坊してしまうという笑えない展開もなく、受付け開始と同時に入館し、すぐに @methane と合流。開始時間まで１時間くらい余裕があったので「こんな問題だったらここをこうしよう」といった感じで軽く打ち合わせしていました。
そして、@methane が共同作業用にAWSのインスタンスを上げてくれたので、そこに recaro のソースを持ってきたりしていたら、ちょうどいい時間に。
NHNさんからレギュレーションや注意事項の説明があり、いよいよ #isucon2 スタートです。
事前の打ち合わせ通り、僕はベンチマーク用のツールを走らせながら、どんなHTTPリクエストがきているのか miruo を使って確認していました。（僕の拡張した DPI 機能で、tcpdumpしながら HTTP のリクエストとレスポンス内容が見れるんだよ！便利だよ！）
この解析作業より「jqueryのソースファイル地味に重いなぁ」とか「チケットの画面時間掛かりすぎ」「POSTリクエスト多いな」とか、ボトルネックになっていそうなポイントや「あ、gzip 受け入れてもらえそう」といった情報が見えてきました。@methane も「チケット画面がヤバそう」という認識で「チケット画面の生成は SSI にして recaro でやってしまおう」「静的ファイルは事前に gzip 圧縮して返すようにしよう」ということが決まりました。
そんな訳で、僕はまず recaro の改造に取りかかることに。ここはもうひたすら実装するだけなので、あまり書くことありませんが、AWS上でこれらの実装が終わったのが、だいたい 13:00 頃でした。
時間的にもそろそろ動作確認しなきゃいけない感じで、実際に isucon 環境で動かして様子を見ることにしたのでした。
通らない、コンパイル
開発環境のAWSから isucon サーバへソースを持ってきてコンパイル開始。が、いきなりコンパイルエラーが発生。一瞬、冷やっとしたものの「error: implicit declaration of function」が多発していたので、これはヘッダファイルの include 漏れだろうと判断し、必要なヘッダファイルを追加して再度コンパイルを実行。
しかし、エラーは半分くらいに減ったものの、まだコンパイルに失敗しています。エラー内容を見てみると「error: too few arguments to function」が発生していて、workqueue関連のマクロへの引数が足りていない様子。DECLARE_WORK と INIT_WORK の仕様が kernel 2.6.20 あたりで変わっているのですが、僕たちが事前検証していたのは CentOS 6.3 の kernel 2.6.32 と Debian wheezy の kernel 3.2.0。これは、古い仕様に合わせて書き直さなければなりません。
幸い、修正箇所は極僅かで、バグ混入の心配もない程度ですみました。ただ、僕はここで大きな不安を覚えてしまいました。この一件で、使われているカーネルのバージョンは、少なくとも 2.6.20 以前ということになります。2.6.20 とか 5 年も前にリリースされたバージョンで、その頃のカーネルの仕様とか制限など当然すぐには分かりません。
（いまになって考えると、そんな大事なこと最初に確認しとけよって話なんですけど）恐る恐る「uname -r」したところ、なんとそこには「2.6.18」の文字ががが・・・
事前情報で OS は CentOS とは聞いていたけど、まさかの 5 、、、#isucon2 恐るべし。。慌てて @methane にこのことを伝えると、どうやら他の作業でも一部苦戦している様子。
いろいろヤバそうだなぁと思いつつも、いまの僕にできることは recaro を動くようにすることだけなので、気を取り直し、再度コンパイルを実行。
僕 > # make
gcc > つ recaro.ko
僕 > ktkr！
僕 > # insmod recaro.ko
insmod > error inserting 'recaro.ko': -1 Unknown symbol in module
僕 > ごめんなさい、こういうときどんな顔していいかわからないの・・
isuconの神様 > 笑われればいいと思うよ
・・・えっと、いまでこそネタとして茶化して書いてますが、そのときはもう頭の中真っ白で放心状態。。
エラーメッセージを頼りに kernel のソースを確認してみると、どうやら kmalloc で slab からメモリを確保する処理で静的なサイズチェックが走っているらしく、それに引っかかっている模様。よくみるとコンパイル時点で warning も出ている。
ぐぬぬ、、これは参った。大きなサイズのメモリが確保できないとなると、根本的に作りを変えなければならないので、どうしようもない。もう recaro を動かすのを諦めるしかないのか・・・
＊ kmallocじゃなくてvmalloc使えばいいんじゃね？という発想は、冷静さを失っていた当時の僕にはありませんでした、、
カーネルの選択を
ここで、@methane にもいまの状況を伝えて、recaroを使わない方針に切換えるか相談することに。そして、二人の出した答えは「kernel を入れ替えよう」でした。recaro を使わなければ二人で参加した意味がない。薄々、もうこれしかないかなと考えていましたが、kernel の入れ替えは本当に最終手段です。#isucon2 のルールで、Dom0 からの支援は一切行われないため、万が一ミスって起動しなくなってしまうと、サーバを１台潰してしまうことになります。ですが、recaro を動かすためにはもうこれしかありません。
ただ、カーネルを入れ替えるといっても、この時点で 15:30 を回っています。残り時間を考えると、いまからカーネルを再コンパイルしていると終了時間までに全ての作業を終えられるかどうか微妙な時間。そして、CentOS 5 から 6 へは「yum upgrade」でバージョンアップできない。さぁどうする。
こういった状況でこそ冷静な判断をしなければならないのですが、僕は愚かにも「ELRepo あたりから比較的新しめのカーネルもってくればいいんじゃね？」と安易な考えをもち、それを実行してしまいます。
ELRepo から新しいカーネル（確か 3.0.48 だったかな）を投入し、grubの設定をして、いざ再起動！
静止したカーネルの中で
「再起動するよ・・本当にするよ・・」僕は reboot と入力した後、Enterキーを押すまでに、5回くらい @methane に確認していたと思います。「まぁこれしか手はないし最悪ダメでもしょうがないよ」と優しい言葉をかけてくれる @methane。その言葉に支えられて、祈るような思いで Enterキーを叩いて再起動をかける僕。再起動の処理が走ると同時に、ping でネットワークの疎通を確認。早く reply 返ってこい！と願うばかり。
しかし、現実とは残酷なもので、幾度待てどもカーネルを入れ替えたサーバが起動してくることはありませんでした。
アニメなら、ここでサーバが暴走してシンクロ率400%とか超えちゃうところですが、現実とは本当に残酷です。
「シンクロ率、０。#isucon2 参加者たる、資格なし。」
せめてISUCONらしく
結局、僕のせいで貴重なサーバ１台潰してしまった訳ですが、流石にこれ以上サーバを潰す訳にもいかないし、なにもできずに採点不能とかなったら会社に帰れなくなってしまうので、recaro を使わない方法で、再度仕切り直すことにしました。
この時点で、残り2時間を切っていたはず・・・（つづく）
