@acidlemonについて
|'-')/ acidlemonです。鎌倉市在住で、鎌倉で働く普通のITエンジニアです。
30年弱住んだ北海道を離れ、鎌倉でまったりぽわぽわしています。
タイトルだけで連絡内容が完結してしまった…。予選結果がでましたのでfujiwara組のリポジトリを公開しました。休日返上でAMI審査を行った運営のみなさまお疲れさまでした。リンクはこちらです。
1行で終わりなのもアレなので、githubのソースコードを引用しつつみなさんの感想ブログを読んだ感想を書いていこうかなーと思います。
AMI締め切り直後に速攻で手の内を出したので結構話題になっていた<link>
をJavascriptで出すように変えた件について。
個人的にはIdobataで運営に確認して見た目の確認はJavascriptの有効なWebブラウザで行われるという確認が取れたのでたぶん大丈夫だろうとは思っていました。が、そこはまぁ運営側が意図した競技になっているかどうかというのもありますので、必ずしも落ちないという自信があったわけではありません。
その辺はfujiwaraの記事にも書いてある通りで、レギュレーションに引っかかるという判断の場合は受け入れるつもりだったというのは3人とも一致しています。
じゃあなんでそこまでやったのかというとISUCONがもともと二つ名(?)としてなんでもありのWebアプリケーション高速化バトルと冠されていたからかなーというところです。当然レギュレーションはあるのでそれに違反するのはダメですけど、自分のレギュレーション解釈を運営に確認して問題ナシとなったらやるしかない。
やらずに負ける(スコアが伸びずに負ける)のとやって負ける(レギュレーションで失格になる)のをどっちを選ぶ? ってなったときに、ぼくは悔いのないようにやって負ける(のを覚悟してやりきる)ほうを選んだ、というところでした。
ISUCONは時間が圧倒的にたりない中でいかに正確に実装するかは結構大きなトピックなので、うちのチームはなるべくキモとなるロジックに手を入れないことを選びました。
具体的には/report
の吐き出しですね。うちは普通にperlでpreforkしたアプリが動いているのでアプリのプロセス上には永続化の必要な可変データを置くわけにはいきません。なので、/login
ではRedisで一度受けてそれを/report
が呼ばれたタイミングで遅延書き込みするという方法でやりました。これなら複数台にスケールできますので、本戦でも利用可能なテクニックです。
そういう意味では、/login
のレスポンスをより高速に返すために一度redisで持つようにして非同期にDBに書き込むようにした、というのはDBを使った構成いわゆるスケール可能な「正攻法」でやることやりきったときの次の一手だと思っています。そういう意味では個人的にはうちも(CSSはずす以外は)正攻法で解いたつもりです。
この手法はスケールできるという他にもう1個メリットがあり、/report
が吐き出すJSONを構築するロジックは参考実装のものがそのまま使えるというのがあります。具体的なコードでいうとrender_jsonの前の部分です。
このreportの作成をRedisから吐き出そうとしたチームは苦労した人も多いのではないかと思いますが、うちのチームではbanned_ips
とlocked_users
には全く手をいれてないので、そこの実装コストがかからなかったのは結構大きかったです。/report
は結果を返すまで60秒も猶予があって時間的には余裕ありまくりなので、時間かかる作業を後回しにして/report
でそれをやるっていうのはよい戦略だったと思います。
個人的にはDBにインデックス張らずにクエリ改造に着手してるチームが多いなーっていうのが結構びっくりしました。今回はusersが20万レコードもあったので、さすがにINDEX張らずにSELECTするのはナシかなーというのがぼくの見解です。
実際10時半にまずINDEXを3つはっただけでDBの負荷が消えて1700から13000になったので、まずはこれが最初にやるべきことかなぁと思います。
LINE選抜も13時まではアプリの変更なしでミドルウェアをチューニングしたりINDEX張ったりしただけで40000点に乗ってます。そういう意味でも、まずクエリを軽量にする必要があるかどうかを判断するのはINDEXを張ってからかなと。INDEXはれない複雑なクエリがあれば、slowqueryでそれが見えてくるのでクエリ書き換えはそれからだと思います。
感想はこんな感じでした。本戦もがんばります。