2013年1月17日
覚え書き:Amazon Web Services(アマゾンウェブサービス)でAuto Scaling環境のCMSを構築する
Zen CartやMovable Type、WordPressなどCMSでサイト構築をする際に、Amazon Web Services(アマゾンウェブサービス:以降AWS)を利用するケースが増えてきました。
AWSのようなクラウド環境を利用するメリットの一つとして、コストをあまりかけずにスケールアウトできる点があげられると思います。
クラウドを利用するメリットの1つ『スケールアウト』
スケールアウトとは、有名ニュースサイトに記事が載った際など大量のアクセスがあった時に自動的に新しいEC2インスタンスを作って、負荷分散ができるようにする仕組みです。
逆に、アクセスが落ち着いてきて自動的に作ったEC2インスタンスを削除するのがスケールインです。
このように自動的にインスタンスを制御することを「Auto Scaling」といいます。
どの時点を「大量のアクセス」と判断してスケールアウトするか...というルールはAWS上のCloudWatchを利用して設定します。
また、スケールアウト中は 2つ(以上)のインスタンスにユーザーからのアクセスを割り振る必要がありますが、このロードバランサーの役割はAWS上の管理画面でELB(Elastic Load Balancing)の設定しておけば勝手にやってくれます。
- ELBはスケールアウトのルールにもとづいて高負荷状態になったら、EC2(B)を作る
自動的にELBがユーザーのアクセスを割り振ってくれる - 各EC2インスタンスが処理してレスポンスを返す
DBサーバーに対するデータ操作は、DBサーバーが一元管理されているのでデータ不整合にはならない - 逆に、ELBがスケールインのルールにもとづいて通常となったら、EC2(B)は消される
通常時に戻る
Auto Scalingのルール
スケールアウト/スケールインするためには、どの時点を「高負荷状態」なのかを判断するルールをCloudWatch上で設定します。
Elastic Load Balancer: 10種の事前選択されたメトリックス(1分間隔)。無料。
を利用するので費用は掛かりません。
ルールは規模によると思いますが、例えば下記のように設定します。
- ELBからの出力の60秒平均が5秒を超えると2台ずつスケールアウト(300秒毎)
- ELBからの出力の60秒平均が2秒を下回ると1台ずつスケールイン(300秒毎)
ただし、ひとつ注意が必要なのは、スケールアウトが必要になってから実際に使えるようになるまでタイムラグがあります(5分など) 。よって、多少余裕をみたルール設定が必要になります。
Auto Scaling 時のCMS利用における注意点
さて、Auto Scaling でサーバーの台数が増減するような環境では、http://www.example.jp/ へのアクセスが複数台のサーバーで処理される場合が出てきます。
すると、以下のような問題が起きることがあります。
管理者がCMSにログインし、コンテンツを news/hoge.html という静的ファイルとして保存しようとしたらエラーになった!
エラーになった原因は、管理者さんの作業中にスケールアウトして、ファイル保存前にスケールインが起きたため、というわけです。CMSのバグ? と推測してしまった場合は原因究明でえらいことになりそうですね。
上記の解決方法としては、CMSへのアクセスは常にメインとなるEC2(A)にアクセスするように設定すれば、Auto Scaling による影響は出なくなります。
具体的には、以下のようなDNS設定をします。
- example.jp は www.example.jp に転送する
- cms.example.jp (管理者用)は メインサーバーのElasticIPを割り振る
- www.example.jp (ユーザー用)は CNAMEでELBに割り振る
また、Auto Scaling の設定は下記のようにしておきます。
- メインサーバーとDBサーバーはそれぞれにオートスケーリンググループを設定して min=1, max=1 にセットする
- スケールアウト/スケールインするサーバーはメインサーバーとは別のオートスケーリンググループを用意して min=0, max=X にセットする ※max=X は何台まで増やすかによる
この場合の費用(概算)
このように、Auto Scaling の設定をしておけば、サーバーダウンを避ける仕組みが構築できます。
では、このサーバー構成のための費用はだいたいどれくらいでしょうか。AWSではアクセスによる転送量や、サーバーに配置するコンテンツ容量など、環境によって金額が異なる従量課金制ですので、費用計算は難しいのですが、概算を出してみます。
想定: EC2 (東京リージョンを想定) L Web用にミディアム L DB 用にスモール Elastic IP (設定済みで費用なし) CloudWatch (Auto Scalingをするのに必要だけど無料の範囲内で利用) Auto Scaling L スケールアウトで起動するインスタンスは 毎日2時間ほど3インスタンスがコンスタントにあがる想定 その他 (EBS, S3) 転送量などは適当に10GB/月
これで、一ヵ月$250?$300 程度でしょうか。ただし、上記の計算はバックアップ体制などは除外しているので、あくまで概算だと思ってください。
タグ:
« 前の記事:新年あけましておめでとうございます(2013年最初のご挨拶)
» 次の記事:事例:現代ギター様ECサイトにスマートフォン版サイトを追加しました
アークウェブの本
Zen Cartによるオンラインショップ構築・運用テクニック―オープンソース徹底活用
内容充実のZen Cart公式本(v1.3対応)がついに発表です。アークウェブのスタッフをはじめZen-Cart.JPの中心メンバーが共著で執筆しました。続きを読む
新着はてブ
カテゴリー
- Shopify(ショピファイ)オンラインショップ構築
- NGO・NPO向け情報
- スマートフォン
- だれもが使えるウェブコンクール
- mixiアプリ
- OpenSocial (システム開発)
- アークウェブのCSR
- A-Form, A-Member, A-Reserve(MTプラグイン)
- Ruby on Rails(システム開発)
- necoったー
- Miqqle
- WebSig24/7
- ecoったー
- ビッグイシュー(The Big Issue)
- CSR(企業の社会的責任)
- マッシュアップ
- RIA (システム開発)
- セキュリティ(システム開発)
- 唐松(アクセス解析)
- Ajax (システム開発)
- テスト(システム開発)
- データベース
- PukiWiki
- Web 2.0
- SEO・サーチエンジン最適化
- XP・アジャイル(システム開発)
- Web・ITニュースクリップ
- Webアクセシビリティ
- Webデザイン
- SEM・サーチエンジン広告
- Webユーザビリティ
- CMS・MovableType
- Zen Cart(オンラインショップ構築)
- Snippy(SNS・ソーシャルブックマーク)
- アークウェブ
- オープンソース
- CMS(コンテンツマネジメント・システム)
- Webマーケティング
- AMP
- SNS