はじめに

こんにちは、たくまです。もう2月になりましたね。今月も個人開発したので、その内容をお届けできたら、思います。というか、もう4月ですね。。。。

ある日、ライブ配信アプリ開発してみたいと思った

なんとなく、日々使っているYoutubeやTwitchって、どのように作られているのか疑問に思いました。そこで、自分で調査してみました。知識にをつけるために参照したリファレンスです。

こちらの記事を拝見して思ったことは、ライブ配信の高負荷部分（エッジ側）は、低コストで国内に強いIDCFクラウドや、パフォーマンスに優れるOCI、もしくはAkamaiなどを導入しているパターンが多いこと。一方、バックエンドのAPI、認証、データ分析部分はAWSやGCPで運用するなど、各クラウドの強みを活かしたハイブリッド構成がスタンダードなやり方だなと感じました。

開発する上の不安点（課題・懸念事項）

コメント処理の仕組み
- ライブ配信中のコメントをリアルタイムにさばく仕組みについての理解不足。
- キューイングシステムや分散チャットサーバー（例：WebSocket＋メッセージブローカー）の導入検討が必要。
高速並列処理の仕組み
- ライブ配信機能を高速で並列処理する仕組みにより、処理を深く分散してCPU使用率を下げる可能性があるが、その実現方法や設計に関する理解不足。
開発経験の不足
- ライブ配信アプリの開発経験者がいないため、企画段階から運用まで全体像が不透明。
- 開発や運用のベストプラクティスの不足が懸念される。
サーバー負荷の不透明性
- リアルタイム配信機能における視聴者数の増加に伴い、サーバーがどの程度負荷を受けるのかが不明確。
- ライブ配信負荷テストで、どの程度の同時視聴者数や配信数に対応可能か、また、限界値をどのように把握するかが課題。
トラフィックとコストの問題
- 知人の話では、ユーザー数が増加すると1秒あたり5GBの転送トラフィックが発生する可能性があり、AWSやGCPはライブ配信画面側の高負荷処理には向かないという意見がある。
- 既存のバックエンド（ユーザー認証、データ分析、管理部分など）はAWSやGCPで運用し、ライブ配信部分の高負荷な処理をOCI、IDCFクラウド、またはAkamaiに寄せるハイブリッド構成も検討すべきだが、現状は検証が不十分。
負荷テスト・オートスケーリングの不安
- ライブ配信負荷テストにより、どの程度の負荷までカバーできるか不明。
- ロングランテストで「このサーバーなら、ここまでが限界」というデータを取得し、運用時にオートスケーリングで対応できるかが懸念材料。
インフラのランニングコスト
- 将来的にかかるインフラサーバー代のみのランニングコスト試算（OCIでの試算結果）が、負荷シナリオによってかなりの金額となる。

考慮すべき技術・運用上のポイント

コメント処理
- リアルタイムで大量のコメントを処理するために、キューイングシステムや分散チャットサーバー（WebSocket＋メッセージブローカー）の導入を検討する。
高速並列処理エンジン
- ワーカープールやタスクスケジューラーを実装し、タスクの細分化・並列化により各ノードのCPU負荷を分散・低減する設計を検討する。
負荷テストとオートスケーリング
- 配信サーバーやAPIサーバーの限界を把握するため、リアルタイムテスト、ロングランテストを実施する。
- オートスケーリング機能を取り入れ、アクセス急増時にも自動でリソースを追加できる仕組みの検証が必要。
ハイブリッドインフラ戦略
- ライブ配信の高負荷部分（エッジ側）は、低コストで国内に強いIDCFクラウドや、パフォーマンスに優れるOCI、もしくはAkamaiなどを検討する。
- 一方、バックエンドのAPI、認証、データ分析部分はAWSやGCPで運用するなど、各クラウドの強みを活かしたハイブリッド構成を模索する。
コスト試算の継続的な見直し
- ライブ配信の品質（720p～4K）や同時配信数に応じたインフラコストは大きく変動するため、実際の利用状況に基づいた継続的な試算・最適化が不可欠。

超簡易的にライブ配信アプリを開発してみた件

技術スタックは、React, TS, MUI, Viteで開発しました。やばいUIですが、すみません。フロントエンドのみ開発しました。アクターは、配信者と視聴者です。
こちらGitHubのURLです。https://github.com/takuma123-type/live-app


ホーム画面	ライブ配信前画面

以上！