URLプレビューとメディアプロキシの瞬間的な負荷を抑える

[samunohito]

Summary

ユーザがURLつきのノートを投稿した際、瞬間的にマシンリソースを圧迫するというお話を聞き、軽く調査検証して問題がありそうなので起票しました。

URLつきのノートが投稿された後、以下のような流れで処理が呼ばれます。

1. あるユーザがURLつきノートを投稿する
2. 別ユーザ（複数人）のTLにノートが配信される
3. 別ユーザ（複数人）のクライアントがノートをレンダリングするためにURLプレビュー生成要求を投げる
4. URLプレビューの生成
5. URLプレビューの生成結果からサムネイルなどのURLを取得し、メディアプロキシに取得要求を投げる
6. 外部リソースの取得と加工処理

という流れのうち、4と6はそれなりにマシンリソースを使う処理です（外部アクセスと画像加工）。
これがTL表示中の複数ユーザーからのリクエストで同時多発的に走り、マシンリソースを圧迫する状態になっています。

上記を軽減するため、以下の施策を考えています。

• Redisによるlock処理で4または6をそれぞれ排他化（URL単位で）
• lockの獲得に成功した場合、4または6の処理を行い、結果をRedisにキャッシュ
• lockの獲得前で待ち合わせていた後続の要求はキャッシュの値を読みだしてフロント側に返す

Purpose

マシンリソース圧迫の軽減

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[syuilo]

こういうのCDNが良い感じにしてくれないものなのかしら

[tamaina]

nginxを設定しておけば万事OK

[samunohito]

nginxを設定しておけば

キャッシュが出来る前にいっぱいリクエストが来たら…というシチュエーションでもよしなに制御して何とかしてくれるものですかね？

[kakkokari-gtyih]

nginxを設定しておけば万事OK

このへんの知見もここに書き足しておけばよさそう（内容見た感じ、すでに書いてある？）

https://misskey-hub.net/ja/docs/for-admin/install/resources/nginx/

[samunohito]

proxy_cache_lock
proxy_cache_use_stale

この2つを設定すれば、まさしくよしなにしてくれることが分かった

[tamaina]

proxy_cache_lock

proxy_cache_use_stale

この2つを設定すれば、まさしくよしなにしてくれることが分かった

exactly

[samunohito]

@syuilo
「Misskey本体として冒頭の記載の対応する予定はなく、nginx等の機能を利用して制御してほしい」
…が回答になります？

[syuilo]

こういう系はアプリケーションレイヤーではなくそれより前段のレイヤーでケアする話だと思うのと、対応する場合URLプレビューとメディアプロキシ以外にも似たような問題が発生する箇所ありそうだからロック処理だらけになりそうということでyes