Navarro]2019.07の頭くらいにちょっと大きめの案件を担当しまして。そのときに予想以上の負荷が来たので振り返りつつ、なんとか当月中にブログに起こすぞっ。現在の日本国内におけるTVの設置世帯数はおよそ5300万世帯です。TVxWebのバックエンドサービスをやっていると戦闘力5300万のクライアント群との熱いバトルができます。実際にきた負荷ETLサービス投票/ユーザー管理サービス企画開始から4min程度でピーク他のサービス等合わせると90kprs程度21:50頃から告知、流入が開始21:53頃に連打企画連動楽曲が放送どうなんの上のグラフを見ていただければわかりますが、かなりの負荷が、いきなりすごい増加量で来ます。1minごとに10krpsずつ増えてく。検索キーワードが表示(告知)されるそれを観た視聴者さんが一斉にWebサイトになだれ込んでくるユーザーさんが地上波放送に合わせてアクションを行うこのような流れになります。地上波ですから、Webでの動画配信等のような大きな遅延はあまり起こりません。よって、遅延によるユーザーアクションのブレはほぼ皆無です。スケールどうすんのじゃあこの負荷がくるとして、サーバーを準備しなければなりません。HAROiDではPlatformとマイクロサービスを組み合わせて企画を実現しています。各マイクロサービスでは何度も負荷試験をしており、インスタンスサイズにおける限界性能、安全率を考慮した運用限界を把握しています。c5.xlargeでxxxxrpsくらい捌けるねー。HAROiDのシステムは基本的にボトルネックを持たないように設計されています。金で殴ればどんどんスケールする構成ですが、1つ1つのアプリケーションに関してはできる限りチューニングを行い、高いパフォーマンスを提供できるようにしています。先程も書いた通り数分、下手すると数秒で数万rpsの増加が発生しうるサービスなので、いくら優秀なAWSのAutoScalingを使っても間に合いません...。サーバー落ちてしまったり、極端なレスポンス速度の低下が起こってしまうとそのまま放送事故に直結します。HAROiDでは、そういったことを防ぐために事前にサーバー負荷の見積もりを行い、それに沿ってサーバーのスケールアップ/アウトを行います。ちなみにETLサービスだと、当日はc5.xlarge*10の構成でした。やって絶対にミスれないので、試算、見積もりはそこそこな時間をとって行います。番組内の告知頻度/強さユーザーアクションにおけるAPIシナリオ上記のような係数をもとに、全て最大値で見積もりを出していきます。6,625,000API約663万回APIが呼び出される計算になります。36,805rpsとなります。実際にはユーザーアクションに偏りがあったり、ブラウザの読み込み速度によってスタートがぶれたりもしますが、おおよそこのような形で計算しています。