B2C Commerce のレプリケーションの解説

Linda Rosenberg は高級なカスタムスニーカーを扱う Cloud Kicks 社の新任管理者です。最近、Salesforce B2C Commerce でいくつかの肝要なデータ管理タスクを実行する方法を習得しました。現在は、データやコードの変更を会社の e コマースの Staging (ステージング) インスタンスから Production (本番) や Development (開発) インスタンスにプッシュするエキスパートになりたいと考えています。

たとえば、先般デベロッパーが、能率的な注文手続きプロセスを作成し、ボーナス商品割引機能を追加しましたが、この際 Business Manager で構成設定を変更する必要がありました。また、Linda は春の新作の商品データを外部システムから Staging (ステージング) にインポートしたところです。B2C Commerce のインスタンス間でコード、構成設定、データを移動するために Linda が実行可能な処理をレプリケーションといいます。

レプリケーション処理は、定義したデータやコードをソースインスタンスからターゲットインスタンスにプッシュするために実行するタスクの集合です。ソースインスタンスとは、コードやデータが現存するところです。ターゲットインスタンスはその移動先です。レプリケーションの場合、ソースインスタンスは Staging (ステージング) で、ターゲットインスタンスは Development (開発) と Production (本番) です。

「Salesforce B2C Commerce の役割と許可」モジュールを完了している場合は、B2C Commerce のアーキテクチャについて習得しています。ここでは、インスタンスについて詳しく説明していきます。マーチャントが最初にサイトを実装する際、そのサイトは通常、1 つのレルムにつき 9 つのインスタンスを受け取ります。これには以下が含まれます。

• プライマリインスタンスグループ (PIG) 上の 3 つのインスタンス:
  • Staging (ステージング)
  • Development (開発) - テスト用
  • Production (本番) - 導入用
• セカンダリインスタンスグループ (SIG) 上の 5 つの Sandbox (サンドボックス) インスタンス - コード開発用。拡張が必要な場合は、レルムあたり最大 47 の Sandbox (サンドボックス) を設定できます。
• 1 つのデモインスタンス。

レプリケーションは PIG でのみ実行します。この点は、データとコードのどちらのレプリケーションでも同じです。

データのレプリケーションでは、データ、メタデータ、ファイルを Staging (ステージング) から Development (開発) と Production (本番) のいずれかのインスタンスにコピーします。このレプリケーションは次の 2 つのレベルで機能します。

• グローバルレプリケーション - 組織全体に適用される構成情報とデータが対象です。
• サイトレプリケーション - 指定した 1 つ以上のサイトに属するデータが対象です (商品やカタログデータ、XML ベースのコンテンツコンポーネント、画像ファイルなど)。

コードのレプリケーションでは、コードのバージョンを Staging (ステージング) から Development (開発) または Production (本番) インスタンスに転送してアクティブにします。

通常、コードを SIG から PIG に移動するのはデベロッパーの任務です。デベロッパーは各自のローカルマシンでコーディングを終えたら、そのコードを Sandbox (サンドボックス) または Staging (ステージング) にアップロードします。このアップロードに Visual Studio Code を使用することもあれば、コードリポジトリ (Git など) を使用して複数のデベロッパー間の作業を同期することもあります。後者の場合は、このコードリポジトリが、Staging (ステージング) インスタンスにリリースするソースになります。この種の開発環境には、アップロードを自動的に行う独自のビルドプロセスが設定されていることがあります。

Linda は、レプリケーションで次の手順を実行することを知りました。

1. Staging (ステージング) から テスト用の Development (開発) にレプリケーションを実行します。
2. Development (開発) インスタンスをテストして、ログを確認します。
3. 検索が機能することと、開発システム上のデータが適切であることを確認します。
4. Staging (ステージング) インスタンスで必要な変更を実施します。
5. 再度 Staging (ステージング) から Development (開発) にレプリケートしてテストします。すべてが適切に機能するまで繰り返します。
6. Staging (ステージング) から Production (本番) にレプリケートします。
7. Development (開発) に適切にレプリケートされた場合でも、Production (本番) ですべてテストします。

Linda がデータまたはコードのレプリケーション処理を構成する場合、すぐに実行する、後で実行するようにスケジュールする、ジョブに割り当てるのいずれかを選択できます。ところで、ジョブとは何なのでしょうか? B2C Commerce のジョブとは、インポートファイルのダウンロードや検索インデックスの再作成など、時間のかかる操作を実行する一連の手順です。ジョブについては、「Salesforce B2C Commerce のスケジュール済みジョブ」モジュールで説明します。

データのレプリケーションは実行に時間のかかる処理で、2 つのフェーズで構成されます。

1. データをターゲットシステムにコピー — データはまだターゲットシステムに表示されません。
2. 公開 — この簡単なフェーズで、変更がすべて同時に反映されます。

Linda は、データのレプリケーション処理が毎日、毎週、毎月のいずれかの指定した時刻に繰り返されるよう設定できます。レプリケーション処理が後で実行されるようにスケジュールすると、このプロセスは、プロセスの作成時ではなく、システムの実行時の状態をレプリケートします。

コードのレプリケーションでは、コードのバージョンを Staging (ステージング) インスタンスから Development (開発) または Production (本番) インスタンスに転送してアクティブにします。

Linda は、レプリケーション中に他の更新を行わないようにしています。レプリケーションを実行中にソースまたはターゲットのいずれかのインスタンスにある Business Manager で手動の変更を行うことはやめたほうがよいことをは身をもって学んでいます。この処理中に編集すると、データの一貫性に影響するおそれがあります。

また、レプリケーション中にターゲットインスタンス上でジョブが実行されないようにし、B2C Commerce の定期メンテナンス期間中にデータのレプリケーションが行われないようにしています。反復的なデータのレプリケーション処理に失敗すると、それ以降自動的に実行されなくなります。

コードとデータのどちらのレプリケーションも、ページキャッシュの影響を受けます。レプリケーションの一部のタスクは、キャッシュを自動的に無効にして更新します。この処理を自動的に行わないタスクもあるため、Linda はレプリケーションの実行後に常にキャッシュを手動でクリアする必要があります。では、キャッシュを手動でクリアする手順を見てみましょう。

Business Manager にアクセスするには、B2C Commerce の実装が必要です。このモジュールでは、受講者が B2C Commerce 管理者であり、次のタスクを実行する適切な権限を有していると想定しています。B2C Commerce 管理者でなくても大丈夫です。このまま読み進み、ステージングインスタンスで管理者がこれらの手順をどのように実行するのかを確認します。Trailhead Playground で次の手順を実行しないでください。Trailhead Playground では B2C Commerce を使用できません。B2C Commerce のステージングインスタンスがある場合は、これらの手順をそのインスタンスで実行できます。ステージングインスタンスがない場合は、使用可能なインスタンスがないかマネージャーにお問い合わせください。

キャッシュにアクセスして無効にするには、次の手順を実行します。

1. Business Manager を開きます。
2. [管理] > [サイト] > [サイトの管理] > サイト名を選択します。
3. [キャッシュ] タブをクリックします。
4. [Staging (ステージング)] インスタンスを選択します。
5. [キャッシュの無効化] セクションで、[無効にする] ボタンを使用して、[サイトの静的コンテンツキャッシュとページ全体キャッシュ] または [サイトのページ全体キャッシュ] を無効にします。この変更はすぐに反映されます。

ページキャッシュをクリアすると、アプリケーションサーバーに多大な負荷がかかる可能性があります。このため Linda は、必要のある場合にのみページキャッシュを手動でクリアし、トラフィックが多い時間帯にはクリアしないようにする必要があります。たとえば、Linda がさほど重要でないいくつかの更新を行う場合は、キャッシュをただちにクリアするのではなく、夜間にスケジュールされたキャッシュのクリアまで待つことが考えられます。変更が重要なセキュリティ機能や、商品またはプロモーションの緊要な更新に関するものである場合は、それに応じた判断を下します。

キャッシュをクリアする時刻がいつであっても、キャッシュのクリアコマンドが Web サーバーに到達するまでに最大 15 秒かかることがあります。キャッシュの更新がすぐに表示されることはないでしょう。レプリケーションを確実に成功させるために、Linda は変更の範囲を調べ、変更をできる限り少なくします。

キャッシュ更新が自動でも手動でも、Production (本番) インスタンスでは B2C Commerce が全ページの更新を 15 分待機してから実行します。アプリケーションサーバー全体に負荷が分散されるようにするためです。Production (本番) 以外のインスタンスでは、ページキャッシュがすぐに更新されます。

データのレプリケーション

データのレプリケーション処理のデフォルトの最後のステップは、特定の場合を除き、キャッシュを自動的に無効にして更新することです。Linda は、キャッシュが自動的にクリアされないようにレプリケーション処理を構成することができます。ただし、この構成は慎重に行わなければなりません。ストアフロントのデータの一貫性が損われる可能性があり、このトラブルシューティングが厄介になることがあるためです。

キャッシュが自動的にクリアされないようにする状況の一例を見てみましょう。B2C Commerce では、商品説明ページが 24 時間キャッシュされます。Linda は商品ページのキャッシュが翌日の夜間にクリアされるようスケジュールしていますが、Production (本番) インスタンスで数種の商品価格が間違っていることに気が付きました。マーチャンダイザーに Staging (ステージング) インスタンスの Business Manager で価格を訂正するよう依頼します。その後、クリアを行わない処理を使用して (ページキャッシュのクリアはすでにスケジュールされているため)、この変更を Production (本番) にレプリケートします。

この方法では、Staging (ステージング) と Production (本番) の価格データが同期している状態が保たれ、買い物カゴに (キャッシュされていない) 正しい価格が表示されます。ストアフロントの商品説明ページには、スケジュール済みのページキャッシュのクリアが実行されるまで、古い間違った価格が表示されます。

B2C Commerce API 内ではショッピングカートのことを買い物カゴといいます。

キャッシュの自動更新を行わないということは、Production (本番) のキャッシュ更新によるパフォーマンスへの負荷を回避するのと引き換えに、商品説明ページに間違った価格が表示されるという代償を払うことを意味します。何よりも大切なことは、Production (本番) インスタンスの買い物カゴに、Staging (ステージング) インスタンスと同期した状態の適切な価格が反映されるようにすることです。

ページのキャッシュには他にもいくつかの考慮事項があります。

レプリケートの対象	B2C Commerce の動作
サイト固有のデータ	クーポン、ソースコード、Open Commerce API 設定、アクティブなデータフィードのいずれかのみをレプリケートする場合を除き、影響を受けるサイトのページキャッシュをクリアします。
グローバルデータ	位置情報と顧客リストのいずれかのみをレプリケートする場合を除き、影響を受ける全サイトのページキャッシュをクリアします。
カタログ、サイト、価格表	キャッシュを自動的にクリアします。
プロモーション、静的コンテンツ	キャッシュを自動的にクリアしません。
カタログ	次表で説明するルールに従って、影響を受けるサイトのページキャッシュを選択的にクリアします。

カタログは次のとおり、特殊なケースに該当します。

レプリケートの対象	B2C Commerce がキャッシュをクリアする場所
組織の全サイトの全カタログ	組織の全サイト。
1 つ以上のサイトに割り当てられた 1 つのカタログ	そのカタログが割り当てられているサイト。
サイトに直接割り当てられていないが、1 つ以上のサイトカタログまたはナビゲーションカタログの商品リポジトリとして機能する商品カタログ	商品カタログから商品を提供するとプログラミングで判断されたサイト。

Linda は今では、レプリケーションについてかなり把握しています。それでも、Cloud Kicks のレプリケーション処理を設定する前に、次のベストプラクティスを注意深く検討しています。

• 異なるデータレプリケーショングループ間の連動関係を特定する。たとえば、ソースコードとクーポンコードを使用するキャンペーンがある場合、キャンペーンをレプリケートするときに同時にまたはその前に、ソースコードとクーポンをレプリケートします。
• 検索インデックスは常に再作成し、インデックスをレプリケートする前に再作成プロセスが完了していることを確認する。検索インデックスをレプリケーションするときは、増分インデックスとスケジュール済みインデックス化を無効にし、他のジョブも停止します。インデックスが再作成または変更されている間は、レプリケーションに失敗します。
• 複数のレプリケーション処理を同時に実行しない。
• データのレプリケーションを実行する権限のあるユーザー数を制限する。
• 静的コンテンツは、同じフォルダーに 1,000 ファイル以上が認められないフォルダー構造に保存する。フォルダーに 1,000 ファイル以上を保存すると、変更されたファイルがなくても、アクセス時間やレプリケーション時間が大幅に増大します。
• 可能な場合は、新しいレプリケーション処理をゼロから作成するのではなく、既存の処理をコピーする。
• カートリッジのパスやコードを Production (本番) インスタンスで直接編集しない。直接編集すると、ページの複数のバージョンが生成されるなど、予期しない動作が生じる可能性があります。コードや環境設定は常に Staging (ステージング) から Production (本番) にレプリケートします。

時として、レプリケーションを元に戻す必要のある場合があります。この場合は、レプリケーションタイプを [元に戻す] に設定し、同じレプリケーションをもう一度実行します。この操作により、ターゲットインスタンスが以前の状態に復元されます。ただし、ロールバックできるのは、データまたはコードの最後のレプリケーションに限られます。

データとコードのいずれか一方をレプリケートしても、もう一方のロールバックには影響しません。たとえば、データのレプリケーションを実行してからコードのレプリケーションを実行した場合、両方のレプリケーションを元に戻すことができます。

この単元で Linda は、コードやデータのレプリケーションにどのインスタンスを使用するかを学習しました。ページキャッシュの実装やベストプラクティス、レプリケーションをロールバックする方法も学びました。次は、データのレプリケーションを構成して実行します。

• Trailhead: Salesforce B2C Commerce (マーチャンダイザー向け)
• Trailhead: Salesforce B2C Commerce のアーキテクチャ
• Trailhead: Salesforce B2C Commerce のスケジュール済みジョブ
• ヘルプ: レプリケーション