Clone Serverパターン
サーバーのクローン
目次[非表示] |
解決したい課題
スケールアウト構成は一般的な手法であるが、スモールスタートしたシステムでは、そもそも複数サーバーでサービス提供できる構成になっていないことが多い。 そのような場合、負荷対策が必要となった場合に、時間がかかってしまう。
クラウドでの解決/パターンの説明
このパターンは、負荷分散が考慮されていないシステムを、容易に負荷分散可能なシステムにする。 既に存在するサーバーをマスターとし、追加するサーバーのマシンイメージを用意する。 そのマシンイメージには、コンテンツ同期やデータベース接続の調整を行っておく。 そうしておけば、マシンイメージを起動するだけでスケールアウトによる負荷分散が実現可能となる。
実装
ロードバランサーサービスの「ELB」とマシンイメージの「AMI」を利用する。 負荷分散できるようにコンテンツ同期などを調整したクローン用AMIを作成し、負荷が重くなればクローン用AMIからEC2インスタンスを起動する。 それをELBの負荷分散対象にすれば、既存システムの変更をほぼ行わずにスケールアウトできる。 （手順）
- （EC2が一つの構成の場合）ELBを立ち上げて、EC2をその配下に置く。
- 現在稼働しているEC2からクローン用EC2を作成する。
- クローン用EC2は下記の方法などで必要に応じてマスターEC2とファイルの同期を行う。
- 定期的にrsyncなどを用いて同期
- 起動時にrsyncなどで同期し、適宜Capistranoなどで、アプリ・コンテンツを配信
- 負荷に伴い（または高負荷が予測されたとき）、必要な数のクローン用EC2を稼働させ、ELBに追加する。
構造
利点
- 現状のシステムを変更することなく、容易にスケールアウトによる負荷分散を行うことができる。
注意点
- マスターEC2がSPOFになってしまう。
- マスターEC2でデータベースが動作している場合、クローン用EC2ではデータベースを動作させず、データベース接続先をマスターEC2にする。
- ファイルのアップロードや書き込みがある場合は、その処理をマスターEC2で行う（Apacheのmod_proxyを用いて、該当URLのみクローン用仮想サーバーからマスター仮想サーバーにプロキシーさせるなど)。
その他
- NFS Sharingパターン、NFS Replicaパターンを参照。
関連ブログ