読者です 読者をやめる 読者になる 読者になる

株式会社クイックのWebサービス開発blog

HAPPYなエンジニア&デザイナーのブログです

アプリ設計者がISUCON5にチャレンジしてみたよ

そして惨敗した話だよ。


こんにちは、ゆめです。
普段はアプリケーションの設計とか、運用周りのこととかやってます。

プログラミングはやりたくなったときに遊び程度にしかやらない私が、ISUCONになんちゃって参加してきました。

ISUCON詳細
http://isucon.net/

チーム編成

  • インフラエンジニアまつb
  • わたし

もう1人いたらいいなと思って「下僕」という名前も含めた3人チームでエントリーしてましたが、
誰も下僕になってはくれませんでした。

会場

住み慣れた弊社のMyデスク

お題

運営さんが用意してくれたSNSサイトで高パフォーマンスを!
※お題サイトみたときの衝撃。凝ってますよね。

予習

去年のISUCONの環境再現したり、ブログ読んだりしました。

言語

PHP
一番慣れていたので。
SQL文以外のソースをいじれる気はあんまりしなかったので、
PHP読んで仕様把握してRubyのソースをアレコレしようとしてましたが、
結局PHPに変えてもらいました。

自分で書くときはフルスクラッチなので他の書き方も慣れてなくて、
人のソース読むのも大変だった。勉強になったなぁー。

方針

  • ブラウザでサイトの内容や機能をざっと確認する
  • MySQLのテーブル構造把握する
  • SQLを投げる部分に重点を置いてソース読む
  • とりあえずindexはる
  • SQL_CACHE使えそうな部分を探す
  • SQL文見直す
  • テーブルを非正規化してみる


あとは、やっていくうちに、
「日記のTitleとBodyで何でおんなじカラムに入ってんの?」
とか
「relationsの設計なんとかならないの?」
とか
「is_friendsをなんとかしたいなぁ」
とか
「そもそもusersにselectかけすぎじゃない?」
とか、徐々に気づくかんじでした。

でも、ちゃんと修正できなかった。。。

  • title/body分離

→もともとtext型だったので、titleをvarcharにしていいのか悩んだ。
text型がテーブルに複数あるってどうなのかしらと余計なことを考えるうちに終わった。

  • relationsテーブル

→「SELECTを変えず、insertを減らす(one、another1パターンのみ)」のが正解だと分かってはいても、
初期データを半分に減らす方法がすぐに思いつかなかった。
結局、SELECT文のWHERE句をoneのみにしました。

  • is_friends

→認識はあったものの、対応策を考えるところまでたどり着けなかった。。

  • users

→呼び出し回数が多い上にテーブルの内容が変わらないので、どっかにまるごと持たせておくとかした方がよかったかも。


※footprintはどうにかせねばと思ってましたが、まつbに任せきりでした



課題の発見ポイントはなんとなく押さえられてたけど、
修正の具体策を考え・実装するのに時間がかかってしまったのが大きな反省。

普段は課題発見して修正方針決めたら、
実際のコーディングは別の方が担当するため、
自分にその力量・経験がないことが露呈してつらたんでした。

やっぱり、普段やってないことはできないね。


感想

SQLのパフォーマンスチューニングをもっとしっかりやってみたいと思った。
NoSQLに興味を持ちました。というかミドルウェアに疎すぎ。
次回はPerlRubyでやりたい。というか、言語選択に幅がある人はやはり強いなと思いました。


悔しかったけどとても楽しかった。


自分の現状把握と、モチベーション向上のきっかけになりました。
やっぱり、実際に技術の必要性を感じる場面に出会えるってすごくいいよね!!!

運営のみなさま、参加者のみなさま、ありがとうございました。


勉強しよ。