―― ISUCON7本戦でのIssue

 

大学でプログラミングサークルというと、コンテストは外せない気がしませんか?だからというわけではないのですが、この度ソフトウェア工房では、ISUCON 8に参加することになりました。

今日のブログは、前回の問題を解いて模擬戦を行ったので、その話を。ブログでは二度目になります、nitoliです。

ISUCONってなに

LINE主催、「iikanjini Speed Up Contest」です。Webサービスを高速化すべく、アプリケーション・サーバソフトウェア・データベース・カーネルその他をチューニングする、今年で8年目の伝統あるコンテストです。保守案件かな?

本戦出場チームを筆頭に、黒魔術の見本市みた高速化の手法が見られ、本職のエンジニアもひいひい言うとかなんとか。学生目線で行くと、nginxやMySQLなど、日頃使ってるものの理解を深めるのに、教材が実際現場で使われている技術というのは豪華だと思います。

工房でも5月の終わりに模擬戦をやりました。覚えておりますでしょうか。

 

ISUCON 7 本戦について

7本戦の問題は、おじいさんや工場や宇宙的ななにかの力を借りてイスを作りまくるというどこかで聞いたようなゲームのチューニングでした。題してChair Constructor Online。

イスて
ISUCONだけに?

やったこと

参考までに、参加者は@nitoli(バックエンド)、@marco(フロントエンド)、@kabe(バックエンド)です。

はじめてすぐは、全員でアプリケーションの全容をつかむことにしました。
なんとなく反応が遅いなあ、websocket使ってるなあ、静的ファイル配信は別に早くないなあ、websocketが遅いっぽいけど一体何が起こってるんだ?という感じでした。
何もせずベンチを回し、Score: 3614

前回の経験から、複数台のサーバに設定・デプロイするのが面倒なのは知っていたので、ぼくはそのスクリプトを書く作業にあたりました(実は1VMで練習したので要らないのですが、あくまで模擬戦なので)。このころ、marco、kabeはアプリケーションと、DBのスキーマを確認していたと思います。

どうやらDBのアクセスが多く、書き込みが読み込みの10倍もあることをkabeが、DBのパフォーマンスが悪そうだというのをmarcoが突き止めました。そうして各人気になる部分を調べるうちに役割も決まり、nitoliがnginx、kabeがアプリケーション、marcoがMySQLのチューニングを担当する流れに。

早速marcoがDBにインデックスを張り、Score: 4362 になり、kabeがレギュレーションを眺めるうちにVMの構成がおかしいことに気づき2Core/2.5GHzに調整し直して Score: 5437 。これは違うか。

前日にサーバー設定とその他(睡眠・ゲーム・ホームページ制作)に疲弊、まぶたの上がらない我がチームはこの時点で4時間経過。ISUCONは8時間だぞ。大丈夫か。nitoliはその間なにをしていたのか。なんと デ プ ロ イ 用 の シ ェ ル を 書 い て い ま し た。本番でも使えるから許せチムメン。これは戦術的に必要な犠牲であるぞ。

ようそろnginxをチューニング、gzip圧縮・静的ファイルのキャッシュ・コネクション数の増大などしてみたのですが、スコアが少し落ちたのでこれはマージされませんでした。

ぼくはnginxのチューニングを終わらせた後、アプリケーションの確認にかかりました。なんか巨大な数値型があるなあ、アホみたいにループする計算があるなあくらいな形ですが、この時点で明確なボトルネックを探せていなかったからか、明確な修正点を見つけられず。

全員で頭を悩ませ、手詰まりを感じ、寝る、夕食、ラジオ体操など迷走しだしたところで、工房に前回出場者が現れました。

 

「なーんできみ本戦やってるの」

 

予選を通過した者だけが解くからか、要求される技術が高く、出場した本職のエンジニアでもつらいとのこと。そらつらい。

 

答え合わせ

ボトルネックは大きく分けて、ゲーム中に多量に発生するDBアクセスと、巨大な数値型の演算でした。

ルール上、1秒以上レスポンスが無かった場合は、タイムアウトとみなされます。処理の過程で1秒をゆうに超えるアプリケーション・DBだったので、nginxの変更やコネクション数の変更が効かなかったようでした。ともかく、big.Intまわりの演算と値の変わらないDBアクセスをキャッシュするのがまずひとつの方策です。Goではbig.Int周りがかなり重いらしく、競プロ的な知見が必要かもしれませんね。

また、DBのアクセスを早くすることは、今回の問題に限らず、有効な戦略になってきます。特に、Redisに代表されるオンメモリDBへの載せ替えを行えば、ストレージベースのスコアからは隔絶されるとのこと。メンバー全員が把握してはいたものの、NoSQLへの載せ替え、自前でオンメモリにする場合の整合性の保ち方とストレージへの適時バックアップが時間内に行くかまではわからなかったこと、MySQLの機能でメモリに乗せる場合は有効性が見られなかったことなどから躊躇しました。実践した人はCassandraに載せ替えたそうですが、技術力…という感じですね。

総じて、かなり悔しい結果となりました。

 

次回予告

明日、というかもう今日なのですが、ISUCON 7 予選を行います。今ならConoHaにイメージがあり、構築しやすい(されてる)ですからね。

本戦・前回の反省も込めて、オンメモリな戦略と、最終的な動きの確認を行うようなのですが、果たして。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)