Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

大きいファイルは HTTP リクエストを分けてアップロードできるようにする #11801

Open
acid-chicken opened this issue Sep 7, 2023 · 23 comments
Labels
[Feat] Drive Drive related issue ✨Feature This adds/improves/enhances a feature packages/backend Server side specific issue/PR

Comments

@acid-chicken
Copy link
Member

Summary

Cloudflare の 100 MB 制限などが実質的なファイルサイズ制限になっているため

@KisaragiEffective
Copy link
Collaborator

use case: #5364 のテストのためにisoを添付しようとしたらCfに怒られた

@KisaragiEffective
Copy link
Collaborator

use case: 動画をアップロードしようとしたら怒られた

@KisaragiEffective
Copy link
Collaborator

https://community.cloudflare.com/t/max-upload-size/630925/3
Enterpriseにあげても気休めにしかならないことが判明

@samunohito
Copy link
Member

オブジェクトストレージのマルチパートアップロード機能を前提に実装する必要がありそうな感じがします……?

@tamaina
Copy link
Contributor

tamaina commented Jul 5, 2024

分割したものをつなぎ合わせるシステムが意外に面倒 (RFCもなさそう)

  • s3のマルチパートアップロードの利用を考えてAPIを設計する?
  • Misskeyサーバーからクライアントへ一時idを発行する時は、完成後のURLを推測されないようにする必要がある

@KisaragiEffective
Copy link
Collaborator

どのサーバーもs3を使っているというわけではないだろうからオブジェクトストレージ中立な設計にしたい

@tamaina
Copy link
Contributor

tamaina commented Jul 5, 2024

PUTに対する課金ってマルチパートアップロードの場合どうなるんだろう

@KisaragiEffective
Copy link
Collaborator

s3の場合: UploadPartの呼び出し回数に比例?

@KisaragiEffective
Copy link
Collaborator

リクエストを開始するときにはアップロードしようとしているファイルサイズを含めたい。
そうすることでドライブの容量が足りないときに無駄なアップロードを発生させず、即エラーにできる

@tamaina
Copy link
Contributor

tamaina commented Jul 5, 2024

S3マルチパートアップロードを使わない場合

  • クライアントから別のクラスタにパートが送られる可能性もあるので、Misskeyバックエンドがアップロード前につなぎ合わせる処理をする方式は取れない
  • ので、ひとまずパートごとにダイレクトにオブジェクトストレージもしくはローカルファイルに保存しておいて、クライアントがファイルを要求するときは、Misskeyバックエンドに/files/で繋ぎ合わせながらダウンロードできる機能をつけるみたいなのが考えられる
    • ただしこれはバックエンドにストリーミングの負荷がかかる
  • もしくはクライアントが要求する?
    • クライアントはメモリが無理そう
  • 動画はHLSにしちゃうとか?
    • mp4を全部読んで解釈しなきゃいけないので無理そう?
    • S3のPUTコストは膨れるけどアップロード終了後に後処理で動画専用処理をやってやる(サーバー管理者がオプションでこれをやるか選べるようにする)というのもありっちゃあり

@tamaina
Copy link
Contributor

tamaina commented Jul 5, 2024

PUTコストはかかるがファイルアップロード終了時に整理して後々のMisskeyバックエンドの負荷を減らす(動画はhls化/それ以外は単一ファイルとして再アップロード)
vs
PUTコストをかけず/files/で繋ぎ合わせたものをダウンロードさせる (Misskeyバックエンドの負荷は増える)

みたいなのを選べるようにすればいいか

@KisaragiEffective
Copy link
Collaborator

大規模なサーバーだったら結合されてた方が嬉しそうではある

@samunohito
Copy link
Member

リクエストを開始するときにはアップロードしようとしているファイルサイズを含めたい。
そうすることでドライブの容量が足りないときに無駄なアップロードを発生させず、即エラーにできる

どの方法をとるにしてもこれは必ずやるとして…(先出しでやっておいても良いレベル)

上記に加え、サーバ側で1ファイルあたりのサイズ上限を決められたらいいようにも思えます(既にある?)
大容量ファイルのアップロード方式以前に、大容量ファイルのアップロードそのものを歓迎しないところもあるでしょうから

@KisaragiEffective
Copy link
Collaborator

上記に加え、サーバ側で1ファイルあたりのサイズ上限を決められたらいいようにも思えます(既にある?)

ないかも?現状はドライブの合計容量だけ存在する認識

@samunohito
Copy link
Member

#11801 (comment)

  • PUTコストはかかるがファイルアップロード終了時に整理して後々のMisskeyバックエンドの負荷を減らす
  • PUTコストをかけず/files/で繋ぎ合わせたものをダウンロードさせる

に加え、マルチパートアップロード対応(かつS3互換のAPIで動かせる)なオブジェクトストレージを使ってる場合は、それを使用できる選択肢があってもいいかも…?
いずれもバックエンドに負担がかかるので損な選択肢ではないと考えています

@kozakura913
Copy link

サーバー単位でのファイルサイズ制限はこれかも?

#maxFileSize: 262144000

@samunohito
Copy link
Member

ありがとうございます。そんなところに…

@kozakura913
Copy link

ロール単位でのサイズ制限が欲しくて独自フォークで実装したけど、Cherrypickベースのフォークだから別に実装した方が楽かもしれない

@samunohito
Copy link
Member

もし単体での上限を実装するときは

ロール単位でのサイズ制限が欲しくて

のほうが融通を利かせやすいかもですね。ちょっと実装量増えるけど…

@KisaragiEffective
Copy link
Collaborator

逆に、先にロール単位でのサイズ制限を実装してしまう?

@kozakura913
Copy link

私の独自フォークからプルリクエスト作れるかも

@tai-cha
Copy link
Contributor

tai-cha commented Jul 26, 2024

メモ: Resumable Uploads for HTTP (draft)
https://datatracker.ietf.org/doc/draft-ietf-httpbis-resumable-upload/

@tai-cha
Copy link
Contributor

tai-cha commented Oct 22, 2024

ほむん
https://github.com/tus/tus-node-server

@samunohito samunohito added packages/backend Server side specific issue/PR [Feat] Drive Drive related issue labels Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feat] Drive Drive related issue ✨Feature This adds/improves/enhances a feature packages/backend Server side specific issue/PR
Projects
Status: Triage
Status: No status
Development

No branches or pull requests

6 participants