Shopper API のパフォーマンスとベストプラクティス

以下の Shopper API パフォーマンスのベストプラクティスを使用して、買い物客の体験と B2C Commerce インスタンスの運用を最適化します。API の実装、テスト、モニタリングにおける選択はすべて、ストアフロントのパフォーマンスに大きく影響します。

この記事で紹介するベストプラクティスは、Shopper API のパフォーマンスに焦点を当てています。この情報の一部は SCAPI Admin API にも適用されますが、フック関連の情報など、一部は適用されません。

コンポーザブルストアフロントのパフォーマンスに関するガイダンスについては、コンポーザブルストアフロントのパフォーマンスガイドを参照してください。

パフォーマンスは API にとって重要な側面であり、顧客がストアフロント内をすばやく移動して簡単に商品を購入できるようにするだけでなく、指定された制限時間内に API が応答しない場合にストアフロントに影響が出ないようにするためにも重要です。Shopper API は 10 秒以内に応答する必要があり、応答しないと HTTP 504 タイムアウトレスポンスが返され、ユーザーはこれらのエラーが原因でトランザクションを完了できません。

Note

SCAPI のパフォーマンス責任 

機能をビルドするときは、そのビルドに使用する API を決定する必要があります。

  • Shopper API (標準搭載)
  • フックを使用する Shopper API
  • カスタム API

この決定は、パフォーマンスと、実行しなければならないパフォーマンス関連作業の量に影響を与えます。SCAPI のパフォーマンスは共同責任であり、次の表にまとめられています。

API タイプパフォーマンステストの責任パフォーマンスに関するメモ
Shopper API (標準搭載)Salesforce:
  • Shopper API コード
お客様:
  • カタログ
  • 送信するパラメーター
Salesforce は、Shopper API のパフォーマンスを確認するためにテストを行います。
フックを使用する Shopper APISalesforce:
  • Shopper API コード
お客様:
  • カタログ
  • 送信するパラメーター
  • カスタムコード
フックは標準搭載 (OOTB) の Shopper API よりも低速です。これは、フックの使用には Shopper API コードとお客様のカスタマイズの両方が含まれるためです。
カスタム APIお客様:
  • カタログ
  • 送信するパラメーター
  • 作成するすべての API コード
コードサイズが大きくなるほど、パフォーマンステストに必要な工数も増加します。

Shopper API 実装のベストプラクティス 

提供されている機能で十分な場合は、標準搭載 (OOTB) の Shopper API を使用します。

たとえば、ストアフロントを構築していて、商品のリストを表示するとします。これは通常、既存の Shopper Search または Shopper Products API の機能で実現できます。

Shopper API を呼び出す際には、以下の点に注意してください。

カタログサイズ 

カタログが大きいほど、特定のプラットフォームリクエストにかかる時間が長くなります。たとえば、Shopper Products を使用して検索する場合、多数の商品を検索するよりも少数の商品を検索する方が高速です。

カタログデータを理解し、最悪のシナリオを想定してテストしてください。一部の Shopper API では、カテゴリやバリアントなど、ページ分割されていないレスポンスが返されるため、レスポンスサイズが非常に大きくなることがあります。

たとえば、getCategories を levels=2 と id=root で呼び出したとします。カテゴリツリーに数千ものカテゴリが含まれている場合、レスポンスのサイズが大きくなります。または、フィット感、ウエスト、股下、色、ウォッシュ、股上、ストレッチによって異なるペイントのペアを expand=variantsgetProducts 呼び出します。これにより、レスポンスが膨大になる可能性があります!

レスポンスサイズ 

レスポンスが大きいほど、取得と転送に時間がかかります。

レスポンスサイズは、次の影響を受けます。

  • カタログとオブジェクトの数
  • 展開 (Expansion)
    • 多くの Shopper API は、関連オブジェクトをクエリする機能である展開をサポートしています。また、展開を使用すると、取得と転送の時間が長くなります。
  • カスタム属性
    • カスタム属性を使用してシステムオブジェクトを拡張します。select またはフックを使用して、不要な属性を削除します。

select または expand パラメーターを使用して、必要なレスポンスプロパティのみを選択します。複雑なレスポンスのフィルタリングには、modify (変更) フックを使用します。

API クライアントが圧縮リソースをリクエストするように構成されていることを確認します。

キャッシング 

一部の展開 (Expansion) は短時間しかキャッシュできないため、展開はキャッシュの有効性に影響を与えます。availability のように 60 秒間しかキャッシュできないような、キャッシュ時間の短い展開を使用する必要がある場合は、必要に応じて追加のリクエストを実行して取得することを検討してください。これは、product search やget products など、頻繁に呼び出す API エンドポイントで特に重要です。詳細については、デフォルトのキャッシュ有効期限とパーソナライズ設定を参照してください。

expand パラメーターが指定されていない場合は、すべての展開が選択されていると見なされます。詳細については、「expand」パラメーターがキャッシュヒット率に与える影響を参照してください。

Note

B2C Commerce API の上に中間キャッシュを追加する場合は注意が必要です。ほとんどの API レスポンスはパーソナライズできるため、NGINX やスタック CDN などのアップストリームキャッシングシステムで URL のみをキャッシュキーとして使用することはできません。

フック実装のベストプラクティス 

Shopper API が存在していても、必要なデータや機能がすべて揃っていない場合は、フックを使用して拡張できます。

フックを含む API は、実行するコードが追加されるため、フックのない API よりも常に遅くなります。フックを使用すると、Shopper API とフックのカスタマイズが実行されます。フックを追加する場合、コードのパフォーマンスは開発者の責任となります。そのため、使用するコードが十分に高パフォーマンスであることを確認するために、適切なパフォーマンステストを実施してください。

フックはシステムロジックの拡張機能であり、これらの拡張機能は、該当する API ロジックが実行されるたびに実行されます。たとえば、Shopper API コードは頻繁に実行されるため、次の点を確認してください。

  • 前述の Shopper API 実装のベストプラクティスに記載されているベストプラクティスに従います。
  • Code Profiler を使用して、フックのパフォーマンスを表示します。
  • フックロジックが、レスポンスをキャッシュできる期間に影響を与えるかどうかを検討します。必要に応じて、Script API を使用して、標準搭載のキャッシュを変更します。
  • 外部システムへの呼び出しを最小限に抑えます。外部サービスを呼び出す必要がある場合は、サービスフレームワークを使用し、関連するサービスのプロファイル対して厳格なタイムアウトとサーキットブレーカーの設定があることを確認します。外部データを実行時にリクエストするのではなく、B2C インスタンスにインポートできるかどうかを確認します。
  • コストの高い操作をカスタムキャッシュにキャッシュすることを検討してください。カスタムキャッシュは合計 20B、エントリあたり 128KB に制限されています。これらの制限を超えると、警告が返されます。カスタムキャッシュの詳細については、カスタムキャッシュを参照してください。

多数の取得を伴う複雑なプロモーションでは、フックのパフォーマンスに悪影響が及びます。マーチャンダイジングチームと協力してプロモーションの最適化を行ってください。

Note

カスタム API のベストプラクティス 

カスタム API は、目的に対応する Shopper API が存在しない場合に使用します。これにはユーザーが記述するコードが含まれるため、カスタム API に対して適切なパフォーマンステストを実行してください。

  • Shopper API 実装のベストプラクティスおよびフック実装のベストプラクティスに記載されているベストプラクティスに従います。
  • カスタム API を使用する場合、キャッシュはお客様の責任となります。API からのレスポンスがキャッシュに適しているかどうかを検討し、適している場合は、Script API を使用してプラットフォームがレスポンスを確実にキャッシュするようにします。
  • 該当する場合はリモートインクルードを使用して、プロモーションの詳細や商品情報など、個別にキャッシュできる再利用可能なレスポンスフラグメントを作成します。

API のテストと測定 

エンドポイント、フック、カスタム API の速度を測定します。レスポンスが遅いと、買い物客の体験に悪影響を与えるだけでなく、ストアフロントインスタンスへの負荷も大きくなります。ストアフロントは、低速のレスポンスよりも高速なレスポンスをはるかに多く処理することができます。

API のパフォーマンスは初期実装時にチェックするだけでなく、ビルド後も継続的にモニタリングを行ってください。パフォーマンスは常に意識すべき課題です。パフォーマンステストの主なアプローチには、「ラボテスト」と「フィールドテスト」の 2 つがあります。

「ラボテスト」では、特定のエンドポイントに対して継続的なパフォーマンステストを設定し、結果を測定します。パフォーマンスが低下すると、アラーム (E メールなど) によってチームに確認するよう警告されます。これは通常、継続的インテグレーション環境で行われます。

「フィールドテスト」では、実際の使用状況における API 呼び出しのパフォーマンスを測定します。詳しくは、Reports & Dashboards の Technical Timing SCAPI ページを参照してください。

ラボテスト 

ラボテストでは、制御された条件を使用して API の変更をテストします。たとえば、デプロイ前にパフォーマンスが低下していないこと、およびパフォーマンスが許容可能な基準を満たしていることを確認するために、すばやく連続してテストします。

ラボテストを継続的インテグレーション (CI) に統合して、タイミング情報を記録するテストを作成できます。たとえば、API に複数のリクエストを送信するテストを作成できます。

パフォーマンスが遅すぎる場合:

  • Shopper API、フック、およびカスタム API の呼び出し時間を検査および追跡する方法については、リクエストの詳細の収集を参照してください。
  • Code Profiler を使用して、コード内のタイミングのボトルネックを調査します。

フィールドテスト 

フィールドテストでは、デプロイ後のライブ環境でのパフォーマンスを測定します。たとえば、異なる買い物客からのリクエストにかかる時間を測定します。これにより、API 呼び出しで何が起こっているかを理解し、ラボテストで見逃したエッジケースやその他の予期しない問題を確認できます。

Reports & Dashboards 

Account Manager の Technical Timing (テクニカルタイミング) タブと SCAPI タブを使用して、API とコントローラーが大規模にどのように動作しているかを確認します。この情報には、次の情報が表示されます::

  • 経時的な平均レスポンス時間、リクエスト数、およびステータスコード

  • パフォーマンスの分布:

    • ドリルダウンして、カスタム API を含む特定の API のパフォーマンスと動作を表示します。たとえば、Shopper Baskets などの API ファミリーを見て、その API ファミリー内のエンドポイントを掘り下げることができます。また、カスタム API を表示して掘り下げたり、最も頻繁に呼び出されるエンドポイントで並べ替えたりして、平均レスポンス時間を確認することもできます。

  • トレンド:

    • 経時的な傾向と、重要なコード変更後の傾向を監視します。たとえば、コードの変更とデータを重ね合わせて表示することで、コードの変更によってパフォーマンスが低下したかどうかを評価できます。

役立つ質問:

  • コードを変更したため、レスポンス時間が長くなりましたか?
  • ユーザーが異なるものを検索したためにレスポンス時間が長くなったのでしょうか?

Code Profiler 

タイミングのボトルネックを理解して対処するには、Code Profiler を使用します。

次のステップ 

入門ガイド
クイックスタート
開発
拡張
サイトの保護
パフォーマンスの最適化
サーバー側の Web 階層キャッシング
トラブルシューティング
Ask the Community