Yuniframeの実行環境は基本的にWebブラウザになり、WebブラウザがWebRTCでやりとりできないケースではWebSocketを中継するサーバを運用することになる。このサーバはWebRTCのシグナリングでも使用する。

... というかWebRTCはkeep aliveの頻度がクッソ激烈に高いため、アイドル時間が長いと想定されるアプリケーションではそもそもWebSocketを基本にすべきかもしれない。

通信の基本スペック

現状の想定では(かなり多めに見積っている)、

• 月間UU 〜1000人
• 通信容量 512kbps = 64KiB/sec = 1092bytes / frame > 1024 bytes/frame
• ひとり当たりの一日平均セッション時間 2時間
• ひとり当たりの一日平均セッション回数 10回
• セッションあたりのDB更新回数 10

お絵描きチャットのようなアプリケーションではペン座標やその他設定の共有のために1フレームあたり1024bytesは通信したい。1秒間に60フレーム通信するとして、これは単純な帯域で言うと512kbps程度に相当する。(ちなみに通常のネットワークゲームは通信間隔がもっと長く、実際のyuniframeアプリケーションでも1対多の場合は間隔を広げることで対応することになる。例えば5人のセッションでは12フレーム/秒になる。)

つまり月間に直すと:

• 月間DB更新回数 30日 x 1000人 x 10回 x 10 = 300万回
• 月間通信量(egress) 30日 x 2時間 x 64KiB x 3600 x 1000人 = 約14TiB

... マジ。。？転送量多くない。。？

AWSだと 0.09USD/GB がEC2インスタンスの転送料金で、(無料枠を考慮せずに)月間に直すと 1290ドル 。高けぇ。。

因みにデータベースはAWS DynamoDBでも100万回更新で 1.25USD 、つまり月間 4 ドル弱、ストレージとegress料金は基本的に無料枠に収まる。

WebSocketをシグナリングにしか使わない場合

というわけでリアルタイム通信は全部WebRTC前提ということにしてセッションの確立にだけ使うことを考える。

• セッションあたりの通信量 16KiB (非圧縮)
• 月間通信量(egress) 30日 x 1000人 x 10回 x 16KiB = 4.8GiB

まぁ5GiBくらいなら大抵の事業者の無料枠に収まるだろう。。