最近、CDNと流量制御を一気に実装して高トラフィック要件からシステムを守る、という対応をしたので書く。
結論は以下。
- CDNやブラウザキャシュを活用し、可能な限り静的コンテンツはキャッシュさせてオリジンへの負荷を低減すべし
- 野次馬ユーザや予測できないイベントによるバーストトラフィックがあるため、流量制御の機構をいれるべし
- システムのボトルネックに合わせた重点監視ポイント、特に各PVにおけるトラフィック量の監視が流量制御運用には必要
CDNによる負荷削減
キャッシュできるものはできるだけエンドユーザに近い場所でキャッシュさせる
大原則として、キャッシュできるものはできるだけエンドユーザに近い場所でキャッシュさせる。
静的コンテンツのキャッシュはブラウザキャッシュかCDNが有用。
ブラウザキャッシュは同一コンテンツを何度もリクエストするような場合有効
ブラウザキャッシュはヘッダ追加で用意に実装可能なので、同じコンテンツを何度もリクエストするような場合は有用。
(ブラウザキャッシュの考え方は以下のGoogleの記事がとてもわかりやすい。)
developers.google.com
CDNは特にユーザアクセスのバーストに有用
CDNは初回ユーザアクセスでもCDNのエッジサーバから配信可能なので、特にユーザアクセスのバーストに有用。
もし、なにかのイベントで100倍級のバーストトラフィックが予想されるならCDNを追加したほうがよい。
静的コンテンツをすべてオリジンサーバから配信するようになっている場合、ユーザアクセスがバーストすると一気に帯域が枯渇する可能性が高い。
キャッシュ効果試算方法
キャッシュによる効果は、Chromeの開発者ツール等で各ページにおける静的コンテンツサイズを確認することで試算可能。
たとえば、仮1ページあたり1MBの削減ができる場合、1MB✕ピークスループット[PV/sec]がピーク時の帯域削減効果試算である。
流量制御
いくらキャッシュさせてオリジンサーバへのトラフィックを動的リクエストのみに減らしたとしても、バーストするときはバーストする。
流量制御を入れるておくと、バースト時にオリジンサーバを守ることができるし、実装によっては既存セッションユーザを守って新規ユーザを弾く、ということもできる。
Nginxが一般的だと思う
流量制御として一般的によくやるのはNginxによるRequest/secに基づくものだと思う。
Nginxを挟み込めばできるので、「過負荷で503が頻発、どうにもならん」という際にいったんNginx挟み込み、ユーザをSorryに飛ばすだけでも時間が稼げる。
ただ、自分はがっつり実装したことないので書かない、、、
CDNの流量制御（WaitingRoom）
Nginx以外の流量制御方法としてCDNの機能を活用する方法がある。
AkamaiだとVisitor Prioritization(以降VP)という機能で流量制御を実装可能である。
blogs.akamai.com
(FastlyでもWaitingRoomの実装はVCLにて可能)
developer.fastly.com
CDNの流量制御（WaitingRoom）は少し癖があるので理解が必要
CDNの流量制御（WaitingRoom）は少し癖があるので理解が必要。
簡単に説明すると、Akamai VPは各エッジサーバ上で、事前に設定した割合(以降、オリジン比率)に応じて以下のように対象のURLへのリクエストに対して流量制御をかける。
- 初回アクセス時にエッジサーバにて、オリジン比率に応じて許可もしくは不可のヘッダが渡される
- 許可の場合→WaitingRoom対象のURLにアクセスしても通常通り処理される
- 不可の場合→WaitingRoom対象のURLにアクセスするとWaitingRoom用のページが返される。10～60秒の一定期間経過後ヘッダが無効化されるので再度エッジサーバにて、許可/不可の判定。
注意しなければいけないのは、各エッジサーバにおける割合における制御しかかけれないため、母数トラフィックがバーストすれば制御される数もバーストしてしまう点。 そのため、Akamai VPによる流量制御を採用するにはリアルタイムな監視と流量制御運用が必要。
どういった項目を重点監視するのか
システムの各ポイントにどれくらいトランザクションが来ているか、その結果としてレスポンスタイムの遅延やボトルネックリソースの枯渇は起きていないか
上述のようにVPの流量制御は割合での制御となるため、システム全体のボトルネックを抑えた上で必要な項目を重点監視し、それに応じたリアルタイムな流量制御運用が必要。
基本的に重点監視対象として定義した項目は以下の通り。
システムの各ポイントにどれくらいトランザクションが来ているか、その結果としてレスポンスタイムの遅延やボトルネックリソースの枯渇は起きていないかがポイント。
これらの重点監視項目をベースにWaitingRoom発動とその比率の判断を行う。
発動の判断
システム全体のトランザクション量と外接にアクセスするページへのトランザクション量について、事前に把握している限界値に達しており、レスポンス遅延が発生し始めていれば発動するという判断。
戻しの判断
また、一度オリジン比率を下げたあとに戻していく場合は、WaitingRoomに入ってきているトランザクション量に応じて次の比率を決める必要がある。
具体的には「比率増加後の流入量≒（WaitingRoomに入ったTPS＋TopアクセスTPS）✕次のオリジン比率」となるはずなので、この計算結果がシステム限界値に達しないレベルで比率を戻していく。
ざっくり過ぎるが以下参考に図。
