転送量とかトラフィックを忘れないように
転送量とかトラフィックを忘れないように:
大量のアクセスが想定されるようなWEBサービスのインフラ環境を設計する場合、全体のトラフィック、サーバの必要台数などをある程度予測して設計する必要があります。
(マシンスペックの試算に関しては実際の構成・システムを動かしたうえでベンチマークを取る事が最善の方法。)
予測しなければならない事が多い時とかに今まで頭の中でしてたことをちょっとまとめてみます。
注)あくまで考え方の参考として捉えてください。
まず、試算する為には、以下の情報を上の式に必要な数値を準備する必要がある。
瞬間最大のトラフィックが 2.3(Gbps)以上であると想定できる。
インフラ環境を準備するうえで最初に考慮しなければならないのは、ネットワークの制限。
その時には実際にかかるコストの試算が重要となる。
あくまで参考にという事でずらずらと書きましたが、実測値とほぼ合致したケースでもあります。
サーバレスアーキテクチャの時代が来る(もう来てる)と思う。
昨日書いてくれたWEBサーバの代わりに AWS Amplify Console を利用できるか検証してみたも デフォルトでCDNで公開されている。
いわゆるPaaS/FaaSサービスを利用していればネットワークの制約とかは意識する事自体が必要なくなりそうな気がする。
それでも転送量というのは一番変動しやすくて予測しにくい上にコストもかかる。
あえてそんなタイミングだからこそ、書いておこうかなと思いました。
1$=112円換算
どちらも東京リージョン
つい最近(2018/09)AWSの転送量の大幅価格改定(日本向け最大34%の値下げ率)が入ったタイミング
ただし、Google はムーアの法則に則った価格改定を今後も続けると宣言しているようなのでまた追いつくかなと
これまでの例をとった場合に、まずここで必要なのは秒間の最大アクセス数
アクセス数が最大1時間で1,000,000PVの秒間最大アクセス数は
1,000,000(PV)/3600(秒) ≒ 278(PV/秒)以上となる。
ここで、実際に1時間で平均して集中するよりは集中する時は最初の10分間に9割程集中する場合が多い。
1,000,000(PV)/600(秒) ≒ 1667(PV/秒)
あとはWEBサーバの性能により、予測していく
例えばApache(preforkの場合)の場合、
MaxClients:256
Apacheの1プロセスで処理できるアクセス数は1であり、
16667/256 ≒ 6.5 となり、単純計算で必要なWEBサーバの台数は7台以上は必要となる。
静的ページ1枚のみ以外では1秒間ですべてのアクセスを処理出来る事はほとんどない。
システムが絡むとサーバの負荷が増大する可能性がある事。
マシンスペックが大きければチューニングも可能。
を前提にすこし台数パターンを試算する。
FORK Advent Calendar 2018
6日目 WEBサーバの代わりに AWS Amplify Console を利用できるか検証してみた @momoken
大量のアクセスが想定されるようなWEBサービスのインフラ環境を設計する場合、全体のトラフィック、サーバの必要台数などをある程度予測して設計する必要があります。
(マシンスペックの試算に関しては実際の構成・システムを動かしたうえでベンチマークを取る事が最善の方法。)
予測しなければならない事が多い時とかに今まで頭の中でしてたことをちょっとまとめてみます。
注)あくまで考え方の参考として捉えてください。
基本的な考え方の式
1リクエストあたりの平均リクエストサイズ+レスポンスサイズ(Bytes/リクエスト)× 瞬間最大のリクエスト数 (リクエスト/秒)= 瞬間最大の転送量数 (Bytes/秒)
用語
- リクエスト数とは
リクエスト数とは、サーバー上に設置されたHTMLファイルやCSSファイル、イメージファイルなど、
全てのファイルに対し、閲覧者がアクセスした数。
ヒット数と呼ばれる場合あります。 - アクセス数(ページ数)
アクセス数(PV数)とはページ数の事。
HTMLファイルへアクセスがあった際、そこに貼られている画像などの数にかかわらずアクセス数(ページ数)は1となる。
算出シミュレーション
必要な情報の準備
まず、試算する為には、以下の情報を上の式に必要な数値を準備する必要がある。-
1リクエストあたりの平均リクエストサイズ
一番アクセスされるであろうページの構成要素から算出する。
- 例えば 1ページが以下の構成要素から成り立っているとする。
50KBのHTMLファイル1枚、20KBのCSSファイル1枚、150KBの画像ファイル50枚、20KBのJSファイル30枚の画像ファイルで構成された場合
→ (50KB×1) + (20KB×1) + (150KB×50) + (20KB×30) / (1+1+50+30) ≒ 100(KB/リクエスト)
- 例えば 1ページが以下の構成要素から成り立っているとする。
- 1リクエストあたりのレスポンスサイズ(bytes)
ここは平均的なHTTPリクエスト文字列長として1KBと仮定(決め打ち)する。 -
瞬間最大のリクエスト数 (リクエスト/秒)
アクセス数が最大1時間で1,000,000PVを捌く事を前提にした場合
- 3600秒(1時間)で均等に割ると仮定する。
1,000,000(PV)×(1+1+50+30)/3600(秒)≒ 22,778(リクエスト/秒)
- 3600秒(1時間)で均等に割ると仮定する。
(100+1)(KBytes/リクエスト)× 22,778(リクエスト/秒)= 2,300,578(KBytes/秒)≒ 2.3(GBytes/秒)
ネットワークの性能
インフラ環境を準備するうえで最初に考慮しなければならないのは、ネットワークの制限。-
オンプレ環境の場合
- 回線速度は契約量以上のものは(すぐには)増やせない。
- 最大でも1Gbpsの回線が保証されていたら贅沢なくらい。
- それでもネットワーク機器1台の性能にしても製品のスループット600Mbpsくらいが平均といったところ。
-
クラウドサービスの場合
- AWS(EC2)
急激なアクセス増加に対してはELBのスケールアウトが間に合わずにサービス断に繋がる。その場合には事前の暖機申請を行う必要がある。 - GCP(ComputeEngine)
事前の暖機とか不要でこなせる模様。やはりGoogleネットワークは凄いと思う!
- AWS(EC2)
その時には実際にかかるコストの試算が重要となる。
最後に
あくまで参考にという事でずらずらと書きましたが、実測値とほぼ合致したケースでもあります。サーバレスアーキテクチャの時代が来る(もう来てる)と思う。
昨日書いてくれたWEBサーバの代わりに AWS Amplify Console を利用できるか検証してみたも デフォルトでCDNで公開されている。
いわゆるPaaS/FaaSサービスを利用していればネットワークの制約とかは意識する事自体が必要なくなりそうな気がする。
それでも転送量というのは一番変動しやすくて予測しにくい上にコストもかかる。
あえてそんなタイミングだからこそ、書いておこうかなと思いました。
- (参考)AWS/GCP転送量料金比較 (2018/12時点)
月間転送量 | AWS月間コスト | GCP月間コスト |
---|---|---|
1TB | 12,755円 | 15,680円 |
3TB | 32,691円 | 470,40円 |
5TB | 62,595円 | 784,00円 |
10TB | 112,435円 | 156,800円 |
どちらも東京リージョン
つい最近(2018/09)AWSの転送量の大幅価格改定(日本向け最大34%の値下げ率)が入ったタイミング
ただし、Google はムーアの法則に則った価格改定を今後も続けると宣言しているようなのでまた追いつくかなと
(おまけ)サーバの台数を試算する場合
これまでの例をとった場合に、まずここで必要なのは秒間の最大アクセス数アクセス数が最大1時間で1,000,000PVの秒間最大アクセス数は
1,000,000(PV)/3600(秒) ≒ 278(PV/秒)以上となる。
ここで、実際に1時間で平均して集中するよりは集中する時は最初の10分間に9割程集中する場合が多い。
1,000,000(PV)/600(秒) ≒ 1667(PV/秒)
あとはWEBサーバの性能により、予測していく
例えばApache(preforkの場合)の場合、
MaxClients:256
Apacheの1プロセスで処理できるアクセス数は1であり、
16667/256 ≒ 6.5 となり、単純計算で必要なWEBサーバの台数は7台以上は必要となる。
静的ページ1枚のみ以外では1秒間ですべてのアクセスを処理出来る事はほとんどない。
システムが絡むとサーバの負荷が増大する可能性がある事。
マシンスペックが大きければチューニングも可能。
を前提にすこし台数パターンを試算する。
FORK Advent Calendar 2018
6日目 WEBサーバの代わりに AWS Amplify Console を利用できるか検証してみた @momoken
コメント
コメントを投稿