[クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す！〜]

2017年3月27日(月)清野 剛史（クラスメソッドAWS事業部ソリューションアーキテクト）

リスト

スパイク対応はある程度予測可能、事前に対策を

　AutoScalingを使用する上で注意する点がある。「急激にアクセスが集中する“スパイク”への完璧な対応は難しい」ということだ。ニュースサイトへの記事の掲載や、TVのCM、LINEへの情報配信、SNSへの拡散などで起こるスパイクでは、数十秒から数分でトラフィックが数倍、数十倍に膨れ上がる。これに対し、EC2が立ち上げるまでには、汎用的な「m3」系で3〜5分、バースト対応した「t2」系でも2〜3分はかかる。最初のスパイクに間に合わないことが充分に考えられる。

　ただ、スパイクの発生は事前に予測できる場合が多い。TVのCMや番組での紹介は放送時間が決まっているし、LINEやニュースサイトへの配信であれば、リリースやアップデートなどの公式発表直後から数時間の間である場合がほとんどだ。安全を期し、そうした時間帯に合わせてEC2の台数を事前に増やすよう、プロビジョニングサービスの「CloudFormation」で「ScheduledAction」を設定したり、イベントドリブンなアプリケーションの開発・実行環境である「Lambda」をスケジュールで走らせたりしておけば、スパイクに対応できる。

　筆者の経験からは、予測するアクセス数の5倍程度のリクエストに耐えられるように台数を増やしておけば、まず問題は起こらない。さらにスパイクの場合、およそ5〜24時間くらいの猶予を持って縮退に入るように設定しておくと良いだろう。

ロードバランサーは暖機運転の必要性を見極める

　AutoScalingのように複数の可変サーバーをバックグラウンドに持つシステムの場合、アーキテクチャーとしては、クライアントがアクセスするフロント部にはロードバランサーを配置し、リクエストが適切に分散されるよう設計する。AWSでは、「ELB（Classic Load Balancer）」もしくは「ALB（Application Load Balancer）」が、その役割を果たす。オンプレミスのロードバランサーと異なり、ロードバランサー自身が負荷によってスケールするのが特徴だ。つまり、AutoScaling同様、一般的な負荷増大に対しては運用側で何か対策を施す必要はない。