多量のアクセスがあってリクエスト数がスパイクした場合、ELBのスケールして対応する。
しかし、あまりに急激でスケールが間に合わない場合はスケールするまで503を返すようになる。
スパイクアクセス時に503を返したくないといった場合の対応方法をまとめてみた。
間違いがあったり他にいい方法があったらツッコミ希望デス。
- 参照サイト
ELBを(なるべく)利用しない
いきなりELBで勝負しない方法。
なるべくELB以外でアクセスを受けてELBにアクセスがこない、もしくは少なくするとサービスとしてのスパイクがあってもELBへの影響は少なくできる。
以下のようなS3との連携方法などでELBへのアクセスを減らす。
- AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む） ｜ Developers.IO
- CDP:Direct Object Uploadパターン - AWS-CloudDesignPattern
- CDP:Web Storageパターン - AWS-CloudDesignPattern
ELBのPre-Warmingを利用する
AWSサポートにお願いしてELBをスケールしておいてもらう。
ビジネスもしくはエンタープライズサポートに加入していて、事前にスパイクが予想できることが条件。
ELBのPre-Warmingを手動で行う
サポートにお願いせず、自らELBにリクエストすることによって予想されるスパイクに対してELBをスケールさせる。
自らのリクエストによるスケーリング中に予想されないスパイクが発生すると危険そう。
ELBで利用するAZを増やす
ELBで利用するAZを増やすとELBのインスタンスが各AZに配置されてラウンドロビンされるのでアクセスが分散されるはず。
利用するAZが1つより2つ、2つより3つの方がELBインスタンスが増えてスパイクに強くなるはず。
DNSラウンドロビンを利用してELBを複数紐付ける
Route53などでDNSラウンドロビン機能を利用して複数ELBを紐付ければアクセスは分散されるはず(各ELBの背後は同じEC2構成)。
運用面で管理するものが増えたりするデメリットがありそう。
