CMS サーバーと公開サーバーを分ける場合に留意すべき事項

セキュリティその他の観点から、CMS サーバーと公開サーバーを分けることがあります。その場合、html ファイルや画像ファイルなど静的なファイルであれば、PowerCMS の同期機能 や rsync その他、何らかの方法で公開サーバーに送ればよいのですが、検索機能やお問い合わせフォーム、会員サイト、DynamicMTML などの機能については PowerCMS アプリケーションが処理する必要があります。

その場合、構成について考えられるパターンとしては次のようなものがあります。各パターンのメリットとデメリットを理解して選択するようにしてください。

CDN を使ってコンテンツを配信する構成の場合、CDN イコール公開サーバーと考えられるので、その場合も同様の考え方になります。

外部サービスを利用する

動的な機能については PowerCMS を利用せず外部サービスをコンテンツに組み込む、というのは最も端的かつ確実な対応方法です。専用の機能を提供しており、実績のあるサービスを使うことになるので、それなりに選択する理由があります。「公開サーバーにアプリケーションを設置してはならない」という要件がある場合にも有効です。

公開サーバーにも PowerCMS を設置する

公開サーバー側にも PowerCMS をセットアップするのも分かりやすい解決方法のひとつです。この場合、公開サーバーに設置した PowerCMS では、CMS サーバーのデータベースを参照するように設定することで、CMS サーバーで処理する場合と同等の動作になります。公開サーバー側で管理画面にサインインする必要はないでしょうから、管理画面を提供する mt.cgi その他、不要なファイルは設置しないようにします。

注意すべき点として、CMS サーバーと公開サーバーの両方で PowerCMS を利用するので、ライセンスが２つ必要になります。また、「公開サーバーにアプリケーションを設置してはならない」という要件がある場合には選択できません。

• ステージング機能を利用しているとき、公開サーバ側で PowerCMS のモジュールを設置します。この場合、ライセンスは台数分必要ですか？

CMS サーバーのデータベースを参照する場合、動的機能に対して CMS サーバーで行った変更が即時に公開コンテンツに反映される可能性がある点にも留意しなければなりません。テンプレートなど、できるだけ静的に出力したファイルをインクルードする構成にしておくなどの工夫が必要です。

CDN を使ってコンテンツを配信する場合、この方法は選択できません。

リバースプロキシで CMS サーバーに渡す

例えば http://example.com/search/ にリクエストがあった場合はそのまま CMS サーバーに渡して処理させる、という構成にすれば、公開サーバーにアプリケーションを設置する必要はなく、またライセンスも CMS サーバー分のひとつで済みます。

この場合でも、動的機能に対して CMS サーバーで行った変更が即時に公開コンテンツに反映される可能性がある点には留意する必要があります。また、CMS サーバーひとつで運用と公開の両方の機能を果たすことになるため、余裕をもったスペックを選択するか、局地的なアクセス増が発生することがわかっている場合にはスペックを変更できるようなインフラを利用するのがよいでしょう。