［開催レポート］ISUCON8インフラエンジニア体験記

• 
• 
• 
• 

はじめに

今回、参加者の方々からの「ベンチの実行で待たなかった」というご反応を多くいただくことができ、大変嬉しく感じました。ISUCONでは、参加者ごとにチューニング対象のWebアプリケーションサーバが配布される他に、運営側の設備としてアプリケーションに負荷をかけてスコアを出力するベンチサーバが用意されます。

参加者が専用のコントロールパネルからベンチの実行をリクエストすると、ベンチサーバが参加者のアプリケーションに対してベンチマークを実行します。このベンチサーバが全参加者で共有されている場合、参加者からのリクエストはキューイングされ、順次ベンチマークが実行されることになります。ISUCON8では、このベンチマーク実行の待ち時間が大変短かったということで、ご好評を頂けたようです。

たしかに、チューニングコンテストのようなトライアンドエラーを繰り返す場面では、ベンチを素早く実行できることがメリットにつながるかと思います。しかし、このご評価は大変光栄である反面、実は心苦しく感じている部分もあります。というのも、この「ベンチの待ち時間が短い構成」になったのは、ConoHaのエンジニアがISUCONの規模にビビった結果だからです。

本ブログ記事では、このサーバ構成になった経緯を通して、私たちがどれくらいビビっていたのかについて記載したいと思います。

準備

ことのはじまりは、LINE様から3月頃「ConoHaのインフラをISUCONに提供しませんか。」というご提案を頂いたことでした。

弊社としても、あの有名なISUCONに使ってもらえることで、認知度の向上とサーバの使い勝手を実感してもらうチャンスを得られるのでは、という思いがあり、お受けしました。

まずキックオフミーティングが3月5日(月）に開催され、LINE様/DeNA様/カヤック様/弊社が参加しました。LINE様よりまずはISUCONの概要説明をして頂き、毎年パブリッククラウドを提供している会社より、サーバー提供を受けている旨を認識しました。

１．ISUCONの過去の参加推移

２．ISUCON7のサーバー構成

３．参加チーム数と1人参加の可否についての決定（仮）

このキックオフミーティングの中では、「参加目標人数（参加見込み数）」と「1名参加が可能な事」が決定しました。参加人数上限に関しては後日Slackにて調整後に確定しました。（この段階で500~600チームを上限とすることが大体であるが決まっていた。）

また、過去のISUCONの傾向などをカヤック様とDeNA様にヒアリングする機会も得られました。利用言語によって、スケールアップ構成が有利になったり、単体での高速化が有利になる等、非常に有益な情報を得ることができました。

過去の傾向を元に2パターンのVM群を、まずはDeNA様とカヤック様にお渡しして問題を作成をして頂き、最適な構成を選んで頂く事となりました。

４．物理サーバーの早急な手配を実施

この段階では500~600チームが参加する為の物理サーバーが足りない状況であったため、早急に発注処理を進めました。今回のISUCON8用に用意したサーバー台数とスペックは以下の通りです。

上記サーバーを使って、弊社筬島と相澤が過去問での検証等を進めてくれることになりました。

過去問で動作確認（筬島）

最大のビビりポイントは予選問題の規模でした。

チューニングコンテストという性質上、1500のVMが最大の負荷をかけるために設定更新されていくはずです。

公開されていたISUCON7の予選結果を参照し、すべてのチームが最大限の負荷をかけることはないとは予想しつつも、インフラとして高い安定性を実現するためには極限のケースも想定する必要があると考えました。まずはISUCON予選の破壊力を見定める必要がありました。

ISUCON専用ホストサーバの購入が完了して使用可能になったタイミングで、ISUCON7の予選問題を使用して負荷試験を行うことにしました。ISUCON7予選に参加された方々が公開されていた設定内容を参考にさせていただき、ISUCON7予選の上位ランカーと同程度のスコアを出せる状態になったVMをホストサーバに詰め込んで負荷試験を実施しました。

想定以上の通信パケット量に、正直ビビりました。ホストサーバ1台でこの量。。。もし全ホストで同時にこれが起こったら。。。

実際の予選問題が同様のトラフィックを発生させるものであるとは限りませんが、起こる可能性があるとわかった以上、事前に手を打たないわけにはいかないと考えました。

そして、ホストサーバ上でのVMの配置構成を変更することにしました。

変更前

共有のベンチサーバのプールを用意すると仮定して負荷試験。

変更後

当初、ベンチサーバとWebアプリケーションのホストサーバをわけて配置することを想定していましたが、チーム毎に用意したベンチサーバを同一ホストサーバに配置して、ホスト内で通信を閉じることにしました。

結果、ホストサーバから外部に送受信するパケット量を無事に減らすことができました（目盛りの桁が減っています）。

その日、ベンチサーバは全チームで共有するのではなく、チームごとに作成させてもらう方向でお願いすることを、ConoHaインフラエンジニアたちは心に強く誓いました。

合宿

8月上旬、ISUCON運営者合宿に参加させていただきました。

問題を作成されるカヤックの皆様とDeNAの皆様と直接お会いできる場ということで、負荷試験の結果とVMの配置構成について共有する絶好の場と思い、意気込んで行きました。

結果、皆々様、熱心に相談に乗ってくださり、チームごとの影響範囲の分離などのご指摘もいただいたうえで、下図の構成で決定いたしました。

こうして、「ベンチの待ち時間が短い構成」が誕生しました。つまり、各チームがほぼ待ち時間なしでベンチを実行できる構成は、ConoHaのインフラエンジニアがトラフィック量にビビって提案した構成の副産物なのでした。

また、各チームにベンチサーバを用意することでデプロイするVMはチームごとに4つになり、トータルで2108VMに増加し、各VMに接続するネットワークの構成もじゃっかん複雑になりました。

今度はVMのデプロイにビビったConoHaインフラエンジニアは、ツールの作成に精を出し始めました。

（こけるパイプラインにつのる焦り。。。）

予選の準備

予選問題での負荷試験

9月上旬、先日の負荷試験でビビっていたConoHaインフラエンジニアは、予選問題の作成担当であるDeNA様にお願いして「初期状態」と「チューニング済」の問題をご提供頂き、負荷試験を実施しました。

そしてあえなく、チューニング済のVMの負荷試験で新しい問題が発生しました。負荷試験の結果、最適化されたISUCON8の予選問題は、トラフィック量はそれほど出ずDiskへの負荷も軽微でありながら、CPUに高負荷がかかるものであることがわかりました。

発生した事象は、1ホストあたり3チームまでしか同時にベンチを実行できず、4チーム同時に実行すると、スコアが想定通りに出ないというものでした。

ConoHaインフラエンジニアは少し余裕をもって用意していたホストサーバをフル動員し、それでもどうにもならず、DeNA様に状況のご報告とご相談をしました。そして協議の結果、ホストあたり同時にベンチを実行できるチーム数を3に制限し、4チーム目はキューイングするという仕組みをDeNA様に実装いただくことになりました。

DeNA様、その節はご協力をいただきありがとうございました。

予選問題のデプロイ

いよいよビビっていた2108VMのデプロイのタイミングがやってきました。

結果的には、事前に準備していたツールとConoHaのOpenStackベース基盤の連携で、心配していたほどの問題は発生しませんでした。作成したのはPythonでAnsibleとSQLiteをくっつけたコマンドラインツールで、チーム単位でVMを作成してネットワークを接続し、IPアドレスやユーザパスワードなどのOS内の設定や、VM間の疎通確認をするというものでした。

デプロイしたVMの情報をCSVにダンプしたり、逆にVM情報をCSVからインポートしてデプロイに使用したりできるのですが、思い返すとエクセルを使ったCSVの集計や加工が一番役立ったように感じます。

エクセルは偉大な発明であると、改めて感じました。デプロイ処理は比較的順調に進み、なんとか1日かけて完了しました。

予選当日

予選の運営

予選は9月15日(土)と16日(日)の二日間行われました。

両日ともそれぞれGMOインターネットから6名ずつLINE様へ伺い、専用の部屋をお借りして待機していました。

サーバ故障やスイッチ故障などの万が一の事態にできるだけスムーズに対応できるよう、サーバ部門やネットワーク部門など、複数の部署からエンジニアを動員しました。また、別動隊として弊社のオフィスにもサーバエンジニアが待機していました。とにかく動員をかけました。

インフラ起因での大規模な競技用VMの異常を検知するため、ホストサーバ用とは別にZabbix 4.0を構築して、Discordに通知して見張っていました。

正直、この二日間は心底ビビっていました。もしCPUの処理が追いつかない状態が続出したら。。。もしホストサーバが故障でもしたら。。。

当日は各チーム8時間という時間制限でチューニングに挑戦します。時間が経過するにつれてスコアがアップしていき、そのたびに恐る恐るホストサーバの負荷状況をチェックしました。

下図は予選をトップで通過したチームの負荷のグラフです。時間経過とともにCPU負荷が上昇していきます。

最初1つのVMで上がっていた負荷が、途中から、利用可能なすべてのVMで上昇していきます。

運営で用意していたベンチサーバも、アプリケーションのチューニングが進むにつれて終盤が大きく上がっています。

やがてすべての競技時間が終了。当日は、18時を過ぎて下がる負荷を見つつ、サーバに「頑張ったね。。。」と声をかけました。

結果的に想定をこえる負荷状況は発生せず、大きなトラブルが発生することもなく予選両日を乗り切ることができました。みるみる上がっていっていた参加者の方々のスコアを思うと、時間制限に助けられたのだと思います。

感想戦

予選終了後、感想戦ということで、予選で使用したVMを一週間延長してご使用いただくことになりました。

「もう少し時間をかけてチャレンジしたい！」と感じられていた参加者の方々が多くいらしていたこともあり、引き続き楽しんで頂けて、インフラを用意した身としても大変嬉しく感じました。

本選の準備

本選問題での負荷試験

予選に参加した527チームのうち、30チームだけが本選へ進むことだできます。サーバインフラを用意する身としては、チーム数が大きく減ったことで心理的には余裕が生まれていました。

ホストサーバも40台以上利用可能な状態であり、チームごとに1ホスト割り当てることができました。しかし、二度経験した負荷試験での衝撃が安心することを許しませんでした。本選問題の作成担当であるカヤック様にお願いをして事前に本選問題を頂き、1ホストの上で1チームだけの負荷試験を実施しました。

結果、初期状態版、チューニング済版ともにまったく問題は発生しませんでした。カヤック様、問題作成の大詰めであったにも関わらず、事前に問題提供のご協力をくださりありがとうございました。

本選問題のデプロイ

予選の準備で使用したデプロイツールが、そのまま本選問題のデプロイにも利用できました。

本選当日

本選は10月20日(土)に行われました。

予選ではエンジニアだけアサインしていたのですが、本選ではConoHaのPR等もさせて頂くお時間があるとのことだったので、GMOインターネットからはエンジニア2名、事業部門2名で伺わせて頂きました。

もちろん予選で対応して頂いたエンジニアも本選同様、弊社オフィスにて待機して頂き、万が一の事態にできるだけスムーズに対応できるよう、サーバ部門やネットワーク部門など、複数の部署からエンジニアを動員しました。

LINE様オフィスに伺った運営メンバーは会場のセッティングや、来場者の誘導等もお手伝いさせて頂き、こういったプログラミングコンテストを運営する上でのノウハウ等も学ぶことができました。ありがとうございます。

一通りの準備が終わった後は、LINE様から運営部屋を一つ用意して頂いていたので、インフラの監視準備を行いました。

LINE様に伺ったエンジニアは弊社本社待機メンバーと多くやり取りを行い、現地がどのような状況なのか伝える事に注力しました。

せっかくなので本選のサーバーの状態のデータも公開したいと思います。

下記グラフは本選にて優勝したチームのグラフですが、vCPUの使用率が上がっていき、アプリケーションの最適化がされている事が分かります。本選ではチームごとに1ホスト割り当てることができたおかげで、参加者同士でのリソースの取り合い等の影響を受けず、純粋に競い合える環境を提供できていたと思います。

特に開始から終了までインフラに問題もおきず、本選も終えることができた事を嬉しく思います。

さいごに

本選も終わり、全体を振り返ってみると、ビビり続きのISUCON8運営活動でした。

これもISUCONという大規模で、ハイレベルな技術が駆使されるイベントの運営に参加させていただけたゆえであり、お声掛けいただけた941さんを始め、LINE様には大変貴重な経験をさせて頂けたものと感謝いたしております。

カヤックの皆様、DeNAの皆様、問題作成が大変な時期にもかかわらず事前の負荷試験にご協力くださり、ありがとうございました。また、我々のVM配置案など、構成に関する相談に真摯に向き合ってくださり、ありがとうございました。ISUCON8のインフラを安定したものに保つことができたのは、問題作成者様との連携があったからであると感じております。

ConoHaの上で競技を楽しみ、喜んでくださった多くの参加者の方々にもお礼を申し上げます。皆様の有意義なISUCON体験の一助になれたこと、大変嬉しく思っております。

もしこの記事をお読みになって、新しくISUCONにご興味を持たれた方がいらっしゃいましたら、ぜひISUCON9へご参加ください。きっと素晴らしい時間を過ごせると思います。

以上、お読みいただき、ありがとうございました。

ブログの著者欄

採用情報

関連記事

• 

  inst（カラオケ音源）制作におけるAIで効率化する方法

  デザイン

• 

  ConoHaとTerraformで始めるインフラ自動化 後編：GPUサーバー構築と運用ガイド

  技術情報

• 

  ConoHaとTerraformで始めるインフラ自動化 前編：導入から基本のサーバー構築まで

  技術情報

• 

  ConoHa – ブランド立ち上げからAI活用に至るまで

  技術情報

• 

  「画像生成AIの認知度・利用実態調査」画像生成AI認知度95.8%・利用率46.2%、著作権課題が普及のカギ【ConoHa byGMO調べ】

  技術情報

• 

  ConoHa VPS の NVIDIA L4 サーバーで Splunk App for Data Science and Deep Learning を使ってみる

  技術情報