ISUCONの練習会をした
ブログを作って２日目です。 三日坊主にならないように、またーりブログを書いて行こうと思います。
ISUCONの練習会をしました
研究室のメンバーで今年のISUCONに挑戦しています。 学生枠の基準ですが、行けるとは思っていなかった本戦の出場権を得たので、来週末に行ってきます。
本戦で人権を失うと哀しいことになるので、足しになっているかわからないのですが、チームメンバでちまちまと過去問を解いたりしています。
今日はISUCON5の本戦問題に挑戦していました。 まるっきり歯が立たなくて辛かったです。 問題に関係ないベンチマーカーがプロビジョニング後にうまく動かなくて、色々と細工をしているうちに使えなくなったりして詰まったりしていました。
今日のブログではこれまでの知見を自分の中で整理するためにある程度まとめてみようと思います。 本戦後に全体感想記事とか書けたらいいですね。
アプリのアクセス解析
ベンチマーク中にどのリクエストが多く呼ばれるか、どのURLがどれくらい処理時間を喰っているか把握するためにはkataribeというログ解析ツールが便利です。
Nginxのアクセスログ設定をして、ログを配布されているバイナリに通すだけで、簡単にURLごとの呼ばれた回数、ステータスコードの割合やリクエスト処理時間等をわかりやすく出してくれます。 ISUCON用のツールなのではと思える出来です。
各種解析コマンド
便利なアナライザーもありますがシンプルなコマンドも大切です。
- top
- vmstat
- free
- iftop
等で負荷プロセスや要因を絞ります。 今日は初めてtcpdumpなるコマンドを使いました。 これでNginxの設定が希望通り通っているかとか見れますね。 どこと通信しているのかわからない初期の段階でも役に立ちそうです。 本番までに使いこなせるようにしておきたいです。
クラウド系の監視サービスとかを使うのはどうなんでしょうか？ 知見が足りないので使いこなせないのですがzabbix_agentをさっと放り込んで手元のサーバに繋いだら少しは監視できるのかもしれない。
slack送信
今までやっていなかったのですが、シェルスクリプトからSlackにパイプ入力を流すのってすごく簡単にできることを知りました。 いつもSlackbotはNodeで作っていたので。
この記事を参考にさせていただいてSlackにログとかを流すようにしました。 チーム内共有が早くなっていいなって思いました。
nginx設定
実際対策に行こうと思います。 nginxの設定は基本的に以下のようにします。
- gzip on
- type指定忘れない
- 事前にファイルを圧縮しておく方式を使う
- js,css,font等はappとlocationを分けて前方一致でdocument rootを指定して流す
- expire等を忘れない
- ベンチマーカーとかでキャッシュが効いてることをチェックする
たいていこれをやれば静的ファイルの配信には劇的に効きます。
app
可能なものはキャッシュ
複数プロセスであればRedis、シングルプロセス＆Redisを持ち出すほどではない場合は
この辺を使います。 オンメモリキャッシュがやはり最強です、桁が違いますからね。
DB系
- ISUCONにORマッパはない（今まで自分たちがやった限り）のでSQL力で挑みます。
- ひどいクエリはロジックに問題があることが経験的に多い気がするので、クエリを見直すよりロジックを見なおしたほうがいいことも頭の片隅に入れるようにします。
- MySQLのクエリログを出してインデックス付与等します。
- Appの飛ばしてるクエリやテーブルサイズ等からMySQLの温めるべきキャッシュを判断して温めます。
- DBが重要なアプリならキャッシュサイズ等は腐るほど解説しているサイトがあるのでそのとおりにとりあえず設定します。
- ISUCONでは再起動に耐える必要があるので、MySQLのキャッシュを終了時に書き出す設定も忘れずにしておくといい感じです。
以上自分の覚書程度に書きました。 意外と今までこういった周りの知識がなく、ここ最近で結構増えたのでISUCON挑戦してよかったなーって思ってます。
