ISUCON4の予選に参加した

はい。会社でみんながISUCON参加するというし、賞金が100万円だとか言うのでISUCONに参加してみました。その結果をとりあえず書いておこうと思います。

チーム編成

いつもあまり一緒に仕事をしない、会社の運用チームの2人と参加することになりました。以前出ようかな〜と行ったらメンツが揃ってない所があると言われてそこに参加する感じになったわけですね。普段一緒に端末を眺める事も無い二人と一緒に参加できたのは楽しかったです。

朝の大失敗

ISUCON4予選参加は会社の会議室を借りて参加することになりました。10時開始なので朝9:00に会社集合ということになっていたのですが…
朝起きたら9時43分wwww
いやー冷えました。起きて「マジ?」とか思った瞬間。チームの一人からLINEが飛んできて「今から行きますwww」と行ってそっこう家を出てバイクに跨がり駅へGo。
電車乗るぜ!!とか思ったら携帯(モバイルSuica)が無い!!家までバイクで15分…頭をよぎったのは…
俺のISUCON4は終わった…
の一言でしたが、バイクまで戻ってみるとバイクのカゴに携帯がひっかかっていたので回収してそっこう連絡。電車の中で何かできることは無いか…
そうだ。レギュ−レーション、読もう。
電車の中から連絡用チャットに入り、レギュレーションを熟読する。超熟読する…熟読しているうちになんかいろんな疑問が湧き上がる…。湧き上がった疑問はレギュレーションにより公開ができないと思うので書きませんが、疑問がいろいろあった。

ISUCON4予選開始

11時15分会議室に着く。遅刻しちゃったので大量におかしを差し入れに買っていくというみんなの起源を食べ物で取ろうという対策を開始。(大人って汚い)
既に2人はいろいろ作業を進めてくれていて。インスタンスを立ててBashの脆弱性のテストをしたり、ベンチマークのテストしたりアクセスログ読んだりしていた。
さて、俺も何かやらないとな…と思ってまずやった作業はこれ。
お菓子の袋の開封作業
開封したお菓子は以下の3点
  1. Kit Kat (やっぱり縁起物だからね)
  2. 歌舞伎揚(これもまぁお約束かな)
  3. 栗のマシュマロ
とりあえずKit Katを食べてやる気を出す。というのはまぁ本当のことなんだけど技術的には以下のようなことをした気がする。
  1. tmuxのインストール
  2. 調査ツール(dstatとか)のインストール
  3. PerlとかRubyとかPythonとかGoの動作状況の確認

チューニング開始

チューニング前に調査

調査ポイントはまぁこんな感じ
  1. 構成確認(nginx+mysql)
  2. nginxのアクセスログエラーログ確認
  3. MySQLのSlowQuerry
  4. messagesログ
  5. Go言語のアプリソース(見てもわからなかった)
  6. Go言語から発行されているSQL
ひと通りいろいろ見て回ったあたりで時間を見たら12時30分くらいだったので
昼食タイム
ぶっちゃけまだなんもしてないwww
昼食は2名のうち1名が
「俺昨日すき家で食ったんで、今日は別のところがいいです」
ということになったので吉野家の牛丼を買ってきて会議室で食べることにしました。
女性の皆さん、男性が3人集まるとこんなもんです。
例えば前日GoGoカレーに行ったのなら、今日はCoCo壱番屋でいいんです。もうそれは別物なのです。

※あ、YSMさん牛丼のお金の精算してないから今度会った時に渡すね。

食べながらいろいろチューニングするポイントどうするか話し合いをしつつ、作戦を練る。他のチームのスコアがその時点でなんかよくわからないスコアが出ていたのを見て、我らのチームの方針として決定したことは
「参加したことに意味がある」
という方針に確定しました。

チューニングポイント

とりあえず結果が出るまでは非公開
メモ:V, n, R

最終結果

こちらも言っていいのか悪いのかよくわからないのでほとぼりが覚めたら書きます。
一応数万点は行きました。

参加した感想

最後3人で反省会を少しして自分たちに足りないもの、課題を話し合い、以下のような結論に達しました。
  1. MySQL力、SQL力を付けないとそもそも無理ゲー
  2. Go言語力
結局WebアプリというところではSQLが読めないとボトルネックの解消もできなければ再実装しようにも何やってるかわからないしとまぁ、基本的な所の解消ができないからきついねという所。
Go言語力については、そもそも誰も読めなかったので、まずはPythonで何をやっているかを読み解き、「あーこれとか解消できると早くなる」とか「ここあーすると負荷下がるね」というところまで読み解き、改善方針まで出しているのに、Goのソースを見たとたん、「この?マーク何?」とか「:=」って何?とか基本的な書式もままならない状態だったのでGo言語力があれば早い言語でガリガリできたなって思いました。

自分も課題が見えたし、自分の力量も数値という形でつきつけられたわけで、自分を見直すのに良いイベントだなぁと思いました。また参加してみたいですね。

ベンチマークのバグについて

この競技凄く楽しかったのですが、競技終了後にまったくもって面白くない事が起きたので苦言を吐こうと思う。以下アドレスにて公開されているので、これはもう書いていいという判断で書きます。

「予選第1日に参加していただいた皆様へ」

この書き方は凄く良くないと個人的には思ってます。
こでは初期値の状態でも「workload」を増やせば良いスコアが出ると書かれているけどそんなことは全くなく、ある程度OS側のチューニングをしなければworkloadを突っ込むことができませんでした。
チューニングの方針として、「workloadを増やせるようにチューニング」をしたチームが少なからず居たのではないでしょうか。
皆ベンチマークにはバグが無い前提で考えているし、ベンチマークのスコアのみが判定基準なのだから1分間しか計測しないという仕様なんかは参加者側が認識する必要もなく、ベンチマークプログラムが出した結果が全てです。(ベンチマークプログラムのデバッグコンテストなら計測時間が正しいかそりゃ確認するけどさぁ…)
workloadを増やしていいスコアが出たら「よっしゃこれworkload増やせるようにチューニングしていこうぜ」ってなります。

しかも、最終結果はその修正をしたベンチマークで運営側が再度計測を行い、最終結果を出すというもの。

うちのチームは初期値でworkloadをある一定以上突っ込んでもスコアが伸びないという事を確認してからチューニングしたのでそのようなチューニング方針にはならなかったから当事者にはならなかったものの、バグを利用しようという意思がなくそこに辿り着いたチームは、確実にスコアが大幅に下がると思います。

2日目の人はそこを解消したベンチマークでトライアンドエラーができる分土曜日参加のチームより有利というか時間をそこに使わなくなるだけお得だなって思います。
上位チームのスコア争いではこういうの影響するんじゃないでしょうかね。本当であれば2日目終わった後に公開しないと公平性にかけるんじゃないでしょうかね。
まぁ、よくわからないけど、元イベント屋としてはもう少し「影響を受ける側」の方々の心情を汲んだ対応をしたほうが良かったんじゃないかな…という感想を持ちました。

次回以降こういうことが無いイベントになるといいな…って思います。
Comments