開発^3

Web開発、宇宙開発、ゲーム開発の3種類についてつらつらと

ISUCON8に1人で参加してきました

ISUCON7は3人チームで参加しましたが、今回は1人参加も可能ということで、ぼっち参加してきました。
1人参加は枠数が限られていたので、慌てて申し込んだ結果、実は見たことのない「RE: ゼロから始めるISUCON 」に。

結果は最高スコア32,596、最終スコア26,873で予選落ちではあるものの、去年の反省を活かした動きである程度のスコアが出せたのは良かったです。
ただ、正直手が付けられていない箇所が多すぎて、不完全燃焼感も。
＃ 後日の検証でLBだけ有効にしたら79,356でましたが、不安定だし、たらればですね。（でも書いちゃう）

やったことと感想

事前に決めていたこと

1人参加、かつアプリ寄りの人間のため、迷ってる暇はなさそう。インフラ側の変更は最低限にして、アプリの改修を優先しよう。
ISUCON7でも使用したkataribe, pt-query-digest, netdataは今回も使いたいな。特に前回の教訓を元にネットワークの帯域には気を付けよう。
1人だと自由に本番環境を使えるから、手元環境で動作させる必要は無いよね。いつも使ってるdotfilesを本番に入れられる準備はしておこう。
前回同様、複数台構成の可能性もあるし、普段のサーバ(tmux入り)からwindow/paneを切ってつなごう。

事前準備

  • 初期設定・計測用スクリプトの準備
  • tmuxのwindow/pane切り分け
  • 最終手順の手順書準備（不要サービス停止、ログ抑制）

チューニング方針

環境を確認した瞬間「出題DeNAじゃん！！」と叫んでしまったのですが……十分考えられる選択だったよね。
nginxに置き換えた人も多かったようですが、設定をみたら割と読みやすかったのと、事前方針を思い出してh2oのまま行くことにしました。
（Evernoteからnginxインストール/設定手順を取り出してダウンロードまでは掛けたんですが）

チューニングの手順としてはpt-query-digestで重い部分を洗い出して修正していくという基本的なもの。
一通りコードを読んでget_events/get_eventが重いことは明らかだったんですが、呼んでいる箇所が多すぎて挙動を変えづらいのが難点でしたね。

結局、cancelの扱いがクエリを複雑にしているので、現在の予約状況を示すテーブルを新しく切って対応しました。

current_reservations(
    id,
    event_id,
    sheet_id,
    num, rank,
    user_id,
    reserved_at,
    reservation_id
)

非正規化の極みとばかりに、どんどん必要になったカラムを増やしていきましたが、最終的にはcurrent_reservations自身がボトルネックになってしまっていたのがちょっと残念かな。

（対応した順番としてはこっちが先ですが）残席数管理はredisにしました。
残席自体もredisのsetで管理しようと考えたんですが、何故か残席のsetじゃなくて、予約席のsetを作ろうと考えてしまい、そうするとreserved_atをどこに持とう？とか考えて、結局RDBにしてしまいました。
atomicなpop処理ができれば、redisだけでロックの代替ができたのかな？

後は細かいところをあれこれと弄っていました。 - get_eventは呼び出し元によってはdetailが要らないので、with_detail引数を増やしたり - sheets情報をpython中にハードコーディング - sha256の計算をhashlibでやってみたり - kataribe的にloginが重いと言われたからやってみたけど、ストレッチングも無いのでそもそも重くないかも - テーブルへのindex追加 - get_login_userを呼ぶ必要のない場所があったので削除 - mysqlをserver3に移動

悔やまれる点

  • admin側が全然見られなかった
  • lock問題についてはそこまで悩まされなかったが、理解して回避したというより、運よく回避した、という感じが強い
  • 実際、スコアが不安定で、failすることもあった
  • 明らかにここ変えたい、という場所に手が回らなかった
  • order by rand()
  • h2oのLBが/etc/hostsでできることを知らなかった
  • /etc/hostsに2レコード書いてping飛ばすところまではやったけど、ダメだったのであきらめた。h2o本体で試すべきだった。
  • ISUCON7予選のトラウマから50Mbpsのグローバル帯域を気にしすぎた

課題・環境について

ポータルがすごく便利。ベンチマークも全く待ち時間が無く、とても快適でした。
課題としては面白かったものの、lockが主題になるとスコアが安定しないのが難点か。
修正が役に立ったのかどうかがもひとつ判断できず、ツライ時間が続いたりしました。

サーバについては、終了後にベンチ環境まで含めて1週間公開してくれるというのがすごくありがたいです。
時間切れで試せなかった場所とか、ロックの関連とかいろいろ見てみたいと思います。
サーバ提供のConoHa GMOインターネット株式会社さまと、このはちゃんには足を向けて眠れませんね！

1人参加のメリット・デメリット

さて、せっかくの1人参加ということで、1人参加のメリットとデメリットも書いておこうと思います。
ISUCON9で1人枠が用意されるかはわかりませんが、参加を考えている人は参考にしてください。

メリット

  • 自宅から参加できる（いつものPC、いつものキーボード、移動時間0分）
  • 本番環境を自由にカスタマイズ可能（zsh, vim）
  • 本番環境で直接作業ができる（gunicornをフロントで起動）
  • ベンチマーク実行時とかに他の人の確認を取る必要が無い
  • 何をやったか、どこまで終わったかが常に把握できる

デメリット

  • 手が足りない
  • 嵌ったときにグーグル先生にしか頼れない
  • 改修してもスコアが出ない時間が続くと気持ちが折れやすい
  • 知識のカバー範囲が足りない
  • アプリ1人、インフラ1人、計測&方針決定1人のチームが強そう
  • 打ち上げがちょっと寂しい