こんにちは！ISUCONの運営担当をしているLINEの櫛井です！進捗いかがですか？ ISUCONというイベントがありまして、LINEが運営を行っていて、問題提供とサーバ提供を毎年色々な会社さんにご協力いただいて開催しているのですが、参加者の皆さんからは「運営コストが増大して継続開催が困難になるのでは？」という声もいただくこともあります。 ISUCON1から運営担当をしている身としましては、出題側のリソースやプレッシャーについて理解しているので、ISUCON8については「出来る限り運営の皆さんにも楽しんでもらう」というのを試してみたいと思い「そうだ、温泉合宿いこう」と思いついたわけであります。 ISUCON8は、問題作成を面白法人カヤックさまと株式会社ディー・エヌ・エーさま、サーバ提供はGMOインターネット株式会社さまにご協力いただいており、今回の温泉合宿では「予選と本選の問題＆ベンチマーカ

予選の問題作成を担当したDeNAのkarupaneruraです。 予選に参加した皆様、お疲れ様でした。 楽しんで頂けましたでしょうか。 お陰様で大きなトラブルもなく無事に予選を終えることができました。 参加者の皆様をはじめとした皆さんのご協力がなければ成し得ないことでした。 ご協力いただいた皆様、ありがとうございました。 課題アプリケーション今回の課題はイベントのチケット予約アプリケーションでした。 ユーザーを作成、またはログインを行うと座席を予約することができます。 座席は抽選で決まる仕組みになっており、ランダムに決まった座席が即座に分かるようになっています。 埋まっている座席は黒く塗りつぶされ、自分の獲得した座席は緑色の字で表示されています。 また、自分の座席をクリックするとキャンセルを行うことができます。 マイページでは自分の最近予約(orキャンセル)した席を5件、最近予約(orキャ

ディメンジョナルハイソサイエティぬれねずみというチーム名で ISUCON8 に出場しました。言語は Perl を選択しました。 結果は 40,867点で、13位 / 528組。 技術的なことについては、すでにチームメンバーの2人が書いてくれているので、自分からは主にそれ以外のことについてまとめます。チームメンバーのブログは以下： ISUCON本戦に出られることになった - hitode909の日記 ISUCON8予選を突破した - $shibayu36->blog; メンバー構成 同じ会社の同僚3人で出ました。 id:hitode909 アプリケーションエンジニア Perl めっちゃ書ける、普段から業務でバリバリ使ってそう 出場は3回目 id:shiba_yu36 アプリケーションエンジニア Perl めっちゃ書ける 初出場 id:takuya-a アプリケーションエンジニア Perl は

id:hitode909とid:takuya-aとチーム「ディメンジョナルハイソサイエティぬれねずみ」としてISUCON8に参加し、40867点で本戦に行けることになった。ISUCON初参加でいろいろ不慣れではあったが、なんとか本戦に行けて嬉しい！ サーバ複数台構成かつボトルネックになる箇所が結構面白いところが多く、非常に楽しめました。運営の皆様ありがとうございました。 振り返りとして、チームでやったこと・良かった進め方をまとめてみる。 チームでやったこと 開始直後は役割分担して作業していった。言語は勉強がてらgolangにしようと思ったこともあったが、せっかくなら勝ちたいし慣れてるperlにした。 shiba_yu36: 鍵置いたりコードのバックアップしたりなどといったオペレーション周り 他二人: アプリケーションの挙動を確認し、作戦を立ててもらう 以下が最初のオペレーションでやっていた

ISUCON7本戦に「railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」チーム (@cnosuke, @rkmathi, @k0kubun) で参加し、4位でした。 本戦の概要 予選より参加者は少ないと思うので軽く解説しておくと、クッキークリッカーを模したトラフィックのほとんどがWebSocketのアプリで、1万桁とかのスコアを計算する都合ほとんどのチームのボトルネックが最後までBigintの演算になるような問題でした。 僕らは15:00くらいに1位になり、その後はスコアをそれほど改善できず終わってしまいました。 方針 「@k0kubun 氏のチューニングした3倍速いRubyで優勝したらまじかっけーっす！」って話をした。 #isucon— FUJI Goro (@__gfx__) 2017年11月25日 最近Ruby向けのJITコンパイラを開発している

予選問題のベンチマーカーと参照実装のコードと、Ubuntu 16.04 上に予選問題を動くようにするための手順を公開します。感想戦にご利用ください。 予選問題のリポジトリ 複数台構成について今年のISUCON予選では、予選としては初めて複数台構成を利用してみました。 倍率が高くなった現代のISUCONにおいては、多くの参加者にとって予選こそがISUCONになるということを念頭に、ISUCONの醍醐味で予選でまだやってないのはなんだろうと考えたときに思いついたのが複数台構成でした。 また、1台あたりの性能を厳しく制限することで、1プロセスで簡単にマルチコアを活かせるGoが強くなりすぎないようにするという考えもありました。サーバー1台あたりのCPUは1コアしかないので、Goでも他の言語でも複数コア数を使いたければ複数サーバーを使うしかありません。メモリも1GBしかないので、1台で捌く状態でチュ

こんにちは、LINEの櫛井です。 前回お知らせしたように、今年はLINE株式会社主催、問題作成は面白法人カヤックさま＆株式会社ディー・エヌ・エーさま、サーバ提供はGMOインターネット株式会社さまでバッチリお届けする予定のISUCON8！今日は3つほどお知らせがございます。 ■1つめ、開催日について ・予選　9月15日(土),16日(日) ・本選　10月20日(土) を予定しています。スケジュールを空けておいてくださいませ。 ※予選は従来通りオンラインで行い、どちらかの日程でご参加いただきます ■2つめ、申込み時期について 7月開始、8月末に締め切りで準備をしています。今年も一般・学生の2つのジャンルで募集を行います。応募開始したら即お申込みいただけると大変ありがたいです。 ■3つめ、1名での参加枠設置について 競技の成り立ちにも由来しますが、ISUCONは参加して学ぶことではなく「勝つこと

ISUCON5の予選に参加して、圧倒的な差で負けたので、 この悔しさをバネに復習して、自分の力にしたいと思う。 今回のファイトではアプリの修正が特に重要であったように思う。 そこでアプリの修正に焦点を当てて、「こうすればよかった」を追っていき、自分のものとして習得したい。 とはいえ、本番とまったく同じ状況を作ることはできないので、ローカル環境でベンチマークを走らせて、簡易に得点を見ていくことにする。 ISUCON5の予選で使われたアプリのコードとベンチマークのコード、gce用のイメージはすでに公開されているのでこちらを使う。 isucon.net なお、極力アプリの修正に集中するため、nginx.confやmy.cnfはいじらない。unicornのworker数すらいじらない。 インフラはせいぜいテーブルにインデックスを貼る程度とする。 これは、ISUCON予選本番で、やたらインフラに時間

お題のWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル「ISUCON」の第7回大会が今年も開催されました。 過去6大会のうち、藤原を中心としてカヤックのメンバー(OB含む)で構成される「fujiwara組」が3度の優勝を飾ってきましたが、今回の大会ではカヤックのエンジニアチーム「MSA」が初出場で初優勝を達成しました！ 「ISUCON7」当日のレポートはこちら そのメンバーであるゲーム事業部のエンジニア荒賀謙作、鈴木恭介、水野敬太の3人に、競技当日の様子や普段の業務などについて聞きました。 初参加で初優勝を達成したISUCON ―まずは自己紹介をお願いします。 荒賀 荒賀謙作です。カヤックに入社して10年目のエンジニアです。フィーチャーフォン向けのソーシャルゲーム開発やLobi事業部を経て、2017年からソーシャルゲーム事業部でサーバー開発をしています

@methane です。 ISUCON 7 本戦で最大のスコアアップできたポイントが、 status と呼ばれる重い計算の結果となるJSONのキャッシュでした。 近年のISUCONによくある、「更新が成功したら以降のレスポンスにはその更新が反映される必要がある」（以降は「即時反映」と呼びます）タイプの問題だったのですが、今回のように更新頻度の高くかつ即時反映が求められるデータをキャッシュする方法について、より一般的に解説しておきたいと思います。 即時反映が不要な場合 まずは基本として、即時反映が不要な場合のキャッシュ方法からおさらいします。この場合、一番良く使われるのは参照時に計算した結果を Memcached などにキャッシュし、時間で expire する方法です。 このタイプのキャッシュには、参照元が分散している場合（Webサーバーが複数台あるなど）に Thundering Herd

「推測するな計測せよ」という格言がよく知られています。この格言は（ISUCONに優勝した）Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 UNIX哲学 on Wikipedia このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。 正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果が

ISUCON7本選の出題を担当した @methane です。参加者の皆様、お疲れ様でした。 すでに Twitter でアナウンスされているとおり、本選の問題を Github で公開しています。 ▼isucon/isucon7-final すでに一週間以上経ってしまいましたが、この記事では本選の問題設計や攻略ポイントについて解説していきます。 お題について予選では、夏期講習参加者や過去問を練習してきてくれた学生チームにいじわるな問題設計にならないようにと考えていました。（残念ながら失敗していた部分も多かったですが） 一方本選では、そういった気遣いを一切無視して自分たちの得意な分野の問題を出そうということで、MOゲームをお題に選びました。 「協力してレイドボスを殴るゲームにしようか。」 「ボスのヒットポイントは無限にして総与ダメージをスコアにできないかな。」 「攻撃スキル、バフ／デバフスキルみ

まずは、素晴らしい問題と素晴らしい会場、素晴らしいインフラを提供してくれた運営に関わる皆様、本当にありがとうございました。 また、腰の重い僕を引っ張ってくれた会社の同僚の皆さんありがとう。 ISUCON7に同僚のmizkei とsuzukiとMSAで参加して優勝してきました。 勝因はこれです。 脳筋使うんで朝食はプロテインにしました #isucon— kensaku araga (@ken39arg) 2017年11月24日 というのは冗談ですが、初参加のため過去の大会のことはわかりませんが、今回の問題は僕たちのチーム編成にとってとにかく相性が良かったというのが大きかったです。 チーム編成や基本的な作戦については下記の予選のブログに書いていますが、今回の問題はインフラはほとんど関係なく、膨大かつ複雑なアプリをどうするかみたいな感じで、手数を打てる僕らに有利だったと思います。 ken39ar

ISUCON7予選一日目 一位通過しました ISUCON7 ISUCONとは お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。 運営の方々のご尽力もあり、今年のISUCON7も無事開催されました。 ISUCON7 開催&日程決定 本当にありがとうございます。 1日目、2日目共に開始時刻が遅延することにはなりましたが、競技中は問題はなく、快適に開発をすることができました。 遅延している間、チームでは、「今どんな発言も運営の人にとってはノイズみたいなものだから、黙って待って、開催出来たら感謝、振替で参加できなかったとしても、ここまで頑張ってくれたことに感謝しよう。」という話をしていました。 無事開催され、本当に運営の方々には感謝しています。 チー

ISUCON7優勝しました ISUCON7 ISUCONとは お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトル、それがISUCONです。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。 運営・主催・協賛・関係者の皆様、非常に楽しいイベントでした。 本当にありがとうございます。 本戦 試合開始前 まず会場に行く途中に不幸な事故がありました。 はー、先週買ったばかりのスマフォ落として、傷がついた テンションが消えた— Kta (@mizkei11) 2017年11月24日 本戦の問題 本戦の問題はクッキークリッカー+ソーシャルなゲームでした。 部屋を作成し、作成した部屋に入った人達で椅子をクリックして、アイテムを購入する。 そして、クリック/購入を部屋の参加者全員に伝えるためにwebsocketでほぼすべての通信をおこ

Speee社でISUCON7の復習会をやったのでその資料を公開します。 ISUCON7復習会 2017/11/08 at Speee Lounge. original repo: https://github.com/isucon/isucon7-qualify 概要 ISUCON7の予選突破組の上位陣の戦略をいくつか分析してみました。 †空中庭園†《ガーデンプレイス》 repo: https://github.com/ryotarai/isucon7q http://eagletmt.hateblo.jp/entry/2017/10/24/010832 https://mozami.me/2017/10/24/isucon7_qualify.html スギャブロエックス repo: https://github.com/gfx/isucon7-qualify http://memo.su

とてもとても悲しいので、とりあえずやったことと言い訳を書いて気を紛らわせることにする。 敗北した身でグダグダ言うのが格好悪いことは百も承知だが、人間には魂の救済が必要であることをご理解いただきたい。 序盤〜方針決定 最初パスワードのコピペミス等でサーバーからガンガンBANされて、そもそもログインできなくなる。これで10分から20分ぐらい無駄にした気がする。 テザリングにIPを切り替えたり、他のノードから入ったりして、何とか公開鍵でログインできる環境を整える。 適当にベンチ流してスコアを取る前に、nginxのログ設定や構成を確認しalpを使って集計できる準備を整えた。デフォルト実装とRuby実装でベンチを流す。その裏で実装を一通り読む。 ざっくり図を書いて、相談。とにかく/iconsを何とかしないと話が進まないので、静的ファイルとして書き出してCache-Controlだよね、までは即決。

ISUCON7予選に「railsへの執着はもはや煩悩の域であり、開発者一同は瞑想したほうがいいと思います。」チーム (@cnosuke, @rkmathi, @k0kubun) で参加し、217,457点で予選通過だったようです。 正確な値は覚えてませんが、Best Scoreは25万くらいでした。 最終形の構成概要 appサーバ1 puma 16スレッド: 画像のアップロード/表示、雑多なリクエスト対応 puma 2スレッド: GET /fetch だけ返す appサーバ2 puma 16スレッド: 雑多なリクエスト対応 (画像はnginxがサーバ1に流す) puma 2スレッド: GET /fetch だけ返す DBサーバ MySQLがいるだけ サーバ1, サーバ2をベンチマーク対象にしていました。この構成なのは GET /fetch がスコアにカウントされないため、それ以外にほとんど

あー、負けたー。「Asakusaの方から来ました」というチーム名で、Asakusa.rbでよくいっしょする @joker1007 さん、および @yancya さんと出た。最終結果は111400くらい? ただし20時*1を過ぎても4〜6万くらいをうろうろしてて、最終的には20:10頃に入れた変更でスコアが倍になり、なんだこれー? と言ってる間にタイムアップした。 去年のISUCON6決勝はやるべきことをやれなくて負けたので素直に悔しかったけど、今年はなんか問題設定の意図がまったくわからなくてそのまま不完全燃焼で手が停まって4時間経過で死んだという感じなので、なんだかなー、という気分。あんま疲れないまま終わってしまった。 なんか、なんで自分があーって思ってるかはわかった。keep-aliveをなかなか切ってくれないエンドユーザクライアントがたまに混ざってくれることはあるかもしれないけど、CD