CDP:Clone Serverパターン

(Difference between revisions)
Jump to: navigation, search
(その他)
Line 32: Line 32:
  
 
== その他 ==
 
== その他 ==
 +
* 関連パターンとして、NFS Sharing, NFS Replicaを参照すると良いだろう。
  
 
== 寄贈したアーキテクト ==
 
== 寄贈したアーキテクト ==
  
 
[[Ninja of Three]]
 
[[Ninja of Three]]

Revision as of 15:06, 15 April 2012

サーバのクローン

Contents

解決したい課題

トラフィックが高くなるにつれてスケールアウトを行い、複数サーバに負荷分散する手法は一般的となっている。 しかしスモールスタートしたシステムは、そもそも、複数サーバがでもサービスが提供できる構成になっていないものも多く、 そのような場合は、負荷対策に時間がかかってしまう。

クラウドでの解決/パターンの説明

本パターンは、負荷分散が考慮されていないシステムを、容易に負荷分散可能なシステムにするための方法である。 最初から存在するサーバをマスターサーバとし、そのマスターサーバをベースとし、コンテンツ同期やデータベース接続の調整も行った マシンイメージを用意する。そして、その起動するだけでコンテンツの同期などを行うマシンイメージを利用することで、 スケールアウトなどの負荷分散が容易に実現可能となる。

実装

AWSにはAMIと呼ばれるEC2のもとなるマシンイメージを作成することができる。 負荷分散用に(コンテンツの同期などを)調整したAMIを作成し、既存システムの変更を、ほぼ行わずスケールアウトできるようにする。

  • ELBを用いてで負荷分散を行えるシステム構成にしておく(EC2が1つの構成でも)。
  • 現在可動しているEC2からクローン用に調整したAMIを作成する。
  • クローン用のEC2は、マスタEC2から起動時(必要に応じて定期的)にrsync等を用いてコンテンツなどのファイルを同期するようにしておく。
  • 負荷に伴い、もしくは負荷が予測されたときに、必要な数、クローン用のEC2を稼働させ、ELBに追加する。

構造

6wNg0ISJczU5Pz1m-A8650.png

利点

  • 現状のシステムを変更することなく、容易にスケールアウトによる負荷分散を行うことができる。

注意点

  • マスターEC2がSPOFになってしまう。
  • データベースが、マスターEC2で稼動している場合は、クローン用のEC2のデータベースへの接続先をマスター用のEC2にしておく。
  • ファイルのアップロードや書き込みがある場合は、その処理をマスター用のEC2で行うようにする(Apacheのmod_proxyを用いて、該当URLのみクローン仮想サーバからマスター仮想サーバにプロキシーさせるなど)。

その他

  • 関連パターンとして、NFS Sharing, NFS Replicaを参照すると良いだろう。

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox