WBS を迎撃しました

はじめに

2015/09/09 に WBS で社のサービスが紹介されたため、事前に行ったサーバー増強対策と当日の結果について記述したいと思います

2015/09/29 追記:
クラスメソッド様・AWS様と質問をやりとりしている中で、サイトの各種パラメータや設定について記述があったほうがよいと判断したため追記しました

過去のサーバー増強対策

初？のTV放映

• 私が社にコミットする以前なので詳細は不明
• 約2年前にTVで紹介され、サーバーがダウンした
• 事前に十分な準備が行えず、 m1.micro 2台構成のまま放映に突入してしまったらしい
• 明確な資料が残ってないが、聞いた話では 20,000 requests/min に達していたとのこと

私がコミットした直後の対応

• ワールドビジネスサテライト砲を乗り越える時にやったこと - 素数好きの元最高技術責任者のブログ などの WEB の記述や、過去に在籍していたインフラエンジニアの助言を参考に EC2 インスタンスを m3.xlarge 10台構成にしてTV放映に臨んだ
• AWS には少し慣れてたもののインフラの経験は無かったため、その後半年ほど同じやり方を踏襲していた

具体的な対策

他の記事で紹介されているものと変わらないと思います

• ELB 暖気申請
• 当日のサーバー増強
  • 平常時は EC2 インスタンスに m1.small 2台を使用している
• 放映時の各種メトリクス監視
  • 現在まで放映の途中でサーバーを追加するといったオペレーションは発生していない

直近の対策

クラスメソッド・メンバーズ に加入しており、いただいた助言等を参考にしてTV放映対策を改善しました

• アクセス数の見積もりが大きすぎた
  • アクセス数の単位を勘違いしていたため、アクセス予測の申請を大幅に修正し EC2 インスタンスも m3.xlarge 2台に減らした
    • requests/min と requests/sec の勘違い、、、
• 1 request あたりのレスポンスサイズを大きく見積もっていた
  • 255KB → 200KB
  • 該当ドメインで最大のレスポンスが 255KB だったため、とりあえず採用したままだった
• 放映日時がずれることがある
  • 予定より15分早く放映が始まったり、ニュースの割り込みで放映が2週間ずれたり
  • 余裕を持った想定や事前準備が大事

WBS 対策

直近のアクセス状況

WBS 放映以前の直近のTV放映では以下のようなアクセス数でした（数値は概算です）
但し、TOP ページの表示に約 90 requests が発行されているため、アクセス数が膨らむ結果となっています（改善したさある）

No.	放映圏	時間帯	アクセス数（requests/min）	アクティブユーザー数
1	全国ネット	平日昼間	11,000	350
2	ローカル	平日夕方	4,000	（観測忘れ）
3	ローカル	平日夕方	9,000	（観測忘れ）
4	全国ネット	平日夕方	1,500	70

アクセスが伸びなかった事例について

4 のケースでアクセス数が伸びませんでしたが、以下の理由かなと推測しています

• 会社名が出なかった
• 関連キーワードで検索した時の SEO が不十分なのでは？

実際に Google アナリティクスで検索キーワードを確認してみたところ、関連キーワードでの流入が目立っていました
討ち漏らしがないように改善したいですね

アクセスパターン

急激にアクセスが増加します

最初のグラフが平日昼間の放映、その他は平日夕方の放映なので、時間帯によってアクセス数の推移が変わるようです
アクセスが増加するのはおおよそ以下のタイミングみたいです

• 会社名・サービス名が紹介された直後
• CM 入りのタイミングで微増することもある

予測・結果

予測

• 直近のアクセス状況を考慮すると、 100 requests/sec → 6,000 requests/min でもいいかな
• でも、 WBS だもんな
• 予測を2倍にし、 200 requests/sec → 12,000 requests/min とした
• いくつか参考にする情報はあるが、まだまだふわっとした予測をしている
  • 全国放映 or エリア放映
  • 時間帯
  • 放映枠は何分か、会社名は出るか、番組の視聴率、etc.

サイトの各種パラメータ・設定について

ELB 暖気申請には幾つかのパラメータ・設定の申告が必要になりますが、これらは ELB のキャパシティを決定する上で必要になるようです
参考までに、以下にこの記事で対象としているサイトのパラメータ・設定を記述します

• 1リクエストあたりのリクエストサイズ+レスポンスサイズ ⇨ 200kb
  • 全リクエストの平均値、、、ですが、これはざっくりした値を申告している
  • 画像ファイルなど静的リソースも含んでいる
• HTTPS の利用有無と割合 ⇨ 1割以下の割合で HTTPS を利用
• keep-alive 設定 ⇨ 有効

サーバー構成

• ELB に m3.xlarge インスタンス2台を配備
  • 他のTV放映対策と同じ構成
  • むしろ普段の対策がオーバースペックではないかと気になっているので構成の変更を考えている

結果

2倍にした予測をさらに1.5倍弱上回る 17,000 requests/min のアクセスがありました
また、アクティブユーザー数は 550 を上回るぐらいでした
当日は以下のような状況もあり、おそらく状況もよかったのではないかなと思っています

• 台風接近 → 帰宅の機運、他局編成が変わった？
• 株価上昇のニュース → 経済への関心？

サイトアクセスが重くなるなどの問題は特に発生せず、 EC2 インスタンスの CPUUtilization も5%未満だったので、余裕でアクセスを捌くことができていたと思います。

今後改善したいこと

• ページ表示に必要なリクエスト数を減らしたい
  • トップページを表示するための該当ドメインへのリクエスト数が約90 requests 、他のドメインも含めた合計が約150 requests と多すぎる
• S3、CloudFront の利用
  • 静的コンテンツが多く、 S3 や CloudFront を利用することでトラフィック・コストなどいろいろ改善できるのでは

おわりに

インフラ周りに携わるのは昨年に現在の社にコミットしてから初めての体験でしたが、それでも基本的な手順でなんとかなる AWS の力は素晴らしいなと思いました。
まだまだ至らない点が多いと思うので、これから改善していけたらいいなと思います。