超小規模環境のMySQL #mysqlcasual
-
Upload
- -
Category
Technology
-
view
3.102 -
download
0
Transcript of 超小規模環境のMySQL #mysqlcasual
自己紹介
• 尾形 鉄次 (OGATA Tetsuji) a.k.a. @xtetsuji
• Blog: http://post.tetsuji.jp/
• Perlプログラマーで、最近はインフラもやっている
経歴
• 2003年から社会人としてIT企業で働き始める
• 2005年頃からMySQLを使ったサービスをいくつか開発
• それと平行して他のプロジェクトの色々なヘルプもする
• この頃は、RDBMS なら PostgreSQL or Oracle な時代
会社成長でサービスが増える
• 全社会議で経営陣が発言して運用保守サービスが増える
• 「あの会社をM&Aしました」
• 「子会社を海外に作って受託開発始めました」
• 「聞いてないよ」とは言えず、自身の開発業務の傍らで即日新しいサービスの保守運用業務が増える
とあるガラケーコンテンツ
• オーソドックスな LAMP 構成
• 朝出社すると「おがたさん、サイトにログインできません!」という慌てた企画担当者
• どれどれと思ってログインを試しても、普通にログインできる
• 安堵しつつ、次の日の朝出社(繰り返し)
さすがに原因調査
• だいたい毎日これなので、調べてみる
• エラー内容は「DBに問い合わせができない」だった
• さらに調べてみると、アプリ(Apache)が永続的なMySQL接続をしていた
• 朝になったらそれがタイムアウトしているという
MySQL接続のタイムアウト• 永続的な接続に長い間(たいてい数時間)データが流れていなかった、サーバ側から接続を切られる場合がある
• クライアント側は接続しているつもりでもサーバ側から切られる可能性があるので、pingなどの手段もある
• アクセスの少ないサイトだと、永続的なMySQL接続をしている prefork のサーバのうち暇なプロセスが見放されることは結構ある(設定で頑張らない場合)
pingで頑張る?
• この話をすると ping とか設定ファイルとか、MySQLに詳しい人達が色々教えてくれる
• だけど、MySQLの接続コストは他のRDBMSに比べても相当低いって言われているし(伝聞)、よほどの規模のサイトでもなければ都度接続でいいのではという結論
小さいプロジェクトの扱い
• 2005年ごろから他プロジェクトの保守運用系のヘルプをするようになって分かったことは、企画担当者が「このサイトは大きくなりますので(備えてください)」と言うサービスの半数以上は大きくなる前に終了する
• 各プロジェクトには備えておきますという素振りを見せておいて、一つくらい当たったら捻出できるリソースは準備しておく程度でいい
小規模しかやらない開発者は
• 長年 SQLのパフォーマンスを考えなくなる
• N+1問題とか以前に、ソレはないよというSQLが
• SELECT * FROM tbl; して毎回捨ててたり
• ちょっとアクセスが増えるだけで楽しいです
• 突然の DDoS !!!
小規模でもMySQL
• 小規模といっても、データストアを別のものにするのは意外に面倒
• ファイルロックを正確に知っているプログラマーの方が少なくなっているという衝撃の事実
• 複数ウェブサーバがNFS上のSQLiteファイルを読み込むとか逆に高度だし
2015年の小規模
• クラウド全盛時代、RDSやAuroraで立ち上げて、ヒットしなければ縮退もカンタンだし、規模が大きくなっても対応できる良い時代
• 10年前はオンプレサーバの出し入れから必要だったのが遠い昔のよう
手元にある小規模
• 社内の管理ツール等、普段ほとんどアクセスが発生しないものは今でもたくさんある
• 普通に素のPHPで都度接続のほうが健康的だったり
• 大規模になってから考えるでいい場合がほとんどだし、備えておいたから大規模になってよかったという事例はそれほどなさそう(あくまで私感ですが)