CDP:NFS Replicaパターン
(Difference between revisions)
KenTamagawa (Talk | contribs) (→注意点) |
KenTamagawa (Talk | contribs) (→実装) |
||
Line 13: | Line 13: | ||
== 実装 == | == 実装 == | ||
− | + | 各EC2インスタンスの仮想ディスクであるEBSに、NFSよりも高いパフォーマンスで利用することができる。 | |
− | + | さらに、エフェメラルディスクもしくはインスタンスストレージと呼ばれるEC2のローカルディスクを利用すると、EBSよりも高速なアクセスが可能となる。 | |
* NFSサーバをEC2上に構築し、共有するファイルをNFS サーバに配置する。 | * NFSサーバをEC2上に構築し、共有するファイルをNFS サーバに配置する。 | ||
− | * Auto Scalingで起動するWebサーバは、起動時にまずNFS サーバをマウントし、さらにNFS | + | * Auto Scalingで起動するWebサーバは、起動時にまずNFS サーバをマウントし、さらにNFS サーバの内容をEBS(もしくは、インスタンスストレージ)にコピーする。 |
* アプリケーションでは、EBSを参照先に設定しておく。 | * アプリケーションでは、EBSを参照先に設定しておく。 | ||
Revision as of 15:19, 15 April 2012
共有コンテンツの複製
Contents |
解決したい課題
NFSで複数サーバ間の共有コンテンツを実現することは可能だが、共有するサーバ数が増えアクセス頻度が増えてくると、 NFS部分のパフォーマンスの劣化が無視できなくなってしまう。
クラウドでの解決/パターンの説明
このパターンは、NFS部分のパフォーマンスの劣化、特に読み込みの部分を改善するためのものである。 各サーバの仮想ディスクにNFSの内容をコピーしておくことで、各サーバは、仮想ディスクにアクセスすることで 共有コンテンツの内容をローカルアクセスで取得することが可能となる。 NFSを直接参照せずに、手元にあるディスクにNFSのレプリカを作ることで、共有コンテンツに対する読み込みのパフォーマンス向上が可能になる。
実装
各EC2インスタンスの仮想ディスクであるEBSに、NFSよりも高いパフォーマンスで利用することができる。 さらに、エフェメラルディスクもしくはインスタンスストレージと呼ばれるEC2のローカルディスクを利用すると、EBSよりも高速なアクセスが可能となる。
- NFSサーバをEC2上に構築し、共有するファイルをNFS サーバに配置する。
- Auto Scalingで起動するWebサーバは、起動時にまずNFS サーバをマウントし、さらにNFS サーバの内容をEBS(もしくは、インスタンスストレージ)にコピーする。
- アプリケーションでは、EBSを参照先に設定しておく。
構造
利点
- 共有コンテンツを更新する際に、NFSに置くだけで、今後の更新作業でそのコンテンツが使われることになる。
- 各仮想サーバは、自身に紐づいたEBSにある共有コンテンツを参照するため、NFSのパフォーマンスが問題になりにくい。
- 例えば、NFSが落ちたとしても、各EBSにコンテンツがあるので、SPOFにならない。
注意点
- 共有コンテンツを更新する際に、NFSに置くだけでは各サーバに更新されないので、rsyncなどを用いて同期をさせる必要がある。
- DBサーバーは、耐障害性、メンテナンスの観点からもWebサーバーとは分離して設置することが望ましい。しかし、DBレイヤのスケールアウトはWebレイヤと比べて一般的に難しい。リレーショナルデータベースのパターンを参照すると良いだろう。