ISUCON7で惨敗してきました

タイトルの通りです。一応自分達のメモ用に何をしたのか簡単に残しておきます。

事前準備

去年ISUCON6では出題側だったので久しぶりの出場でした。一昨年まで一緒に出ていたチームではなく、今年は鍋部として『@walf443, @st-cyrill』の3人で出ました。

事前に数回練習を行い、お互いのやることなどを決めていきました。自分はアプリケーション担当としてアプリケーションの特徴や実装を調べたり、実際の実装を進める役割でした。

今年は例年と違い、予選からサーバーを運営側が提供だったので運営側の負担を考えたら複数台は絶対にやらないと思っていました。しかし事前に公開されたレギュレーションには複数台という文言がありました。それを見たときに正気か!?と思いました。

正直当日まで複数台については懐疑的でしたが、実際には複数台でした。もう少し複数台で出題されたときの対策を真面目に考えるべきだったな、と後悔しています。

当日の開始時間前

当日は開始がドンドン遅れて、いつ始まるのか、本当に始まるのかという不安がありました。
そもそも予選の規模の参加者インスタンスを運営が用意すると聞いた時点で、インスタンスを用意する運営の方々がとても心配でした。運営の方々の苦労を考えると自分のことのようでつらくなります。

当日は大分遅れた13時過ぎから始まりました。この時点で既に待ち疲れていた感もあり、しかも台風が近づいていたため時間帯が遅くなるにつれて自分の体調が悪くなっていきました。

当日

リポジトリはこちらです。

最初に問題を見た時点で、画像がMySQLに突っ込まれており、しかもメモリもかなり絞られているという設定で、自分達が作ったpixiv社内ISUCONに似ている問題だと感じました。

とりあえず初期データの画像をファイルに書き出す、ということはすぐに思いつきましたが、問題はベンチマーカーが直接送ってくる画像データです。今回の予選は複数台なのでアップロードされたファイルを分散する仕組みが必要です。今回の最初から用意されているnginxはなぜかWebDAVが有効になっていたので、今回はWebDAVを使用しました。WebDAVはPUTするだけなので動かすことは簡単です。ただ今回のマシンはメモリが不足しているので本当はファイルを全部オンメモリに載せた上でnginxにPUTする実装を辞めようと考えていました。しかしファイルのSHA1を取得する必要があったので初期段階では諦めました。最終的にここがボトルネックになるところまで行けなかったので、結局やらなくて正解でした。

ベンチマーカーは画像配信のタイムアウトが多く、dstatなどから指定された帯域を使い切っている事が明らかでした。帯域の問題を解消するためにフロントを複数台にして配信を最適化しようと考えましたが、すぐに帯域を使い切ってしまい、一定以上の負荷をかけてもらえず何をしてもスコアが上がらない状態になりました。

ステータスコード304を返すことである程度解消できることはレギュレーションにも書かれていたのでnginxのexpiresディレクティブを使っていました。一部が304を返していましたが全部が304になっていませんでした。ここについて深入りすれば良かったのですが、もう十分304を返せていると考えてしまったために、しっかりと深入りすることができませんでした。

また今回WebDAVを使って複数台構成にしたタイミングでスコアが下がったのですが、それは304を返せる量が減ったことによるものだったようです。しかしそこまで深く考えることができず、複数台構成のまま突き進み続けてしまい、抜け出せませんでした。

今回複数台構成であったことからキャッシュをオンメモリにもつのではなく、Redisに入れる戦略でいきました。しかし今回の問題は帯域問題を解決しない限り負荷を増やしてもらえないので何をしても無駄という状況でした。帯域問題を解消しなければ無駄であることが分かっていたのに、有効な手を最後まで打てなかったので完敗でした。

また今回使っていたGoのWebアプリケーションフレームワークのechoを初めて使ったのですが、Goの標準ライブラリから逸脱していて分からないことばかりでした。UNIXドメインソケットにしたいと思っても、うまくいかなかったり、色々と思い通りにいかずストレスが溜まっていきました。

色々なことを試していましたが、結局帯域問題が解決できていないのでスコアには寄与しませんでした。帯域問題が解決した後に効く最適化をいくつかしていたと思うので、帯域問題をしっかり解決して次の勝負に突入したかったです。

今回は私がしっかりサーバー構成も含めて全体を見渡して、しっかり帯域問題を解決していれば先に行けていたはずなので私にとって非常に反省点が多いISUCONになりました。今回複数台構成で想定よりもインフラ担当のタスクが多く、インフラ作業待ちになることが多かったです。そのことに気付いていたのに私が有効な手立てを打とうとしなかったことが敗因の1つと思います。今回の教訓を活かして今後のISUCONに参戦したいので、来年もぜひISUCONが続いて欲しいと思います。運営の方々、非常に素晴らしい出題をありがとうございました!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.