写真は、住所やゲーム一覧だけでは伝わらない店舗の様子を見せられる。一方、保存時だけでなく利用者へ送るたびにも容量を使う。同じ枚数でも、一枚が大きければ表示時の転送量は増える。

現在は無料ホスティングの利用量を抑えるため、画像を選び、画質を下げている。この方法だけでは写真を増やしにくいため、Next.jsとPocketBaseをVPSへ移す準備を始めた。

画像の保存容量と転送量

保存容量はサーバーに置くファイルの大きさで、転送量は利用者へ送るデータ量である。写真の増加は両方へ影響する。小さな名称や住所と同じ感覚では、将来の使用量を見積もりにくい。

Vercelの無料枠の余裕が減り、無料バックエンドでも5GBの保存上限に対し約3.5GBを超えて使用している。これは現時点の数字だ。空きが残っていても、写真ごとに同じ速度で増えるなら、その先の保存方法を考える必要がある。

flowchart TD
    accTitle: 写真増加と無料枠の衝突
    accDescr: 保存と転送の増加が画像の選別と画質縮小につながった。
    A["店舗写真の増加"] --> B
    B["保存と転送の使用量増加"] --> C
    C["画像選別と画質縮小"]

画像圧縮と移行先の検討

すぐできる対応は、残す写真を選んでファイルを小さくすることだ。保存と転送をともに減らせるが、入口や筐体配置の写真がぼやければ、写真を用意した効果も小さくなる。

圧縮だけに依存せず、サーバーを自分で運用する方法を調べることにした。対象は画面を提供するNext.jsとデータを扱うPocketBaseである。現在は移行先と構成を検討する段階で、移行が完了したわけではない。

flowchart TD
    accTitle: VPS移行で調べる対象
    accDescr: 共通の入口で画面とデータのリクエストを分ける構成を検討する。
    A["外部リクエスト"] --> B
    B["リバースプロキシの構想"] --> C
    C["Next.jsとPocketBase"]

VPSとリバースプロキシ

VPSは、仮想的に分割したサーバーを借りて必要なプログラムを動かす方式である。管理されたホスティングより配置を選びやすくなるが、要求がどこへ届き、どのプログラムへ渡るかを理解する必要もある。IPとTCPを学んでいる理由はそこにある。

検討中の構成は、共通の入口から画面の要求をNext.jsへ、データの要求をPocketBaseへ振り分けるものだ。この入口を担当する仕組みをリバースプロキシと呼ぶ。図はこの案を整理したもので、確定した配備構成やアドレスではない。

flowchart TD
    accTitle: 選択権と責任
    accDescr: 資源を選ぶには実行・接続・障害対応の責任も準備する必要がある。
    A["VPS運用の検討"] --> B
    B["資源とサービス配置の選択"] --> C
    C["実行・接続・障害対応の準備"]

サーバー運用の準備

自分で資源を選べれば、写真の枚数と画質を調整する余地は増える。ただしVPSにも保存と転送の制約があり、借りれば画像の費用がなくなるわけではない。

プログラムの稼働状態や接続、障害時の確認箇所も自分たちで管理する。現在はその運用範囲を調べて準備している。利用量の問題を解くために移る以上、ファイルの置き場所と、継続して提供する構成をともに考えたい。

参考：Musecatエンジニアリング記録。