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

学習の目的

この単元を完了すると、次のことができるようになります。

• レプリケーションの影響を受ける 3 つのインスタンスを挙げる。
  
• レプリケーションを実行可能な 3 つの方法を挙げる。
  
• キャッシュ更新を自動的にトリガーする 3 つのタイプのデータのレプリケーションを挙げる。
  
• レプリケーションのロールバックについて説明する。
  

現在 Commerce Cloud は Agentforce Commerce に、B2C Commerce は Agentforce Commerce for B2C に名称が変更されています。アプリケーションやドキュメント内では Commerce Cloud や B2C Commerce という名称が引き続き使用される場合があります。

B2C Commerce の管理者とデベロッパーは、ステージングインスタンスから本番インスタンスや開発インスタンスへ、定期的にデータとコードをレプリケートします。

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

レプリケーション処理は、定義したデータやコードをソースインスタンスからターゲットインスタンスにプッシュするタスクの集合です。ソースインスタンスには、移動したいコードやデータが格納されています。ターゲットインスタンスは、それらの移動先です。レプリケーションでは、ステージングがソースで、開発と本番がターゲットになります。

PIG と SIG を区別する

B2C Commerce のサイトには、通常、次のインスタンスがあります。

• Three instances on the primary instance group (PIG):
  
  • Staging (ステージング)
    
  • Development (開発) - テスト用
    
  • Production (本番) - 導入用
    
• 1 つのデモインスタンス
  
• コード開発、サイトのステージング、テスト、リリースのためのオンデマンド Sandbox インスタンス
  

レプリケーションは、データとコードの両方について PIG 上でのみ実行します。

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

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

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

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

レプリケーション処理

レプリケーションには、次の手順が含まれます。

• ステージングからテスト用の開発にレプリケーションを実行します。
  
• 開発インスタンスをテストして、ログを確認します。
  
• 検索が機能することと、開発システム上のデータが適切であることを確認します。
  
• ステージングインスタンスで変更を行います。
  
• 再度ステージングから開発にレプリケートしてテストします。すべてが適切に機能するまで繰り返します。
  
• ステージングから本番にレプリケートします。
  
• 開発に適切にレプリケートされた場合でも、本番ですべてテストします。
  

データまたはコードのレプリケーション処理を構成する場合、すぐに実行する、後で実行するようにスケジュールする、ジョブに割り当てるのいずれかを選択できます。

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

• コピー: データはターゲットシステムに転送されますが、まだそこには表示されません。
  
• 公開: この簡単なステップで、変更がすべて同時に反映されます。
  

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

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

レプリケーション中の競合を避ける

レプリケーション中には、ほかの更新を行わないようにします。レプリケーションの実行中に、ソースまたはターゲットのいずれかのインスタンスで Business Manager を使用して手動編集を行うと、重大なエラーやデータの不整合が生じる可能性があります。

また、レプリケーション中にターゲットインスタンス上でジョブが実行されないようにし、B2C Commerce の定期メンテナンス期間中にデータのレプリケーションが行われないようにします。定期的なデータのレプリケーション処理が失敗した場合、以降の繰り返しが停止されます。

ページキャッシュの影響を評価する

ページキャッシュの無効化により、ページキャッシュ内の古いデータが削除または更新されます。データまたはコードをレプリケートすると、B2C Commerce によってキャッシュの無効化が自動的に開始されます。キャッシュの無効化を手動で開始すると、システムがキャッシュ済みデータの無効化を開始します。パフォーマンスへの影響を軽減し、中断を最小限に抑えるために、15 分間 (クリア期間) にわたってキャッシュの削除が処理されます。

このモジュールでは、受講者が B2C Commerce の管理者で、次のタスクを実行する適切な権限を有しているものと想定しています。ただし、B2C Commerce 管理者でなくても大丈夫です。このまま読み進み、管理者がこれらの手順をどのように実行するのかを見てみましょう。Trailhead Playground で以下の手順を実行しないでください。この機能は Trailhead Playground では使用できません。

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

1. Business Manager で [App Launcher (アプリケーションランチャー)] をクリックし、[Administration (管理)] | [Sites (サイト)] | [Manage Sites (サイトを管理)] を選択します。
   
2. サイト名を選択します。
   
3. [キャッシュ] タブをクリックします。
   
4. [Staging (ステージング)] インスタンスを選択します。
   
5. [Cache Invalidation (キャッシュの無効化)] セクションで、[Invalidate (無効化)] ボタンを使用して、[Static Content Cache and Entire Page Cache for Site (サイトの静的コンテンツキャッシュとページ全体キャッシュ)] または [Entire Page Cache for Site (サイトのページ全体キャッシュ)] を無効にします。
   

ページキャッシュをクリアすると、アプリケーションサーバーに高い負荷がかかります。ページキャッシュは必要な場合にのみ手動でクリアし、トラフィックが多い時間帯にはクリアしないようにします。たとえば、軽微な更新の場合は、すぐにクリアするのではなく、夜間にスケジュール済みのキャッシュのクリアまで待ちます。

キャッシュのクリアコマンドが Web サーバーに到達するまでに最大 15 秒かかります。更新はすぐには反映されません。レプリケーションを成功させるために、変更の範囲を調べ、変更をできる限り少なくします。

キャッシュ更新が自動でも手動でも、B2C Commerce はアプリケーションサーバー間で負荷を分散するために、本番インスタンスのすべてのページの更新を 15 分間遅らせます。

コードのレプリケーションのキャッシュ動作を確認する

デフォルトでは、データのレプリケーション処理の最終ステップで、キャッシュの無効化と更新も自動的に行われます。このステップをスキップするように処理を設定することもできますが、注意が必要です。スキップすると、ストアフロント上でデータの不整合が発生し、トラブルシューティングが困難になる場合があります。

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

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

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

キャッシュの自動更新をスキップすると、商品説明ページに誤った価格が表示されるリスクがあります。本番のキャッシュ更新によるパフォーマンスへの影響を避けるため、このトレードオフを受け入れます。何よりも大切なことは、本番インスタンスの買い物カゴに、ステージングインスタンスと同期した状態の適切な価格が反映されるようにすることです。

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

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

対象を絞ったレプリケーションのベストプラクティスを適用する

対象を絞ったレプリケーションをスムーズに実行し、エラーが発生しないようにするために、詳細なデータ転送に関する次のベストプラクティスに従ってください。

連動関係を特定する

連動関係は、レプリケーション失敗の最も一般的な原因です。詳細なレプリケーションのタスクを選択する前に、連動関係を特定し、解決する計画を立てます。

たとえば、ソースコードとクーポンを使用するキャンペーンがある場合、キャンペーンデータの前、またはキャンペーンデータと同時に、ソースコードとクーポンのデータをレプリケートします。キャンペーンを先にレプリケートすると、ターゲットインスタンスのデータが破損する可能性があります。このエラーは、キャンペーンがソースコードとクーポンデータと連動しているために発生します。

同時処理を避ける

複数のレプリケーション処理を同時に実行しないでください。レプリケーションはリソースを多く消費する処理です。処理を同時に実行すると、パフォーマンスの問題や予測できない結果が生じる可能性があります。

連動関係を先にレプリケートする

システムオブジェクトタイプを変更する場合 (たとえば、商品オブジェクトにカスタム属性を追加する場合)、そのタイプのオブジェクトをレプリケートする前に、グローバルシステムオブジェクトタイプ定義をレプリケートします。

必ず本番の前にテストする

ライブの本番インスタンスに変更をレプリケートする前に、まずステージングインスタンスから開発インスタンスへ同じレプリケーション処理を実行します。この手順により、変更をテストし、本番環境へのリスクなしに、検索などのストアフロント機能を含むすべての内容が正しいことを確認できます。

トラフィックの少ない時間帯に実行する

レプリケーション処理には、大量のシステムリソースが必要です。深夜や早朝など、トラフィックの少ない時間帯に主要なレプリケーションを実行するようスケジュールします。トラフィックの少ない時間帯にレプリケーションをスケジュールすることで、ストアフロントのパフォーマンスへの影響を最小限に抑え、買い物客に最良のエクスペリエンスを提供できます。

ログを調べる

本番インスタンスにレプリケートするときには、まずデータまたはコードを転送して転送処理を確認します。データを公開またはコードをアクティブ化する前に、ログを調べます。

検索インデックスを再構築する

検索インデックスは常に再構築し、インデックスをレプリケートする前に再構築プロセスが完了していることを確認します。検索インデックスをレプリケートするときは、増分インデックス作成とスケジュールインデックス作成を無効にし、ほかのジョブも停止します。インデックスの再構築中または変更中にレプリケーションを実行すると、処理が失敗します。

ユーザーアクセスを制限する

データのレプリケーションを実行するユーザー権限を制限し、複数のユーザーの役割で責任を分担します。次に例を示します。

• プロダクトマネージャーはレプリケーション処理を定義しますが、スケジュールして実行する許可を持ちません。
  
• レプリケーションマネージャーは、レプリケーション処理を管理して実行します。
  

静的コンテンツのレプリケーションを避ける

静的コンテンツファイルの変更や移動は、できる限り避けます。これらの変更はレプリケーションに長い時間がかかります。

既存の処理を使用する

可能な場合は、レプリケーション処理をゼロから作成するのではなく、既存の処理をコピーします。

レプリケーションのロールバック

レプリケーションをロールバックしてターゲットインスタンスを以前の状態に復元するには、レプリケーションタイプを [Undo (元に戻す)] に設定して別のレプリケーション処理を実行します。ロールバックできるのは、データまたはコードの最後のレプリケーションに限られます。

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

正式リリース (GA) 前に実行されたデータのレプリケーション処理に、元に戻す操作は使用できません。たとえば、バージョン 24.7 の処理は、システムがバージョン 24.8 にアップグレードされた後に元に戻すことはできません。これは GA の更新 (例: 24.8.1 から 24.8.2) には適用されません。

次のステップ

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

リソース

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