こんにちわ。伊勢です。去る2015年10月31日の土曜日、世間はハロウィンとかいう悪魔祓いの儀式にうつつをぬかす中、渋谷ヒカリエLINE株式会社のカフェにて、とあるWebサービスの性能を限界まで高速化を図るガチンコチューニングバトル、ISUCONが開催されました。回を重ねる事、今回で第5回目の開催です。
ちなみに私はライブドア主催による第1回およびNHN主催による第2回ISUCONの大会委員長を務めさせていただきました。特に何もしてないですけど。これは第1回当時の写真です。若いな、おれ。

その後LINE株式会社による第3回、第4回を経て、今回もLINE様による開催です。
NHNテコラスはライブドア、データホテル、テコラスとその名称を変えつつも第1回からずーっとこのISUCONにサーバ機材を提供し続けています。もちろん今回も！そして私はいちスタッフとして本選会場に（午後から）お邪魔してきました。ちょうどコンテスト会場についたのが昼時で、ISUCONではスタッフ、参加選手用にお弁当が用意されていました。

しかし、私はあえて会場へ行く前に渋谷道玄坂にある喜楽でワンタンメンをいただきました。やっぱり喜楽はうまいっ！

会場はシンとして各チームとも、チューニング作業に余念がない。出題者ルームではtagomoris、kamipoさんらがスコアやエラーのチェックをしています。

会場には第5回ICTトラブルシューティングコンテスト の実行委員、さくらインターネットの「こたまご」が率いるチーム「マウント竹田氏」がいました。お洋服、カワイイですね。

第1回、2回の出題者であり、第3回、4回のチャンピオンLINE選抜チーム「生ハム原木」のkazeburoさんが所属するチーム「GoBold」もいます。

 
そして第1回、2回のチャンピオン、そして第3回の出題者であるカヤックの藤原さん率いるチーム「fujiwara組」。今回のメンバーには第1回fujiwara組で出場した「すぎゃーん(sugyan)」がいます。

すぎゃーんは第2回の出題者、そして第3回、4回にtagomoris、kazeburoさんと同じくチーム「生ハム原木」で優勝しています。皆さんは気づいていないかもしれませんが、実は今回の結果を含めるとISUCON史上における最多優勝経験者はすぎゃーんだったりします。
コンテストの様子はISUCON公式ブログをご参照いただくとして、こちらのブログでは「ISUCONの裏側」ならぬ「ISUCONの下側」をご紹介しましょう。
前述しましたが、NHNテコラスでは今回もISUCON本選用のサーバを提供しています。「ISUCONの裏側」というとコンテスト問題の仕掛けを指しますが、「下側」とはもちろんISUCONを支える物理的ハードウェアの事です。今回のISUCONはいわゆるマイクロサービスという奴で、様々な外部APIを利用するアプリケーションサーバのパフォーマンスをチューニングするという仕立てでした。今までのコンテストサーバ環境は、各チームがチューニングするためのサーバ、運営サイドが検証するためのサーバ、そしてベンチマークを実行するサーバによって構成されていましたが、今回はそれらに加えAPIを提供するサーバ群が提供されています。結構要求スペックが高かったのでサーバやToRスイッチは今までにないハイスペックのモデルを以下のように用意しました。
[サーバスペックと台数]

【APIサーバ、ベンチマーク、足場、運営検証用】
DL360P Gen8 (6Core CPU x 1, メモリ32GB、オプション10G NIC) 5台
【参加チーム用VM】
DL360P Gen8 (8 Core CPU x 2、メモリ128GB、オプション10G NIC） 20台

[スイッチスペックと台数]

バックボーン　CiscoSystems Nexus9332PQ  1台 (40G NIC x 32)
ToRスイッチ　CiscoSystems Nexus9372TX  3台(40G NIC x 1、10G NIC x 48)

これらのサーバとスイッチが以下のように接続されています。

 
実際のサーバラックはこんな感じです。
 
 

各サーバは10Gbpsイーサネット(メタル)でToR(Top of Rack)スイッチに接続され、ToRとバックボーンスイッチは40Gbpsの光イーサネットで接続されています。参加チームが使うVM用サーバは仮想ハイパーバイザであるKVMを基盤として1台たり5個のubuntu VMがデプロイされ、各VMには1Gbpsの仮想ネットワークインタフェースが割り当てられています。参加チーム用サーバ数が20台なので、全部で100VMですね。コンテストでは各チームごとに3つのVMが渡されたので27チーム分で81VM使用しました。ただし、チームが使用できるVMが同じハードウエア上にあるとは限らず、どちらかというとチーム用VMはそれぞれ別々のハードウエアでデプロイされているVMが割り当てられておりました。

そうすると物理サーバ間のネットワーク速度や帯域が気になると思います。VMの仮想ネットワークが1Gbpsなので物理サーバ1台あたりのVMが使用するネットワーク帯域は最大でも5Gbpsです。1つのToRスイッチに接続されているサーバ10台全てが5Gbpsを出したとするとトータル50Gbpsとなりアップリンクの40Gbpsを超えてしまいますが、さすがにそれは無いでしょう。普通に考えるとアップリンクがダウンリンクの最大ワイヤースピードの80%であれば異なる個体上にあるVM間の通信速度がパフォーマンスのボトルネックになる事はまずありえません。ちなみにバックボーンスイッチのトラフィック状態はこんな感じでした。

参加チーム用VM(1)

参加チーム用VM(2)

運営用API/BENCH

全然問題なかったですね。運営用側はピーク1Gbpsぐらい出ておりますが、チーム用はそれほどでも無い。従来のISUCONだとネットワーク帯域がボトルネックになるケースもあったようですが、今回のコンテスト問題はあまりネットワーククリティカルではなかったようです。
私自身は実際に問題に手を付けたわけではありませんが、問題作成者や参加者の話を聞くと、今回の問題はAPIごとにキャッシュのTTLや処理をきちんと調整する必要があるとの事でした。したがってネットワーク速度云々というよりリクエストの非同期並列化におけるキャッシュのチューニング、特にＴＴＬ調整がキモだったようです。バックボーンは40Gも必要無かったのかも。

今回、予選はGoogle Cloud Platform(以下GCP)で実施されましたが、ネットワークヘビーでは無いとしても究極のパフォーマンスを競う本選には仮想インスタンスが利用可能なハードウェアリソースがはっきりしている必要があって、やはりこれくらいの物理環境が必要だったということでしょうか。ちなみにこれらを直球勝負で普通に新品を調達すると、サーバ、スイッチ、NIC、RAIDオプションなど込み込みで、その総額は

約3000万円

を超えます。 ISUCON、やっぱかなり金かかってます。このコンテストって来年もやるんだろうか・・・・？