CDP:NFS Replicaパターン

(Difference between revisions)
Jump to: navigation, search
(実装)
(その他)
Line 31: Line 31:
  
 
== その他 ==
 
== その他 ==
 +
* ローカルディスクとしてEBSを用いる代わりに、インスタンスストレージ(エフェメラルディスク)と呼ばれるEC2のローカルディスクを利用すると、パフォーマンスを向上させコストを抑えることも可能である。
  
 
== 寄贈したアーキテクト ==
 
== 寄贈したアーキテクト ==
  
 
[[Ninja of Three]]
 
[[Ninja of Three]]

Revision as of 15:22, 15 April 2012

共有コンテンツの複製

Contents

解決したい課題

NFSで複数サーバ間の共有コンテンツを実現することは可能だが、共有するサーバ数が増えアクセス頻度が増えてくると、 NFS部分のパフォーマンスの劣化が無視できなくなってしまう。

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

このパターンは、NFS部分のパフォーマンスの劣化、特に読み込みの部分を改善するためのものである。 各サーバの仮想ディスクにNFSの内容をコピーしておくことで、各サーバは、仮想ディスクにアクセスすることで 共有コンテンツの内容をローカルアクセスで取得することが可能となる。 NFSを直接参照せずに、手元にあるディスクにNFSのレプリカを作ることで、共有コンテンツに対する読み込みのパフォーマンス向上が可能になる。

実装

各EC2インスタンスの仮想ディスクであるEBSにNFSの内容をコピーしておくことで、全EC2インスタンスから共有して使用させるNFSよりも高いパフォーマンスで利用することができる。

  • NFSサーバをEC2上に構築し、共有するファイルをNFS サーバに配置する。
  • Auto Scalingで起動するWebサーバは、起動時にまずNFS サーバをマウントし、さらにNFS サーバの内容をEBSにコピーする。
  • アプリケーションでは、EBSを参照先に設定しておく。

構造

6wNg0ISJczU5Pz1m-63945.png

利点

  • 共有コンテンツを更新する際に、NFSに置くだけで、今後の更新作業でそのコンテンツが使われることになる。
  • 各仮想サーバは、自身に紐づいたEBSにある共有コンテンツを参照するため、NFSのパフォーマンスが問題になりにくい。
  • 例えば、NFSが落ちたとしても、各EBSにコンテンツがあるので、SPOFにならない。

注意点

  • 共有コンテンツを更新する際に、NFSに置くだけでは各サーバに更新されないので、rsyncなどを用いて同期をさせる必要がある。
  • DBサーバーは、耐障害性、メンテナンスの観点からもWebサーバーとは分離して設置することが望ましい。しかし、DBレイヤのスケールアウトはWebレイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。

その他

  • ローカルディスクとしてEBSを用いる代わりに、インスタンスストレージ(エフェメラルディスク)と呼ばれるEC2のローカルディスクを利用すると、パフォーマンスを向上させコストを抑えることも可能である。

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox