こんにちわ、スタートアップで働くサーバーサイドエンジニアです。
メインはサーバーサイドですが、スタートアップなのでインフラやフロントについても担当させて頂く機会が多いです。
そこで今回はTV放送に耐えられるように行った負荷対策とその結果について書いていこうと思います。
AWSなどのクラウドサービスを使えば、インフラ専門の方でなくても随分な対策ができてしまいます。
ぜひサーバーサイドメインでインフラわからないよって方の参考になればと思います！
①アクセス数の予測
放送される番組の視聴率や放送範囲からアクセス数を予測しました。
(視聴がわからない場合は番組担当者の方に直接聞いたり週間高世帯視聴率番組10 - ビデオリサーチ、テレビ視聴率ランキング | インターネットTVガイドが参考になりました)
計算内容はこちら(参考: カウル Tech Blog)
# 総アクセス数を求める公式
総アクセス数 = テレビ局のリーチ人数 × 視聴率 × Web検索する人の割合 (=総アクセス人数) × 一人あたりの平均閲覧ページ数
総アクセス数 = 4,000万(テレビ局のリーチ人数) × 5%(視聴率) × 1%(Web検索する人の割合) × 2(一人あたりの平均閲覧ページ数) = 4万アクセス
出演時間のQPS = 4万アクセス ÷ 60秒 = 平均 666 QPS
* OPS(平均リクエスト数)
666 OPS(平均リクエスト数)と予想されます！
(↓のAuto ScalingでこのOPSをもとにインスタンス数を決定しています)
②行った負荷対策
1. コンテンツのキャッシュ
TOPページのコンテンツについてキャッシュしました。キャッシュの方法は
①TOPページにはアクションキャッシュを適用(rails)しました。
→TOPページは最も瞬間アクセスが多いところだと思います。画像などの静的コンテンツだけでなく動的コンテンツもあったので適用させたのは非ログインユーザーのみにしました。
②CDN(Cloudfront)を、使い方、会社概要ページについて適用
→こちらの2つについてもアクセス数が多く、CDNによるキャッシュをしました。
2. Auto Scaling(インスタンス数の最適化)
普段はEC2、RDS、ALB、R53で運用しています。EC2は以下のようにスケールアウトしました。
| 変更前 | 変更後 |
|---|---|
| t2.medium×2~5(通常2台稼働) | t2.medium×5~10(通常5台稼働) |
こちらの5台稼動したのは
EC2とRDSで動く Rails x MySQL の構成で、1vCPUあたり100[QPS]程度のリクエストを捌くことが可能
の内容を参考に
t2.medium = 2vCPU×5 = 1000 OPS > 666 OPS(予測)
という見立てに基づいています！
③結果
約180req/sec(google analyticsで測定)でした(笑)。サーバーも重くなることも、もちろん落ちることもありませんでした。
1000req/secの想定で予想の半分も行かない結果とはなりましたが、アクセス予測→予測をもとに負荷対策の実施を一通り経験できたのでインフラに対する知識は少しは深まったかと思います。今後サービスが大きくなるにつれて、DBの対策の方もしていかなくてはと思います。(それはまた後ほど)
またかなりさらっと触れてしまいましたが、会社概要や使い方ページは熱量の高い初回訪問ユーザーが訪れるページでもあるので、しっかりと登録の導線を設置しておきましょう！(会社概要ページは難しいかも)
前回はスタートアップで働いていることを活かした記事も書きました！もし実際こういうのどうなの? なんてことあればぜひお聞きください!
スタートアップで働いて得られた開発tips