SCP Playerの音声生成基盤をCloudflareとUbuntuで分けた理由
Flutterアプリ、Cloudflare Workers、D1、R2、Ubuntu音声生成サーバーを分担させた構成を説明します。
SCP Playerでは、ユーザー認証や利用回数の判定と、CPU負荷の高い音声生成を同じ場所で処理していません。公開APIはCloudflare Workers、データはD1、生成済み音声はR2、実際の音声合成はUbuntuマシンへ分担しています。
公開部分をCloudflareへ置く
アプリから直接自宅や研究用マシンへ接続させると、公開ポート、IPアドレス、TLS証明書、攻撃対策を個別に管理する必要があります。Workerを入口にすることで、クライアントには一つのAPIだけを公開し、内部の生成サーバーはCloudflare Tunnel経由で接続できます。
生成済み音声を再利用する
記事ごとに毎回合成すると待ち時間と計算量が増えます。音声生成が完了したらR2へ保存し、次回以降は同じファイルを配信します。D1には記事情報、音声状態、ユーザーごとの利用量を保存し、音声ファイルそのものとは分離しています。
障害を分離する
音声エンジンが停止しても、記事一覧や生成済み音声の再生まで停止させないことが目標です。機能ごとに責任を分けると構成は増えますが、どこで失敗したかを確認しやすく、将来エンジンを追加する際にも影響範囲を限定できます。