Staging Best Practices for DXP

この記事では、管理者がサイトでステージングを使用する準備をするときや、すでにあるステージングインフラを管理するときに注意すべきことをまとめています。

解決

ステージングの使用を計画する場合、最初に決定する必要があるのは、 ローカルライブ を有効にするか、 リモートライブ のステージングを有効にするかということです。

その判断のために、以下の情報をご検討ください：

ローカルステージングとリモートステージング

ローカルステージング：

ステージングサイトとライブサイトの両方が同じサーバーでホストされています。この機能を有効にすると、Liferayプラットフォームは、ページと選択したポートレットデータを公開することで、ポータル内に同じ隠しサイトを作成します。クローン化されたサイトはステージング環境となり、元のサイトはライブ環境となります。
ローカルライブステージングでは、ネットワークトラフィックがないため、サイトの変更を素早く公開することができます。しかし、ステージングされたコンテンツは制作コンテンツと同じデータベースに保存されているため、サーバーにはより多くのリソースが必要となります。
ローカルステージングを有効にしたときに、サイトがすでに多くのデータを持っている場合、そのクローンを作成するには時間がかかり、リソースを必要とする操作になることがあります。また、リモートライブステージングのようにデータのバックアップも万全ではありません。

リモートステージング：

ライブサイトは、全く異なるLiferayインスタンス/サーバー上にあります。有効にすると、Liferay プラットフォームは、ネットワークを介して 2 つのサイト間の接続を確立します。リモートサーバー上のサイトがライブ環境になり、現在のサイトがステージング環境になります。
リモートライブステージングでは、データがより分離されているため、アセットの区別や管理が容易になります。また、新しいバージョンのアプリやコンテンツは別のサーバーにあるため、ライブ環境に干渉する心配なく、ステージング環境にデプロイすることができます。ただし、リモートライブの場合、データをネットワーク経由で転送する必要があるため、ローカルライブよりも公開が遅くなります。
別のステージングサーバーを実行するためには、より多くのハードウェアも必要になります。

ハードウェアの最適化

ステージングを使い始める前にハードウェアのことを考えておくべきです。

ネットワーク速度：

リモートステージング環境では、ネットワークは考慮すべき重要な要素となります。膨大な量のデータ、たくさんの画像、大きな動画を公開する場合は、ネットワークを介してプッシュする必要があることを認識しておく必要があります。このため、リモートサーバーをサブネットワークの外に配置すると、公開速度に悪影響を及ぼす可能性があります。

ドキュメントの読み取り/書き込み速度：

例えば、大量の画像を使用する場合は、Liferayが非常に高速に画像を読み書きできることを確認する必要があります。これはローカルファイルシステムにも当てはまりますが、特にドキュメントにリモートでアクセスする外部リポジトリに当てはまります。

CPUの速度：

大量のWebコンテンツを公開している場合、それはディスクやネットワークを集中的に使用する操作ではありませんが、このユースケースでは記事の実際の文字列データが処理されるため、CPUがタスクに対応していることを確認する必要がありますその場で更新されます。たとえば、埋め込みデータへのすべてのリンクと参照は、ライブ環境での場所に応じて変更する必要があります。

お客様のニーズに最適なハードウェアとステージング構成を実現するためには、さまざまなシナリオで多くのテストを行うことを強くお勧めします。

ステージングをオンにする前に、ステージングしたいポートレットを決める

ステージングを有効にする場合は、ステージングするコンテンツの種類を選択する必要があります。個々のポートレットデータに対してステージングをオン/オフにすると、ステージングとライブサイトの間でデータの不整合が発生する可能性があるため、一度ステージングを有効にすると個々のポートレットの設定を変更することはできません。

後で調整が必要になった場合は、ステージングを完全にオフにして、新しい設定で再度有効にする必要がありますが、サイトにすでに多くのデータが含まれている場合は、さらに問題が発生する可能性があります。

早めに公開、頻繁に公開、小規模で公開

ローカルステージングは有効にするとすぐにサイトのクローンを作成し、リモートステージングはネットワークを使用してデータを公開します。どちらの場合も、時間とリソースを消費する作業になります。このため、使用するステージングの種類にかかわらず、新しく作成されたクリーンなサイトでは、ステージングを有効にすることをお勧めします。

よくある間違いは、誰かが最初にすべてのコンテンツを作成し、最後のステップとしてステージングだけをオンにしてしまうことです。

サイト作成の初期段階でステージングをオンにしておくと、パブリケーションの規模が小さくなり、インクリメンタルなデータの公開が可能となり、パブリケーションの終了を長時間待つ必要がなくなり、問題の可能性を早期に発見することができます。
データセットを制限することで、より少量のデータを公開することができます。これは、コンテンツタイプと日付範囲に基づいて行うことができます。例えば、最近作成されたWebコンテンツ記事のみを、バージョン履歴（最新バージョンのみが必要な場合）や参照されたコンテンツを含まずに公開することができます。（すでにそれらを個別に公開している場合は、再度公開する必要はありません）

データベース・ファイルシステムの整合性を保つための計画の作成

ステージングに障害が発生した場合、トランザクショナルなデータベースは元の状態に戻すことができます。しかし、ファイルシステム（DBStoreのように”データベースに格納された”状態ではない場合）は、トランザクションではないため、ロールバックが必要になります。これにより、ファイルとそのファイルが参照されている場所との間に不一致が生じる可能性があります。

このため、管理者は、ドキュメントライブラリをステージングする場合、データベースとファイルシステムの両方の定期的なバックアップが維持されていることを確認し、細心の注意を払う必要があります。また、データベースのバックアップに対応するファイルシステムのバックアップが明確になっている必要があります。

同じパッチレベルを使用する

エクスポート/インポートやリモートステージングを使用して2つの異なる環境間でデータを移動する場合、 使用する全てのサーバーに同じパッチが適用されていることを確認する必要があります。古いパッチバージョンからエクスポートされたLARファイルは、同じLiferayバージョンの将来のすべてのリリースに正常にインポートされますが、これらのエクスポートファイルを定期的に更新することを強くお勧めします。これは、同じサーバーから発信されたLARファイルをインポートする場合にも当てはまります。

すべてのサーバーが同じパッチレベルで更新されていることが重要です。

ステージングをデバッグする方法

ステージングの問題の大部分は、データ検証中プロセスで発見される矛盾が原因で発生します。このため、トラブルシューティングで最も重要なステップは、問題のあるエントリを見つけることです。一般的な方法としては、いくつかの方法があります。

公開するコンテンツをを構成要素に分けます。
問題が解決するまで、Webコンテンツの記事だけを公開してみてください。次に、ドキュメントとメディアのみ、などです。
スタックトレースからより多くの情報を得るために、ステージング関連クラスのログレベルをDEBUGに上げます。この方法では、問題が発生する前にどのエントリが処理されたかを確認できます。
コントロールパネル > サーバー管理 > ログレベル に移動し、以下のカテゴリを DEBUG に設定します。

com.liferay.exportimport

com.liferay.exportimport.lifecycle

com.liferay.exportimport.lar
ステージングの公開に成功または失敗した後、生成されたLARファイルをライブ環境のアプリケーションサーバーのtempフォルダに保存するようにLiferayプラットフォームを設定することができます。これは、Liferayプラットフォームで処理されたデータを正確に分析したい場合に非常に役立ちます。そのためには、portal-ext.propertiesファイルに以下のプロパティを設定します。
```
    #

    # Set this property to false to avoid deleting the temporary LAR during a

    # a failed staging publication process.

    #

    staging.delete.temp.lar.on.failure=false

    
    #

    # Set this property to false to avoid deleting the temporary LAR during a

    # a successful staging publication process.

    #

    staging.delete.temp.lar.on.success=false
```

ステージングを正しくオフにする方法

ローカルライブステージングを使用するかリモートライブステージングを使用するかにもよりますが、最終的にサイト上でステージングを無効にすることを計画している場合は、いくつかの点に注意する必要があります。

ローカルステージングの場合：

ローカルステージングを有効にすると、すべてのステージングコンテンツを保持する重複サイトが作成されます。つまり、元の「本当の」サイトはLiveサイトであり、ステージングから公開した場合にのみ作成したデータが含まれることになります。このため、ステージングを無効にすると、 公開されなかったすべてのコンテンツが失われます。下書きのコンテンツタイプは公開されていないので、それらも失われる可能性があることを覚えておきましょう。

リモートステージングの場合：

ライブサイトとステージングサイトの接続のみが解除されます。これは、ステージングが無効化されてもデータが削除されないことを意味します。
リモートライブサイトを有効にすると、特別な制限が適用されるため、ステージングを無効にすると、これらの制限を取り消す必要があります。
このため、ステージングが無効になっている場合、ステージングサーバーは、これらの制限を解除するために、ネットワークを介してライブサーバーと通信する必要があります。ライブサーバーにアクセスできない（削除された、またはアドレスが異なる）場合、 「強制的にステージングを無効にする」オプションでのみ、通常のステージングを無効にすることができません。このオプションを使用すると、ステージドサイトのステージング情報はクリアされますが（コンテンツはクリアされません）、ライブサイトはロックされた状態のままになります。