CDP:Cache Proxyパターン
(Difference between revisions)
KenTamagawa (Talk | contribs) (→注意点) |
|||
Line 27: | Line 27: | ||
== 注意点 == | == 注意点 == | ||
* SPOFを作らないようにするために、キャッシュサーバも冗長化する必要がある。 | * SPOFを作らないようにするために、キャッシュサーバも冗長化する必要がある。 | ||
− | * Web/ | + | * Web/AppサーバはELBに対して間接的に配置されるので、サーバ増減の際にAuto ScalingがELBに自動にEC2をアタッチする機能が利用できなくなってしまう。 |
== その他 == | == その他 == |
Revision as of 15:31, 15 April 2012
キャッシュの設置
Contents |
解決したい課題
負荷対策の容易な方法としてサーバを複数利用する方法があるが、そのぶん、利用料もサーバの数分かかってしまうので 予算が少ない場合は、サーバ数を増やさずに対策を行うことを考えなければならない。
クラウドでの解決/パターンの説明
Webシステムのパフォーマンスを上げる代表的な方法に、コンテンツをキャッシュ化する方法がある。 これは、静的なコンテンツなど、変化の(あまり)ないコンテンツをWeb/Appサーバの上流でキャッシュし、 キャッシュの期限が切れるまでは、配信パフォーマンスの高い上流のキャッシュサーバで、コンテンツの配信を行う方法である。 クラウドの場合は、仮想サーバを容易に構築することができるので、キャッシュサーバが導入されていないシステムに対しても容易に導入が可能である。
実装
AWSではEC2と呼ばれる仮想サーバを利用することができる。OSにはLinuxなどがりようできるので、 Varnishなどのよく使われているキャッシュサーバの構築も容易に可能である。
- Web/Appサーバの前に、Varnishなどのキャッシュサーバを配置する。
- キャッシュサーバでオリジンサーバやキャッシュ期限などの設定を行う。
構造
利点
- Web/Appに手を入れずに、キャッシュを用いたコンテンツ配信が可能となる。
- HTTPのヘッダやURL、Cookieなどでキャッシュ化の対象にしたり、逆にキャッシュしないようにしたりなど、柔軟に調整も可能。
注意点
- SPOFを作らないようにするために、キャッシュサーバも冗長化する必要がある。
- Web/AppサーバはELBに対して間接的に配置されるので、サーバ増減の際にAuto ScalingがELBに自動にEC2をアタッチする機能が利用できなくなってしまう。