コーポレートサイトがメモリを無限に食べていたので修正した話

まえがき

この記事は VR法人HIKKY Advent Calendar 2024 の 3 日目の記事です。

前日は シングルトンアンチのためのUnityにおけるオブジェクト共有方法 、明日は @kazu0617 さんが何か書きます。

Webチームの飛び道具担当を自称している called_D という者です。つい一ヶ月ほど前に公開されたコーポレートサイト（リニューアル）についての記事を書きたいと思います。この記事で取り扱うのはメモリリークについて。

(作者近影)

要約

• SPA のページ遷移の都合で、要素が作られて消えてを繰り返すことで状態が悪化する
• きちんとリソースを開放しよう。JavaScriptだからといって全部がGCの対象ではない
  • ライブラリが提供している開放操作がある。使い勝手が悪くても泣かない
    • Three.js なら dispose()
    • lottie なら destroy()
• メモリリークのデバッグの仕方

初回: ライブラリの提供する関数とキャプチャされた変数について

Vket 2024 Summer が終わってすぐの 8 月初旬、コーポレートサイトリニューアル作業中のチームメンバーから「メモリ消費量が下がらない」と相談を受けて対処しました。

NOTE: タブごと¹の消費メモリはメニューから「その他のツール」→「タスク マネージャ」で見れます。

症状は「サイトのヘッダーから各ページを行き来するとサイトのメモリ消費量が増え続ける」というもの。夏の Vket が終わって精神力が尽きていたので、思考停止でも進められる " 二分**コメントアウト**探索 " でざっくり問題の箇所を特定します。

このときの開放漏れは共通レイアウトに書かれたサイトフッターのコンポーネント内で、Three.js で読み込んでいた 3D モデルでした。

タブのメモリと SPA

ところで HIKKY ではフロントエンドのフレームワークに Nuxt を採用しており、このサイトは SSR（サーバーサイドレンダリング）モードで動作しています。Nuxt や Next の SSR は最初のレンダリング²こそサーバーで行いますが、その後ブラウザ側で「ページ遷移」が起きるときの動作は SPA（シングルページアプリケーション）と同等なので同じように考えてよいです。

すなわち、通常の Web ページと異なり「ページ遷移」で js の世界はリセットされません。GC から漏れたリソースは同一アプリケーションのページ内を回遊するかぎり開放されずそのまま積み重なっていきます。

（Vue / Nuxt ではコンポーネントの onBeforeUnmount() フックでリソースの開放処理を行うのがよいと思われます。大体はそれで事足りるはず）

js でしょ？　GC されるんじゃないの？

ページ遷移のたびにフッターのコンポーネントは unmount され消えているので、直感的にはそこに紐づく変数も参照されなくなりガベージコレクションで消えるように思われます。ところが、内部で自前でリソースを管理³しているような、ある種のライブラリはライブラリ側が提供する操作を用いないとメモリが開放されないパターンがあります。

Three.js はマニュアルにリソースの開放についてのページがあります。ところでこれ Getting Started じゃなくて Next Steps の中なので、普通に 3D モデルが描画できてそこで満足してたら読み飛ばすのでは……？

フッターのコンポーネントを書いた同僚氏は Three.js の dispose() を書いていなかったので、さくっと書いて解決！⁴

GC されない（変数への参照が生き残っている？）

……解決しませんでした。そんなー。

当時のメモ:
最終的にこの行コメントアウトすればリークしないのは分かったけどそっから先が一番重要なんだわ……。

イベントリスナーの宣言の階層がずれていて undefined を代入しそびれていたのを直したり、変数をクロージャの外に移したり、この関数のスタック無限に伸び続けていない？　というのを色々直してどうにか修正しました。

キャプチャで 3D モデルの変数への参照が残っていて云々だとは思うのですが、きちんと原理を説明できるまでの検証をできていません。腑に落ちないまま他のタスクに移りました。

そして二ヶ月半が経ち……。

第二: リリース数日前のメモリリーク

すみません。
品管チームから下記連絡をいただいて、共有です！

サイトのtopからMISSION~RECRUITのいずれかに移動→hikkyのロゴを押しTOPページに戻るを繰り返すとサイトのメモリ使用率がどんどん上がる事を確認しました。
こちらサイト側の処理で何か起きている物とおもわれますので念のためご確認をお願いします。

品管チームってメモリ使用量とかも見てくださるんだ…すごい…

called_D メモリリーク！　殺したはずでは！？

メモリリークが再発していることが、リリース前の QA 期間に発覚しました。ローカルで試したところ、サイトトップと子ページを行き来⁵することできちんと再現することが確認できました。

（前よりひどくなってる……）

Firefox Developer Edition⁶ でサイトを開き、メモリツール でメモリのスナップショットを撮って中身を見ます。

Three.js の dispose() は全部一括で開放してくれるインターフェイスを持たない

ドミネータービュー で確認すると、 scene から参照されている何かが。

前回から変更されていて、scene が直接持っているものはあまり多くないためいくつかコメントアウトして挙動を確認し、結果、新しく追加された環境マッピングの dispose() 呼び出しが漏れているため対処しました。

（環境マップ。3Dモデルの表面に写っている光沢、ライトの形状）

（Three.js の dispose() は「ある種のリソースには dispose() 関数があるから都度呼んでね」という方式なので、存在を認識していないと容易に呼び漏れるなぁ、と）

もう一人の実行犯⁷、Lottie

上記修正を加えてもまだ軽減されるだけで解決しなかったため、調査を進めます。

参照ツリーに scene が含まれるものは増殖しなくなったのですが、**UNKNOWN SLOT 1** を含む（つまり、参照関係が上記とは別の）オブジェクトが開放されずに残っているようです。

（mCallback って変数 Three.js には居ないぞ……？）

情報が足りないので「コールスタックを記録」のチェックを入れて再度計測します（これはスナップショットを取得する直前に入れてもだめで、メモリが確保される実際の操作の前に ON にしておきます）

ちなみにコールスタックの記録はだいぶ計測自体が重たいです。再現するために必要な操作が複雑だったりするときは、これなしで当たりが付けられるならOFFのほうがストレスが少ないと思います。

表示: ドミネーター、ラベル: Call Stack で表示します

アニメーションライブラリの Lottie が原因のようだ、と分かったので開放操作を調べます⁸

lottie.destroy() -- To destroy and release resources. The DOM element will be emptied.

lottie.destroy() を onBeforeUnmount で呼んで解消です。

called_D lottie まで直してトップページと、ヘッダーメニューに乗ってる各ページ往復で計14回ページ遷移すると、消費メモリが470MB近辺⁹に落ち着く認識
（Firefox）

400MB台まで下がっておりました!!!!!!!!!!!(下層->TOPを20回検証)
動かなくなっているLottieなども見られませんでした！
 

まとめ

こうして再度書いてみると

• コメントアウトして調べる
• メモリツールで調べる
• 参照を掴んでいそうな部分を片っ端から書き換える
• メモリツールでコールスタックを出して調べる

と複数の手法を使ったこと、開発者ツールのメモリツールが問題の特定に役に立ったことがよく見て取れます。

ライブラリによっては独自のリソースの開放の作法があり、呼び忘れると参照が失われた後も GC の対象とならず生きていることが直接的な原因でしたが、本来ならページ遷移のタイミングでリセットされるものが SPA の性質により開放されないことで、結果的にギガバイト単位でタブの消費メモリが膨れることになりました。

PC からの閲覧ならともかく、スマートフォンからの閲覧の場合タブごとクラッシュするはずなので、サイトリリース前にこれを修正できなかったらと考えると怖いですね。

こぼれ話

• コーポレートサイト公開と前後して lottie-player に暗号資産を窃取しようとする悪意あるコードが追加されていました。これは肝が冷えた

called_D コーポレートサイトで使用しているのは lottie-web パッケージであり、今回の @lottiefiles/lottie-player ではないため対象外です
https://x.com/LottieFiles/status/1851848602093777273

• コメントアウトで部分部分で切り分けていくアプローチとは異なり、git bisect と Puppeteer を使って時間方向で切り分けていくアプローチも考えられます
• Webデザインの参考サイト SANKOU! に掲載されました。自薦・他薦を受け付けていないらしいのでリニューアル当日・翌日とかでどうやって把握してるんでしょうか……？

1. 実際にはプロセス単位での使用量を見ることになる。Spectre脆弱性への対策によりサイトごとにプロセスが分離されるので、各サイトのリソース消費がまとまる挙動となる
   ↩

2. 3D 用語の、画面を描画する「レンダリング」と異なり、単に HTML を組み立てて返すことをいう ↩

3. Three.js の場合、おそらく WebGL とデータをやり取りする都合でそのような構造になっているのだと思います ↩

4. 実際には全部のリソースを把握して dispose() を呼ぶのは書くプログラマ側の負担が大きいので、シーンで利用しているものを再帰的に辿って dispose() 関数があれば呼び出すようなヘルパー関数を使います https://discourse.threejs.org/t/when-to-dispose-how-to-completely-clean-up-a-three-js-scene/1549/11 ↩

5. サイトロゴとサイトヘッダーの各ページをクリックし往復、計14回のページ遷移 ↩

6. こっちのほうが Chrome よりメモリツールが見やすかったので ↩

7. 「指示役」は開放操作を呼んでないプログラマなのでここでは実行犯と表現しています ↩

8. https://stackoverflow.com/questions/69567046/memory-leak-in-lottie-web とか ↩

9. ブラウザ上でメタバース動かすならともかく、コーポレートサイトで消費メモリ 0.5GB ってどうなの、という思いはあります ↩