超小規模サイトのDB運用

尾形 鉄次 (OGATA Tetsuji)

Twitter: @xtetsuji2013/12/9 Machida.pm #1

自己紹介

• 尾形 鉄次 (OGATA Tetsuji)

• Twitter: @xtetsuji

• Blog: http://post.tetsuji.jp/

• 北海道生まれでよくHokkaido.pmに行く

地域.pmに行きたい• 東京やその周辺の、行くことができる地域.pmには精力的に行きたい

• コミュニケーション大事

• 北海道には帰省で行くし、他の場所にも旅行目的で行きたい

大規模事例のDB運用とか見飽きた人～

今日は超小規模運用のDB事例です！

DBの接続コスト• MySQLは他のDBより接続コストが低いと言われている

• 都度接続でも問題無い→PHP等でGood

• それでも大規模環境では接続を保持しておくことが多い

DBの接続保持

• DBI->connect() のオブジェクトをパッケージ変数として永続化しておく

• mod_perlであればApache::DBIを使えば透過的に接続維持ができる

超小規模の場合

• 夜中にアクセスがほとんど来ない！

• preforkプロセスのうち、たまたま日没から日の出まで全くアクセスを受けない、運がよいのか悪いのかわからないプロセスが出てくる

超小規模の場合

• 朝出社すると「時々ログイン出来ませんってエラーが出ます」ってディレクターが必死にサイトいじっている

• なんだろうと思って調べ始めてももうエラーがでなくなっている

Morning Bug

• こういう「朝にログイン出来ない」といったバグのことを「Morning Bug」という（本当です）

• 大規模サイトではほとんど出会わず、このバグは超小規模サイトでのみ出る

さてなぜでしょう？

DBから接続断される• stateにしておいた$dbhはDBの設定にもよるが、6時間とか12時間とかのスパンでアクセスされないと、DB側から接続が切られる

• $dbh はオブジェクトとして有効なので$sth->prepare()等の段階でエラーになる

Morning Bugの回避• 超小規模サイトなら、MySQLの接続コストは他のRDBMSに比べて無視できるくらいなんだし永続接続とか考えないほうがよい場合が多い

• ハマるとわからないケースが多い

• my.cnf の調整とか考えなくてもよさげ

結果的には• 会員数二桁くらいのサイト、さっさとやめたほうがいい！！！

• 超小規模サイトだけでなく、社内ツールをこういう構成にするとMorning Bug

に遭遇するケースもあるから注意

• 社内ツール、CGIがいいケースもある？

ご清聴ありがとうございました