Uncategorized

1週間ハッカソンで「縦型ライブ配信」を作って学んだこと

福品悠翔
福品悠翔 ・ Backend

はじめに

初めまして♪
新卒バックエンドエンジニアの福品です。

最近はNext.jsやGolang、AWSを使ったWebアプリケーション開発を学んでおり、日々試行錯誤しながら開発に取り組んでいます。

今回の研修ハッカソンでは、これまで学んだ技術を活かして「縦型ライブ配信サービス」の開発に挑戦しました。

ライブ配信サービスの開発は初めてだったため、配信基盤やリアルタイム通信など新しく学ぶことも多く、とても良い経験になりました。

この記事では、実装した機能や技術構成、苦労したポイント、そして1週間で得られた学びをまとめています。

作ったもの

今回開発したのは、配信者・視聴者・管理者が利用できる縦型ライブ配信システムです。

配信者機能

  • ライブ配信開始
  • ライブ配信終了
  • カメラ ON / OFF
  • マイク ON / OFF
  • コメント・スタンプ確認

視聴者機能

  • 配信一覧表示
  • ライブ視聴
  • コメント投稿
  • スタンプ送信

リアルタイム機能

  • コメント即時反映
  • スタンプ即時反映
  • 配信中一覧のリアルタイム更新

管理機能

  • 配信者への警告メッセージ送信
  • 配信強制停止
  • 1日のスパチャ合計金額などのデータ表示

ライブ映像については、アプリケーション側で動画配信を実装するのではなく、AWSのライブ配信サービスである Amazon IVS を利用しました。

これにより、アプリケーションは「配信管理」「コメント」「スタンプ」などの業務ロジックに集中できる構成になっています。

使用技術

フロントエンド

技術用途
TypeScript開発言語
ReactUIライブラリ
Next.jsフレームワーク
CSS Modulesスタイリング
Socket.IO Clientリアルタイム通信
Amazon IVS Web Broadcast SDKライブ配信

バックエンド

技術用途
TypeScript開発言語
NestJSフレームワーク
PrismaORM
MySQL 8.4 LTSデータベース
Socket.IOリアルタイム通信
Redisキャッシュ管理

インフラ

技術用途
Docker Composeローカル開発環境
Nginxリバースプロキシ
AWS EC2本番環境
Amazon IVSライブ配信基盤
nip.io無料DNS

つまずいたポイントと解決方法

1. HTTP環境ではカメラ・マイクが取得できない

ライブ配信ではブラウザの getUserMedia() を利用してカメラやマイクを取得します。

しかし Chrome などの主要ブラウザでは、HTTPS環境でなければ利用できません。

開発終盤になって映像が取得できず焦りましたが、原因は通信方式でした。

解決方法

  • nip.ioで無料ドメインを取得
  • Nginxを設定
  • CertbotでSSL証明書を発行
  • HTTPS化

これにより正常にカメラ・マイクを取得できるようになりました。

2. ライブ配信の仕組みを理解するのに苦労した

最初は「ブラウザとamazon IVS同士でリクエストとレスポンスを返しあっている」程度の認識しかありませんでした。

実際には複数の技術が連携しています。

Amazon IVSを利用した配信フロー

getUserMedia()
↓　カメラ・マイク取得
IVS Web Broadcast SDK
↓　映像をエンコード
RTMPS
↓　Amazon IVSへ送信
Amazon IVS
↓　HLS形式へ変換
IVS Player SDK
↓　動画再生
videoタグ
↓
視聴者へ表示

まず配信者が配信開始ボタンを押すと、ブラウザの getUserMedia() を利用してカメラ・マイクの映像を取得します。

取得した映像は Amazon IVS Web Broadcast SDK に渡されます。このSDKは映像や音声を配信用データへ変換し、RTMPSというストリーミングプロトコルを利用してAmazon IVSへ送信します。

Amazon IVSは受け取った映像を視聴者向けのHLS形式へ変換します。HLSは動画を小さなセグメントファイルへ分割し、HTTP経由で配信する仕組みです。

視聴者側では IVS Player SDK がHLSのプレイリストを読み込み、分割された動画を順番に取得しながら再生します。取得した映像は最終的にHTMLの video タグへ描画されます。

3. OSの違いによる改行コード問題

チーム開発中に、WindowsとMacで改行コードの違いによる差分が大量発生しました。

解決方法①：Git設定を統一

git config –global core.autocrlf input

解決方法②：.gitattributesファイルを追加

* text=auto eol=lf

これにより改行コードをLFに統一できました。

小さな問題ですが、チーム開発では意外と時間を奪われるポイントでした。

4. EC2は新しい世代のインスタンスの方がコストパフォーマンスが高い

当初は t3 インスタンスを利用する予定でした。

しかし先輩エンジニアから、

「特別な理由がなければ t4g を使った方が良い」

とアドバイスをいただきました。

理由

  • インスタンス料金が安い
  • 消費電力が少ない
  • 同価格帯で高い性能を出せる
  • ArmベースのGravitonプロセッサを利用

実際に今回の構成では x86 CPU が必須となるライブラリもなく、問題なく利用できました。

クラウドでは「とりあえず慣れたものを選ぶ」のではなく、最新世代のサービスを確認することも重要だと学びました。

1週間で得た学び

ライブ配信は映像だけでは成立しない。

視聴者体験を作るためには、

  • コメント
  • スタンプ
  • リアルタイム更新
  • 管理機能
  • 配信状態管理

など、多くの機能が必要になります。

また、短期間の開発では「全部を作ろうとしない」ことも重要でした。

映像配信は Amazon IVS に任せ、アプリケーションが提供すべき価値に集中したことで、1週間という限られた期間でも動作するプロトタイプを完成させることができました。

さらに、

  • HTTPSの重要性
  • ライブ配信基盤の仕組み
  • WebSocketを利用したリアルタイム通信
  • AWSインフラ構築
  • Dockerを使った環境統一

など、実践的な知識を多く学ぶことができました。

おわりに

今回のハッカソンを通じて、「ライブ配信は映像を流すだけではなく、多くの技術が組み合わさって初めて成り立つサービスである」ということを実感しました。

配信基盤、リアルタイム通信、インフラ構築など、普段のWebアプリケーション開発とは異なる視点で学べることが多く、非常に刺激的な1週間でした。

また、すべてを自前で実装するのではなく、Amazon IVSのようなマネージドサービスを活用しながら、アプリケーションが提供すべき価値に集中することの重要性も学ぶことができました。

短期間ではありましたが、技術的にも大きく成長できたと感じています。

今後も新しい技術に積極的に挑戦し、ユーザーに価値を届けられるサービス開発に取り組んでいきたいと思います！

おすすめ記事

Recommend