ISUCON公式Blog

WINNER'S PRIZE \1,000,000



   

こんにちは、櫛井です。
エンジニアの皆さんお待たせしました!色々ありましたが正式に ISUCON5 開催決定です!やったー!

isuconlogo_2


ISUCONとは

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

ってやつです!
今回もLINE株式会社にてイベントの企画・運営・会場・賞金提供などを行います。本選用サーバは今年もテコラス株式会社さまにご提供いただきます。気になるアプリ提供(出題)は、トレジャーデータ株式会社さまにご協力いただく事となりました。ありがとうございます!
基本的には@tagomoris氏、@kamipo氏が担当される予定ですが、問題作成時、いくつかの言語については課題アプリケーションの実装をお手伝いいただける方を募集します。対象の言語はPython, PHP, Javaなどを予定しています。(お手伝いいただく場合はISUCON5に参加できません。また応募がない場合は予選・決勝における参考実装が提供されない可能性があります)

優勝賞金は今年もドドンと100万円!そしてなんとなんと準優勝も賞金30万円(予定)と超ウルトラ太っ腹コンテストとなっております!皆様、ふるってご参加ください。昨年の予選参加数185組を上回っていただけると運営的にはとても嬉しいです。

過去の開催模様はこちらをご覧ください
ISUCON4 本選リアルタイムフォトレポート 【更新終了】 : ISUCON公式Blog
第三回 #isucon 本選リアルタイムフォトレポート【更新終了】 : ISUCON公式Blog
#isucon2 リアルタイムフォトレポート 更新終了 : ISUCON公式Blog
写真と動画で振り返る #isucon オフィシャルレポート : ISUCON公式Blog

開催概要

今年も2〜3名1チームでの参加制としますが、より多くの方にISUCONへご参加いただきたいので予選を設定させていただきます。今年の予選は Google Cloud Platform上にて行います。Googleさまからは、予選期間で利用できるクーポンをご用意いただけることになりましたので、参加予定の方はアカウントの準備や使い方の予習などをしておいてください。

本選への出場枠ですが
・オンライン予選 TOP20チーム
・学生枠 5チーム
・運営枠 2チーム(LINE選抜チーム、テコラス選抜チーム)
の合計27チームを予定しています。

学生枠はチームメンバーが全員学生であること(休学中でもOK)を条件とさせていただきますが、オンライン予選にはご参加いただく必要がありますのでご注意ください。

本選会場はLINE株式会社ヒカリエオフィスのカフェとなります。本選参加は当日渋谷ヒカリエにお越しいただける方のみとします。オンラインでの参加は不可とします。

予選と本選でチームメンバーの交代は出来ません。予選を3名で参加、本選を2名で参加するといった形はOKです。


オンライン予選の概要と開催日

オンライン予選の方式は以下を予定しております
  • 予選はGoogle Cloud Platform(GCP)のCompute Engineを利用
  • 出題者側で作成したお題アプリ、ベンチマークツールが乗ったマシンイメージを公開
  • 各参加チームが自分のGCPアカウントでそのマシンイメージを起動
  • 出題者側で発行したAPI key(文字列) を入力してベンチマークツールを設定
出題内容は当日発表となりますが、詳細なレギュレーションや予選の参加申し込み等については予選開催日の1ヶ月前を目処に発表予定です。

予選の開催日は
9月26日(土)、27日(日)の二日間のいずれか、それぞれ10時〜18時の時間帯固定とします。日程をずらしての参加は出来ません。参加申し込み時にどちらかを申請していただきます。
参加費は無料、Google Cloud Platformを利用する料金は予選参加者負担となりますが予選期間での利用額をカバー出来る程度のクーポンをご用意いただく予定です。(十分な数を用意する予定ですが、万が一にも参加チーム数が予想を超えた場合は足りなくなるかもしれません。その場合はご容赦ください)


本選開催日

10月31日(土) LINE株式会社 渋谷ヒカリエオフィスにて開催となります。
当日は10時から開始、懇親会も予定しておりますが詳細は追ってお知らせいたします。予定を空けておいてくださいませ。


よくありそうな質問

順次追加しますので、質問などは Twitter @941 までお願いします。DMでのやりとりがよければフォローいたしますのでMentionを飛ばしてください。

Q.予選は渋谷まで行く必要ありますか?
A.オンライン上で完結しますのでお越しいただく必要はありません。希望者にはLINEの渋谷オフィスのカフェエリアを会場提供する予定です。

Q.1社あたり何チームまでとか制限ありますか?
A.ありません

Q.前回のチャンピオンと対決したいのですが
A.過去開催回の優勝チーム所属者はそれぞれ出場が可能となっております(出題者を除く)

Q.予選はどんな問題ですか?本選はどんな問題ですか?
A.予選については随時お知らせします。過去問はそれぞれのまとめページから参照してください。
ISUCON1 まとめ : ISUCON公式Blog
ISUCON2 まとめ : ISUCON公式Blog
ISUCON3 まとめ : ISUCON公式Blog
ISUCON4 まとめ : ISUCON公式Blog


予選の告知は改めて行いますので、参加しようかと思っている方はチームメンバー予定の方にお声がけし準備をしておいてください!それまで過去問にチャレンジしたり、感想エントリを見て当時の対策方法を探ったり、何かしらの素振りをしておいてください!今年も宜しくお願いします。
Read more...

みなさんこんにちは。ISUCON4 出題担当チームの mirakui です。

2014年11月に行われた ISUCON4 本選ではテコラスさん提供のホスト上に用意された VM で競技を行いました。今回、本選の VM に似た環境を再現する AMI を用意しましたのでご紹介いたします。

AMI

本選環境を再現するために、2つの AMI を提供します。1つはチューニング対象アプリケーション用の AMI 、もう1つはベンチマーカー用の AMI です。

  • アプリケーション AMI
    • ami-86e8e287
  • ベンチマーカー AMI
    • ami-84e8e285

アプリケーション AMI は、本選で参加チームに3台ずつ提供された VM とほとんど同じ内容です。

ベンチマーカー AMI は、ベンチマークサーバを再現するもので、 benchmarker の実行ファイルと、本選で実際に用いられた動画ファイルのセット(13GB程度)が入っています。

推薦環境

本選の競技環境に近づけつつ、安定したスコアを得るため、以下の環境で試すことを推薦します。

アプリケーション用インスタンス(1〜3台)

  • インスタンスタイプは c3.large
    • ただし、カーネルパラメータによって 2 cpus / 1GB memory に制限されている(後述)
  • EBS は gp2 (general purpose SSD) 80GB
    • standard (magnetic) タイプだと性能の個体差が激しく、ガチャ問題が発生するため

アプリケーション用インスタンスは1台から3台のうち好きな台数を立てて下さい。初期状態の参考実装では複数台のアプリケーション用インスタンスがあっても無意味なので、最初は1台だけで充分でしょう。

なお本選では、VM3台のうち1台が 1 cpu 、のこり2台が 2 cpus で提供されました。この条件を再現するために、アプリケーション用インスタンスを3台立てる場合は、そのうち1台の /etc/grub.conf を編集して maxcpus=1 にしてください。詳細は後述します。

ベンチマーカー用インスタンス(1台)

  • インスタンスタイプは c3.2xlarge (8 cpus / 15GB memory)
    • 合計13GB程度の動画ファイルをメモリに展開する必要があるため

なお、インスタンス間のネットワークレイテンシを安定させるため、ベンチマーカー用1台およびアプリケーション用3台のインスタンスは、すべて同じ Availability Zone で起動してください。

もっとこだわる方へ

AWS に詳しい方は、上記の推薦環境に加えて、 Placement Group や Dedicated Instance の利用、インスタンスタイプの変更、 EBS Optimized オプション、Provisioned IOPS EBS 等を試してみてもいいと思います。そのようなスコアをブログ等で公開する場合には、利用したテクニックを明示しましょう。

カーネルの起動パラメータによる性能の制限

EC2 は、性能の高いインスタンスほどネットワークや CPU 等の性能が安定するように作られています。本選では非常に貧弱な VM 環境(1-2 cpus / 1GB memory)があえて使われたのですが、これを再現する EC2 インスタンスとして t2.micro などの貧弱なインスタンスタイプを使ってしまうと、性能が安定せず、スコアの再現性が非常に低くなることが予想されます。

そのような事態を避けるため、今回の AMI 提供では、推薦環境として c3.large という比較的高性能なインスタンスを指定し、その代わりにカーネルの起動パラメータで CPU 数とメモリ容量を制限するという方式を採用しました。

カーネルの起動パラメータは /etc/grub.conf に記述してあります。

(/etc/grub.confから抜粋)
kernel          /boot/vmlinuz-2.6.32-431.29.2.el6.centos.plus.x86_64 root=LABEL=ROOT ro consoleblank=0 console=ttyS0 maxcpus=2 mem=1G

「maxcpus=2 mem=1G」の部分で制限を指定しています。この maxcpus を 1 に変更してインスタンスを reboot することで、CPU 数を 1 に減らすことができます。

ベンチマークの実行

インスタンスを立てたら、ベンチマークを実行してみましょう。各インスタンスには、インスタンス作成時に指定した鍵ペアを利用し、 root ユーザで SSH ログインすることができます。ログインしたら isucon ユーザに su してください。

実際の本選とは異なり、ベンチマーカー用インスタンスから benchmarker の「bench」コマンドを利用してアプリケーション用インスタンスに負荷走行を実行します。本選競技で利用した「remote」コマンドは使えないので気をつけて下さい。

(ベンチ―マーカー用インスタンス)
$ su - isucon
$ pwd
/home/isucon
$ ./benchmarker bench --hosts=XX.XX.XX.XX --workload=1
[2014-12-28 13:13:13] アセットデータを事前ロード中です...
[2014-12-28 13:25:04] 初期化エンドポイントへ POST リクエストを送信しています...
[2014-12-28 13:25:05] 初期化完了
[2014-12-28 13:25:05] ベンチマーク開始
[2014-12-28 13:26:05] ベンチマーク完了(1m0.000371136s)
[2014-12-28 13:26:25] レポートの検証開始
[2014-12-28 13:26:25] レポートの検証完了
[2014-12-28 13:26:25] 結果を JSON 形式で標準出力へ書き出します
[2014-12-28 13:26:25] 得点: 1000.00 (加点: 1000.00 / 減点: 0.00)
{
  "errors": {},
  "score": {
    "fail": 0,
    "success": 1000.00,
    "total": 1000.00
  }
}

負荷走行の初回は、メモリに 13GB の動画ファイルを読み込むので、「アセットデータを事前ロード中です...」が表示されてから5〜10分程度かかります。2回目からは OS のページキャッシュが利用されるため、30秒程度で負荷走行が開始されるようになります。

「--hosts」オプションでは、負荷走行を行なう対象のアプリケーション用インスタンスの IP アドレスをカンマ区切りで指定します。IP アドレスはベンチマーカー用インスタンスから 80 番ポートが疎通するものにしてください。複数の IP アドレスを指定した場合は、その中からラウンドロビンで切り替わりながらリクエストされます。

「--workload」オプションでは負荷走行の並列度を 1 から 8 の中で指定することができます(デフォルトは1)。

「bench」コマンドの help は以下のコマンドから参照することができます。

$ ./benchmarker help bench

実際の本選でもそうであったように、アプリケーション用インスタンスにもベンチマーカー用インスタンスのものと全く同じ benchmarker のバイナリが同じパスに置いてあります。これを使って負荷走行をローカルに対して実行することができますが、動画セットがベンチマーカー用インスタンスのものとは異なるので、あくまで動作確認での利用にとどめてください。

その他の操作方法

参考実装の切替方法や、アプリケーションの使い方などについては、本選とまったく同じです。以下のマニュアルを参照して下さい。

ISUCON4 本選 AMI マニュアル

レギュレーション

レギュレーションは本選のものに準拠します。

ISUCON4 本選レギュレーション

ソースコードの公開

本選の参考実装およびベンチマーカーのソースコードは以下の GitHub リポジトリで公開しています。

GitHub: isucon/isucon4

注意事項

ISUCON4 本選の解説と講評 でも書いたように、本選では1チームに与えられた3台の VM は1つの物理ホストに入っているという状況でした。このため、VM 間では非常に低いネットワークレイテンシが得られました。EC2 でも Dedicated Instance (ハードウェア専有インスタンス)を利用することで近い状況にすることはできますが、比較的高価なオプションのため利用は自己責任でお願いします。先にも書きましたが、AWS の様々なオプションを利用してパフォーマンスの最適化をした際のスコアをブログ等に書く場合は、利用したテクニックを明示しましょう。ISUCON は AWS に詳しい人のためだけのものではないので、AWS のオプションを駆使して本選の再現性を追求するよりは、あえてセットアップが簡単な最低限の設定を推薦環境としました。

おわりに

AMI について質問や不具合などありましたら、isucon4 リポジトリの issue か、 @mirakui までご連絡ください。

それでは、本選に参加された方も、そうでない方も、ぜひ ISUCON4 の問題をお楽しみ下さい!

Read more...

ISUCON4本選の振り返り

こんにちは。ISUCON4 出題担当スタッフの mirakui です。
あの盛り上がった本選から約一ヶ月が経過してしまいましたが、本選について振り返ってみます。

ISUCON4 の予選は、参加チーム180組以上という過去最大の規模でしたが、本選に出場できたのはその中のたった30組でした。この倍率の高さからも激戦であったことは想像に難くないと思いますが、一体どのような問題で、どのような戦いだったのでしょうか。

テーマは「動画広告配信」

本選問題のテーマは、「動画広告配信」でした。広告リクエストに応じて表示すべき動画クリエイティブを抽選し、5MB 程度の mp4 ファイルを出力するという問題です。

この問題には以下の内容が含まれていました。

  • 広告主が動画広告を入稿する API。おもに以下の情報を POST する
    • 広告動画ファイル
    • ユーザが広告(リダイレクタ)をクリックした時のリダイレクト先 URL
    • 広告枠の ID
  • 広告表示 API。広告の抽選を行う
  • ユーザが広告をクリックしたときのリダイレクタ API
  • インプレッション数のカウンタをインクリメントする API。インプレッションが発生したときに XHR で呼ばれる想定
  • 動画ファイルを返す API
  • 広告主向けにクリック数、インプレッション数を集計してレポートする API。レポートは速報レポートと最終レポートの2種類があり、それぞれ集計の内容が異なる

アプリケーションの概要は上記の通りで、Ruby 参考実装では約230行程度の規模でした。

また、参加者が動作確認をするための簡単な HTML を用意はしていましたが、ベンチマーカがアクセスするためのフロントエンドは無く、JSON API のみから構成されたアプリケーションでした。

本選レギュレーションと当日マニュアル

本選では、以下のドキュメントを競技者に配布しました。これらに目を通していただくと、当日の雰囲気が伝わるかもしれません。

競技環境

本選の競技に用いるサーバ環境は、テコラスさんが提供して下さいました。

今回の競技用サーバは1チームに3台(VM)ずつ提供され、全ての VM には同じようにアプリケーションがセットアップされていました。この3台をどのように使い分けてもいいし、1台だけでもいいというレギュレーションでした。ただ、参考実装では複数のホストで動作するようには作られていないので、3台で負荷分散するためには何らかの工夫をする必要がありました。

負荷走行は全チームで共有のベンチマークサーバから行ないました。ベンチマーカには、負荷走行を行う対象 VM の IP アドレスを1つ以上指定するという方式になっており、3つの IP アドレスを指定した場合は3台にラウンドロビンで負荷がかけられるという仕様になっていました。

競技環境の VM について、1台あたりのおおまかなスペックは以下のとおりでした。

  • OS: CentOS 6.5
  • CPU: 仮想 2 core (ただし1台のみ 1 core)
  • メモリ: 1GB
  • HDD: 80GB

本選では3台の VM を「1号機」「2号機」「3号機」と呼んで提供していましたが、このうち「1号機」だけは CPU が 1 core しかなく、他の2台は 2 core あるというちょっとした「ひっかけ」を用意していました。物理ホストの関係でこの方が都合がよかったためです。

今回の競技環境の特徴は、動画広告配信というテーマに比べて非常に貧弱な環境であったことが特徴といえます。特に、メモリが 1GB しかないため、参考実装を動かすのもギリギリという状況でした。

ちなみに、競技中には公開していませんでしたが、物理ホストは各チームで1台ずつを専有するようにしてありました。すなわち、1チームに提供された3つの VM は必ず1つの物理ホスト上に立っていました。
また、こちらも競技中には公開しなかった情報ですが、ベンチマークサーバと各チームの物理ホストとの間のネットワーク帯域は 1Gbps を確保していました。

ISUCON の出題傾向と歴史

ISUCON は競技者同士の戦いであるのと同時に、出題者と競技者の戦いでもあります。

ISUCON の歴史を遡ると、ISUCON1,2 ではキャッシュ戦略の台頭がありました。これは、ビューのレンダリングを巧みにキャッシュすることでスループットを飛躍的に向上させるというものです。実際のウェブアプリケーションのパフォーマンス改善でもよくある戦略と言えます。このような戦略の対策として、出題側はキャッシュしにくいアプリケーションにする工夫を凝らし始めました。

ISUCON3 あたりから、オンメモリ戦略をとるチームが現れ始めました。Go などの高速な処理系を使って、RDB を使わずに全て1プロセス内のオンメモリで返してしまうことで高速化するという技法です。多くの場合、参考実装を捨ててアプリケーションをすべて書き直す必要があるので、競技時間中にこれを実現するのは簡単ではありませんが、うまくいけばキャッシュの難しいアプリケーションでも高得点を期待できます。

オンメモリ戦略への対策

今回の本選では、このオンメモリ戦略への対策を積極的に講じました。その対策は主に以下のとおりでした。

  • 1台あたりのメモリが少なすぎる(1GB)
  • そもそも最初から Redis を用いたオンメモリな参考実装にしてある

いままでの ISUCON ではアプリケーションのバックエンドとして MySQL を使ってきましたが、今回は初めて MySQL を使わずに、 Redis のみを使っています。

参考実装では、なんと、広告主がアップロードした動画ファイルはすべて文字列として Redis に格納するというむちゃくちゃな設計になっています(実際の業務でこんな設計をしたらお説教ものなので気をつけましょう!)
そんな実装のせいで、初期状態では負荷走行を1度走らせるとスワップアウトが激しく発生するという状況に仕上げてありました。

そんなわけで、多くのチームが Redis に入ってくる動画を適宜ディスクに書き出すように書き換えるところからチューニングを始めたと思われます。ディスクにあるものをメモリに載せるのはよくあるチューニングなので、あえてそれと逆のことをさせるというのが今回の出題意図の一つでした。

ベンチマーカと Cache-Control ヘッダ

本選の競技が始まってしばらくすると上位チームのスコアが軒並み8,000点〜9,000点あたりで停滞しはじめ、終盤まで先頭集団のスコアが団子状態になるという事態が起こりました。

その原因は、ある程度の動画配信スループットになるとベンチマークサーバのネットワーク帯域が頭打ちになってしまうためでした。そのような理由で、9,000点を超えたあたりからスコアがほとんど伸びませんでした。

実はこの状況には打開策が用意してありました。それはベンチマーカが Conditional GET に対応していたという点です。大きくネットワーク帯域を消費する動画配信のレスポンスに、Cache-Control ヘッダを適切に指定することで、ベンチマーカは内部的に動画をキャッシュするようになります。出題側の意図としては、この挙動は、実際の動画ファイル配信では通常 CDN が用いられるということを模倣したものでした。ベンチマーカのこの挙動に気づくことができれば、飛躍的にスループットが上がり、スコアを10万点以上に引き上げることができました。

我々出題スタッフは、多くのチームが上記の Cache-Control を設定するだろうと予想し、高スループットの戦いが始まることを期待して、ベンチマーカやレギュレーションを調整していました。しかし、出題側のヒントの与え方が適切ではなかったこともあり、残念ながらこの仕様に気づくことができたチームは1位の「生ハム原木」と2位の「チームフリー素材」のみでした。結果として共有ベンチマークサーバの帯域が詰まりがちになり、参加者の皆様にストレスをかけてしまったという反省点があります。

今回の本選は、前述の Conditional GET の挙動が不条理であったという指摘を何名かの参加者から受けており、出題チーム一同、実際にそのとおりであったと反省しております。また、競技序盤に多くの不具合が発生し、十分な競技運営ではなかったことも含め、あわせてお詫びいたします。

もっと ISUCON4

ISUCON4 をまだまだ楽しみ足りない皆様のために、本選の環境を再現できる Amazon AMI を準備中です。近日中に公開予定なので、もう少々お待ちください。

なお、宣伝で恐縮ですが、私 mirakui が主催している Podcast Admins Bar において、 ISUCON4 出題チームの @rosylilly, @sora_h に加えて @941 さんをお呼びし、 ISUCON 4 の裏話を収録したので、よろしければお聞き下さい。

また、 2014/12/10 には LINE 株式会社のカフェスペースで ISUCON Makers Casual Talks : ATND というイベントが開催されます。今回の我々を含む歴代の出題者達が登壇し、ビールを飲みながら語るという会です。これを書いている現在すでに定員に達していますが、年末でキャンセルも発生しやすいと思いますので、諦めずに補欠登録してみてください。

おわりに

過去の ISUCON では参加者として楽しんできましたが、今回は出題側として、貴重な体験をすることができました。至らない我々の出題が競技として成立したのは、ひとえに参加者の皆様が支えてくださったからです。本当にありがとうございました!

Read more...

↑このページのトップヘ