大きなファイルのアップロードを、どう作りますか

アプリのサーバーで受けると何が困るか

アプリのサーバーで受けてから保存する形だと、送り終わるまでの長い間、接続とメモリを 1 人のために使い続けます。大きなファイルが何本も同時に来ると、ほかの利用者の普通のリクエストまで遅くなります。前に置いたロードバランサや、サーバーのリクエストの大きさと時間の上限に引っかかって、途中で切られることもあります。

そこで、アプリのサーバーは「誰が、どこへ、何を置いてよいか」を決める役だけにし、重い中身の受け渡しはストレージに任せます。

署名付き URL で直接送らせる

流れは次の通りです。

1. ブラウザが「このファイルを送りたい」と、名前、大きさ、種類をアプリのサーバーに伝えます
2. サーバーはログインと権限を確かめ、保存先の名前を自分で決めて、期限付きの署名付き URL を返します
3. ブラウザはその URL へ、ファイルの中身を直接送ります
4. 送り終えたら、ブラウザかストレージの通知が、サーバーに完了を知らせます

保存先の名前は、利用者が付けたファイル名をそのまま使わず、サーバーが決めます。ほかの人のファイルを上書きしたり、思わぬ場所に置かれたりするのを防ぐためです。URL の期限は短くし、置ける大きさや種類も、作れる範囲で URL の条件に入れておきます。

分けて送り、途中から再開する

大きなファイルを 1 回で送ると、最後のほうで切れたときに全部やり直しになります。塊に分けて 1 つずつ送り、どの塊まで届いたかを記録しておけば、切れても残りだけを送れます。塊は同時に何本か送れるので、速くもなります。

オブジェクトストレージの多くは、このための「分けて送る」仕組みを持っています。塊の大きさや数の上限はサービスごとに決まっているので、使う物の文書で確かめます。

届いた後の処理

届いたファイルは、送る側の言う種類や大きさを信じず、サーバーの側で中身を確かめます。画像の縮小、動画の変換、ウイルスの検査のような重い処理は、キューに入れて別の働き手に回し、利用者には「処理中」と見せます。終わってから「使える」に変えます。

途中で捨てられたアップロードは、ストレージに塊が残り続け、費用がかかります。一定の期間で消す決まりを付けておきます。

トレードオフ

直接送らせる形は、サーバーの負担が軽く、大きなファイルにも強い一方で、流れが 2 段になり、完了の知らせを取りこぼしたときの手当てが要ります。数 MB のプロフィール画像のように小さく数も少ないなら、アプリのサーバーで受ける素直な形のほうが、作りも確かめも簡単です。ファイルの大きさと数で選びます。

話す例は架空の例で構いません。「動画の投稿で、サーバーが重くなったので署名付き URL に変え、届いた後の変換をキューに回した」のように、何に困って何を変えたかを話せると伝わります。