生中継システムやろうぜ

いきなりLiveシステム

突然ですが、会社の業務都合で、生中継システムの改造を任せられた。
まぁ……結構余裕のあるスケジュールだけど、何せ初めてだし、一人だし、いろいろと苦労しました。
愚痴はこの辺にして、さっそく本題に入ろうとするかー

AWS構成

とりあえず、二種類の構成を準備しました。流行りのAWSでいきましょうー

AWS構成

以上、ご観賞ありがとうございました。

……なんて、もちろん、冗談です。
ご覧の通り、会社各拠点で使われるキャリア閉域網とAWSとDirectConnectによってつながってて、インターネット向きの生放送では無かった。
何故かというと、けっこう個人情報とか色々出て来るので、あくまでも社内で限定にしたいという上からの要望でした。
全体像はこのくらいで、中身の話をしましょうー

ScaleOut

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

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構成
ご覧のとおり、リバースプロキシ(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をカウントし、同時閲覧者数をアウトプット

    負荷test
    GatlingとJMeter(HLSプラグイン利用)を使って負荷テストを実施

  • Gatlingはけっこ簡単な設定で、テスト出来るツールですが、Scalaがわかる人はもっとチカラを発揮できそう…

  • JMeterの場合、シナリオを作るので、かなり実際のユーザーの振る舞いをシミレーションできそう。

    CI/CD
    bitbucketによってCI/CDを回す。
    今回はとりあえず形だけ、実際には使っていませんー
    この辺は、やっぱりbitbucketが社内ネットワークがわからなくて、lambda関数を踏み台にし、DirectConnect経由で社内ネットワークにたどり着くしかいないですね。