メディア処理のサービスを選ぶときの判断軸
画像や動画の変換は、自前で組むと「作れはするが運用が重い」典型になる。 ImageMagick や FFmpeg を動かすところまでは短時間でできるが、 その先で配信・キャッシュ・元画像の保管・失敗時の再処理が必要になり、 気づくと本業と関係ない基盤を保守している。外部サービスを使う理由は 機能そのものより、この運用を引き受けてもらえることにある。
変換をいつ実行するかで構成が変わる
大きく 2 つの型がある。どちらを選ぶかで設計がかなり違う。
- リクエスト時に変換する型 — URL にパラメータを載せると、その場で 変換して返す。あらかじめサイズを決めなくてよく、後から表示サイズを 変えても作り直しが要らない。初期の実装がいちばん軽い
- アップロード時に変換する型 — 保存の段階で必要な形をすべて作る。 配信時の計算が要らないぶん速く、変換回数も読めるが、 必要なサイズが増えたときに過去分の作り直しが発生する
リクエスト時変換は手軽なぶん、幅や品質の指定がテンプレート中に散らばりがちです。この状態で提供元を変えると、URL の書式が違うため全箇所を直すことになります。サイズの組み合わせに名前を付けて 1 か所で管理し、テンプレートからはその名前だけを参照する形にしておくと、移行も仕様変更も 1 か所で済みます。
課金の単位が「保存量」ではないことが多い
ストレージと同じ感覚で見積もると外れる。この領域の課金は 変換の回数や配信した転送量に紐づくことが多く、 保存しているファイルの量とは連動しない。
とくに効いてくるのが、同じ画像でもサイズ違いを別の変換として数える点だ。 一覧・詳細・OGP でそれぞれ違う寸法を出していると、 1 枚の画像が何回分にもなる。画面ごとに必要な寸法を洗い出してから 見積もると、実際の請求と近い数字になる。
元のファイルをどこに置くかは別途決める
変換と配信を任せても、変換前のファイルを保管する責任は残ることがある。 提供元が原本も預かる形なら話は早いが、自分のストレージを参照させる形なら、 そちらの可用性と料金は別勘定になる。 どちらの構成かを最初に確認しておかないと、あとから 「原本が消えたので作り直せない」という事故につながる。
移行のしやすさは URL の作り方で決まる
この領域は一度入れると外しにくい。理由は機能差ではなく、 変換 URL がページの至るところに埋め込まれるためだ。 提供元ごとに URL の書式が違うので、そのまま書き散らすと移行が大工事になる。
逆に言えば、URL を組み立てる処理を 1 か所にまとめておけば、 乗り換えのコストはかなり下がる。導入時にその 1 か所を用意しておくことが、 この分野で唯一効く保険になる。