CDP:NFS Replicaパターン

From AWS-CloudDesignPattern
Revision as of 15:20, 15 April 2012 by KenTamagawa (Talk | contribs)
Jump to: navigation, search

共有コンテンツの複製

Contents

解決したい課題

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

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

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

実装

各EC2インスタンスの仮想ディスクであるEBSにNFSの内容をコピーしておくことで、全EC2インスタンスから共有して使用させるNFSよりも高いパフォーマンスで利用することができる。さらに、エフェメラルディスクもしくはインスタンスストレージと呼ばれるEC2のローカルディスクを利用すると、EBSよりも高速なアクセスが可能となる。

  • 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レイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。

その他

寄贈したアーキテクト

Ninja of Three

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox