いきなりLiveシステム
突然ですが、会社の業務都合で、生中継システムの改造を任せられた。
まぁ……結構余裕のあるスケジュールだけど、何せ初めてだし、一人だし、いろいろと苦労しました。
愚痴はこの辺にして、さっそく本題に入ろうとするかー
AWS構成
とりあえず、二種類の構成を準備しました。流行りのAWSでいきましょうー
以上、ご観賞ありがとうございました。
……なんて、もちろん、冗談です。
ご覧の通り、会社各拠点で使われるキャリア閉域網とAWSとDirectConnectによってつながってて、インターネット向きの生放送では無かった。
何故かというと、けっこう個人情報とか色々出て来るので、あくまでも社内で限定にしたいという上からの要望でした。
全体像はこのくらいで、中身の話をしましょうー
ScaleOut
ここは、ちょっと複雑になりましたね。
まず、ScaleOutというのは、インスタンスを増やすこと。
CloudWatchが随時、LoadBalancerの状態を監視し、指定のしきい値(CPU使用率など)を越えたら、アクションがトリガーされ、AutoScalingにScaleOutを要求する。
AutoScalingが予め設定したAMIを元に新規EC2インスタンスを立ち上げるが、それが最新のversionでは限らないので、いったん「Pending」の状態に置き、LoadBalancingのターゲットグループにいれないようにする。
AutoScalingグループのEC2が新規Launchの状態であることをCloutWatchEventが捕獲し、予め設定済のSSMがトリガーされ、実行される。
これによって、Ansibleでの構成チェックが行われ、最新のSWバーションを担保される。最後に、チェック済みのEC2インスタンスをLoadBalancingのターゲットグループに入れてから、ユーザーからアクセス出来るようにする。
Scale可能というのはクラウドの神髄ですね。フルタイムで全リソースを使うことじゃなくて、必要な時必要な分だけ利用する。こうしたことで、費用対効果を最大限に引き上げることが可能になるわけですね。
各サービスの機能説明は個人にお任せします。(面倒だから…)
私はあくまで、アイデアだけご提供しますんで……
ScaleIn
ScaleInはインスタントを減らすことですね。基本は、前とほぼ一緒な工程ですね。が、インスタンスを削除すると、web serverのaccess logも消えるので、削除直前にaccess logをs3に逃がすことをお忘れなく。
参考URL
https://dev.classmethod.jp/cloud/aws/using-ansible-at-autoscaling-launching/
https://dev.classmethod.jp/cloud/aws/reinvent2017-awselemental-medialive-mediapackage-livestreaming/
Docker構成
AWS構成以外、Dockerを使った構成も用意しました。
アイデアだけ、ご提供します。細く説明するのは、勘弁してください。
ご覧のとおり、リバースプロキシ(docker-container)と3つのweb server+app serverのcontainerセット、および後ろのストリーミングサーバによって構成されたシステムです。
docker-compose利用し管理する。各コンテナは同じdockerネットワークに
BroadcasterでCanonのビデオカメラを使え、USBケーブルでPCと直結します。
PC側は所謂配信サーバの役割をやってもらい、OBSというソフトウェア経由して、ビデオカメラが撮ったものをRTMPモジュールインストール済みのNginxサーバに送信(RTMPストリーミング)
受け取ったRTMPストリーミングをhlsストリーミングに変換
Front-EndのNginxサーバがBack-Endのhlsストリーミングフォルダをマウントし、hlsプレーヤーを使って、表示させる。
ユーザーはリバースプロキシサーバにアクセスし、ロードバランシングされ、それぞれのNginxサーバにルートされて行く
各containerのアクセスログをfluentd(docker-container)が収集し、zabbix serverとElacticSearch Serviceに転送し、グラフとして描画される
ElacticSearch Serviceにて、ユニークなIPをカウントし、同時閲覧者数をアウトプット
GatlingとJMeter(HLSプラグイン利用)を使って負荷テストを実施Gatlingはけっこ簡単な設定で、テスト出来るツールですが、Scalaがわかる人はもっとチカラを発揮できそう…
JMeterの場合、シナリオを作るので、かなり実際のユーザーの振る舞いをシミレーションできそう。
bitbucketによってCI/CDを回す。
今回はとりあえず形だけ、実際には使っていませんー
この辺は、やっぱりbitbucketが社内ネットワークがわからなくて、lambda関数を踏み台にし、DirectConnect経由で社内ネットワークにたどり着くしかいないですね。