作ったもの
YouTube Liveの放送から盛り上がった箇所を自動で抽出するサービスです。長時間配信を観る時間がない方や配信の切り抜きを作りたい方などは是非利用してみてください。
リンク→https://www.highlight-ranking.com/
YouTubeLiveの生放送から盛り上がった箇所を自動抽出するwebサービス作りました。是非使ってみてください。https://t.co/fYxddc2jOV
— tf (@tf0101_tw) January 6, 2020
作った理由
元々はYouTube Liveの生放送から盛り上がった箇所を自動抽出するCLIとしてPyPl(pipでinstallするアレ)に公開していたがエラーが出る等の連絡があったので一部機能を修正して誰でも使えるようにwebサービスとして公開することにした。
サービス概要
サービス内容はいたってシンプル
入力フォームにYouTube Liveのアーカイブ動画のURLを入力するとその放送のハイライトをランキング表示するというもの
※どのようにハイライト(盛り上がった箇所)を定義しているかについてはこちらの記事に詳しく書いています。
処理の流れとしては、入力された動画URLデータを自作したWebAPIに投げてランキングデータをレスポンスとして受け取って表示している
使った技術
##フロントエンド
-
Vue.js
- 双方向バインディングなどリアクティブな処理ができるjavascriptフレームワーク
-
Vuetify
- Vue.jsでマテリアルデザインを使えるようにするライブラリ
-
Vue-cli
- Vue.js開発できるようにいろいろ準備してくれるすげーやつ、Nuxt.jsでもよかったかもしれない
SPAにしたかったのでVue.js、React、Angularの3つを候補に上げてVue.jsを選択した。ReactやAngularにも興味はあったが開発スピードを重視したかったのでReactやAngularと比較して学習コストが低いVue.jsが適切だと判断した。
##バックエンド
- Django
- pythonのフルスタック・フレームワーク
- Nginx
- webサーバー
- gunicorn
- WSGIサーバー、webサーバーとWebアプリケーションフレームワークを繋ぐ仲介人的なやつでセキュリティ面でNginxと相性がいい (URL)
- MySQL
- RDB
公開していたCLIパッケージをpythonで書いていたので、これを使い回せるpythonのwebフレームワークのDjangoを選択した。URLディスパッチャーやO/Rマッパーやテンプレートエンジンなどの機能が充実していてさすがフルスタックといったところ
webサーバーはApacheとNginxの2択
ここは正直迷った、というのもマルチプロセスのApacheは重い処理が得意だが大量リクエストに弱い、一方シングルスレッドのNginxは少ないプロセス数で大量リクエストを捌けるが重い処理は苦手でボトルネックになる。
そこで、使えるリソース(AWSEC2)で判断することにした。元々EC2の無料枠の利用を前提として考えていた**（できるだけお金をかけたくなかった）**ので無料枠の少ないリソースでも回せそうなNginxを選択
DBは特に選定せずMySQL使った、NoSQLを使ってみてもよかったかもしれない
##インフラ
AWSでVPCを構築しS3で静的Webページをホスティングして動的コンテンツはWebAPIとして実装、画像の方が理解し易いので概要図を作成しました。
- Route53
- DNS
- CloudFront
- CDN
- S3
- クラウドストレージ
- EC2
- 仮想サーバー
- Amazon RDS
- RDBサービス、DBエンジンはAmazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle、Microsoft SQL Serverの6種類に対応
インターフェース部分(静的webページ)はs3でホスティング
ランキング結果(動的コンテンツ)はEC2リソースで生成、定期batch処理で動的コンテンツのキャッシュを生成することでリクエストに対するレスポンスを高速化している
定期batch処理はEC2Schedulerで指定時間にインスタンスを起動して処理している(これを使うとEC2のタグに起動/停止させたい時間を設定するだけなので便利)
- EC2Scheduler
- Lambda、Dynamodb、CloudWatch Eventsを組み合わせてEC2の起動・停止を自動化する。使い方などはクラスメソッドの記事が詳しいので参考にしてください。
#開発する上で意識したこと
個人開発する上で意識したのは、自分が使いたい物(最低限自分は使うであろう物)を作ろうという点だ。(技術の勉強もできるし一石二鳥)
個人的な考えなのだが、収益の期待が低い場合の個人開発においてモチベーションを維持するためには理由が必要だと思うし、誰も使わないかもしれないサービスの維持にお金や労力を割き続けることは避けたい。
この、「自分が使いたい物を作る」というのが個人開発は赤字になると仮定していた自分なりのモチベーション維持方法だった。
まぁ、モチベーション維持の理由は人それぞれだと思うが、自分の場合は「最悪自分が使うしまぁいいか(オレオレ思考)」ぐらいの軽いノリで作り始めたのが性に合っていたんだと思う。
二つ目に意識したことは開発スピード、細かい所にこだわるよりまずは完成させることを優先した。
自分の場合はこだわるのはサービスの根幹をなす部分(WebAPIでの処理)だけにしてインターフェース面は最低限の実装にした。というのも、過去の個人開発でインターフェース面にこだわった結果、開発の長期化からモチベーションが低下し開発を投げ出した経験があるからだ。こういった経験から今回の開発では注力する箇所を決めて自分のリソースの配分も考え開発スピードを重視した。
しかしながら個人開発においては開発スピードの速さが正義だとも思えない、時間を掛ければサービスの質も上げられるだろうし技術の勉強を目的とした開発ならば時間が掛かるのも仕方ないと思うからだ。
そもそも個人開発なら誰にも迷惑がかからないんだから自分の目的やスタイルに合わせて気楽にやるのが一番だと思う