お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。第７回目となった ISUCON のフォトレポートをお届けいたします。

関連エントリ
▼ISUCON7 開催＆日程決定！ #isucon : ISUCON公式Blog
▼【締め切りました】ISUCON7 オンライン予選の参加登録を開始＆参加チームとメンバーリスト : ISUCON公式Blog

▼ISUCON7 本選 Tweet まとめ#isucon - Togetter

会場はこのような雰囲気です



9時開場という、比較的早朝とも言えるのに集まりのよさがハンパではありません



やる気がみなぎっております

ISUCON7本選の出題を担当した @methane です。参加者の皆様、お疲れ様でした。

すでに Twitter でアナウンスされているとおり、本選の問題を Github で公開しています。
▼isucon/isucon7-final

すでに一週間以上経ってしまいましたが、この記事では本選の問題設計や攻略ポイントについて解説していきます。

お題について

予選では、夏期講習参加者や過去問を練習してきてくれた学生チームにいじわるな問題設計にならないようにと考えていました。（残念ながら失敗していた部分も多かったですが）

一方本選では、そういった気遣いを一切無視して自分たちの得意な分野の問題を出そうということで、MOゲームをお題に選びました。

「協力してレイドボスを殴るゲームにしようか。」
「ボスのヒットポイントは無限にして総与ダメージをスコアにできないかな。」
「攻撃スキル、バフ／デバフスキルみたいなのはコード量を大幅に増やす割にISUCONとして面白くないから、もっとシンプルなルールが良いよね」
「あれ、クッキークリッカーってレイドボスになるんじゃない！？」
という流れで Chair Constructor Online にすることになりました。

自分たちの得意分野をやるということで、WebSocketを使ってマルチプレイ対応することまでは考えていましたが、ボトルネックをどう作り込むかなどはアイデア時点では考えていませんでした。

アイデア段階では存在しなかったタイムスタンプや未来に反映されるコマンドを使った同期といった難しい部分は、予選期間中にお題のゲームのプロトタイプを作ってくれていた @hasi_t が作り込んでくれました。

オンメモリ戦略と分散構成

ISUCON を攻略するテクニックの1つとしてオンメモリ戦略があります。この名称は自然発生したものできちんとした定義は無いものの、私の理解では次のような方法です。

オンメモリ戦略: RDB上のデータを正としてプロセスメモリ上のデータをキャッシュとしてのみ利用するのではなく、プロセスメモリ上のデータを正として、RDBは永続化のためだけに使う（もしくはRDBを捨てて別の永続化手段を取る）

ISUCON参加者の中にはオンメモリ戦略を嫌う方もいます。
その理由は次の2点が大きいと思います。

RDB 以外の永続化手段は実際のWebの現場では安全性のために利用しにくいので、ISUCONでしか使えない戦略である（現場でも活かせる方法で勝てるようにしたい）