1954

Thoughts, stories and ideas.

ISUCON8本選に出場して5位だった

Webアプリケーションの高速化バトルISUCON8本選に「チーム人間性」で出場しました。

最終スコアは13,914で5位という結果に終わりましたが、素晴らしい運営と問題で、大変楽しいコンテストでした。

使用言語はGoでした。

やったこと

3人チームで参加し、自分はデプロイなどの足回りやインフラ周りを主に担当しました。

ここでは自分のやったことにフォーカスして書きますが、他にもクエリのキャッシュやmysqlのindex最適化など色々入ってます。

非docker化

今回与えられたマシンは4台で、ベンチマーク対象として指定できるのは1台でした。

初期状態では全てのマシンが同じ中身で、1台の中にnginx, mysql, アプリが全てdocker-composeで上がっていました。

後々辛くなりそうな気がしたので、dockerを剥がして以下のような構成にしました。

  • app server1
  • app server2
  • app server3 兼 nginx (エントリポイント)
  • db server (mysql8)

また、各サーバーのプロビジョニングはansibleで行いました。

ログのバッファリング

今回のアプリケーションには、外部のログ分析APIに一部の操作のログを送信するという仕様がありました。

ただしログ分析APIにはrate limitが設けられていて、rate limitを超えて送信した分はログが欠損し、ベンチマーク後のvalidationを通過できずfailするようになっています。

初期状態では1件ごとにログを送信しているため、スコアが伸びてくるとrate limitに引っかかってベンチマークがfailしてしまいます。

お誂え向きに、ログ分析APIにはバルクでログを受け付けるAPIが用意されていたので、goroutineとchannelを使ってログを一定数バッファリングしてバルクで送信するようにしました。

他の言語を使っていて、バッファリングをいい感じに書くのに苦労したチームもいたようです。

share有効化

今回は「仮想椅子取引所ISUCOINが世界的SNS"いすばた"と提携開始!」というシチュエーションで、いすばたでシェアされるとバイラル的にユーザーが増え、スコアが伸びるようになっています。

ただし、すごい勢いでユーザーが増える(ような挙動をベンチマーカーがする)ことによりrequest timeoutが頻発して、規定のエラー数を超えてfailしてしまうため、初期状態ではシェア機能がOFFになっています。

これを、10%のリクエストでのみシェア機能を有効にするようにしました。(単純にシェア機能を有効にするだけだと、エラー数超過でfailしてしまった。)

シェア機能を有効にするリクエストを絞るという発想にいたったのが17:30ごろだったのでだいぶ苦し紛れでしたが、これによりスコアがだいぶ伸びました。

まとめ

スコアの遷移はこんな感じでした。(予選もそうでしたが、ポータルサイトかっこよかった)

f:id:ocadaruma:20181021003417p:plain

うまく分担して進められた気はするものの、それでも時間が足りないと感じるほどボリュームのある問題でした。

あらためて、素晴らしい運営をしてくださったみなさん、ほんとうにありがとうございました!!