Help us understand the problem. What is going on with this article?

ISUCON8予選に参加した話

More than 1 year has passed since last update.

ISUCON8に参加してきました。ISUCONは今回が初めてだったのですが、学ぶことも多く、来年も是非参加したいなと思いました。

この記事では今後ISUCONに参加される方へ、ISUCONがどんなものか、また自分たちがどういうことをしてきたか記していきたいと思います。今後参加される方の参考になればと思います。

ISUCONが始まるまで

「(I)いい感じに(S)スピー(U)ドアップ(CON)コンテスト」の名の通り、架空のWEBサービスを高速化するらしいと聞き、サーバーとアプリケーション要員を一人ずつ、それと自分の3人で挑むことにしました。この布陣はバランスが取れててよかったと思います。

事前対策

本番まで2回ほどチームメンバーで集まって過去問を解きました。言語は3人の共通部分をとってPHPです。題材は公式や、VagrantAnsible、色々と作ってくださったものがありますが Vagrant でやるのが一番いいと思います。公式のでセットアップしたら軽く1日溶けました。Docker作ってくれる人いないかな...

「isucon 対策」とかでググるとhtopとかでプロセスを監視しつつ、alpやらpt-query-digestといったツールを使ってアプリケーションのボトルネックを探せばよいとあり、確かにそれで十分スコアあげれる感がありました。

思い描いていたシナリオ

リハーサルで3人だと開発環境作らないと厳しい感じだったので、DockerComposeを書いて環境の共有をしようという話になり、最初の1,2時間で一人がDockerComposeを書き上げ、その間にアプリケーション担当がコードリーディング、サーバー担当がボトルネックを見つけたりなんなりして、「30分くらい指針を話し合い2時間くらい開発を行う」のローテーションを回すみたいな感じを想定していました。

定期的に話し合うのは、一回全員が好き勝手にチューニングした時に優先度の共有がなされず、まさに「船頭多くして船山に登る」状態になったからでした。

で、この布陣になると自分がcompose書くわけなので、どうせphp-nginx-mysqlで来るだろう しISUCON7のcomposeファイルを書いてカンニングペーパーにすれば余裕では?という思いで、とりあえず一年前の予選のcomposeファイルだけ書きました。

そして事件が起きました

ISUCON本番

第一関門「起床」をクリアし順調な滑り出し。が、問題を見て

\def\textlarge#1{%
  {\rm\Large #1}
}

サーバー3台あるとか聞いてないんやけど

$\textlarge{ってかH2Oってなんや}$

あとあとよく見ればISUCONは複数台のサーバーが使えるという記事も見つけました。よくわかんないけどなんか色々分散させるんですかね。

h2o初耳だったので調べるとDeNAの方が作ったそう...あ、そういやDeNAさんも作問してるんやった...

やったこと

計画通りまずDockerComposeファイルを書き始めたのですがなかなか上手いこといかず、2時間過ぎた時点で諦めました。特にh2oに関する知識が足りなかったように思います。仕方なく全員でPHPプログラムのみをgitで管理することに。

その間にh2oについてある程度調べがついたので、htopを見つつスレッドこれくらいがいいかなとかconfをいじりました。この時点でスコア1,500程度。

ここでCPUの使用率が100に張り付いていたので、中でも異様にスレッドの使用率が高かったMariaDBを別サーバーに移そうとしました。が、サーバーを分けた分RTTが増え/initializeが通らなった(/admin/で死ぬ)ため、一旦据え置きに。

そのあと気づいた点として、スロークエリログを見てもアクセスログを見てもget_eventメソッドが異様に遅いということがあって、圧倒的に優先度が高かったのでこれを解消しました。sheet自体のrank別の数や金額というのはeventに関せず同じ値なので、これを利用しforeach内のN+1クエリを解消、これでようやく6,000を超えました。

ついでに言えば/initializeでのボトルネックもここで解消されたので、MariaDBを移行。スコアは一気に22,000に。ベンチ回してもCPUはほとんど食われず。その他多少のアプリケーション変更やらキャッシュの共有やら使っていないシステムプロセスの終了を行なったり、この時点で割と手を出し尽くした感。

最後にh2oも最後の一台に移行しようということになったのですが、なぜか上手いこといかず諦めました。この時点で25,000を超えており、1時間前の時点で学生一位だったので、まあいいかということで30分残し、分析に使った余計なプロセスを全部消して皆PCを閉じました。

結果

予選落ち。不思議でしたが一点確認していなかったことがありました。「再起動試験」です。どうやら何かのプロセスが再起動時に起動せず、死んだ??

リアルに▂▅▇█▓▒░(‘ω’)░▒▓█▇▅▂ うわああああああってなりましたがちゃんとレギュレーション読めって話です。

まとめ

  • やるのは基本的にプロセス監視とアクセスログ、スロークエリログ監視。数値に基づいて改善すべし。
  • ISUCONは予想外の構成を出してくかもしれないのでバクチな対策をしない
  • 再起動試験に備えよ

ということで来年も挑戦したい。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした