feature image

2019年12月17日 | ブログ記事

部内ISUCONを開催しました

SysAd班のxecuaです。公式Twitterでもちらっと触れました(CATechPitchBattleのスライドでもちらっと見えてたみたいですね)が、部内ISUCON(PISCON)を開催しました。
今回はそのときに詰まったこと、反省などを書き記しておきたいと思います。

ISUCONについての説明は割愛させていただきます。


traPからは毎年数チームISUCONに出場しており、その練習会をSysAd班主催で毎年行なっています。
また、毎年度はじめにも開催しています。ISUCONはUnixサーバーに触れる良い機会であり(実際、私は2年前のISUCON練習会で初めてUnixサーバーに触れました)、新しくSysAd班に加入したメンバーに、競技を通してサーバーの操作に慣れたり、問題の解決方法を学んだりしてもらおうという意図があり、結構大事なイベントだったりします。

これまでは主にとーふとふさんやながてちさんが開催されていましたが、そのお二人が今年度で卒業してしまう(予定)ことを受け、次回以降の開催するにあたり知っておいたほうが良いことなどを聞いておき、今回はその確認をするために開催しました。

環境

今回はISUCON9 予選の問題を使わせていただきました。
https://github.com/isucon/isucon9-qualify

競技用のインスタンス、およびベンチマーカーにはConoHa VPSのメモリ1GBプランのものを利用させていただきました。なんでかというと前回の部内ISUCONで使っていたから(https://blog.nagatech.work/post/isucon/561)と、実際の予選で使用したAlibaba Cloudを利用したことがなく、準備に間に合わないと判断したためなんですが、前者に関しては、ISUCON8 予選の競技用インスタンスがそうだったかららしいです(あとから知りました...)。
実際の予選で利用したecs.sn1ne.largeインスタンス(vCPU2個、メモリ4GB)(http://isucon.net/archives/53789931.html)に比べるとやや弱い構成で、参加者が思うようにスコアを伸ばすことが出来ませんでした(bcryptの処理を2台目に移してもスコアが改善しなかったそうです)。やはり多少無理をしてでも実際の環境に寄せるべきでした。

また、ベンチマーカーをこの構成にしたのは最大のミスでした。サーバーの処理が追いつかず、ベンチマーク中にBad Gatewayを返す最悪の事態が起きてしまいました。ベンチマーカーなのだからかなり性能を上げるべきでした。反省。
いちおう問題リポジトリに別ブランチとしていい感じに最適化したアプリがあって、それで試したところ43000点まで行ったのでいいかなぁ〜wってなったんですが、そういうことではなかったんですよね...

ネットワークに関しては、1つのインスタンスにつき2つのプライベートネットワークにしか接続できないらしかったので、チームごとにプライベートネットワークを作成することは諦め、すべてのインスタンスとベンチマーカーを同じプライベートネットワークに入れ、広い帯域でベンチマークが利用できるようにしました。
IPアドレスをこちらで指定することができなかったので中途半端な感じのする値になってしまいましたが、妥協しました。

問題の準備

前回同様、問題のリポジトリに環境構築用のAnsible設定ファイルがあったので、それを使って競技用のインスタンスを作成し、イメージに固めてそこからインスタンスを作成する形を取りました(Ansibleは使ったことなかったんですが便利ですね)。

ベンチマーカーはポータル(https://github.com/traPtitech/piscon-portal)の中で起動する形になっているので、自分で環境を作り、必要なファイルなどを揃えてポータルサーバーとしてデプロイしました。

どうせなら最新がいいなぁってことでapt ppaからインストールしたAnsible2.9を使ってプロビジョニングをしようとしたんですが、synchronizeモジュールでBroken pipeが出てしまい、調べていると、以下のようなissueを見つけました。
https://github.com/ansible/ansible/issues/56629
どうやらpythonとこのモジュールの相性が悪い(超解釈)らしく、よくわからなかった(思考放棄)のでデフォルトのリポジトリから入れ直した2.5を使ったところうまくいきました。問題解決ができてないので載せるべきか迷いましたが...

また、ISUCON 9予選の特徴の一つとしてHTTPSで通信を行うことが挙げられます。予選で使われた証明書も問題のリポジトリにあったのですが、有効期限が切れていてエラーを吐かれたので自分の持っているドメインで適当に作って置き換えました。
また、shipmentサービス、paymentサービスでIPアドレスとポートを直接指定するとなんかうまく行かなかったんですが、適当に名前を割り振り、競技用サーバーの/etc/hostsに書いてみたところ、うまくいきました。

競技

実際の競技より1時間短く7時間で高速化をしてもらいました。
一応大学の講義室を取ってオンサイト会場にしてたんですが、2人しか来なくて少し寂しかったです。

私も一応参加しました。簡単なN+1の解消やDBにある不変データを取り出すことでちょっと高速化が出来ましたが、予選参加時に解消できなかった部分が今回も解消できなかったのでなんだかなぁとなりました。
また、翌日提出の重めの課題があったこともあり、あまり集中して競技に望めませんでした。

最終的な結果はこんな感じで、スコアが乱高下する人が発生してしまいました。
----------2019-12-15-17.01.07-2


今回は反省点の残る結果となりました。この反省は次回に活かしていきます。

ちなみに上に挙げた以外にも反省点はありまして、ポータルの機能改修案がいくつかあったんですが、講義が忙しかったこともありほとんど手をつけられなかったことなんかがあります。
こちらは次回開催までになんとかしておきたいと思います。

最後に、この場を借りて参加してくださった皆さん、サポートしてくださったとーふとふさんとながてちさんに感謝の意を表します。
ご迷惑おかけしました。

xecua icon
この記事を書いた人
xecua

音ゲーマーじゃないです

この記事をシェア

このエントリーをはてなブックマークに追加
共有

関連する記事

2019年12月22日
部内製チャットサービス「traQ」UIのこれから 【AdC2019 53日目】
sigma icon sigma
2019年12月4日
部内製チャットサービス「traQ」UIのこれまで 【AdC2019 35日目】
spa icon spa
2019年12月1日
traP部内サービス「booQ」で発見した脆弱性でOSSコントリビュートした話
nagatech icon nagatech
2019年11月26日
部内製チャットサービス「traQ」とPaaS基盤「Showcase」の障害対応の話【AdC2019 25日目】
to-hutohu icon to-hutohu
2019年11月2日
traQのmarkdownのパースをWeb Workerでやるようにした話【AdC2019 3日目】
sappi_red icon sappi_red
2020年3月31日
2019年度SysAd班を振り返る【新歓ブログリレー2020 23日目】
to-hutohu icon to-hutohu
記事一覧 タグ一覧 Google アナリティクスについて