Webサーバー複数台化への道のり::設計編


small__3595638270

概要

とあるレビューサイトではアクセスのピーク時間帯になるとサイト動作が全体的に遅くなる現象が長く続いていました。取り急ぎの改善としてはSQL、I/O負荷の高い処理の見直しをしてきましたが、あくまで局部的な修正に過ぎず、根本的な改善となりませんでした。

PHPのパージョンアップ、ミドルウェアの導入などソフトウェアによる改善も検討しましたが、今回はハードウェアの強化を優先することにしウェアサーバーを一台から複数台に変更するすることにしました。このエントリーで懸念点、対策方法の設計についてまとめます。

複数台に伴う懸念点

実際Webサーバーの2台目以降を構築して、DNSラウンドロビンをして、ハイ終わり!とはならず、いろいろ既存の仕様の問題や疑問点が見つかりました

  • 複数台への同時デプロイはどうすべきか
  • アップロード画像データのDB管理また複数台時の共有はどうすべきか
  • アップロード画像データの独自のサイズ変換機能
  • Sitemap.xmlなどの出力データの共有
  • PHPセッションはどうやって共有するのか
  • これを機にPHPや各種ミドルウェアのバージョンもすべきか
  • サーバー構築の手順書を作るのが大変だ
  • サーバー構築はどこでやるのか
  • サーバーが複数台になったらいちいち全台にsshするのはめんどい・・
  • 監視はどうする?
  • その他の独自仕様が‥

他にもあったような気もしましたが忘れました

解決方法

複数台サーバーへのデプロイ

capistrano1

画像管理とサイズ変換と共有方法

nginx2

画像サーバーを構築しそこでユーザーのアップロード画像を一括管理。またnginx+HttpImageFilterでリアルタイム画像変換

Sitemap.xml

newrsynclogo

rsyncで常に同期

PHPセッションの共有

web-accelerators-memcached

PHPや各種ミドルウェアのバージョンアップもすべきか

しない。目的は複数台化でありバージョンアップではない。バージョンアップを新規構築分だけしてしまうと問題が起きた時に調査しずらい。あくまで既存のウェブサーバーを忠実に再現することが前提。今回はしないという意味で複数台化が終わってからやるべき。

サーバー構築の手順書作りが大変

Chef Logo

サーバー構築はどこでやるのか

logo_wide-cab47086

サーバーが複数台になったらいちいち全台にログインするのは面倒い・・・

Knife Solo

監視

munin_logo_325x100

その他一台構成前提の独自仕様が‥

気合いで直す!

設計から約一年後‥

スタートから様々なイベントや既存の運用もあったので時間もかかりましたが、ほぼ想定通りに実装完了しました。リリース直後から様々な障害もありましたが(今もまだ残作業が残ってますが)、サーバー負荷は想定以上に下がり、体感的に早くなりました。正確には早くなったというより、負荷が下がったので重たい頻度が少なくなったというのが正しい表現かと思います。

基本的には設計時にあげたソフトウェアは全て未経験なので手探り状態で始めたのでかなり時間がかかりましたがとても良い経験になりました。これも開発チームの協力あってのおかげです。

今後の予定

  • serverspecを導入してテスト駆動インフラ構築をしたい
  • PHPのバージョンアップを・・・

次回以降は各対応でのまとめや経験した問題の解決方法などを公開したいと思います。ではでは

PS


シェアする

  • このエントリーをはてなブックマークに追加

フォローする