ISUCON5本選で3位(+特別賞)でした

ISUCON5本選に@kazeburo、@shmorimo、@cubicdaiyaの3人でチーム「GoBold」として参加して3位になりました。また、合わせて運営が定めたスコア（100,000点）に最も早く到達したチームにもらえる特別賞ももらいました。

開始3時間ちょいで10,0000点に到達し、とても順調なスタートを切ることができましたが、ここから思うようにスコアを伸ばすことが出来ず最終スコアは89,254点でした。

チームの方針とやったこと

既に@kazeburoさんが書いてるエントリ↓があるのでこちらではそちらに補足して書いていきます。

blog.nomadscafe.jp

予選での役割分担がうまくいってたので今回も予選と同じく自分がインフラやミドルウェア周りのチューニングと整備やログ等の分析を行い、 @kazeburo、@shmorimoの二人がPerlアプリケーションのチューニングを行うという体制になりました。実際に自分の方でやったのは、

  • sshの公開鍵を各サーバに配る
  • ngx_http_stub_status_moduleでベンチマーカーの並列数を計る
  • ngxtopでアクセスの傾向を探る
  • nginxやsysctl.conf等のチューニング(静的コンテンツをnginxから配信等)
  • memcachedの導入

といった感じです。

ngx_http_stub_status_moduleでベンチマーカーの並列数を計る

ISUCONで時々話題になるベンチマーカーの並列数(ってどうやって調べてるの？)ですが、 今回はnginxのngx_http_stub_status_moduleで計ってみました。 ngx_http_stub_status_moduleはnginxへの接続数や Activeな接続数、各接続の状態(Reading、Writing、Waiting)といった情報をHTTP経由で取得できるモジュールです。

location /stub_status {
    stub_status on;
}

/stub_statusにアクセスするとこんな感じで情報が取れます。(数字はテキトーです)

Active connections: 54
server accepts handled requests
 10331 10331 51946
 Reading: 0 Writing: 11 Waiting: 43

今回はベンチマークを実行している間「Active connections」が大体50前後だったので これを元に全部で3台ある各ノードのアプリケーションサーバのプロセス数を決めていきました。(20だったかな？)

キャッシュとAPIリクエストの多重化

今回は出題内容を確認して早い段階で、外部APIへの問い合わせが大きなボトルネックになっていることがわかりました。 なので当初、キャッシュによる効果はあまり期待できないだろうなーというのがチームの共通見解でした。

まぁ、でもとりあえずやってみようということで3台構成で動かせるようになった後はいろんな箇所でmemcachedにキャッシュして突っ込んでいった結果、 ほかのチームが数万点台の中、それで10万点を越えてしまったので「あ、キャッシュでいいんだ」という感覚でした。 出題側にとってもキャッシュだけでここまでスコアが大きく上がるのは想定外だったのではないかと思います。

元々APIリクエストの多重化や7つのAPIエンドポイントのうち2つがHTTPSになってることは最初は頭にありましたが、 キャッシュがあまりにも効果的すぎたので、その二つについてはこのあたりで考えるのをやめてしまいました。

その後

さて、先述の通りその後はいろいろとうまくいかず、スコアが横ばいのまま推移して最終的に特別賞のスコアよりも低い89,254点でフィニッシュしました。 また、今回個人的にかなり悔しい点があって、それはngxtopで静的コンテンツへのアクセスが多いことに気付いてたのにも関わらずレスポンスのgzip圧縮をしなかったことです。

たらればを言うとキリがありませんが、nginxのgzip_staticを有効にしていたらもっとスコア上がってたかも。

3位(10万円)+特別賞(5万円) = 15万円

獲得賞金は1人あたり5万円。

さいごに

出題の@tagomorisさんと@kamipoさんをはじめとする運営の方々、大変お疲れ様でした。来年も開催されたらぜひ参加したいです。