Webサーバー複数台化への道のり::設計編
January 25, 2014
概要
とあるレビューサイトではアクセスのピーク時間帯になるとサイト動作が全体的に遅くなる現象が長く続いていました。取り急ぎの改善としてはSQL、I/O負荷の高い処理の見直しをしてきましたが、あくまで局部的な修正に過ぎず、根本的な改善となりませんでした。
PHPのパージョンアップ、ミドルウェアの導入などソフトウェアによる改善も検討しましたが、今回はハードウェアの強化を優先することにしウェアサーバーを一台から複数台に変更するすることにしました。このエントリーで懸念点、対策方法の設計についてまとめます。
複数台に伴う懸念点
実際Webサーバーの2台目以降を構築して、DNSラウンドロビンをして、ハイ終わり！とはならず、いろいろ既存の仕様の問題や疑問点が見つかりました
-
複数台への同時デプロイはどうすべきか
-
アップロード画像データのDB管理また複数台時の共有はどうすべきか
-
アップロード画像データの独自のサイズ変換機能
-
Sitemap.xmlなどの出力データの共有
-
PHPセッションはどうやって共有するのか
-
これを機にPHPや各種ミドルウェアのバージョンもすべきか
-
サーバー構築の手順書を作るのが大変だ
-
サーバー構築はどこでやるのか
-
サーバーが複数台になったらいちいち全台にsshするのはめんどい・・
-
監視はどうする？
-
その他の独自仕様が‥
他にもあったような気もしましたが忘れました
解決方法
複数台サーバーへのデプロイ
画像管理とサイズ変換と共有方法
画像サーバーを構築しそこでユーザーのアップロード画像を一括管理。またnginx+HttpImageFilterでリアルタイム画像変換
Sitemap.xml
rsyncで常に同期
PHPセッションの共有
PHPや各種ミドルウェアのバージョンアップもすべきか
しない。目的は複数台化でありバージョンアップではない。バージョンアップを新規構築分だけしてしまうと問題が起きた時に調査しずらい。あくまで既存のウェブサーバーを忠実に再現することが前提。今回はしないという意味で複数台化が終わってからやるべき。
サーバー構築の手順書作りが大変
サーバー構築はどこでやるのか
サーバーが複数台になったらいちいち全台にログインするのは面倒い・・・
Knife Solo
監視
その他一台構成前提の独自仕様が‥
気合いで直す！
設計から約一年後‥
スタートから様々なイベントや既存の運用もあったので時間もかかりましたが、ほぼ想定通りに実装完了しました。リリース直後から様々な障害もありましたが(今もまだ残作業が残ってますが)、サーバー負荷は想定以上に下がり、体感的に早くなりました。正確には早くなったというより、負荷が下がったので重たい頻度が少なくなったというのが正しい表現かと思います。
基本的には設計時にあげたソフトウェアは全て未経験なので手探り状態で始めたのでかなり時間がかかりましたがとても良い経験になりました。これも開発チームの協力あってのおかげです。
今後の予定
-
serverspecを導入してテスト駆動インフラ構築をしたい
-
PHPのバージョンアップを・・・
次回以降は各対応でのまとめや経験した問題の解決方法などを公開したいと思います。ではでは
PS
- データセンター画像探しは
これを参考にしました。
- photo credit: