ISUCON公式Blog

WINNER'S PRIZE \1,000,000



   

[追記]一部表記に誤りがありましたので訂正いたしました

オンライン予選の利用言語比率を公開します。
オンライン予選は407チームの参加があり、予選についてのアンケートにて有効回答数 218チームとなりました。

オンライン予選 利用言語比率

利用率の全体ランキングは以下の通りです。利用言語は自由記入で複数入力したチームもありますので合計が回答チーム数を超えます。

Ruby  68組 31.2%
Go   62組 28.4%
Python 28組 12.8%
PHP  25組 11.5%
Perl   19組 8.7%
Node.js 18組 8.3%
C#    1組 0.5%


本選出場が決まった30チームに限定すると以下となります。

Go   16組 53.3%
Ruby   6組 20.0%
Node.js  4組 16.7%
Python  2組 6.7%
未回答   1組 3.3%



ご参加いただいた皆さんの感想などはこちらにまとめています。
ISUCON7 オンライン予選 関連エントリまとめ : ISUCON公式Blog
Read more...

[11/6 10:45 更新終了]
オンライン予選にご参加いただいた皆さん、ありがとうございました!
こちらでは感想エントリや何をしたかに言及されたエントリをまとめていきます。見つけた順ですが後で何かしらのルールで並び替えます。もしここに載っていないものがある場合は ISUCON7 オンライン予選のブログ書いたよ!フォームで教えていただけると助かります。重複はこちらでチェックしますのでドシドシお願いします。

ブログを書くまでがISUCON予選です!

予選のTweetはこちらでまとめています
ISUCON7 オンライン予選 Tweet まとめ#isucon - Togetterまとめ


参加者
本選出場
ISUCON7 予選通過した - すぎゃーんメモ
ISUCON7予選2日目「Railsへの執着はもはや煩悩」で予選通過した - k0kubun's blog
ISUCON7 予選を学生枠で突破した – ymyzk’s blog
ISUCON7 予選突破コードをissue & PR付きで大公開! | Wantedly Engineer Blog
ISUCON 7 予選2日目を3位で通過しました - 酒日記 はてな支店
ISUCON7 予選突破した (白金動物園) #isucon - diary.sorah
ISUCON7 予選通過した! - Islands in the byte stream
ISUCON7予選を2日目3位で突破した - beatsync.net
ISUCON7参加しました@チームinarisan - sugilogのブログ
ISUCON7 予選1日目1位通過しました - mizkeiのブログ
isucon7予選に参加し通過した
ISUCON7の予選を学生枠で通過しました - くじらにっき++
そして人権を取り戻した(ISUCON7予選突破したぞ!!!) - 雑な話
ISUCON7の予選をはてなメンバーで通過してきました | おそらくはそれさえも平凡な日々
ISUCON 7 予選に参加した話
ISUCON7予選に参加しました - 男女比はカレーと福神漬けと同じくらい
ISUCON 7 予選に参加した話
ISUCON7に参加しました. - chigichan24のお気持ち表明
ISUCON7 予選感想 - TITD
ISUCON7予選通過できた #ISUCON - 水底
ISUCON 2017 の予選を突破したので、その記録 - Qiita
isucon7学生枠で予選通過してしまった - $a(){ a|a& };a
ISUCON7の予選を突破しました! - abcang’s blog
ISUCON7 予選通過した!! - Hateburo: kazeburo hatenablog
hidekiy blog: [isucon] ISUCON7 予選通過しました
ISUCON 7 予選1日目を1位で通過して来ました
ISUCON7 予選1日目を1位で通過しました。 - ken39arg’s blog
ISUCON7予選に学生チームで参加して1日目3位枠で突破しました!
ISUCON7 予選参戦メモ | ただのメモ
ISUCON7予選を総合4位で通過した - stoshiya's blog
ISUCON7予選参戦記 - Goryudyuma’s blog

ISUCON7予選1日目にチーム「ババウ」で参加して最終スコアは205148でした - Dマイナー志向
ISUCON7に参加した - いがにんのぼやき
ISUCON7で人権喪失を味わった #isucon - 私が歌川です
ISUCON7に参加しました - ぬぬん!
ISUCON 7 やまのほすけ 提出スコア 11,204 | うなすけとあれこれ
ISUCON7 オンライン予選に参加しました - 眠すぎて明日が見えない
ISUCON7にチーム「common.php」で出場しました。 - uzullaがブログ
ISUCON 7 予選落ちを支えた技術 - ほとラボ
ISUCON7に出た #isucon - はらへり日記
ISUCON7に参加〜そして敗北へ〜 - Foreverly
ISUCON7 に参加して相変わらず予選敗退しました。 - あいつの日誌β
ISUCON7予選敗退を受けていま考えていること - まさ@ブログ書き込み中
ISUCON7予選に秒速5000兆クエリというチームで参加した - Sexually Knowing
静的ファイルのキャッシュコントロールについて #isucon 7 – そろそろちゃんとやります
ISUCON7に参加して予選突破しませんでした。 – そろそろちゃんとやります
ISUCON7 に、 D2C dot チームで参加してきました! – D2C dot Weblog – デジタル・マーケティングの技術&事例ブログ
SmartHR 開発チームで ISUCON7 に参加しました | SmartHR Tech Blog
ISUCON7予選に参加してパフォーマンスチューニングの代わりにC#実装のために全時間を使ってきた - 451 Unavailable For Legal Reasons
ISUCON7 の予選に出た (95352点) - Unyablog.
ISUCON7の予選に参加しました #isucon - @matsumana の技術メモ
ISUCON7 予選敗退した #isucon - tknzk's tech log
ISUCON7で人権を得ることに失敗した - chiastolite’s blog
ISUCON7予選敗退してきました - ragi256のブログ
ISUCON7 予選に参加した | TRIAL DANCE
ハンバーグは中身が少し赤い程度が美味しい(ISUCON7予選参加記) - 日々精進
ISUCON7 に参加して惨敗した - おうさまのみみはロバのみみ
ISUCON7予選に参加してボロ負けしてきた – Ryosuke Sato – Medium
ISUCON 7予選に参加しました - すてにゃん氏の技術ぶろぐ
ISUCON7 競技者として、コーチとして、出場してきました - The paradigm shift
何も知らないのに ISUCON 2017 に参加した - mayoko’s diary
ISUCON 7 予選(1日目)に参加して悔しい思いをしてきました(アプリ編
ISUCON7予選、学生枠で挑みました。 - おれ、エンジニアになるよ。
ISUCON7「学生気分」 - Write and Run
ISUCON7 予選2日目にチーム「学生気分」で参加した - osyoyu.hatenablog.com
ISCUON7 予選2日目に参加して予選通過出来ませんでした #isucon - ainameの日記
ISUCON7にrubyで参加して手も足も出なかった - azihsoyn's blog
isucon7で惨敗した。 - フクチ@プログラミングと釣り好き大学生のブログ
ISUCON2017に初参加した - Screaming Loud
ISUCON7予選 参加振り返り | Dabits
残念ながら ISUCON 7 は予選敗退で幕を閉じた | ごみばこいん Blog
ISUCON7で予選落ちしてきた - 日頃の行い
ISUCON7参加記録とふりかえり #isucon - Qiita
ISUCON7予選1日目にチーム「ババウ」で参加して次点で落選しました - netmark.jp
ISUCON7に「ガトリンガー葉の仲間たち」で参加して今年も惨敗しました - SEEDS Creator's Blog
ISUCON7に参加したのでその雑記 - Qiita
ISUCON7参加記録とふりかえり #isucon - Qiita
ISUCON7の予選で敗退した - TakiTakeの日記
ISUCON7予選で得た知見 - non117's diary
ISUCON 7 予選敗退しました - ナチュラル @rch850
チーム ZGB で ISUCON7 予選に参加しました - ravelll の日記
ISUCON前線異状なし | owlWorks
ISUCON7に初参戦してフルボッコw - めじなてっく
ISUCON7に参加して予選敗退した - 平常運転
ISUCON7に参加して予選を突破できませんでした😱 – okyunnura – Medium
ISUCON7予選にチーム「Rising Sun」で参加しました | hypermkt blog
ISUCON 7 予選に参加した - castaneaiのブログ
ISUCON 7 予選参加 | にろきのメモ帳
ISUCON7予選に参加してきました - Qiita
ISUCONに初参加した - ふぁんふぁん建てました
ISUCON7に参加してきました - Hack Your Design!
ISUCON7の予選に参加しました - Hitori-Gotten Log
#isucon 7 予選敗退しました | へぼい日記
ISUCON2017参加記 - kyuridenamidaのブログ
ISUCON7で惨敗してきました – Tatsuya Kaneko – Medium
ISUCON7の予選2日目に参加した話 - kariaの日記 @ Alice::Diary
ISUCON7予選で81位でした | gam0022.net
ISUCON7予選に出場してきました(インフラ編)
ISUCON7 予選参加した - はてなブロック

Read more...

出題担当の @methane です。今年の予選問題について解説します。

問題の公開

予選問題のベンチマーカーと参照実装のコードと、Ubuntu 16.04 上に予選問題を動くようにするための手順を公開します。感想戦にご利用ください。
予選問題のリポジトリ

複数台構成について

今年のISUCON予選では、予選としては初めて複数台構成を利用してみました。

倍率が高くなった現代のISUCONにおいては、多くの参加者にとって予選こそがISUCONになるということを念頭に、ISUCONの醍醐味で予選でまだやってないのはなんだろうと考えたときに思いついたのが複数台構成でした。

また、1台あたりの性能を厳しく制限することで、1プロセスで簡単にマルチコアを活かせるGoが強くなりすぎないようにするという考えもありました。サーバー1台あたりのCPUは1コアしかないので、Goでも他の言語でも複数コア数を使いたければ複数サーバーを使うしかありません。メモリも1GBしかないので、1台で捌く状態でチューニングが進むと画像のアップロードなどで苦戦する可能性が高いです。(実際に1台オンメモリ戦略を実装してみて苦戦しました。)

最近の予選では本戦での実力以上にGoを使ったチームがトップ争いをすることが多い印象がありましたが、今年の予選では(アンケート結果を見ないとわからないものの)そこまでGoが強い印象もなく、本戦に近い雰囲気の問題にできたのではないかと思います。

残念ながら、各日200以上のチーム数×3台=約600台のサーバーに、ベンチマーカーを加えた大量のサーバー群の構築を甘く見ていたために、大きなトラブルの要因になってしまいました。特に土曜日の参加者に迷惑をかけてしまったのと、インフラ構築をしてくれたメンバーに連日の徹夜をしてもらう事になったのは、もとを辿ればこの思いつきが原因です。ごめんなさい。

来年以降の出題者へのアドバイスとして、予選は絶対に参加者自身にサーバーを起動してもらう去年までの形式が良いと思います。

アプリケーションについて

今年の予選はチャットアプリケーションでした。特別な意味があったわけではなく、単にN+1や画像アップロード、簡単なリアルタイム要素など、程よくISUCONの過去問のエッセンスを配合しやすかったのでこのお題になりました。

静的ファイルと画像ファイルのキャッシュについて

私の想定では静的ファイルや画像はCDN経由のアクセスだから
Cache-Control: public, max-age=3600
をつければ自力で配信する必要はない、という問題にするつもりでした。

ベンチマーカーは(エラーが起こらない限り)毎秒一定のペースでユーザーを増やし、各ユーザーがプロフィール画像を登録していくのですが、キャッシュが無い、あるいはユーザー単位のキャッシュではユーザー数に比例したダウンロード帯域が必要になってしまい、後半すぐに帯域がサチってしまいます。

ユーザー数が増えていってもダウンロード帯域をサチらせないためには、CDNによるキャッシュが効いているという前提にしてユーザー数が増えても画像一つあたりのダウンロード数が増えない設計が必須でした。

当初の予定では単に
Cache-Control: public, max-age=3600
をつければいいので難しくないはずだったのですが、予選直前に
max-age
をつけなかったときの 304 によるスコアが想定より大きいことに気づいて、「
max-age
をつけないほうがスコアが簡単に上がるのはおかしい」と
max-age
がついていたらダウンロードをスキップする部分を削ってしまいました。

このときに複数台構成で正しく304を返す難しさに思い至らなかったために、意図せずこの部分で多くのチームをハメてしまうことになってしまいました。

GET /fetch と GET /message

エラーやタイムアウトがない場合、毎秒新規ユーザーが登録してきます。メッセージの投稿数はユーザー数に比例するだけですが、メッセージの受信数はユーザーの2乗に比例します。ボトルネックを潰してメッセージの流量を上げていけば気持ちよくどんどんスコアが上がっていくという設計にするつもりでした。

特に、
GET /fetch
はスコアがなく、
GET /message
には受信メッセージ数にも加算されるというところがポイントでした。

クライアントは
GET /fetch
をポーリングしていて、閲覧中のチャンネルに新着メッセージがある場合には
GET /message
を呼んで新着メッセージを受信します。
GET /fetch
のレスポンスをどんなに改善しても、新着メッセージがなければスコアは上がりません。閲覧中のチャンネルに新着メッセージが1件ある状態ですぐに返しても、
GET /message
で1点とそこに含まれる1メッセージ分の1点で、2リクエストで2点しか稼ぐことができません。

しかし
GET /fetch
をタイムアウトにならない範囲で遅くしてやると、
GET /message
は1リクエストで数十件のメッセージを取得することができるので2リクエストで数十点を稼ぐ事ができます。

このようにリアルタイム性のあるアプリケーションでは、要求される時間内でイベントをバッチ化することでスループットが上がっても比例して負荷が上がらないように設計できることがあります。

GET /fetch
GET /message
は N+1 クエリや COUNT クエリなど非常に重い処理になっていたのでどのチームもこの処理を軽くすることに力を入れたと思いますが、単に処理を軽くするだけでなく一見無駄に見える参照実装の sleep の意味に気づくとブレイクスルーすることができたと思います。

最後に

今回の予選は甘い想定や調整・検証不足のため、参加者の皆様に気持ちよく楽しんでもらうことができず、申し訳ありませんでした。

本選までもうあまり時間がありませんが、参加者が余計な部分で苦しむことのないように最善を尽くします。本選もよろしくお願いします。
Read more...

↑このページのトップヘ