パフォーマンス向上への飽くなき挑戦！ さくらのエンジニアによるISUCON座談会 (前編)

はじめに

ISUCON(Iikanjini Speed Up Contest)は、ウェブサービスの性能向上を競うコンテストです。これまでに11回の大会が開催され、回を追うごとに参加者も増えて大規模なイベントとなっています。大会のレベルも非常に高く、IT業界の第一線で活躍しているエンジニアの方々でも、優勝の栄冠を手にすることはなかなか難しいです。

さくらインターネットはISUCONのスポンサーとして協賛しているだけでなく、多くの社員がコンテストに参加しています。また、過去にはISUCONの問題作成を担当したこともありますし、ISUCONの創設に関わったメンバーも在籍しています。

そこで今回は、ISUCONに関わったことのある社員の皆さんに集まっていただき、ISUCONではどんなことをやっているのか、何がおもしろいのかなどを、座談会形式でうかがいました。

参加者の皆さん

座談会に参加した皆さんに、自己紹介をしていただきました。

長野雅広(kazeburo)
クラウド事業本部で、さくらのクラウドの、主にアプライアンスと呼ばれるサービス(エンハンスドLB、DNS、シンプル監視など)の開発や運用をやっています。ISUCONには初回から関わっていて、ISUCON2までは出題を担当し、ISUCON9の予選でも出題をやりました。その他の回では普通の出場者として参加していて、予選落ちも何回もありますが、ここ2回ほどは本選にも出ています。(編集部注：ISUCON3と4では優勝も経験しています)

江草陽太(ひなたん)
さくらインターネットに新卒で入社してから7年ぐらい、ソフトウェアエンジニアとかをしてまして、今は技術統括の執行役員と、セキュリティの担当であるCISOを兼任してます。ISUCONは5のときに初めて参加して、それ以降だいたい同じメンバーで出ています。ISUCON8では準優勝しまして、そのときに「来年は出題をやりませんか？」とお声がけいただいて、当時メルカリにいらっしゃったkazeburoさんとさくらのメンバーで一緒にISUCON9の問題を作りました。

関根隆信
さくらではエンジニアリングラボに所属していて、電子契約などの業務に関わっています。エンジニアリングラボに入る前はsakura.ioの開発とかやってました。ISUCONとの関わりは、江草さんと一緒にしか出てないんで、ほぼさっき江草さんに言っていただいた通りです。

川畑裕行
さくらインターネットとソフトバンクの合弁会社であるBBSakura Networksに出向しておりまして、自社MVNOの携帯電話のパケット交換機のソフトウェア開発とか、SMS送信設備のソフトウェア開発をしています。さくらの中でもかなり風変わりな仕事に就いております。ISUCONには参加者として出たことはなくて、ISUCON9の出題と運営という形で関わりました。

穎川和弘
クラウド事業本部にて、さくらのクラウドのバックエンドアプリケーション開発をしています。ISUCONには参加者として数回に加え、運営メンバーとしてベンチマーカー、ポータルサイトの開発に携わらせていただきました。

飛田一貴
2021年に新卒でさくらに入りました。さくらのVPSのコンパネとかAPIの開発をしています。ISUCONは今回(ISUCON11)初めて参加しました。

現場に即したチューニングコンテストをやりたい！

法林：長野さんがいらっしゃるので、立ち上げ当初のことをぜひお聞きしたいのですが、どういったきっかけで始めたんですかこれは。

長野：もう11年前になるんですけど、当時ライブドアに所属してまして、そのときに、同じようなインフラ系のチューニングコンテストがありました。それの確か2回目だと思うんですけど、アプリケーションのソースコードを変更してはならず、ミドルウェアをチューニングしたり、入れ替えたりするコンテストでした。

それを見ていて、当時の同僚だったtagomorisさんと一緒に「自分たちがやってることってこうじゃないよね」って言って。現場ではソースコードも手を入れるしインフラも手を入れるし、何でもありだよねっていうところから、何でもありなチューニングコンテストをやりたいと。そこに櫛井さん(櫛井優介さん。現LINE)だとか、当時ライブドアにいた伊勢さん(伊勢幸一さん。現さくらインターネット執行役員)なども入って始まったのがISUCONですね。

法林：最初から長野さんが問題作成とかもやってたんですね。

長野：そうですね。最初はtagomorisさんと自分の2人で問題を作ってました。

法林：スタートしたときは何チームぐらいだったんですか？

長野：参加者が全員会議室に収容できるぐらいだったんで、20チームぐらいですね。

法林：それが今では600チームの定員が数時間で埋まると聞いています。

長野：ISUCON5か6の頃あたりからですかね、参加者が大幅に増えてきたのは。「予選こそISUCONだ」とも言われるようになり、予選が本格化したのがたぶんそのあたりなんですよね。

少数精鋭！ ISUCONの運営体制

法林：ISUCONの運営ってどんな体制になってるんですか？　どれぐらいの人数でやっているのかとか、メンバーは固定なのか持ち回りなのかとか。

江草：最近だと、運営メンバーで固定されている人は櫛井さんと、その周囲にいるLINEの皆さんですね。その方々は問題作成には関与せず、会場の手配だとか、運営としての調整をしてくださってます。その他に、問題作成チームが予選と本選それぞれにいて、これは毎回変わるんですが、それぞれ数人っていう感じだと思います。

長野：ISUCON11が10人くらいだったっけ。(編集部注：櫛井さんによると、出題に関わった人は18人でした)

法林：なんかもっと大規模なチームで運営してるのかと想像してたんですが、そんなに人数が多いわけではないんですね。

江草：そうですね。ISUCON9では、予選出題がメルカリさん(当時在籍していた長野さんも担当)、本選出題がさくらだったんですが、本選は、川畑さん、関根さん、頴川さん、私の4人で問題作成や運営をやりました。順位を表示したり、参加登録を受け付けるためのポータル画面は予選・本選共通で使うのですが、メルカリさんは先に予選問題を作らないといけないんで、さくらのメンバーは先にポータルを作り、それから本選の問題を作りました。

法林：4人！そんなに少人数でやってたんだ…びっくりです。

繊細な配慮が必要なスコアリング設定

法林：運営側で用意するものは、問題はもちろんだと思いますが、他にどんなものを用意するんですか？

頴川：ISUCONの運営側で実装すべき部分は大きく分けていくつかあります。ウェブアプリケーション、フロントエンド、ポータルサイト、ベンチマーカー(パフォーマンスを測定しスコアを算出するプログラム)といったものがそれにあたります。いずれも大会の運営や参加チームのランキングに必要なものになりますね。ISUCON9で出題を担当したときは、問題が物品の売買に関するものだったので、この他に課金サーバなどが実装されていました。

ベンチマーカーの実装においては、例えばフロントエンドをいじったら失格になるなどのレギュレーションがあるので、それを厳密にチェックしていく必要があって、むしろ気付けないと適切な指摘ができなかったってことでミスになっちゃうので、そこは気をつける必要がありますね。

あとはチューニングを一つ一つ加えていったときに、ちゃんと妥当にスコアが上がっていくようにすることが重要です。ちゃんとチューニングしたのにうまくスコアが上がらないと参加者も混乱しちゃうので、そういうことにならないように出題側はなるべく注意を払う必要があります。

法林：なるほど。スコアリングの作り方は難しいのではないかと思うんですが、どうなんですか？

頴川：例えば、ISUCON9の予選では売買の売り上げをベースにしたものだったので、売り上げが上がっていくとスコアが高くなります。一方、本選の場合はリクエスト数をベースに評価したので、さばけるリクエストの数が増えるとスコアが上がるという感じです。

このあたりは、実装するサービスごとに、どういう風にスコアリングしようかっていう議論ももちろんありますし、それぞれにどれぐらいの重みをつけるかということも運営側で話し合ってたりします。

法林：なるほど。ここをこうすると、どれぐらいの得点になるとか、そういうこともあらかじめ設定しておかないといけないんですね。なかなか大変ですね。

頴川：問題を解いていて、簡単なチューニングポイントなのに間違えて重み付けを重くすると異常にスコアが上がっちゃってチグハグなことになるので、そうならないように注意を払う必要があります。スコアリングは結構シビアに検証していって調査しないといけないところだと思いますね。

法林：そういうのって本番の前に検証するんですか？

頴川：本番の前に「問題はまだ未完成だけれどもちょっと試してみませんか」っていう事前回答会を設けて、本番のISUCONには出られないという条件に同意いただいた上で、有志で競技に参加いただいてました。その際、ベンチマーカーがまだ未熟でスコアが暴発してしまったり、他にもいろんなトラブルがあったり、そういう中でスコアリングについていろいろ調整する機会があって学べました。

法林：長野さんはこういったスコアリングみたいな部分で考えたことはありますか？

長野：最近関わったのはISUCON9の予選ですが、予選はさっきも話に出たように参加者がすごく多くて、600組ぐらい出るんです。でも、参加者のレベルはさまざまなんですね。なので、その中で何か残してもらいたいっていうか、何かやったらスコアが上がったっていう経験はしてもらいたいっていう思いがありますね。ですので、わかりやすいボトルネックを設けて、最初はスコアが上がりやすいように作ってました。あとは実際にスコアが上がるよねっていうのを、社内でISUCONの予選に出ない方に声をかけて解いてもらったりしてました。

稚拙な実装が求められる出題の苦労

法林：では問題の作成についてお聞きしたいと思います。ISUCON9で出題したのはどんな問題だったんですか？　というか、そもそもISUCONの問題ってどうやって作っていくんですか？

江草：まず最初にテーマを決めないといけなくて、例えばISUCON9予選でメルカリさんが出題したのは「椅子を売り買いするためのプラットフォーム」なんですが、こんな感じで何らかのサービスを想定するところからスタートですね。過去の問題とテーマがかぶってもよくないので、そこも考慮ポイントです。自社のサービスに関連するようなものをテーマにしてもいいんですが、さくらの場合はいいのがなかったので、「鉄道の座席予約システム」というテーマにしました。

• 参考：ISUCON9 予選問題の解説と講評(担当：メルカリ)
• 参考：ISUCON9 本選問題の解説と講評(担当：さくらインターネット)

そして、実装において気をつけるポイントは、最初からあまりいい実装だと、速くするポイントがなくなってしまうのでよくないんです。「実装としては良くないけど、こういう実装しちゃうことあるよね」とか「こういう実装はあってもおかしくないよね」というような、わざと遅い実装を作って出題するわけです。

法林：わざと遅い実装をする！それってある意味、とても難しいですよね。長野さんも何回か問題を作っていたそうですが、どうでしたか？

長野：わかりやすいところではデータベースのインデックスを張らないだとか、N+1問題が発生するような状況でSELECTで記事の一覧を取って、その記事の一覧に対するユーザーの情報を、さらにその記事の数だけSELECTするみたいな、何も考えずに作ったらそういう風になっちゃようよねというような実装で出題してました。

さらに先ほど話題になったISUCON9予選の問題だと、メルカリで実際に起きたような問題、例えば決済とサービスとの絡みみたいなところ、決済のサービスってどうしても速度が遅いので、ここに単純に問い合わせていると、サービスが大きくなった時にボトルネックとなりがちで、そういう問題にどう対処するのかというの組み込んでいたりしてました。

法林：それはつまり、実務経験で遭遇した問題や、それを解決する中で得られたノウハウみたいなものが問題に含まれたりするわけですね。

長野：そうですね。メルカリの場合は、メルカリで出すんだったらメルカリのサービスで起きていることの中からっていうことで作りました。

法林：これって毎年出題者が変わるんですよね。ってことは、それによって問題のテーマも変わるし、使ってる技術も変わってくるという感じですか？

長野：そうですね。

法林：川畑さんや関根さんは、問題作成に関する思い出はありますか？

関根：ある程度やった記憶がありますけど、もう当時何をやったか覚えてないんですよね(笑)。

頴川：関根さんはウェブアプリのデータ生成の部分とか、あとポータルのフロントエンド部分もほとんど実装してもらいましたし、それからウェブアプリの方にも結構改修を入れていただいてました。

江草：川畑さんには予約システムの実装、空き座席の検索とかを実装してもらったりしてました。それから課金API。これは決済するのに時間がかかるという遅いシステムの動作を、ちゃんと平等に何ミリ秒かかってから応答するみたいな感じで再現しています。

川畑：わざと遅い実装を書くっていうのが普段の業務では全然やってこなかったんで、そこですね。こんなクソみたいな書き方せんだろうみたいなことを思いつつ、使うライブラリも最低限で、それで参考実装のコードを書くっていうのが逆に新鮮でいい勉強になったというのが1つありますね。

それから、課金APIの実装の話がさっきありましたけれども、これは参加者には非公開のAPIで、かつベンチマークでスコアを出すために、とにかく最速で実行する必要があって、いかにシンプルかつ高速に間違いなく実行されるかというのを考えるところが大変楽しかったです。

法林：やっぱり出題側も勉強になることが多いんですね。

頴川：ISUCON9本選では、開始直後にベンチマークを走らせたらfailする実装になってたんですよね(笑)。もうあまりに遅すぎて、予約しようとしたらなんか1分ぐらい待たされるみたいな。

法林：落ちるんだ(笑)。落ちるところからスタート。

頴川：ベンチマーカーから0点って評価を食らうような感じの実装になってました。

川畑：このときは本選のオープニングで見てもらう映像を用意しまして、それを見てもらうとこの実装の動きがわかります。1分ぐらい気長に待ったらちゃんと計算されて帰ってくるってのがすごいよね。

ISUCON9 本選 オープニング映像(出題したシステムが見られます)頴川：なんかコードを読んでると、結構ネストしてる感じになっててですね、読むのも結構大変だっていう評価をいただきました。

関根：書いた側も何を書いたのかもはやわからない状態でした(笑)。

江草：難読化したつもりはないんだけど、検索ロジックが複雑で読みづらいと。

関根：いまだになんで動いてるかわからないですね、あれ。

法林：そういうのを出題したわけですね。すごいですねこれは。普通の業務ではやらない発想なので。

サーバ1800台超！ ISUCONのインフラ

法林：ところで、出題にあたってはインフラを用意することになるはずです。結構な規模のインフラを用意しないといけないんじゃないかと予想されるんですが、どれぐらいの規模のものを用意するんですか？

頴川：ISUCON9の本選では、参加チームが全部で30チームぐらいありまして、各チームだいたい3名から5名ぐらいいらっしゃいます。そして、各チームに3台のサーバが用意されるので、30×3で90台ぐらいですね。それとは別にポータルサイトとベンチマーカーも必要で、本選の場合は各チームに専用で1台のベンチマーカーがあるという状況になってました。これらを合計すると、だいたい120台前後のサーバを提供した計算になります。

法林：本選でこれだと、予選はもっと大変なんじゃないかと思うんですが、どうなんですか？

長野：予選は、初期の頃はサーバ台数が1チーム1台だったのが、途中から複数台に変わったんですよね。ISUCON9のときは600チームに対して1チーム3台だから1800台ですか。今年(ISUCON11)もそれぐらいだと思うんですけど。

法林：うわ。そんなに用意するんですね。これ、毎回インフラ提供スポンサーみたいなのがいるんでしたっけ？

江草：櫛井さんが、提供が毎回同じ会社にならないように、AzureだったりAWSだったりGCPだったりさくらだったり、アリババクラウドだったり、いろいろ使ってくださっています。オンプレミスのサーバで出題される場合もあります。NHNテコラスさんが出題したときはテコラスの物理サーバだったんじゃないかな？　そういう場合もあります。

法林：物理サーバで来る場合もあるのはすごいな。さくらの場合はさくらのクラウドを提供したんですかね？

頴川：そうですね。

法林：なかなか大変な規模のインフラなので、それなりの事業者でないとポンと提供できないでしょうね。ありがたいことです。

つづきは後編で

座談会はまだまだ続きますが、この続きは後編の記事でお楽しみください。後編では、参加者としての立場で見たISUCONや、さくらの社員たちがISUCONに感じる魅力などを語り合います。お楽しみに！

※「ISUCON」は、LINE株式会社の商標または登録商標です。