search

misskey-dev / misskey

🌎 A completely free and open interplanetary microblogging platform 🚀
https://misskey-hub.net/
GNU Affero General Public License v3.0
9.93k stars 1.34k forks source link

絵文字をv12の仕様に戻す #9721

Closed SanMurakami closed 1 year ago

SanMurakami commented 1 year ago

v13になってから絵文字の仕様が変わったが、はっきり言ってキャッシュを消さないと追加した絵文字が反映されないのはめちゃめちゃ使いにくいし、外部絵文字を謎プロキシで圧縮する様になってからサーバーのCPU使用率も無駄に増えた。

かと言ってクライアントが軽くなっているかというとそうでもなく、301リダイレクトが多発しているためむしろ体感レスポンスは悪く、絵文字の様な元々小さい画像はWebPに圧縮しているサイズよりもHTTPヘッダーのサイズが上回っている物も多数あるため通信容量も増えている。

絵文字のキャッシュも部分的に消しているわけではなく全部消していて、毎回すべての絵文字を取得しているため通信量も無駄に多い。

また以前指摘したとおりDDoSに使われる可能性が十分あり、ユーザーアイコンと違ってかなり頻繁に呼ばれる絵文字の場合レートリミットをある程度緩める必要があり、キャッシュなどを行っても根本的な対策を取ることができない。

tamaina commented 1 year ago

キャッシュを消さないと追加した絵文字が反映されないのはめちゃめちゃ使いにくい

一応 https://github.com/misskey-dev/misskey/pull/9619 で直る

syuilo commented 1 year ago

絵文字のキャッシュも部分的に消しているわけではなく全部消していて、毎回すべての絵文字を取得しているため通信量も無駄に多い。

以前はページ読み込み毎に全カスタム絵文字取得してたからそれに比べたらそれでも10分の1以下にはなってると思う

SanMurakami commented 1 year ago

以前はページ読み込み毎に全カスタム絵文字取得してたからそれに比べたらそれでも10分の1以下にはなってると思う

ブラウザキャッシュを使っているはずなのでそれはないと思われる

syuilo commented 1 year ago

ブラウザキャッシュ使ってたら

キャッシュを消さないと追加した絵文字が反映されない

が起こる気がした

SanMurakami commented 1 year ago

v12まではそもそも実装が違ったので起こらなかった

syuilo commented 1 year ago

のため全てv12の仕様に戻すというのはしない

SanMurakami commented 1 year ago

メンテナンス性はともかくパフォーマンスは確実に落ちていることを体感している

やるならメディアプロキシなどの外部サーバーとして使える様にするべき（DDoSを受けても本体が影響を受けないため）だし、Misskey本体でこの処理をするのは問題でしかない

SanMurakami commented 1 year ago

投稿などについては戻すらしい

ローカルのmetaとemojisを分離して取得するようににゃった仕様は変更にゃし ノートとかにくっついてくるリモート絵文字情報はemojisとして復活する予定 https://misskey.io/notes/9af6xzf708

syuilo commented 1 year ago

v12でも外部カスタム絵文字は毎回プロキシ通してたからDDoSされる可能性はあった模様

tamaina commented 1 year ago

それを言ったらプロキシの存在自体がDDoSなんでは

(DDoSの問題は/emoji.webpの話では)

syuilo commented 1 year ago

それを言ったらプロキシの存在自体がDDoSなんでは

そういうことっぽい 例えばユーザーアイコン用エンドポイントもカスタム絵文字用プロキシも処理的には同じものだけど、

ということと理解している

SanMurakami commented 1 year ago

v12でも外部カスタム絵文字は毎回プロキシ通してたからDDoSされる可能性はあった模様

v12は直リンクだったのでキャッシュが使えたのとリダイレクトじゃないのでレートリミットが使えた

それを言ったらプロキシの存在自体がDDoSなんでは

そう。 なので個人的にはMisskey公式でMediaProxyを作ってもらって別鯖で建てれるようにしてほしい

(DDoSの問題は/emoji.webpの話では)

そう

syuilo commented 1 year ago

プロキシしてもリダイレクトじゃなくて直接画像返せば問題ない(というよりはv12と負荷的には同等になる)のであれば、やっぱりノートとかにemojisくっつける必要ないかも？

tamaina commented 1 year ago

プロキシしてもリダイレクトじゃなくて直接画像返せば問題ない(というよりはv12と負荷的には同等になる)のであれば、やっぱりノートとかにemojisくっつける必要ないかも？

emoji.webpをFileServerServiceに移すといった感じかしら

syuilo commented 1 year ago

そうね

tamaina commented 1 year ago

でも

なので個人的にはMisskey公式でMediaProxyを作ってもらって別鯖で建てれるようにしてほしい

が微妙になるかも

syuilo commented 1 year ago

プロキシ用サーバーが別に存在する場合はmetaとかでそのホストを返してクライアントがそれを見てリクエスト先変えれば良いと思った

SanMurakami commented 1 year ago

ノートとかにemojisくっつける必要ないかも？

これMilkteaの実装めっちゃ大変だったと聞いているのでサードパーティクライアントが育たなくなりそう

syuilo commented 1 year ago

今までのクライアントが移行するのは大変かもしれないけど、新たに出るクライアントが実装する場合はむしろ簡単になってるはず

SanMurakami commented 1 year ago

画像のURLを投稿に返さず、リダイレクトもしないでどうやって拾ってくるの

tamaina commented 1 year ago

プロキシ用サーバーが別に存在する場合はmetaとかでそのホストを返してクライアントがそれを見てリクエスト先変えれば

emojisのURL情報がない場合(v13初期の場合)のプロキシ用サーバーへのリクエストって可能？（ただしMisskey本体へのリクエストをせずに）

今までのクライアントが移行するのは大変かもしれないけど、新たに出るクライアントが実装する場合はむしろ簡単になってるはず

簡単かなぁ…

syuilo commented 1 year ago

Misskey Webもクライアントだけど実際emojisが無いことでかなり実装が簡潔になる

syuilo commented 1 year ago

画像のURLを投稿に返さず、リダイレクトもしないでどうやって拾ってくるの

プロキシに絵文字名を投げると絵文字画像が返ってくる

SanMurakami commented 1 year ago

それプロキシ前提ってことでしょ プロキシ使わないサーバーはどうやって処理すればいいの

tamaina commented 1 year ago

プロキシに絵文字名を投げると絵文字画像が返ってくる

HTMLのimgは301リダイレクトはブラウザが勝手にやってくれるけど、他の環境ではどうなんだかという

syuilo commented 1 year ago

プロキシは組み込まれてるからプロキシ使わないという選択肢はないと思う アバターもそうだけど各インスタンスのアイコンとかもプロキシ通してる

tamaina commented 1 year ago

プロキシ使わないサーバー

それはMisskey互換と言えない気がする

syuilo commented 1 year ago

プロキシに絵文字名を投げると絵文字画像が返ってくる

HTMLのimgは301リダイレクトはブラウザが勝手にやってくれるけど、他の環境ではどうなんだかという

画像直接返すのを想定してる

SanMurakami commented 1 year ago

リモートのカスタム絵文字のパフォーマンスについては、CDNでキャッシュするか、それができない場合はリモートのものも直URLリクエストするようにする

それができない場合はリモートのものも直URLリクエストするようにする

これはやめるってこと？

syuilo commented 1 year ago

(「プロキシから絵文字画像が返ってくる」は処理的にはまさにv12がやっていたこと)

SanMurakami commented 1 year ago

(「プロキシから絵文字画像が返ってくる」は処理的にはまさにv12がやっていたこと)

やってないと思う 直でproxyからURLにアクセスしてる

image

syuilo commented 1 year ago

リモートのカスタム絵文字のパフォーマンスについては、CDNでキャッシュするか、それができない場合はリモートのものも直URLリクエストするようにする

それができない場合はリモートのものも直URLリクエストするようにする

これはやめるってこと？

プロキシ通しても画像を直接返せば負荷的にv12と変わらないということが分かったからやめるかも

syuilo commented 1 year ago

(「プロキシから絵文字画像が返ってくる」は処理的にはまさにv12がやっていたこと)

やってないと思う 直でproxyからURLにアクセスしてる

image

直で「proxyからURLにアクセスしてる」ということは「プロキシから絵文字画像が返ってくる」と同じ

SanMurakami commented 1 year ago

プロキシ通しても画像を直接返せば負荷的にv12と変わらないということが分かったからやめるかも

それならそれでもいいけど、それやるならMediaProxy公式で作ってほしい もちろんユーザーアバター、絵文字、リモートファイルに対応したものを

SanMurakami commented 1 year ago

直で「proxyからURLにアクセスしてる」ということは「プロキシから絵文字画像が返ってくる」と同じ

コメントした後に編集が入ってたのに気付いた

↓最初のこれに対して言っていた

(「プロキシに絵文字名を投げると絵文字画像が返ってくる」は処理的にはまさにv12がやっていたこと)

syuilo commented 1 year ago

v12と本質的には一緒だからこの変更をすることによってMediaProxyの必要性が増すわけではないと思うけど、MediaProxyやりたいはやりたい

tamaina commented 1 year ago

MediaProxy公式で作ってほしい

これをやるとしたら（やったほうがいいと思うけど）、/emoji.webpとしてデータベースと密結合してぶら下げた状態ではMediaProxyに切り分けることができない

syuilo commented 1 year ago

脱線するけどONLY_SERVER / ONLY_QUEUE みたいに ONLY_PROXY オプション作れば解決かしら

syuilo commented 1 year ago

MediaProxy公式で作ってほしい

これをやるとしたら（やったほうがいいと思うけど）、/emoji.webpとしてデータベースと密結合してぶら下げた状態ではMediaProxyに切り分けることができない

まあこれはアバターとかも言えるね

syuilo commented 1 year ago

MediaProxyってデータベースに関与できない縛りあるのかな

SanMurakami commented 1 year ago

/emoji.webpとしてデータベースと密結合してぶら下げた状態ではMediaProxyに切り分けることができない

外部プロキシに投げると言う形であればDDoSされてもそこが落ちるだけでサービスの根幹には影響しないので /emoji/emoji@remote-instance.example や /avatar/user@remote-instance.exampleみたいな形式で投げても良さそう

tamaina commented 1 year ago

MediaProxyってデータベースに関与できない縛りあるのかな

ん〜〜、なんとなく個人的にデータベースと切り離したいんだよね

syuilo commented 1 year ago

MediaProxyがDBと繋がってるとDDoSされた時にDBが死にそう

tamaina commented 1 year ago

DDoSされた時にDBが死にそう

リードレプリカで良くね（リードレプリカが死ぬんだけど）

syuilo commented 1 year ago

DDoSされたらDBが死ぬというのは全てのエンドポイントにおいて言えることだった

tamaina commented 1 year ago

脱線するけどONLY_SERVER / ONLY_QUEUE みたいに ONLY_PROXY オプション作れば解決かしら

MediaProxyとしてドメインを分けた時の挙動がどうなるのという感じがしており

tamaina commented 1 year ago

/emoji.webpとしてデータベースと密結合してぶら下げた状態ではMediaProxyに切り分けることができない https://github.com/misskey-dev/misskey/issues/9721#issuecomment-1404823398

訂正: できんことはないが私が個人的に実装するならデータベースと接続させない

tamaina commented 1 year ago

MediaProxyとしてドメインを分けた時の挙動

というかもしドメインを分けずに動かす場合、ディレクトリごとにnginxとかでサーバー宛先を仕分け……るなら別にONLY_PROXYオプションというか、そもそも別個のMediaProxyなんて必要ないんだな

SanMurakami commented 1 year ago

というかもしドメインを分けずに動かす場合、ディレクトリごとにnginxとかでサーバー宛先を仕分け……るなら別に

DDoSされたらNginx落ちるけど

SanMurakami commented 1 year ago

これはあくまで提案なんだけど、こう言う形式にできないの？

[絵文字の場合] 外部プロキシを使わない場合: https://misskey.io/emoji/emoji@remote-instance.example 外部プロキシを使う場合: https://proxy.misskey.io/emoji/emoji@remote-instance.example

[ユーザーアバターの場合] 外部プロキシを使わない場合: https://misskey.io/emoji/emoji@remote-instance.example 外部プロキシを使う場合: https://proxy.misskey.io/emoji/emoji@remote-instance.example

[リモートファイルの場合] 外部プロキシを使わない場合: https://example.com/example.png 外部プロキシを使う場合: https://proxy.misskey.io/file?url=https%3A%2F%2Fexample.com%2Fexample.png

もちろん全て直接ファイルを返す前提で