ISUCON公式Blog

WINNER'S PRIZE \1,000,000



商標「ISUCON」利用の
ガイドラインはこちら
スポンサー各社からの応援特設ページ ISUCON10 個人スポンサー

こんにちは。株式会社サイバーエージェント プライベートクラウドグループの中西 (@whywaita
) です。2020年9月と10月に行われたISUCON10へ、サイバーエージェント プライベートクラウドグループとしてインフラ提供を行いました。

今回はプライベートクラウドのチームが2020年のISUCONにインフラを提供した裏側についてご紹介します。本記事では準備編として、インフラ視点のISUCONについて、及び我々が行った事前準備について触れます。

インフラ提供のはじまり

私がISUCON8で優勝したのち、ISUCONコミュニティ還元のためインフラ提供として関わりたいという気持ちが大きくありました。
その後、ISUCONの運営であるLINEの941さんに最初にお声がけさせて頂いたのが2019年2月、その後弊社内の交渉を経てISUCON10での提供が決定しました。

本当はISUCON9での提供で話が始まったのですが、私の力及ばずスキップとなってしまい、次回こそはということでISUCON10でのインフラ提供となりました。

最初に941さんとの個人的なやり取りがはじまり、インフラ視点では次のタイムラインで進みました。

  • 2019/11/27 最初に941さんからメールをいただく
  • 2019/12/17 941さんとサイバーエージェント側で初回ミーティング
    • 過去開催でのインフラ規模感の共有
    • サイバーエージェント側で実現するためのスペック選定
  • 2020/01/30 サイバーエージェントがインフラ提供として参加確定、運営Slackに参加
    • 「今年は予選を1日開催にしようと思ってるんですが、いけますかね…?」「サーバ台数が単純に倍になりますね!?」
  • 2020/03/26 キックオフミーティング
    • 実際に利用する物理的なキャパシティを問題チームへ共有
  • 2020/03 〜 ISUCON用プライベートクラウド基盤開発開始
  • 2020/09/12 予選開催日
  • 2020/10/03 本選開催日

ISUCONにおけるインフラについて

ここで改めて、ISUCONにおいてインフラ提供を行う人間が何を準備しているのかについておさらいしましょう。

過去10回の中である程度の変遷がありますが、近年のISUCONでは「参加者が問題用に用意されたVirtual Machine (VM) にログインを行い」「Webポータルから実行したベンチマーカーがアプリケーションにアクセスしスコアを決定する」という形で競技が行われています。
過去回では問題用VM上でベンチマーク用のバイナリを実行する形式も存在しましたが、近年はベンチマーク用にVMを別に用意しておき、そのVMからのHTTPリクエストを捌く形式が採用されています。

また、問題用のVMも当初は1台でしたが近年のWebアプリケーションの変遷を反映し予選本選ともに複数台構成での出題となっています。最初期はlivedoorさんを始めとしてオンプレミスでのインフラ提供でしたが、参加者が500名を超えたあたりからパブリッククラウドやパブリッククラウドを提供する事業者のインフラ提供が多くなってきました。

直近で近い構成だとISUCON8にてGMOインターネット様がConoHaを拡張した基盤で提供されていたのが珍しい例でした。 https://hoscon.gmo.jp/blog/1080/

我々は社内のエンジニアに向けてクラウドを提供する「プライベートクラウド」を日々運用しています。普段、参加者の皆さまが利用していない環境であるため、競技の進行に影響が出ないよう様々なレイヤーから検討を行いました。

物理構築編

今回のISUCON10は1日開催ということもあり、参加チーム数の上限について検討が必要でした。
ISUCON9では600チームが上限となっていましたが、2日開催が1日開催になったからと言って単純に半分の300チームとしてしまうと参加できる人数が減ってしまいます。
せっかくのお祭りですから、1日開催ではありますができるだけ多くの方が参加できるよう早い段階から検討を行っていました。

インフラとしては最大限用意できるスペックを、ということで次のようなハードウェアを用意しました。

サーバ部門

次世代クラウド基盤用に利用する予定で検証を進めていたAMD EPYCシリーズのRome世代マシンを予定よりも早く調達しISUCON用に利用しました。

調達時点で最も高速であったx86アーキテクチャCPUです。Discordなどで言及いただけてとても嬉しかったです。予選では1コアのみEPYC割り当てたVMでしたが、たしかに謎でしたね……。
  • 競技用マシン: DELL PowerEdge C6525 x 24 Node
    • CPU: AMD EPYC 7352 24-Core Processor x2
    • Memory: 64GB x 16
    • NIC: Intel XXV710 (25Gbps SFP Dual Port), bondingで利用
    • Disk: オンメモリブートのため搭載せず
  • 管理用マシン: SuperMicro 2124BT-HTR x 8 Node
    • 性能は競技用マシンと同等

スペック上は競技用マシンと管理用マシンともに同じものでしたが、競技用に提供するものに関しては全て同じベンダーとなるよう調整しました。基本的には起こりえないのですが、ベンダー間で何らかの性能差が出てしまうことを回避するためにこのような割り振りをしていました。

管理用マシンは以下のような用途として利用していました。

  • 作問 & 言語移植チーム向けのVM
  • 参加者の踏み台用サーバ (物理2台の冗長構成)
  • クラウド基盤のコントローラ (後述)
  • 監視用のPrometheus
  • 問題作問用のGitHub Actions self-hosted runner


  • ネットワーク部門

  • ファイアウォール: Juniper Networks SRX5400 x1
  • スイッチ: Huawei CE8850 100GE x2

  • 基本的には次期基盤で利用するための予備部材で構築しました。

    ストレージ部門

  • ストレージアプライアンス x4
  • VM用ストレージ実容量: 130TB all flash (NVMe)
  • ネットワーク: 100Gbps x4
  • I/O Per Seconds: 約10万IOPS

  • 2台で1クラスタとなるアプライアンス製品を2クラスタ用意しました。競技用マシンとはiSCSIで接続し、ブロックストレージとして利用していました。

    収容ラック部門

    上記の物理機材を弊社管理のラック2つに収容しました。当初は1ラックの予定だったのですが、参加者全員がフルにCPUを利用した場合にも電源容量が足りるよう万全を期すために2ラックに収容しました。

    こちらは実際のラックの写真です。弊社DCチームは普段からとても綺麗なケーブリングをされているのですが、「のちのちインターネットに公開するので写真を撮りたい」という話をしたところ気合が入り最高のケーブリングになりました。
    rack_front
    rack_back


    今回採用したマシンは2Uに4Node搭載できるタイプであり、背面で利用するケーブルの本数も相当な数になります。
    そのケーブル群を運用しやすく美しくまとめる職人芸をお楽しみください。

    今回のアーキテクチャ

    今回は次のようなアーキテクチャでインフラ基盤を構築していました。あまり特殊なことはせず、素朴な物理アーキテクチャで安全側に倒していました。また、ISUCON8でのGMOさん提供時の構成は大幅に参考にさせていただきました。

    topology


    ベンチマーク用のVMを各チーム1つずつ用意することにより、いわゆる「ベンチ待ち」という事象が起こりえないような設計を行っていました。
    これによりベンチマークのトラフィックが1つの物理筐体内で収まるため、ネットワーク機器のキャパシティによってスコアの変動が起きにくいようにすることができました。

    結果として、今回は「問題用VM 3台」「ベンチマーク用VM 1台」「踏み台用VM 2台」の合計6台を1チームあたりに割り当てており、500チームが参加した予選では総計3000台前後のVMを提供していました。

    ネットワークについて

    今回は弊チームの管理するAS24284よりインターネット接続性を提供しました。AS24284からの経路広報情報を注意深く観察していた方がもしいらっしゃれば、ISUCONで利用したサブネットが開催前後に経路広報されたことが分かったのではないかと思います。

    BGPの経路広報ログを提供しているRIPE NCCのRIPEstatでの観測結果を引用します。5月ごろにBGPの経路広報を開始、本選終了後の10月26日ごろに経路広報を終了しました。

    ripestat_bgplog


    今回はSSHの入口のためだけのVMを各チームごとに用意しておき、インターネットからそのVMを経由してISUCON環境にログインしていただく方式を採りました。SSH踏み台と呼ばれる古来から存在する方式なのですが、近年クラウドの隆盛によって使ったことがないという方も多くいらっしゃったようでした。実際に予選開催中にはSSH接続に関するお問い合わせを数件いただきました。

    そのような方がいらっしゃると想定し、予選本選の当日マニュアルには次のように踏み台を利用する
    ssh_config(5)
    例を示していました

    チーム間の性能差について

    ISUCONは与えられた同一のコードを同一のスペック上で動かすことで平等にベンチマークのスコアを設定することが可能となる競技であるため、提供する際に各レイヤーでチーム間の性能差が出ないよう検証を行いました。
    ISUCON8でのアーキテクチャを踏襲するとしてもCPU性能に本当に差が出ないのかを確認するため、UnixBenchや過去のISUCON開催のコードを用いて性能差を比較しました。

    一例として、EPYCにおけるSimultaneous Multi-Threading (Intel CPUにおけるHyper Threading) を用いたときに物理コアと論理コア間で性能差がでないのかについて、UnixBenchを用いた検証結果について公開します。
  • AMD RomeにおけるHyper-Threading(SMT)の検証.pdf


  • いくつかの検証結果をもとに、自チーム及び他チームの状況次第で1つのVMの性能が上下しないようなチューニングを行いました。

    結果としてBIOSなどの設定変更を加味した上で"物理コア2コアと論理コア2コアを各チーム占有とする"という方式を採用しました。予選開催時は問題解答用として1コアを3台、ベンチマーク用として1コアを1台の合計4台が必要だったため、チーム占有コアを各VMに割り当てていました


    まとめ

    ISUCON10でのインフラ提供に向けての準備段階に行った検討事項などについてお届けしました。

    ISUCONにおいては参加者並びに利用するVMの数が多い予選こそが本番と言っても過言ではありません。多くの参加者にご利用いただいてもインフラ的な問題がでないよう議論を重ねてISUCON10インフラは完成に向かっていきます。

    後編では提供するまでの道のりや、予選本選にて起きた出来事についてお届けしますのでお楽しみに。

    公開されました、こちらです!
    ISUCON10にインフラ提供として参加しました 提供編 | CyberAgent Developers Blog
    Read more...

    こんにちは、ISUCON10 の本選出題を担当した白金動物園の mirakui です。最近はパン作りにハマっています。この記事では、本選問題であるアプリケーションの「XSUCON」について、問題の概要と想定していた解き方について解説していきたいと思います。

    XSUCON とは

    近年の ISUCON にはとても多くの方が参加してくださり、スコアランキングを表示したりベンチマーカー実行を指示したりするいわゆる「ポータルサイト」の負荷対策には毎年の出題担当たちが苦労してきました。記念すべき 10 回目の開催である ISUCON10 ではぜひこの ISUCON ポータルサイト自体を問題にしたい、と私たち白金動物園が1年前から温めてきた構想を形にしました。

    というわけで ISUCON10 の本選問題は「XSUCON」という、 ISUCON を模した仮想的な競技のポータルサイトでした。XSUCON の世界観を表現するために動画まで作ってしまいました。せっかくなので見てください。



    詳しい仕様は下記のマニュアルやソースコードを参照いただければと思います。
    ISUCON10 本選当日マニュアル
    XSUCON アプリケーションマニュアル
    ソースコード (GitHub: isucon/isucon10-final)

    簡単に概要を説明すると、
    1. 最初に仮想選手登録・仮想チーム登録リクエストが押し寄せる(初期状態では10チームで締め切り)
    2. 仮想選手たちが仮想負荷走行をエンキューしたり、仮想運営に質問を投げたりする
    3. 仮想運営は、質問が来たら返答を返す
    4. 仮想選手達は仮想負荷走行が終わったかどうかや、質問の回答が来たかどうかを知るために、通知のエンドポイントをひたすらポーリングしまくる
    5. その間も仮想選手や仮想オーディエンスがスコアのダッシュボードを常にポーリングしまくる
    といったシナリオでした。

    なお本稿および、上記マニュアル等では ISUCON10 本選の用語と XSUCON の用語の混同を避けるため、ISUCON の用語には「実」を、XSUCON の用語には「仮想」をつけて書き分けています。たとえば「実選手」「仮想選手」といった具合です。とってもややこしくておもしろいですね(開発時のコミュニケーションでも常に混乱を招いて大変でした)。

    余談ですが、フロントエンドのコードや API 設計等の多くを本選の実ポータルから流用しています。そのため、ブラウザで見たときの見た目はそっくりです(競技中に見間違えないよう背景色は変えておきました)。

    01
    図1: 仮想ポータルの画面(オーディエンス向けダッシュボード)

    アプリケーションの構成

    本選問題となるアプリケーションは仮想ポータルと仮想ベンチマークサーバという2つのサーバから成り立っていました。仮想ポータルは HTTPS を、仮想ベンチマークサーバは gRPC を採用していました。

    仮想ポータルのフロントエンドは React.js で実装(これはチューニング対象外)したのですが、フロントエンドとサーバとの通信には JSON ではなく Protocol Buffers (以下 protobuf)を利用しました。ですので、仮想ポータルのサーバはあらゆる API レスポンスを protobuf にエンコードして HTTPS で返しています。protobuf を採用したのは gRPC サーバを開発する都合上、全体的に protobuf に揃えたかったというのと、あと本選問題に先行して実ポータルの開発を進めていた sorah の趣味とのことです。protobuf であらゆる API やデータ構造を定義し、仮想ポータル・実ポータル・実ベンチマーカーでバックエンド・フロントエンド通して .proto を共有して開発したところ、開発者間の情報共有やバグの防止においてとても体験がよかったです。

    アプリケーションの前段には Envoy があり、これが仮想ポータルと仮想ベンチマークサーバへのリクエストを振り分けていました。Envoy を採用したのは、gRPC と HTTPS の両方を受けて振り分けたいという今回のユースケースと合っていたからというのと、近年 reverse proxy としての事例も増えてきているので最近のネタとしていいだろうという判断でした。

    問題設計と出題意図

    ここからは、参考実装および実負荷走行シナリオがどのようなチューニングを意図して作られていたかについて解説します。

    スコア設計

    参考:当日マニュアルのスコア計算式

    本選問題のスコアは、「仮想選手・仮想オーディエンス・仮想運営それぞれの視点からの XSUCON の満足度の高さ」がスコアになるように設計しました。これは、ISUCON 3 から参加し続けているチーム白金動物園として、「満足度の高い ISUCON とはどういうものだろう?」ということを議論をして方針を組み立てていきました。その結果として、

    XSUCON の仮想選手の視点では、
    • たくさん仮想負荷走行を実行できること
    • 仮想運営への質問がすぐに返ってくること
    • ダッシュボードが正確かつ素早く表示されること
    仮想オーディエンスの視点では、
    • ダッシュボードが素早く表示されること
    • 大会が盛り上がっている(=たくさん仮想負荷走行が実行されている)こと
      • 仮想負荷走行が実行されるたびに仮想オーディエンスが 1 人増えるようになっていました
    仮想運営の視点では、
    • 多くのチームが参加すること
      • 初期値は10チームですが、100チームまで増やすと仮想選手スコアが最大2倍になるようになっていました(大会規模ボーナス)
    という考え方を基本にスコア計算式ができています。仮想選手の満足度はこの中でも特にスコア比重が高いので、問題を解く上ではいかに仮想負荷走行や質問の回答頻度を上げるかが重要になってきます。

    3台のサーバのリソース

    本選問題では予選と同様に、スポンサーである株式会社サイバーエージェント様のご協力により、競技サーバーとして1実チームあたり3台が提供されました。実選手に対して、特にスペックはアナウンスしませんでしたが、実はこの3台はそれぞれ異なるスペックを有していました。もしこのスペック差に気付いてないと、3台への振り分けをする際に苦しむことになったかもしれません。
    • 競技サーバー1: 1 GB RAM, 2 vCPUs
    • 競技サーバー2: 2 GB RAM, 2 vCPUs
    • 競技サーバー3: 1 GB RAM, 4 vCPUs

    今回はサイバーエージェント様のプライベートクラウドを利用させていただいたので、このように柔軟なリソース割り当てができ、とてもありがたかったです。いわゆるオンメモリ戦術が有利になりすぎないようメモリを少なめにしていましたが、実際のところ 1 GB はきつすぎたようで、ちょっと無理をするとサーバから応答がなくなってしまうような状況にありました。また今回は高い並列性が求められる問題だったこともあってメモリの少なさが言語の差がつく原因の一つになっていたようで、ここに関しては申し訳なく思います。

    静的ファイル配信

    ISUCON10 本選の実ベンチマーカーは Web ブラウザを模した挙動をするように作られていました。 ISUCON10 のために rosylilly が開発した isucandar というベンチマーカーフレームワークを利用しています。

    isucandar は取得した HTML の link 要素、script 要素を解釈し、含まれている外部リソース(css, js)へのリクエストを行います。また、 favicon.ico へのリクエストもいちいちしてくれるのでリアルです。実ベンチマーカーからのアクセスログをじっくり読まれた方は、そのリクエスト群の「それっぽさ」を味わっていただけたかと思います。
    初期状態では上記のような静的ファイル(css, js, favicon.ico, HTML)へのリクエストもアプリケーションで捌いてる状態になっているので、これを前段に nginx 等を置くなどすることでアプリケーションの負荷を下げることができます。

    実ベンチマーカーはリクエストの際に Accept-Encoding: gzip, br, deflate のリクエストヘッダを送っていました。静的ファイルのリクエストはネットワーク帯域を考えるとそれなりに無視できない量があったはずで、nginx 等を用いて static gzip の設定をするか、実は対応していた brotli にしてあげるとかなり転送量を抑えられたかと思います。オススメは(せっかく対応したので) brotli でした……が気付いたチームはいたんでしょうか。また、マニュアルにわざとらしく書いてあるとおり実ベンチマーカーは Cache-Control に対応しているので、 max-age を設定すれば静的ファイルへのリクエスト自体を減らすことができます。仮想オーディエンスは増えるたびに新しいブラウザセッションで訪れてきてそのたびに静的ファイル配信はどんどん増えていくため、これらのような対策をしていないと次第に大きなトラフィックになっていったはずです。

    SQL

    提供された競技サーバーでは MySQL 8.0 が動いており、アプリケーションから利用されていました。初期状態ではこれといったスロークエリは無く、スロークエリログを有効にして張っていてもほとんど出力されなかったと思います。今回の問題では、初期状態ではすべてのテーブルは空の状態から実負荷走行が始まります。そのなかでテーブルに書き込みが走っていくので、初期状態ではアプリケーションのスループットが低くテーブルのデータがあまり増えないため、データ量起因のスロークエリが起こり始めるのはチューニングが進んだ実競技後半になるとおもいます。

    そのかわり、N+1 や、本来叩く必要の無いクエリが意図的に随所に仕込んであります。一つ一つは 1ms 前後で返されるようなものですが単純に量が多いため、これらのクエリが発生しないようにアプリケーションを変えていく必要があります。
    たとえば、仮想コンテストの開催時間を管理する contest_config テーブルは、/initialize 以降は更新されることがないので、負荷走行の中ではずっと使い回すことができます。
    また、contestants や teams テーブルは、仮想チーム登録フェーズが終わった後は更新されることがないので、使い回すことができます。これらを protobuf にエンコードする頻度は高いため、protobuf にした状態でキャッシュしておくのもいいと思います。

    ダッシュボード(Leaderboard)

    実負荷走行の中でダッシュボードページは高い頻度でアクセスされますが、重い集計処理が走るようになっているので、これはチューニングが重要になってきます。

    02
    図2: ダッシュボードの Leaderboard 部分

    ダッシュボードの Leaderboard 部分の集計は69 行もある 1 つの SQL クエリで実装されており、多くの方は見た瞬間に嫌気が差したかと思います(mirakui の力作です!)。このクエリはデータ量(仮想負荷走行の実行回数)の少ない初期状態ではスロークエリではないですがチューニングが進むと重くなっていくので、手を打っておく必要があります。対策としては

    • 仮想負荷走行が完了したときにあらかじめ Leaderboard のデータを作っておく
      • このデータ更新を同期的に行うとボトルネックになるので、非同期である程度まとめて処理するのがおすすめ(report_benchmark_job の ack は更新完了まで返さない)
    • student flag や latest / best score をカラム化しておくとよい
    などが有効だったかと思います。

    ダッシュボードにアクセスするのは仮想選手と仮想オーディエンスなのですが、仮想オーディエンス向けダッシュボードのみ、最大 1 秒のキャッシュが許可されていました。この 1 秒の判定はシビアで、単に1秒キャッシュをしているだけだと、アプリケーションが詰まり始めたときに「仮想負荷走行の結果が 1 秒以内にダッシュボードのレスポンスに反映されている」が達成できなくなる場合があったかと思います。このときに出力される「期待より古い内容のリーダーボードが返却されています」というエラーに悩まされたチームも多かったのではないでしょうか。
    仮想オーディエンス向けダッシュボードのキャッシュについては、アプリケーションに対して同時に複数のキャッシュ更新(Thundering Herd)が走らないようにしたり、非同期でキャッシュ更新を走らせるようにしたりするのが効果的だったかと思います。たとえば Go の singleflight や Varnish を使うことでこういった制御をする事が可能です。

    通知の Web Push 化

    03
    図3: ダッシュボードの通知機能

    今回の問題では、仮想選手たちが高頻度で通知のエンドポイントをポーリングし、新着通知(仮想負荷走行の終了通知、質問仮想運営からの回答通知)を取りに来ます。今回の実ベンチマーカーは Web Push サーバーを内蔵しており、アプリケーションからの通知を Web Push 通知に実装し直すことで、ポーリングの処理を軽減できるというギミックがありました。Web Push 方式への書き換え方については、各言語でのサンプルコードを用意し、あまり高い障壁にならないように配慮していました。実ベンチマーカーへの Web Push サービスの実装は(sorah が)頑張って実装したのでぜひ使って欲しかったですが、参加者の多くは実装しなかった、あるいは実装したけどスコアが下がったのでポーリング方式に切り戻した、というご意見が多かったような印象です。実は、単にすべての状態の変化を即時に仮想選手に Web Push 通知するだけだと、仮想選手達は同時かつ即時に次のリクエストを送ってきていわゆる Thundering Herd 問題が発生し、より瞬間的な負荷が高まってしまうという状況が予想されるからです。

    この状況の対応として想定していた回答の一つは、全体通知(Clarifications への回答は全選手へ同時に通知する場合がありました)については Thundering Herd 問題を避けるためにポーリング方式で処理し、それ以外の個別通知は Web Push 方式で処理する、というものです。実ポータルでは実際にそういう実装にしてありました。本選競技中になかなかそこまではしないだろうなーと思いつつも、やりこみ要素の一つとしてご理解いただければと思います。

    白金動物園による解答例

    本選と同じスペックの競技サーバー 3 台をお借りして sorah が解いたところ、以下のようなスコアになりました。
    • 使用言語: Ruby
    • スコア: 36,768
    おもにやったことは以下の通りです(順不同)。

    • ミドルウェアの導入: nginx, Varnish, Redis
    • 最終的な競技サーバー 3 台の役割: server 1 で実負荷走行を受け、 Envoy で3台に振り分け
      • server 1 (1GB, 2 vCPUs): Varnish, 静的ファイルの配信 (nginx), benchmark_server (gRPC)
      • server 2 (2GB, 2 vCPUs): web のうちスコアに寄与しないもの, MySQL, Redis
      • server 3 (1GB, 4 vCPUs): web のうちスコアに寄与するもの, benchmark_server (gRPC)
    • 静的ファイル配信
      • nginx + static brotli
      • Cache-Control (expires 1d;)
    • receive_benchmark_jobs (gRPC)
      • benchmark_jobs のキューを Redis 化し、sleep つきループの代わりに BRPOP でジョブのエンキューを待つようにした
    • ダッシュボード(仮想選手&仮想オーディエンス)
      • 仮想負荷走行が成功したときにあらかじめ Leaderboard を構築し、都度 Redis に保存するようにした
      • 負荷軽減のため Leaderboard はアプリケーション側で計算するようにし、例の巨大な Leaderboard SQL は廃止
      • Leaderboard の更新負荷を下げるため、時間の近い (0.3s 以内の) 複数の report_benchmark_jobs (gRPC) を待ち合わせてLeaderboard 更新を 1 回にまとめるようにした
      • 仮想オーディエンス向けダッシュボード
        • Cache-Control: public, max-age=1
        • Leaderboard から生成した ETag を付与
        • varnish でキャッシュ (ttl=0.5s, grace=0.2s)
    • 各種 N + 1 の解消, MySQL index の改善
    • カウンタキャッシュ等の導入
      • teams.student, teams.last_answered_clarification_id
    • 通知の Web Push 化
      • (Ruby のため) Envoy で HTTP/2, TLS を終端し接続処理の負荷軽減も併せて実施
      • Web Push の購読がある場合、 GetNotifications では通知を返さないように
    • Puma 4 -> 5
      • 9/17 にリリースされていた
      • 4 ->5 でのパフォーマンス改善 (wait_for_less_busy_worker で負荷の低い worker にリクエストが行くようになる等) や nakayoshi_fork によるメモリ使用量削減効果を期待
    • 参加仮想チーム数の引き上げ
      • 最高スコア時は TEAM_CAPACITY=65
    • gRPC server (griffin) や Puma の workers, threads 調整
      • 併せて envoy の max_concurrent_streams を調整して gRPC server の最大同時リクエスト数を考慮してロードバランスするように


    講評

    今回の本選問題はあのシンプルな予選問題とは打って変わってとても参考実装のコード量が多く(移植チームの皆様本当にありがとうございます!!!)、またマニュアルもそれなりにボリュームがあったため、全体を把握するだけで多くの時間が取られてしまったチームは多かったのではないでしょうか。また、protobuf / gRPC や Web Push、Envoy など、これまでの ISUCON に登場しなかった技術要素も登場し、これらに馴染みのないチームは頭を抱えたかもしれません。

    実競技の前半は、これまでの ISUCON でも活躍してきたベテランのチームがスコアを大きく伸ばし、上位を占めていた印象です。今回の問題は最初からアプリケーションネックの状態から始まるので、複数のサーバにうまく負荷を振り分けたり、静的ファイルの負荷がアプリケーションに行かないようにしたりなど、アプリケーションコードではなくインフラの技術によって大きくスコアを伸ばせる状態だったため、サーバのリソースと相談しながらこういったチューニングを素早くできるような、経験のあるチームが有利な展開だったかと想像します。

    アプリケーションの解読が進んで各チームが具体的なアプリケーション改善に取り組み始めたであろう後半では、やはりパフォーマンスチューニングの基本である、今のボトルネックを正しく計測・理解し、改善していくサイクルを精度良く回せていったチームが上位に上がっていったのだと思います。参考実装のコード量が多く、視界に入ったものを推測で改善するのではなく、やることをうまく絞っていく必要があるからです。例の巨大な Leaderboard の SQL はそのためのちょっとした仕掛けのひとつでした。経験のあるエンジニアほどあのクエリを見たら真っ先になんとかしたくなると思いますが、先に改善するべきボトルネックは他にあります。

    最終的に 1 位から 3 位まで学生チームが占め、しかも 1 位は 1 人チームだったという、これまでの ISUCON の常識を覆す結果となりました。記念すべき 10 回目となる ISUCON がこのように新しい時代を感じさせる象徴的な結果となり、それに立ち会うことができたのは問題作成者の一人として誇らしく思います。

    最後に、ISUCON10 の予選や本選に参加していただいたチーム、スポンサーをしてくださった企業の皆様、ISUCON10 を応援し盛り上げてくださった全ての人に感謝申し上げます。
    Read more...

    こんにちは、運営の櫛井です。
    10月13日に放送した ISUCON10 アフターイベントご視聴・ご参加いただきありがとうございました!
    放送の中で行なったISUCONクイズ(通称ISUCONカルトクイズ)は、80名ほどの方にリアルタイムにご参加いただき大変盛り上がりました。AhaSlidesというツールを利用しましたが、参加者が同時に参加できる楽しさがありオススメです。
    ididi


    結果は、本選と同じくtakonomuraさんの優勝となりました。完全制覇おめでとうございます!
    isucon quiz

    ISUCONカルトクイズがなかなか好評だったので、設問・選択肢・正解率を共有させていただきます。皆さんは何問わかりますか?

    Q.1 ISUCONに予選という仕組みが始まったのはいつから?
     (100点 正解率 61%)
     A. ISUCON1
     B. ISUCON3
     C. ISUCON5
     D. ISUCON7

    Q.2 競技時間8時間のうち、自チーム以外のスコアランキングが更新されなくなるのはいつ?
     (100点 正解率 96%)
     A. 残り4時間
     B. 残り2時間
     C. 残り1時間
     D. 残り30分

    Q.3 ISUCON1の優勝賞金は?
     (100点 正解率 6%)
     A. 100万円
     B. 50万円
     C. 10万円
     D. 6万円

    Q.4 エンジニアHubのインタビューでISUCON10の本選出題担当である白金動物園が語った「学生が強くなったのは◯◯を手に入れたから」 正しいのはどれ?
     (200点 正解率 30%)
     A. (ブログなどの)情報を手に入れたから
     B. (擬似的な)負荷を手に入れたから
     C. (相対的に)時間を手に入れたから
     D. (物理的な)練習場所を手に入れたから

    Q.5 ISUCONに学生枠が初めて設置されたのはいつ?
     (100点 正解率 10%)
     A. ISUCON3
     B. ISUCON5
     C. ISUCON8
     D. ISUCON10

    Q.6 ISUCON8で優勝した学生チーム「最大の敵は時差チーム」の3人が参加したのは東京、海外、あと一人はどこから?
     (100点 正解率 9%)
     A. 東京
     B. 神奈川
     C. 埼玉
     D. 千葉

    Q.7 本選問題の動画で表示されていたX41さんはどれ?
     (100点 正解率 70%)
    abc




    Q.8 ISUCON 夏期講習 2020で講師のrosylillyさんが伝えた「チームの???を確保しよう」 正しいのはどれ?
     (100点 正解率 75%)
     A. TPO = Time(時間) Place(場所) Occasion(場合)
     B. KPI = Key Performance Indicators(定量的な指標)
     C. bps = bits per second(データ転送速度)
     D. HRT = Humility(謙虚)  Respect(尊敬)  Trust(信頼)

    Q.9 ISUCON10の準備期間中、運営の941さんがハマっていたゲームは何?
     (100点 正解率 9%)
     A. ゼルダの伝説 ブレスオブザワイルド
     B. Ghost of Tsushima
     C. スプラトゥーン2
     D. ポケモン 剣盾

    Q.10 ISUCON10 本選ライブアンケートの結果で「複数回答あり、面白かったコンテンツ」2位になったのはどれでしょう
     (100点 正解率 53%)
     A. mirakuiさんのパンの話
     B. 本選出場33チーム紹介
     C. 並行チーム企画
     D. 本選問題発表

    Q.11 ISUCON4はどれ?
     (100点 正解率 26%)
    1234



    Q.12 エンジニアtypeのインタビューでISUCON10インフラ担当 サイバーエージェントの中西さんが語った「ISUCONに惹かれたところ」は?
     (200点 正解率 23%)
     A. アドレナリンが出るところ
     B. 終わったあとの感想戦が楽しいところ
     C. 打ち上げが楽しいところ
     D. 実務にすぐ活かせる技術力が身につくところ

    Q.13 社内ISUCONを最初に開催したのはどの会社?
     (100点 正解率 48%)
     A. 株式会社リクルート
     B. ウォンテッドリー株式会社
     C. 株式会社モバイルファクトリー
     D. 面白法人カヤック

    Q.14 Qiita ZineのインタビューでISUCON10 予選出題担当の古川さんがISUCONについて語った「限られた◯◯の中で◯◯を出すことは難しい」で正しいのはどれ?
     (300点 正解率 66%)
     A. 限られた時間の中でパフォーマンスを出すことは難しい
     B. 限られたリソースの中で結果を出すことは難しい
     C. 限られた予算の中で景品を出すことは難しい
     D. 限られた可処分所得の中で新しいパソコンの費用を出すことは難しい


    参考までに、優勝したtakonomura氏は14問中11問正解したとのことです。

    正解はISUCON10 アフターイベントのアーカイブからどうぞ
    Read more...

    ↑このページのトップヘ