Summary
この文書の要点
- 署名付きURL発行前にユーザー権限とファイル条件を確認する。
- アップロード前に仮レコードを作り、完了後に確定する。
- アップロード前にDBへ予約レコードを作り、完了後にサイズ、MIME、checksumを検証する。
- 署名付きURLは短命にし、用途、ユーザー、ファイルIDを紐付けて発行する。
どこが設計の難所か
直接アップロードは効率的ですが、署名付きURLを発行すると、そのURLを持つクライアントが一定時間アップロードできます。保存先やファイル条件を制限しないと、意図しないオブジェクトが置かれる可能性があります。
ブラウザからのアップロードは途中で中断されます。アップロード成功後にアプリDBの登録が失敗することもあります。DBとGCSの整合性を後から回復できる設計が必要です。
GCSへブラウザから直接アップロードすると、アプリサーバーを経由しないため大きなファイルに向きます。一方で、サーバーが実際のファイル内容を見ないまま完了扱いにすると、権限外アップロードや不正な形式を見逃します。
境界をどう切るか
APIでアップロード予定を作成し、ユーザー権限、ファイル名、サイズ、MIMEタイプを確認してから署名付きURLを返します。クライアントはGCSへ直接アップロードし、完了後にAPIへ確定を通知します。
設計では、アップロード予約、署名付きURL発行、クライアントアップロード、完了通知、検証、利用可能化を分けます。署名付きURLはファイルIDと利用者に紐付け、期限と許可メソッドを限定します。
実装で効く細部
DBには仮ファイルレコードを作り、状態を`pending`、`uploaded`、`confirmed`、`expired`のように管理します。オブジェクトキーはサーバー側で生成し、クライアントに自由入力させません。確定時にGCSのメタデータを確認します。
Cloud Run側では、予約時にstorage_keyを生成し、GCS署名付きURLを発行します。完了通知後にGCS metadataを取得し、サイズ、content-type、generationをDBと照合してからavailableへ遷移させます。
- 元ファイル名をobject keyに使わず、推測できないIDで保存する。
- 完了通知を信用せず、GCS上の実体とmetadataをサーバー側で確認する。
- 期限切れや途中失敗の予約レコードを掃除するジョブを用意する。
壊れ方を観測する
検証では、期限切れURL、MIMEタイプ不一致、アップロード後の確定失敗、仮レコード放置、権限外ユーザーの確定を確認します。大容量ファイルやモバイル回線での中断も見ます。
検証では、期限切れURL、別ユーザーのURL利用、サイズ超過、MIME偽装、完了通知なしのファイルを確認します。GCSのgenerationを使い、同じkeyの上書きが想定外に起きないことも見ます。
捨てた選択肢とトレードオフ
直接アップロードはサーバー負荷を下げますが、フローは複雑になります。小さなファイルだけならアプリサーバー経由の方が単純です。ファイルサイズや頻度を見て採用を判断します。
直接アップロードはスケールしやすい一方、状態管理が増えます。小さいファイルだけならアプリ経由アップロードの方が単純な場合もあります。ファイルサイズ、セキュリティ、実装コストで方式を選ぶべきです。
現場に残す判断軸
GCS署名付きURLは、アップロード経路を効率化する道具です。仮登録、確定、未確定掃除まで含めて設計することで、DBとストレージのずれを抑えられます。
署名付きURLは、アップロード経路を開ける仕組みです。安全に使うには、URL発行前後のDB状態とGCS実体の検証をセットで設計する必要があります。
