perf(timeline): Optimizing for CDN Caching

[tar-bin]

What

こちらの実装を行った。

公開投稿(public, home)について

• 通常ユーザーについてはchannelのidOnlyフラグをtrueで渡すため以下の動作をする
• Websocket：note.id と idOnly フラグのみ返し、prependで /notes/:note.json を呼び出す
• /notes/:note.json：Cache-Control: public を返し、CDNにキャッシュさせる

限定公開投稿(followers)について (※specifiedは基本的にTLに表示されないため今回の主な対象ではない)

• Websocket：noteの情報をすべて返す(既存の実装と同等)

モデレーター権限をもつユーザーについて

• モデレーターについてはchannelのidOnlyフラグをfalseで渡すため以下の動作をする
• Websocket：noteの情報をすべて返す(既存の実装と同等)

Why

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

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

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

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

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

またシステム管理者およびモデレーターに関しては、非公開ロールなどパブリックな投稿に加えて管理者向けの非公開の情報が必要となるケースがあるため、パブリックも含めてすべての投稿を従来通りWebsocketで受け渡す方式とする。

Additional info (optional)

・画像内にある「投稿削除時にCloudflare APIでパスのキャッシュをクリアする」は別トピックであるため本PRには含めない

・Cloudflareのキャッシュルールで以下の設定の追加が必要。

データ削減試算(ioのケース)

前提：
・平均的なノートのサイズを 1kB ぐらいと仮定する
・idのみの通信サイズは45 バイトなので、おおよそ20分の1ぐらいになるとする
・現在5000人がオンライン、デッキモードの利用を含め平均2TLを見ているとする。
・1投稿すると両TLにに表示される場合を考える。
・1日あたり30万投稿とする(チャートより)

対策前：
・1投稿がされると、5000人 * 2TL = 10000回Websocketで通信する
・1投稿あたり 1kB * 10000回 = 10MB
・1日あたり 10 MB * 300000投稿 = 3TB
・1か月あたり 3TB * 30 = 90TB

対策後：
・1投稿がされると、5000人 * 2TL = 10000回Websocketで通信する
・1投稿あたり 0.05kB * 10000+ 1kB * Edge ≒ 0.5MB (CDNのキャッシュのための通信量は誤差レベルなので無視する)
・1日あたり 0.5MB * 300000投稿 = 150GB
・1か月あたり 150GB * 30 = 4.5TB

結果：
・1か月あたり85.5TB分サーバー処理の削減(CDNでのキャッシュ活用)が見込めるかも
・平均的なノートのサイズ、オンライン数、一日当たりの投稿数、平均のTL数が増えればもっと増えます

Checklist

• Read the contribution guide

• Test working in a local environment

• (If needed) Add story of storybook

• (If needed) Update CHANGELOG.md

• (If possible) Add tests

[tar-bin]

ちょっとテストの結果はコメントに追記します。

[tar-bin]

※Public/Homeについては通常ユーザーのいずれかがcf-cache-status:がHITすることを確認する
※モデレーターの/api/note/showの通信が発生せずWebsocketのみで表示できていることを確認する

通常ユーザー1
・local (HIT)

・social (HIT)

・global (HIT)

・home (HIT)

・followers (API通信なし、表示OK)
・channel (HIT)

通常ユーザー2
・local (MISS)

・social (MISS)

・global (MISS)

・home (MISS)

・followers (API通信なし、表示OK)
・channel (MISS)

モデレーター
・local (API通信なし、表示OK)
・home (API通信なし、表示OK)
・social (API通信なし、表示OK)
・global (API通信なし、表示OK)
・followers (API通信なし、表示OK)
・channel (API通信なし、表示OK)

🆗 パブリック投稿は/api/notes/showが呼ばれ、2回目以降はHITしている
🆗 限定投稿はWSでデータ取得できている
🆗 モデレーターはパブリックも限定投稿もWSでデータ取得出来ている

[tar-bin]

Public/Home -> OK

Follower -> OK

Admin/Moderator -> OK

大丈夫そうです。

[riku6460]

WebSocket のメッセージの送信タイミングを適当に散らしてあげないとうまくキャッシュヒットしない予感（あるいは受け取り側で調整するか）

[tar-bin]

@riku6460

WebSocket のメッセージの送信タイミングを適当に散らしてあげないとうまくキャッシュヒットしない予感（あるいは受け取り側で調整するか）

こちらに関しては以前村上さんが検証ツールを作って試しましたが、CF側でいい感じにキャッシュヒットするように遅延してくれるみたいでした。

[riku6460]

@riku6460

WebSocket のメッセージの送信タイミングを適当に散らしてあげないとうまくキャッシュヒットしない予感（あるいは受け取り側で調整するか）

こちらに関しては以前村上さんが検証ツールを作って試しましたが、CF側でいい感じにキャッシュヒットするように遅延してくれるみたいでした。

一応調べてみましたがここにありましたね これなら問題なさそう
https://developers.cloudflare.com/cache/concepts/revalidation/#example-2

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
20.4% Duplication on New Code

See analysis details on SonarQube Cloud