More than 5 years have passed since last update.

ELBでスパイクアクセスと戦う

Posted at 2014-06-06

多量のアクセスがあってリクエスト数がスパイクした場合、ELBのスケールして対応する。
しかし、あまりに急激でスケールが間に合わない場合はスケールするまで503を返すようになる。
スパイクアクセス時に503を返したくないといった場合の対応方法をまとめてみた。
間違いがあったり他にいい方法があったらツッコミ希望デス。

ELBを(なるべく)利用しない

いきなりELBで勝負しない方法。
なるべくELB以外でアクセスを受けてELBにアクセスがこない、もしくは少なくするとサービスとしてのスパイクがあってもELBへの影響は少なくできる。
以下のようなS3との連携方法などでELBへのアクセスを減らす。

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構成)。
運用面で管理するものが増えたりするデメリットがありそう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up