Isucon2参戦記(Q)
男の戦い
recaro が使えないことになってメゲそうになったものの、 やれることがまだまだ残っているのに何もせずに負けるわけにはいきません。 「逃げちゃダメだ逃げちゃダメだ」と呟きながら、残り2時間弱でできそうなことは 全部やってしまいます。
@pandax381 に、リバースプロクシで静的ファイルを直接返す設定、死んだ Web サーバーの 代わりにリバースプロクシと同じサーバーとDB サーバーでWebアプリを動かす設定をお願いして、 Webアプリのチューニングを進めます。
Webアプリ側でやったことは、 (1) Webサーバーの meinheld 化, (2) ページキャッシュを アプリから返すのでその高速化, (3) マルチプロセスの対応とチューニング, です。
(3) のマルチプロセス対応ですが、もともとアプリはシングルプロセスで動かすつもりで、 状態やページキャッシュを全部アプリの変数に持っていました。これをマルチプロセスで 動かすためには、POSTリクエストが来た時に全プロセスで状態を同期しなければいけません。
これを実現するために Redis の Pub/Sub 機能を使いました。 (ちなみに、Redis も一発では コンパイルが通らなくて、 yum install しました。) 誰がどの席を買ったのかという情報を pub/sub で全プロセスに通知して、データの整合性を とります。ですがこの Pub/Sub は非同期なので、チケットの購入をするときに同一のチケットを 並列で購入させないために、その部分は MySQL を使う状態のままでした。 (ソース)
終わる競技時間
リバースプロクシ＋マルチプロセスのアプリという構成ができたのですが、まだテストが Failします。その時は気づかなかったのですが、リバースプロクシを Apache から nginx に 切り替えたためにアプリケーションに来るリクエストの並列数がデフォルトの構成より増えて しまったのがテストがFailする原因だったのだと思います。
WebサーバーのCPU使用率が100%に張り付いているのでひたすらWebアプリのチューニングをすすめ、 テストをPassする確率が上がった所で再起動してもちゃんと動くかの確認などの最終設定を行いました。
最終的にGETの処理数は、リバースプロクシが直接ページキャッシュを返す構成が取れなかったにしては結構
良い数値を出していたものの、肝心のチケット購入のチューニングは RAND() を消しただけだったので、
成績はあまりよくありませんでした。
(後でみたらインデックスがめちゃくちゃで、それをチューニングしたらチケット購入の速度が4倍くらい早くなりました。)
双龍、心、重ねて
今回の #isucon2 では、 recaro が使えなかった以外にも、状況把握や判断ミスが多く、全然能力を 発揮できないまま終わってしまいました。 安定して発揮できる能力を実力と呼ぶとすれば、優勝チームに比べて完全に実力不足です。
とても悔しいですが、「こういう勝ち方をしたい」という中二病的な妄想を実現するために ちょっとズレた方向で全力を尽くしたことを後悔はしていません。 次回もぜひ、僕と @pandax381 と recaro で参加して、今度こそ勝ちたいと思います。
最後になりましたが、こんなに楽しいイベントを主催して下さった NHN Japan の皆様に 心から御礼申し上げます。
