***本記事にはプロモーションが含まれています。***
Amazon Web Services(AWS)でWebサービスを提供しようとしたとき、ロードバランサはどういう場合に使えばよいのでしょうか。
ネットワーク構成などとAWSの報告例を参考にその料金を検討してみました。
複数のサーバーでネットワークを構成するときの基礎
こちらにユーザー数が1から1100万以上になったときに何が必要になるのかが紹介されています。AWSのre:Invent 2015での講演を簡単にまとめたものです。
Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド
講演のビデオのリンクもあるので、詳細はそちらをご覧ください。英語ですけど。
簡単にまとめると、ユーザー数が10までは、1インスタンスでいいです。10を超えたら、DBサーバーを分けましょう。100を超えたらAmazon RDSを使いましょう。1000を超えたらロードバランサをつかい、Webサーバーを複数にしましょう。
ユーザー数1－10：サーバー1個
ユーザー数10－100：Webサーバー＋DBサーバー
ユーザー数100-1000：Webサーバー＋DBサーバー（Amazon RDS）
ユーザー数1000－10000：ロードバランサ（Amazon ELB)＋Webサーバー複数＋DBサーバー（Amazon RDS）
このユーザー数が何を表すか疑問だったのですが、ユニークユーザー数と考えるといいようです。
ビデオを見た感じだと、アクセスが1つのインスタンスでさばけなくなった時がロードバランサの導入時ということだと思います。
評価する目安
限界となるアクセス数を考えた時に、原因は、CPUの性能、メモリ容量、ディスクのアクセス速度、ネットワークの速度と4つくらいが考えられます。
評価する目安としては、同時アクセス数（同時接続数）、ページビュー数（PV数）、ユニークユーザー数（UU数）とかがある。ページビュー数というのが難しくて、1日の中でも変動します。そのため、単純に1秒当たりのページビュー数を3600倍して、24倍しても1日当たりのページビュー数にはなりません。
Apacheの接続が維持される時間が2秒の場合、
同時アクセス数 ＝ ページビュー数／1秒あたり X 接続時間（2秒）
という関係にあります。
サーバーの性能を考えた時、限界はまずメモリに現れるようです。メモリが限界になって同時アクセス数が限界になる。
アクセス数が多くなれば、ネットワークの転送料も気になってきます。
海外のクラウドサービスでは、ネットワークの使用料は従量課金です。
画像のないサイトだと、0.2MB／1ページくらいなので、10万ページビュー／1日だと、1日当たり20GB／日になります。1か月で600GB/月。
1か月の転送量 ＝ 0.2MB/1ページ ｘ 10万ページビュー／日 ｘ 30日
Amazon Web Servicesで$54ドルです。画像が多くなって1ページが2MB／1ページと10倍になれば、かかる料金も10倍になります。Contents Delivrty Network(CDN)を使うといいかもしれません。
実際の報告例
まず、簡単な見積もりの話から。
メモリの量で同時アクセス数が決まります、というお話。こちらでは、メモリ2GB、2コアのサーバーで、同時接続数100人が目安。
これは、1日の変動を考えて1日に100万ページビュー／日だそうです。
単純計算なので、実際にはもっと少ないと思います。
次に、実績を調べていきます。
VPSのメモリ2GBでどのぐらいのPVに耐えられるのか？
どこで測定したかわかりませんが、こちらで実験した結果では、メモリ2GB、CPU3コアのサーバーで、同時アクセス80人。
一日に5万ページビュー／日から10万ページビュー／日だそうです。
こちらは、ApacheとWordPressでの実績です。
さくらのVPS 1Gプランで真面目にWordpress運用は厳しい！？
さくらのVPSの、メモリ1GB、CPU2コアのサーバーで、3ページビュー／秒。
単純計算で、一日に10万ページビュー／日だそうです。
でも、さくらのVPSは負荷が続くと制限がかかるそうです。
接続時間が2秒とすると、同時アクセス数は６人ですね。メモリが少ないとはいえ、同時アクセス数は意外と少ないです。
メモリを増やすとどうなるかです。
GMOクラウドVPSで動かしてるWordPressのアダルトブログが日刊10万PVを突破
GMOクラウドVPSの、メモリ12GB、CPU仮想7コアのサーバーで、同時アクセス300人。
一日に10万ページビュー／日がさばけている。
これは、実績なのでもっといけそうですね。メモリが多いとその分同時アクセス数も多くなるということだと思います。
Amazon Web Servicesの場合
では、Amazon Web Servicesでインスタンスを借りた場合、限界となるアクセス数はどれくらいでしょうか。
AWSをやめて普通のレンタルサーバーにした理由
こちらの方は、AWSではt2.small + RDSという構成で、アクセスユーザー2万人／月、50万ページビュー／月、同時アクセス数は20人だったそうです。費用が$146だったそうです。t1.smallではさばけないとのこと。
100万ページビュー／月までなら、レンタルサーバーの方が安く上がるとのことです。
こちらの例では、EC2がt2.large、RDSがdb.m3.2xlargeで、同時アクセス数が50人から最大で300人だそうです。
これだと、データの転送量がどれくらいあるかわかりませんが、月に7万円以上かかりますね。これだと、上にあげたGMOクラウドVPSのようなVPSを借りた方が安くなりますね。
こちらはsiegeというプログラムで、t2.microとt2.smallを比較しています。t2.microで1000ページビュー／1時間、t2.smallで2000ページビュー／1時間だそうです。
同時アクセス数は1にも届かないのですね。
AWS(Amazon Web Services)の月額コストを抑えたいのでアドバイスいただきたいです
こちらは、EC2(t1.small)+RDS(db.t2.micro)で2万ページビュー／月を処理している。$400かかっているけど安くならないかという相談です。
契約を見直すことで安くなりそうとのことですが、こちらもレンタルサーバーの方がいいのではというアドバイスを受けています。
PV数とインスタンスタイプの目安
こちらは、AWSでAMIMOTOというnginx+WordPressのイメージを販売しているところですが、t2.smallでは、10万ページビュー/1か月だそうです。RDSを使わずに、１つのイメージだけで動かしています。
WordPressのみを考えていて、シングルインスタンスでいいのならAMIMOTOを使ってサイトを運営するのが一番安く上がると思います。2000万ページビュー／月までいけるのが驚きです。その時の値段は、こちらを見ると、$2.40/hrということですから、消費税もいれて17万円／月ほどです。もっとも、ネットワークの転送料がもっとかかると思われます。
その他にも、テレビのWBSで放送されたときにアクセス数が増得た時の対策 HerokuでWBS砲を打ち返した話 や、Yahoo!でリンクされたときの対策 Yahoo砲に耐えられるインフラの話 があります。
こういうのを見ると、クラウドでロードバランサを使った構成が有効だなと思います。
スタートアップのためのAWSピーク対策入門@JAWS-UG千葉
Webサービス向けスケーラブルな構成例 - 継続的な成長やメディア紹介時のアクセス集中に備える -
こちらでは、AWSの人が、ピーク対策にロードバランサ＋Webサーバー2台＋DBサーバーという構成をすすめています。
まとめます。
まず、数万ページビュー／月から数十万ページビュー／月といったアクセス数が少ないサイトは、レンタルサーバーやVPSを使った方が安くなります。
どうしてもAWSでという場合は、AMIMOTOを使った方が安くなります。
t2.mediumで同時アクセス数20人、t2.smallはその半分の性能ということから、t2.smallは同時アクセス数10人以下と思われます。AMIMOTOのnginxで10万ページビュー／月ということから、apacheの場合t2.smallの性能は10万ページビュー以下と思われます。
t2.microでアクセスをさばききれなくなったら、まずt2.smallにしてメモリを増やしたほうがいいです。
その後、スケールアップするか、それともロードバランサを使ってスケールアウトするか考えどころですね。次に検討してみます。
AWSでスケールアップした場合とEC2をスケールアウトした場合
AWSで、EC2をメモリを増やしてスケールアップした場合と、ロードバランサとEC2 2台でスケールアウトした場合の料金の違いを見てみました。
さきほどのt2.small + RDSという構成を再現してみます。
Amazon EC2
| タイプ： | Linux,t2.small |
| 月額： | $16.84 |
Amazon EBS
| ボリュームタイプ： | General Purpose SSD(gp2) |
| ストレージ： | 30GB |
| 月額： | $3.00 |
データ転送
| データ転送送信： | 1000GB/月 |
| 月額： | $89.91 |
Amazon RDS
| クラス： | db.t2.small |
| ストレージ： | 汎用(SSD) 5GB |
| リージョン内データ転送： | 1000GB/月 |
| 月額： | $35.47 |
| 合計： | $145.22 |
この構成から、転送量が2倍になって、メモリを2倍にしてt2.medium 1台 ＋ RDSにスケールアップしてみます。
Amazon EC2
| タイプ： | Linux,t2.medium |
| 月額： | $34.41 |
Amazon EBS
| ボリュームタイプ： | General Purpose SSD(gp2) |
| ストレージ： | 30GB |
| 月額： | $3.00 |
データ転送
| データ転送送信： | 2000GB/月 |
| 月額： | $179.91 |
Amazon RDS
| クラス： | db.t2.small |
| ストレージ： | 汎用(SSD) 5GB |
| リージョン内データ転送： | 2000GB/月 |
| 月額： | $33.03 |
| 合計： | $250.35 |
元の構成からロードバランサを増やし、t2.small 2台 ＋ RDSという構成にしてみます。
Amazon EC2
| タイプ： | Linux,t2.small |
| 台数： | 2 |
| 月額： | $33.68 |
Amazon EBS
| ボリュームタイプ： | General Purpose SSD(gp2) |
| ストレージ： | 30GB |
| 月額： | $3.00 |
ELB
| Elastic LBの数： | 1 |
| 全ELBによって処理されたデータ転送： | 2000GB/月 |
| 月額： | $34.30 |
データ転送
| データ転送送信： | 2000GB/月 |
| 月額： | $179.91 |
Amazon RDS
| クラス： | db.t2.small |
| ストレージ： | 汎用(SSD) 5GB |
| リージョン内データ転送： | 2000GB/月 |
| 月額： | $33.03 |
| 合計： | $283.92 |
ロードバランサにも転送量によって料金がかかるのですね。
ネットワークの転送料が大きな比重を占めます。サイトが画像や動画を含んでいるかによって費用が大きくかわります。
スケールアップした場合の$250に対して、スケールアウトした場合$284ということで、ロードバランサの分だけスケールアウトした場合が高くなります。
スケールアップとスケールアウトでどちらがいいかですが、スケールアウトしてEC2 2台の方がトラブルになったときの可用性があがります。その分をどう考えるかによります。差額$30なら、スケールアウトしたほうが、アクセス数が変動した時の対応が出来ていいように思います。
まとめると次のようになります。
EC2のt2.small 2台のインスタンスとt2.medium 1台を借りる費用は変わりません。
ロードバランサを借りると、t2.medium1台借りたくらいの費用がかかります。
その結果、ロードバランサを借りた方が1台分だけ費用がかかります。
データ転送料が2倍になることが大きくて、費用が2倍に膨らみました。
今回の場合は、転送量をいかに減らすかが大切なように思います。
まとめ
ロードバランサを借りるのは、ユーザー数が1000以上になって1台ではアクセスがさばききれなくなった時です。
アクセス数の限界は、メモリの量が大きく関係しています。t2.microの場合は、まずt2.smallにすることを考えた方がよいです。
WordPressのみを考えていて、シングルインスタンスでいいのなら、AMIMOTOを使った方が安くなります。
ロードバランサを借りると、1台分だけ余計に費用がかかります。トラブルになったときの可用性を考えると、ロードバランサを借りてスケールアウトしたほうがいいように思います。