
本記事は某有名アドカレみたいに書いてみたらどうなるのかを妄想した記事になります。
また、やや虹ヶ咲第二章のネタバレになります。
予兆はあった
後々ユーザーからヒアリングしたところ、「起動までやや時間がかかった」「画面遷移の途中で動作が遅くなった」ということから、この時すでにシステムに異変は生じていました。
トラフィック量は確かに多かったですが、アラートが発砲されていなかったこと、一時的なアクセス過多によるものと思い込んでいました。
あとから見返すとトラフィックが増加傾向にあり、すでに構築時のシステムの許容範囲をこえつつありました。
その日は突然に
あるユーザーが配信をし、その動画が人気になったところ、数日しないうちにアプリへのアクセスが不可能になった。ファイルオーバー等の機能もむなしく、サービスは終了となった
影響範囲
・ライブ配信者
関西圏、沖縄にいる女子高校生の配信希望者(数百人から数千人を想定)
・閲覧者
全国(女学生を中心とする一般ユーザー)
何がいけなかったのか
・ユーザーアクセス想定数が耐えられなかった
こちらが大まかな理由です。構築当初はこのぐらいの同時アクセスを見込んで配信用のサーバーを建てましたが、気づいた頃には同時アクセスを捌ききれないことになってました。
・(妄想1)スケールアウトする構成になってなかった
最大アクセス数を想定して構築したため、これ以上スケールアウトしての運用は厳しい状態にありました。(多分オンプレ構築だったらこうなってた)
・(妄想2)構築・運用費を削減するためにサーバーとDBを共通のものにしてしまった
ライブ配信用の書き込み処理とアーカイブ検索などの処理を一つに集中させた結果、耐えられなかったのだと思います。他にも共通で利用していた部分もあり、結果として1台あたりの負荷が高くなりすぎたものと思います。
と、妄想でアレコレ書いてみたけど
自分が担当者だったらこんな悠長にしてられないですし、最終的にサービス終了まで追い込んでるんですから胃がキリキリしそうな感じですよね。
あくまで耐えられなさそうな構成とか規模にしてる妄想なので、大手とか(それこそYouTubeとかニコニコ)なら案外いけてたかもと思っちゃいました。
じゃあこんな構成なら事故は防げた?
あんまり配信とかの構築みたことないんで、某ユーザーグループの資料とかハンズオンをみてたんですが、こういうのならいけたのでは?と書いてみます。
あ、初心者です、マサカリはやめて…
・そもそもサーバーとDBは処理を分ける
そもそもアーカイブデータをDBに放り込む、というのはありえないでしょうが、念の為。配信サーバーとアーカイブサーバーの処理を同一にするのではなく、URLとかで振り分けてしまえば負荷はぐっと減ると思います。
・アーカイブはとっととS3にいれる
ライブ配信されたデータを裏でS3に入れてしまえば配信サーバーは無事なら気がします。分ける以前の問題かなと。
・AWSなら Media Services使えば?
SO RE NA
それにしても虹ヶ咲学園はなぜ配信できたのか
すごいですよね。1日で配信しています。ドローンからのリアルタイム映像とかはさておいて、これらの配信サービスを自前で持ってたってことですよね。
SIFの頃につかってたものを流用してるってことはオンプレかクラウドか、何かしらの形で耐えられるものを持ってたんでしょうかね。
アーカイブは見れなさそうなのでリアルタイム配信のみみたいですが、授業とかで使うものに相乗りしてるのかな。
案外調べてて楽しかった
映画館で聖地の情報メモりながらこんな妄想をし続けてた自分はどうかと思いますが、案外楽しかったです。
参考
https://aws.amazon.com/jp/blogs/news/jpmne-fujitv-introduces-unified-content-management-system/