よく訓練されたカレンダー職人、たじま（１年ぶり４回目）です。
今日は大規模サイトを構築する際に表面化しやすい Movable Type の管理画面のパフォーマンス問題について書いてみたいと思います。

この記事は Movable Type Advent Calendar 2024 17日目の記事です。

いつの間にか遅くなる？

Movable Type を使ってサイトを構築したあと、やんわりと感じることはないでしょうか？

「インストールしたての頃はあんなサクサクだったのに…」

一度作成したコンテンツは基本的に削除されることはなく、データベースは大きくなり、データベースへのアクセスや、読み込むファイルの数も増えていきます。少しのコンテンツを追加しただけでは小さな負荷であっても、これらは時間の経過とともに、積み重なるように増えていき、いつか体感で気づくほどになってしまいます。

これはデータを管理するどのアプリケーションでも起こる話なのです…が！

では Movable Type を長期的に運用する際、管理画面のパフォーマンスを快適に保つため、どういったことに気を付けるべきでしょうか？
増え続けるデータのうち、管理画面のパフォーマンスに多くの影響を与えるのは、どのデータであるのか、これまでも経験則的に感じていた部分ではあるのですが、手っ取り早く一言でまとめますと…

コンテンツフィールドの使いすぎはほどほどに…

…となります。

「知ってた」

という声も聞こえそうですが(汗)。今回このコンテンツフィールドついて、少し深堀りしてお伝えしつつ、多種大量のコンテンツを管理する Movable Type の管理画面を極力快適に使用するために開発したプラグインを公開します。

なお、たまにログインが遅いようなケースではまずは前記事「MTのログインがたまに遅い話」を見ていただくといいかもしれません。

コンテンツフィールドとパフォーマンスの関係

カスタムフィールドもコンテンツフィールドも、実のところデータとしては似たような構造になっています。もちろん細部を見ると違うところは多いのですが、フィールドの設計としては似ています。

カスタムフィールド登場時には、データ操作のためのDBアクセスが増えてしまったため、これが負荷に直結するものとして、作りすぎに気を付ける傾向がありました。
しかしながら、カスタムフィールドについては、バージョンアップを重ね、DBアクセスの最適化が進められたことに加え、PSGI対応が行われ、フィールド定義が適切にキャッシュできるようになったことから、そこまで気にするものではなくなりました。

コンテンツフィールドについても、同様の問題が発生しています。ただ、それであれば、カスタムフィールド同様に、そこまで気にするものではないといえるのですが、コンテンツフィールドは、カスタムフィールドと根本的に違う要素があります。

ユーザーの「権限」です。コンテンツフィールドは、権限管理されているのです。

それでは Movable Type 8 のドキュメント「ユーザーの権限とロールの概要」を見てみましょう。

「コンテンツタイプごとの権限」の説明に「XXX フィールドの編集」と書いてありますね。

試しにコンテンツタイプのサンプルサイトとしてシックス・アパートさんが公開しているテーマ「Jungfrau」でサイトを１つ作成したあとの「ロールの編集」画面のキャプチャを添付します。（でっかいのでサムネイルは貼りません…）

「ロールの編集」画面
おわかりいただけただろうか…

そうなんです。増えたチェックボックスの数だけ、管理画面の裏側では権限チェックの量が増えるのです。

サイト設計への影響は？

では、コンテンツタイプを活用したサイト設計が一般的になりつつある現在、この問題にどのように対処すべきでしょうか？

実は4年前、このブログでコルシス桐田さんも書かれています。

ただ大規模サイトの場合はこれまで通りお知らせ系はブログ記事、固定ページはウェブページで構築した方が良いのでは無いかと考えています。（少なくとも現時点では）
理由は以下の通りです。
コンテンツタイプの数を増やすほど、ロール設定の数が増え、権限設計も複雑になり、そしてロールを有効にすると管理画面の遷移速度にも影響する。

この記事から4年経ち、Movable Type のアップデートも進み、着々と改善も進んでいます。
開発元のシックス・アパートさんも認識されており、先日開催されました MTDDC Meetup TOKYO 2024 のトークセッションでも次のように話されていたようです。

コンテンツタイプは作りすぎると管理画面のパフォーマンスが低下することがあるので、今後はコンテンツタイプのパフォーマンス改善も進めていく

権限がからむため慎重に進めるべき部分ではありますが、実際、バージョンを重ねるごとに、着々と改善されています。

そのためこの問題について現在は

(今後のアップデートを注視しつつ)
現状困らないように気を付けてサイト設計しましょう

というスタンスが我々制作サイドとしてはよさそうです。
設計段階で似たようなフィールド構成のデータを１つのコンテンツタイプにまとめることが可能か検討してみる…ような対応はアリかと思います。

…が！

「作りすぎちゃった私はどうすれば…？」

今そこにある問題にどう対処すべきか…悩ましい問題です。

作りすぎたコンテンツフィールドへの対処法

先日相談いただいたケースですが、４ケタのコンテンツフィールドが作成されていて、目に見えてもっさりとした動作になってしまっていました。
１つ目のサイトをベースに、同様のサイトを複数同時に増やしたところ、一気に遅くなったとのことで、じわじわ遅くなったわけではなく、一気に我慢の限界を超えてしまったようです。

さすがに、構築後に「コンテンツタイプをまとめましょう」「サイトをまとめましょう」みたいな話は難しいわけで、こういった如何ともし難いケースに対応すべく、現状自分で気づいた改善要素を反映するプラグインを用意してみました。

エンジニアの方に向けてこのプラグインがどのような対応を行っているか軽く説明します。
執筆時点で配布しているバージョン0.32では次の３つの対応を含んでいます。

• コンテンツタイプに付与された全権限を返すメソッドのキャッシュ
• 権限の配列を返すメソッドのキャッシュ
• 「ロールの編集」画面のループ改善

１つめについては、コンテンツフィールドの増加で重くなる処理がリクエストまでに複数回呼び出されるためキャッシュしています。MT8.1.0 にて同等の処理が実装されているため、MT8.1.0未満で適用されます。なお、キャッシュはレスポンス送信後破棄されます。

２つめについては、管理画面のテンプレートを読み込むたびに、表示制御を行うため権限の配列をデフォルトで適用しているのですが、こちらもコンテンツフィールドの増加で重くなるうえに、読み込んだすべてのテンプレートに同じ処理を行うため、キャッシュしています。こちらもレスポンス送信後破棄します。

３つめについては、「ロールの編集」画面なのですが、非効率なテンプレートのループが行われていることと、そのループ内で比較的負荷の高い test モディファイアが使用されているために、コンテンツフィールドの増加によって過剰に重くなる現象を改善しています。こちらは MT8.4.0 で改善されていますので、今後のバージョンではプラグイン側のコードを無効化する予定です。

今後新たな対策が見つかった場合にはフィードバックをあげつつプラグインにも反映し、Movable Type のアップデートによって対策されたものについては、バージョンを見て無効化するような対応を行っていければと考えています。

なお、このプラグインは、外部（たじま）が開発したプラグインであり、動作についての一切の保証・サポートはありません。必ず自己責任にてご使用いただくようお願いします。