こんにちは。
ひさびさの更新となりました、キラメックス開発ブログ。今回は田中が担当します。

個人の趣味的サービスにしても、ベンチャーが始めたサービスにしても、ユーザが増えてきたときに必ず直面するのがサーバ増設です。

1台のサーバでアクセスがさばききれなくなったとき、いずれは複数台化するタイミングがきます（きました）。

近年、VPS、クラウドなど、即時で立ち上げられるサービスも数多く出ていて、選択肢は広がっています。
VPSであれば専用サーバよりも安く手軽に立ち上げられるし、クラウドであればコストを抑えながら日々変わるアクセス負荷に応じて、柔軟にサーバ増設や集約が可能なメリットがあります。

目的やコストに応じた選択が必要ですが、やり方はどうあれ、最初の増設は少々厄介です。
当たり前と言われればそれまでですが、1台のサーバを2台にするのであれば、ユーザにはどちらのサーバでも同じコンテンツを見せる必要があります。

今回はそのあたりに軸をおいて、サービスのサーバ増設について整理してみました。

昨年末ごろに当時KAUPONで発生していたサーバダウンや処理遅延などの根本対策として、実際におこなった事例をベースにしています。
最新のベストプラクティスではないかもしれませんが、いちサービスでの事例として参考になれば幸いです。

環境について

KAUPONはいわゆるLAMP環境です。

• Linux（CentOS）
• Apache
• MySQL
• PHP

多少詳しい環境についてはこちらの記事をご覧ください。

KAUPONつくってます
KAUPON開発で使ったオープンソース10個

1. 分割単位を検討する

増設にあたり、単純に同じシゴトをするサーバを増やすこともできますが、基本的には役割を分けて増設するやり方がスタンダードだと思います。

コンテンツを返すサーバはいっぱい必要だけど、データベース用のサーバは1個でいいよね、とかそういう話です。

役割を分けるために、どのようなシゴトがあるかを考えます。
細かいモジュールまで見ていくとキリがありませんので、大きなシゴトのみ整理します。

• アプリケーション（PHP）
• バッチ（PHP）
• ウェブサーバ（Apache）
• データベース（MySQL）
• データキャッシュ（memcached）
• メール送信（Postfix）

大きくはこんなところでしょうか。

これを元に、増設後のサーバ構成を検討してみます。

ウェブサーバ

• アプリケーション（PHP）
• ウェブサーバ（Apache）
• メール送信（Postfix）

バッチサーバ

• バッチ（PHP）
• メール送信（Postfix）

データベースサーバ

• データベース（MySQL）
• データキャッシュ（memcached）

今回、メール送信機能はDBサーバを除く各サーバに持たせることにしています。
セッションデータや頻繁に参照されるデータをつっこむmemcachedはできれば別サーバにしたいところですが、コスト面を考慮してDBサーバに相乗りする形にしています。

ウェブサーバはアクセスを集中的に受けるため台数を調整して、以下の構成でサーバ増設を進めていくことにします。

before

• サーバ×1

after

• ウェブサーバ×3
• バッチサーバ×1
• データベースサーバ×1

2. データベースサーバ

まずはデータベースサーバです。

データベースサーバを分けることにより、大量アクセスなどでCPU使用率やメモリ使用率があがった場合でも、MySQLやmemcachedに処理影響を与えにくい構成がとれるようになります。

MySQLはソケット通信からポート通信に

これまではサーバ内のDBを見ていましたが、今回から別のサーバのDBを見ることになるので、ソケット通信からポート通信に変わります。
セキュリティを考慮して、標準ポートの変更、サーバのポート開放、ユーザアクセス権限をおこなっておきます。

ユーザアクセス権限については、ホスト単位でのアクセス制限などをおこないます。

具体的なSQL例などは以下のサイトにお世話になってます。

MySQL講座 [Smart]

よくはまるのでTIPSとして。
権限変更時は反映のためのFLUSH文の実行を忘れずに。これが原因で権限反映できてないことに気づくと悲しくなります。

FLUSH PRIVILEGES;

アプリケーション側については、設定を切り替えるだけでよく、cakePHPであればapp/config/database.phpを編集して、ソケットファイルしてからポート番号指定に切り替えればOKです。

memcachedはそのまま利用

memcachedは、ローカルホストの接続でもポートを使用して通信していますので利用方法は基本的には変わらずです。
MySQL同様、セキュリティを考慮し、標準ポートの変更、サーバのポート開放をおこないます。

3. バッチサーバ

次はバッチサーバです。

バッチサーバを分けることにより、集計処理やメルマガ送信時のバッチ処理などによりCPU使用率やメモリ使用率があがった場合でも、ユーザレスポンスに影響が及ばなくなります。
今回はバッチサーバを1台としていますが、将来的な複数台化や処理時間が増加した際に同サーバ内での並列実行ができるように、それぞれのバッチを分割実行できる形にしておけると楽だと思います。

バッチ処理をグループ化して実行しやすく

KAUPONでは、例えばこんな感じでバッチ処理を引数でグループ化して、分割実行ができる形にしています。

/hogehoge/shell_exec.sh daily_magazine 1
/hogehoge/shell_exec.sh daily_magazine 2
/hogehoge/shell_exec.sh daily_magazine 3
/hogehoge/shell_exec.sh daily_magazine 4
/hogehoge/shell_exec.sh daily_magazine 5

グループ化にはIDをグループ数で割った余りをよく使います。

ユーザIDならユーザID%5+1とかすれば、日々IDが増えても均等に1～5のグループをつくることができます。

 

今回はこのあたりで。次回は増設の肝となるウェブサーバを整理します。

引き続き採用強化中です！

日々試行錯誤しながら、KAUPON開発メンバーは頑張ってます！
KAUPONのインフラをもっとイケてる仕組みに変えたいという方、アプリ開発をがっつりやりたいという方、どちらの興味も歓迎ですので気になった方は以下もチェックしてみてください。

また、デザイナーについても募集中ですのでご興味ある方はぜひ！
ソーシャルコマースサイト「KAUPON」のWebデザイナー

Tags: インフラ, サーバ