リアルタイム更新時のノートのデータをCDNにキャッシュできるようにするオプション

[kakkokari-gtyih]

Summary

特定のフラグ付きでWebSocket Channelに接続すると

• WebSocket経由では、公開ノート（公開範囲がpublic/homeかつログイン制限などがないもの）についてはノートの部分的なデータ（リアクション・pollなどのリアルタイム性のあるデータとnoteId）しか流れてこないように
• WebSocketでノートが来たらノートのデータをAPIからGETで取得して（←ここでCDNやブラウザキャッシュが効く）、WSのデータと突合する

というような仕様になるモードを用意する

Purpose

いままでWebsocketにてリアルタイムにノートのすべての情報を対象のユーザーすべてにブロードキャストしていた。つまり「ノートの投稿数 * ノートの情報量 * WSで購読しているユーザー数」分の通信量と処理負荷がサーバーにかかっていることになる。

これをIDのみ渡し実体の取得をCDNのキャッシュに委譲することでWebsocketでの通信量およびサーバー負荷を削減する。

TLでリアルタイムに取得する投稿は大部分がパブリックの投稿であるため、それなりの通信、処理負荷の削減が見込まれると考えられる。(サーバーの処理は「ノートの投稿数 * ID情報 * WSで購読しているユーザー数 + CDNにキャッシュされる前の最初の1回のリクエストへの応答)」になる)

ノートの実体についてはCDNでキャッシュすることで本体サーバーの処理をノートごとに1回にする。CDNにキャッシュされたあとは、当然ながらCDNのキャッシュから返却されるようになるため本体サーバーの(通信/処理)負荷にはならない。

上記の問題点として、限定公開投稿の権限管理をサーバー側でしているため限定公開投稿はCDNでキャッシュできないことである。
そちらの対策として、限定公開投稿はWebsocketで受け渡す方式とする（既存実装と同等）。
またCache-Controlを制御することで意図せずCDN側でキャッシュされることを防ぐ対策を行う。

MisskeyIO#834

Additional Info

• CloudflareのCache Rulesを前提にするなら、キャッシュさせるノートデータを取得する専用のエンドポイントを持たせたほうがCache Rulesの設定がしやすそう（それこそioの実装どおりhttps://host/notes/xxxyyyzzz.jsonとか）
• キャッシュさせたくないノートはその全体をWSで流すのではなく、単純に{ id: 'xxxyyyzzz', vary: true }とかをWSで送ったうえでepをnotes/showのPOSTに切り替えるほうが単純かも

Do you want to implement this feature yourself?

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

[syuilo]

• キャッシュできる情報は限られる
• クライアントの視点に立つとノートごとに追加のHTTPリクエストが発生する

からパフォーマンス的な恩恵は大きくはない気はするわね
とにかくサーバー側の通信量さえ減らせれば良いというユースケースでは効果はありそう

[kakkokari-gtyih]

それはそうなのでオプションで有効にできる形（オプトイン）で実装すると良いんじゃないかなと思ったりしている
（こういうのって、大規模サーバーでは恩恵が大きいが中小規模ならそうでもない系の機能なので）

[syuilo]

「負荷やクライアントの通信量が増えても良いからサーバーの通信量を削減したいケース」がどれくらいあるかによるわね

[kakkokari-gtyih]

負荷

どこで負荷が増えそう？

[syuilo]

HTTPリクエストを送ったり送られてきたりする負荷かしら

[kakkokari-gtyih]

• クライアントが送る方についてはそれはそう（「負荷やクライアントの通信量が増えても良いからサーバーの通信量を削減したいケース」）
  • ただしクライアントからのHTTPリクエストについてもブラウザキャッシュが効くので実際はたいしたことないかも
• サーバーからのレスポンスについては、CDN等にキャッシュさせることが前提の機能なのでキャッシュされないはじめの数回だけで済みそう（CDN等を用意していないサーバーはこの機能を使わなければいいだけ）

[syuilo]

そのような負荷が増えることよりも通信量が減るメリットを優先したいサーバーがどれくらいあるのかという話だわね

[kakkokari-gtyih]

需要調査がむずかしいわね
（サーバー負荷の軽減にはなりそうだけどクライアント側の負担が大きくなる…）

とはいえ今のところioのクライアントがこの変更の影響で極端に重くなったかと言われればそんなことはない気がする（体感）

[syuilo]

投稿がされるごとに最初の数回リクエストが飛んでくるだけでも投稿数が多いと無視できない負荷になる

[kakkokari-gtyih]

Cloudflareの場合はいい感じにキャッシュが当たるように遅延が入るようになっているらしい

MisskeyIO#834 (comment)
MisskeyIO#834 (comment)
https://developers.cloudflare.com/cache/concepts/revalidation/#example-2

[syuilo]

サーバーの負荷軽減になるかどうかはよくわからないわね

[syuilo]

(「負荷」はCPUやメモリ使用率のことを指してる)

[kakkokari-gtyih]

サーバーの負荷軽減になるかどうかはよくわからないわね

後日ioに効果があったかどうか聞いてみるとか

[syuilo]

あとクライアントは重さもそうだけど通信量増加のインパクトがどれくらいあるかも気になる

[syuilo]

結構ｷﾞｶﾞを気にする人が多い印象

[kakkokari-gtyih]

通信量増加のインパクト

もともとWSで来ていたデータが（リアルタイム性のある部分が一部重複が発生するとはいえ）HTTP経由になるだけなのでいきなり2倍になるとかは無いとは思う
それか、「一部重複が発生する」部分をWSで取る前提でCDN用データから抜いておくか（抜けが発生しそうで怖いのでそこまでしなくても）

[syuilo]

HTTPはペイロード以外にもデータが結構ある印象

[syuilo]

重複を考えたら最悪2倍くらいになってもおかしくはないと思う

[kakkokari-gtyih]

サーバーの負荷軽減になるかどうかはよくわからないわね

後日ioに効果があったかどうか聞いてみるとか

これできるなら参考になりそう