皆さんこんにちは！@kurimoni367です！
前の記事 高校でのAWS開発・運用日記~文化祭＆NYGstreaming編~ と 高校でのAWS開発・運用日記~体育祭編 に続き自分の高校でのAWSの活用事例です！
是非読んでいってください！
目次
1.経緯
2.環境構築
3.運用
4.クラウド編集の利点と運用レポ
5.まとめ
1.経緯
そもそも、普通の高校で少なくともクラウド編集をすることにはならないと思うのですが、それにはとある背景があります。
前の記事にもある通り、技術統括局では多数の業務を行っています。
技術統括局とは
そもそもなぜ私が学校でサービスの導入を行えたのかというと、技術統括局という組織を学校の中で作りそこで局長として活動していたからです。前身組織であった生徒会電算部をパワーアップさせ、技術的アプローチによって学校行事や日々の学校生活までの運営をになう組織です。いわゆる技術屋といったところでしょうか。主に撮影・編集・音響・無線・3DCG・配信の6セクションに分かれて活動していました。そして、この編集・配信セクションこそが開発部始動のきっかけになりました。
＜＜＜高校でのAWS開発・運用日記~文化祭＆NYGstreaming編~より
その中で大きな業務の一つとなっている動画編集ですが、前身の生徒会電算部の頃から行っていたので作業の規模も大きくなりその分だけ問題点も出てきました。
一つ目はやはり、操作するパソコンの性能問題です。動画編集にはある程度のスペックのパソコンが必要であり、それなりのパソコンを持っていなければ編集作業ができません。
二つ目は、プロジェクトの共有化です。複数人が同じ動画編集に係わっている場合、メインで編集する人以外が編集する場合、パソコンを変えるか、プロジェクトファイルの書き出しが必要でした。
そこでワークフローの改善が課題となっていた時にmedia-JAWSでクラウド編集について知り、実践してみることにしました。
クラウド編集前に挑戦した改善
クラウド編集をする前にトライしたものが Google Driveのデスクトップ版 + Blackmagic cloud の構成です。
Blackmagic cloudは製品になっているものがありますが、これはクラウドサービスだけのものです。
この構成ではプロジェクトファイルがBGKのクラウド上にあり、作業ファイルがGoogle Driveにある構成になります。作業ファイルは毎度ストリーミングされるわけですが、作業ファイルはかなり容量が大きくダウンロードに時間がかかり、決して快適と言える環境ではありませんでした。
お願い
この記事の記載事項やサービスについて、弊学及び当局へのお問い合わせはおやめください。
またこの記事の記載事項について、誤りの無い様細心の注意を払っていますが正確性を保証することはできません。
予めご了承下さい。
2.構築手順
今回は実務で使用しながらもテスト段階であり、かつ本局はあくまでも高校という小規模な場のものであるので最も基礎的な構成で行うことにしました。
構築の方法は他にもたくさんあるのですが、ここでは省略させていただきます。こちらの資料にとてもわかり易くまとめてくださっているのでリンクを貼らさせていただきます。
構成内容
今回の構成は図にするとこのようになります。
今回は構成図の通り、EC2上にWindowsインスタンスを立てて運用することにしました。
他にはAmazon WorkSpacesで運用する方法もあるのですが、セットアップが楽な代わりにコストが掛かってしまうので今回はパスしました。WorkSpaces自体は文化祭のときに作業用で運用しましたが、セットアップ面でも運用面でも非常に良かったのでぜひ使ってみてください。
その他、ファイル転送についてはAWS上様々なサービスがありますが、今回は学校ですでにあるGoogle Driveを使うことにしました。
構築手順
それでは実際に作業環境の構築をしていきます。
1.EC2のインスタンスを立てる
これは特に困ることはないかなと思います。
windowsのAMIを選択してキーペアを選択して…(以下略)という流れです。
ただし、Gインスタンスは、初期値のクオータが0に設定されていたり、vCPUの数にも制限がかかっていたりするので、事前に必要な分だけ制限を緩和してもらいましょう。サポートプランがBasicの私達?は土日等の場合、サービスの対応が月曜日からになってしまうので要注意です。
2.インスタンスにドライバを入れる
本局では動画編集ソフトでDavinchi Resolveを使用していますが、立ち上げただけでは使用することができません。実際にドライバを入れずにやってみるとGPUエラーが起こってしまいます。
なので、NDIVIAのドライバをインストールします。
インストールの方法はAWSの公式ドキュメントにまとめられています。
ちゃんと手順に従ってインストールしていきましょう。私の場合、オプションの２と３が必要でした。
注意
オプションの3を行うには該当EC2のインスタンスにS3のRead以上の権限が必要です。適切なIAMロールをアタッチしてください。
3.(NICE DCVをインストールする)
NICE DCVはリモートでデスクトップに接続するためのソフトです。ですが、この作業はあくまでもオプションとなります。一番最初に接続する時、.rdpで接続をされると思いますが、そのまま.rdpで作業を続けてもNICE DCVで接続しても大きな差が生まれるわけではありません。
ですが、機能面や多少の差からNICE DCVをインストールできるならインストールをおすすめします。
インストールの手順は今回は省かせていただきますが、クライアントとサーバー側でソフトをそれぞれインストールするだけの簡単な手順となっています。インストール以外には、AWSのコンソールからEC2側で接続に必要なポート 8443 を開けておく必要があるのでご注意ください。
上で機能の面でと書きましたが、違いとしては
- ソフトとしてUIが整っており、操作しやすい
- Webブラウザからも接続できる
などが挙げられます。
4.(Elastic IPを適用する)
これもオプションの操作になります。
今回の私達のケースでは使うときだけインスタンスを起動し、使用が終わったら停止するという運用をしたので、その度にIPアドレスが変わってしまうと接続のときに面倒です。
なので、今回はIPアドレスを固定化しました。この固定化は有料となってしまうのでご注意ください。
3.運用
コスト管理
今回、構築したインスタンスはG系のインスタンスでOSもWindowsなので、どのように運用していくかがコスト管理において重要になってきます。
簡単に言うと Start と Stop を随時ちゃんと行うということです。
Rootユーザー(私)が編集担当者の生活リズムに合わせても良いのですがそれはあまりにも非効率なので、該当インスタンスのStartとStopのみを許可したIAMユーザーを作成して編集担当者に随時操作を行ってもらいました。
毎度コンソールにログインするのが少し面倒ですが、コストのことを考えるとこれが最善手だと思います。スマホからだとアプリがあるので簡単に操作できます。
アップスケーリング
これはクラウド編集の利点として挙げられる大きな特徴の一つではないでしょうか。
EC2ではインスタンスのサイズを途中で変更することができます。過剰スペックのときはより低いスペックのインスタンスに変更したり、適切なインスタンスファミリーに変更できるということです。
また、この変更はAWSコンソール上で4,5回クリックするだけですぐに変更が行われます。変更に再契約やサーバーデータを移したりなどと言った手間もなく、処理待ちもありません。
今回のケースではこの利点をエンコード時のスケールアップという活用方法をしました。先述の通り、本局ではDaVinci Resolveをメインで使用していますが無料のものを使用しているので、特にCPUの性能がエンコード時間に影響してきます。
エンコード前に一度インスタンスを止めなければいけないという欠点はあるものの、例えば2x largeから4x largeへのアップスケーリングを行うと8コアから16コアになるので、単純計算で処理時間が半分になります。
4.クラウド編集の利点と運用レポ
使用感としては、一個人的には革命レベルの体感でした。テストでオレゴンリージョンでx largeを建てた時はラグが多くてあんまりかなと思ったのですが、いざ本番環境を建ててみると 0遅延！ 普通に編集もできる！ きれい！ でとても感動したのを覚えています。
ざっと利点としてあげられるのは以下になります
- 遅延が実質なし
- 2x largeでも重い処理をしなければ十分編集できる
- 画面が普通にきれい
- エンコード時だけマシンをアップグレードできる(エンコード時間の短縮)
- 編集の共同化ができる
- エンコード中に操作元で別の作業ができる
- 通信制限がかかっている端末でテザリングしても操作できる
- データの流出がなくなる(データを物で持ち運ばなくて良い)
- 各個人の端末のスペック依存がなくなる
- Webブラウザから接続できるので操作元PCのOS依存問題がなくなる
今回の編集ではカラーやfusionの処理を行っていませんが、いつもローカルで作業する時(i9-10850K・RTX 3060ti)と差を感じることはありませんでした。
また、編集担当に言われてすごく納得したのはエンコード時に手ぶらになることがないことです。
いくらどれだけ良いPCであってもエンコード中はPCのリソースを大きく割かれますし、別の編集を行うのはもちろんのこと、パソコンによっては文章作成も不快感を感じることもあると思います。ですが、クラウド上で編集を行っていると、エンコードをしているのはクラウド上のインスタンスなので自分のマシンにはなんの負荷もかかっていません。その間に別の作業や編集を行うことができます。これは非常に効率化できた点です。
それに編集作業の共同化も非常に手軽に行なえました。ファイルを書き出して別の機体に移すこともなく、ただそのインスタンスに接続してもらうだけで1秒前まで別の人が行っていた作業ができます。わざわざデータベースを立てる必要もありません。
他には、接続のときのネットワークとハードへの負荷の軽さは驚かされました。セレロンのChromebookからでもスイスイ操作できましたし、通信制限がかかっている状況でテザリングをしても操作できた時は本当に驚きました。
そして、運用のところでも触れたエンコード時のアップスケーリングをした結果が以下のようになります。
これは8分のFHD 59.94コマの動画をエンコードしたときのものです。
上が2x largeで書き出したもの、下が4x largeで書き出したものになります。あまりにもきれいにコア数に反比例しています。結果、すごく時間の削減になりました。
といっても欠点は存在します。
それはコストです。これほどのことができて一時間1~2ドル程度なら安いと思いますが、でも1~2ドルかかるのは事実です。今回の編集では販促クレジットを使ってコストが掛からないようにしましたが、大規模なプロジェクトになるとその分作業時間が増えてコストがかさんでしまいます。ですが、20万円や30万円もするパソコンを学校に導入するより、どこからでも使えて・使うときしか払わなくて済む方が安く済むと思いますし予算も通しやすいのではないでしょうか。
まとめ
クラウド編集はコストだけ除けば、可能性しかない素晴らしいリソースだと思います。実際、クラウド編集で現在の課題は全て解決しましたし、新たな利点の創出もできました。
今後はもっと新たな使い方や構築方法をしていきたいと思います。
今回の構築に当たってご指導賜りましたAWS様、記事の校閲を手伝ってくれた方に感謝申し上げます。
それでは、またお会いしましょう！！