インフラエンジニアの河井です。
今回は、イベント時の負荷見積りについて書いてみます。
負荷見積りとは
負荷見積りには大きく分けて「長期的な見積り」（長期間のサービス提供により増加した取扱データ量への対応）と、「短期的な見積り」（イベントやメディア露出による突発的なアクセス増への対応）がありますが、今回は後者について話をします。
取得すべき監視項目の決定
AWSで言えば、ELBの時間辺りリクエスト数や、EC2のCPU使用率などの中から、利用すべき項目を抜き出します。たとえば、ELBの時間辺りリクエスト数であれば、以下のようなコマンドを実行することで取得することができます。
$ LB_NAME="LBの名前"
$ aws cloudwatch get-metric-statistics \
> --namespace "AWS/ELB" \
> --dimension Name=LoadBalancerName,Value=${LB_NAME} \
> --metric-name RequestCount \
> --start-time $(date --date '2 days ago' +%FT00:00:00Z) \
> --end-time $(date --date '1 days ago' +%FT23:59:59Z) \
> --period 60 \
> --statistics Sum
必要最低限の項目の情報のみ取得する、という考え方もありますが、現時点では、取得できる項目はできるだけ取得しておく、ただし全てを見積りに使用するわけではない。という考えで見積りをおこなっています。使用しなかった項目は、見積りと結果にずれが生じた場合の資料として使用しています。
基準線の作成
各項目の情報を取得したあとは、必要な項目ごとに時系列に分け、傾向を取得します。以下に示すのは、複数日のLBへのリクエスト数の平均を取り、グラフにしたものです。日に数回、アクセスの高くなる場所があることがわかります。これを、見積りの基準として使用します。
過去の特異日との比較
次に示すのは、過去の特異日（青色のライン）と、基準線（橙色のライン）との比較です。Y軸の値が変わってしまったため、縦に押しつぶされてしまっていますが、右側から1/3ほどのところで、青線が跳ね上がっているのが判ると思います。このタイミングでイベント（プッシュ通知や新規クエストの開放、プレゼントの配布など）が発生しています。
他にも、web/APIサーバーや、RDB, NoSQL等における、CPU,メモリ、ディスク、NW負荷などを併せて確認し、高負荷時の各サーバーの挙動の変化を確認します。
イベント規模の聞き取りと負荷見積り
負荷に対する各サーバーの挙動がわかったところで、今度はプランナーチームから、今回のイベント規模について聞き取りをおこないます。
この時のコツは、「できるだけ楽観的な予測を出してもらうこと」です。楽観的な見積もりの結果、想定を遥かに下回る負荷で、サーバー費用が無駄にかかる、と言うのはそれはそれで問題なのですが、サービスを止めてしまうことに比べれば遥かにマシです。サービスを止めてしまうと、現在のユーザーのみでなく、将来のユーザーを得る機会も失うことになりかねませんので。
聞き取りの結果得られた情報から、イベントの想定負荷を見積ります。
システム増強メンテナンス
得られた想定負荷と、過去のイベント時の処理量などから、現在のシステム構成で耐えきれるかを計算し、耐えきれないと判断した場合はシステム増強メンテナンスを実施します。これは、場合によっては数十分〜数時間のサービス停止を伴うことがあります。サービス停止が発生する場合は、関係するチームに連絡し、メンテナンス日時の調整やお知らせの発行、メンテナンス後のお知らせなどについて相談します。
メンテナンスが完了すると、もうあとは当日を待つのみです。
いかがでしたでしょうか？ 実際には、このような見積りをしていても、当日は不安に押しつぶされそうになりながらイベント開始を待っていたりするのですが、それはまた別の話。
ということで、今回は、こんな風に負荷見積りを行っている、という雰囲気を感じていただければ幸いです。