静的ファイル再構築効率化「Shared Background Publishing」取得済み特許について

PowerCMS X ver.3.5に新たに追加された機能で先日のウェビナーでもご紹介した「Shared Background Publishing」についてこの記事で改めてご紹介します。

概要

• 特願2023-78784(査定済み) ※ 令和5年9月19日特許取得済み 特許番号 第7351469号
• 発明の名称 : テキストコンテンツ提供システム、テキストコンテンツ提供方法、コンピュータプログラム、およびウェブファイル
• 解決したい課題 : 安定的な静的ウェブサイト配信を実現するための再構築処理の最適化
• 一覧ページやトップページの再構築を遅延、まとめて行うことで効率化を図る仕組み

PowerCMS X(に限らず)一般的な静的ファイルを生成するタイプの CMSは個別のページや記事を更新(追加・更新・削除)するとトップページ、サイトマップなどをはじめ関連するページを同時に更新します。 トップページやサイトマップに限らず、例えば「カテゴリ別」「年度・月別」などのアーカイブなどの更新が必要なケースもあり、1ページの更新はすなわち複数のページ群を同時に更新する処理を伴うことになります。

あるいは「静的ファイルジェネレータ」などでは、個別ページを更新、追加などしたあと、サイト全体をビルド(再構築)しなおすような運用をする場合もあるでしょう。

ここで考えたいのが、複数のユーザー(あるいは単一ユーザーであっても)が複数のページを同時または逐次更新するようなケースです。

考え方と動作の仕組み

1記事を操作した時の処理です。記事詳細ページ以外にトップページ・カテゴリ・年度別・サイトマップといった複数の関連ページが同時に再構築されます。

続いて、多少の時間差(例えば2分とか3分の間)をおいて3人のユーザーが同じあるいは異なる記事を操作した時の処理です。このケースでは3記事の更新に対して各々5ページ、合計15ページが更新されます。このうち12ページは重複して3回ずつ更新されています。

Shared Background Publishingを有効化する

PowerCMS Xでは環境変数「shared_backgroud_publishing」に数値(秒)を指定します。ここでは仮に「120=2分」を指定したと仮定します。

この設定をしてページの操作を行うと、記事詳細ページがすぐに更新されるのに対して関連ページの更新はキューに保存され待機モードとなります。この時、CMSのプロセスは処理完了後120秒間は待機モードとなり残ります(キューを処理するのはスケジュールタスクではなく、このページの操作処理を行ったWebサーバーのプロセスとなります)。

続いて2人目のユーザーが別の(あるいは同一の)ページを操作します。

この時、ユーザーAのプロセスが作成した4ページ分のキューが待機状態だった場合、ユーザーBのプロセスがユーザーAのキューを「横取り」します。そして、再度120秒の待機状態となります。ユーザーAのプロセスはここで終了します。

3人目のユーザーがページの操作を行った時も同様に、ユーザーCのプロセスがユーザーBのキューを「横取り」します。そして、再度120秒の待機状態となります。ユーザーBのプロセスはここで終了します。

そして、次の更新がその間に行われなければ、キューが実行され各ページが更新されます。これによって、設定なしの場合の15ページに対して、設定後更新されるページが半分以下の 7HTMLとなります。

デメリットとその対策

このケースでは、ユーザーAがページを操作してからトップページやその他の関連ページが更新されるまでに「最大4分」の時間差が生じます。その間にページを見にきたユーザーは更新前の情報を見ることになります。

オンデマンド再構築の併用

そこで、リアルタイム性の問われるサイトでは、その対策として PowerCMS Xの「オンデマンド再構築」を併用します。オンデマンド再構築とは以下のような仕組みです。

• 関連ページへの更新処理が呼ばれた時、一旦静的HTMLページを削除する
• そのページへのリクエストがあったら、その時点でページを動的に生成(ダイナミック・パブリッシング)して、同時にページを保存する(この時、キューも破棄される)
• この間リクエストがなかったページについては、キューによって再構築される

キューに入れた状態でHTMLを削除して、オンデマンド待機状態となります。ファイルがない状態でリクエストがあれば、動的生成をその時点で行い(つまりキューを実行する)、キューを削除するという仕組みで常に最新の情報を返すようにする、ということです。

この設定が有効と考えられるケース

以下のようなケースでは、この設定のメリットが大きいと考えられます。

• 再構築トリガーの数が多い環境
• 頻繁に更新がかかるメディアサイトなど
• AWSの Cloud Front などを利用していてリアルタイムの更新が前提ではないウェブサイト
• CPU使用率が料金に影響する環境(AWSのバーストパフォーマンスインスタンスなど)

設定方法

前提として、ページが存在しない場合に .htaccessなどによって pt-view.php へリクエストが渡っていることが必要です(オンデマンド再構築が不要な場合はその必要はありません)。

環境変数に以下を指定します。

    "shared_background_publishing": 120,
    "enable_on_demand": true,

その他詳細についてはサポートにお問い合わせください。

カテゴリー：技術情報

投稿者：Junnama Noda