調査プレイブック
Adobe Commerce Traffic Insights アプリは、次の問題の調査に役立つように設計されています。
- 帯域幅の超過
- Web クローラー負荷
- 悪意のあるトラフィック
または、Advanced Security: ネイティブボット管理、レイヤー7 DDoSとレート制限、手動による緩和が不十分な場合のAdobeのネイティブエスカレーションパスをリクエストすることもできます。 各ステップは、症状を表示するウィジェットを参照するので、指標から具体的なアクションに移動できます。
CDN帯域幅の超過
帯域幅の超過を考慮する前に、帯域幅の請求方法を理解してください。 allのFastly サービスのトラフィックは、実稼動 および のステージング環境を含むAdobe Commerce on Cloud Infrastructure アカウントにバンドルされ、契約の年間許可に対する一般的な使用量にカウントされます。 帯域幅>総帯域幅から開始し、コンテンツの種類 および 帯域幅ドメインの詳細 で 帯域幅を持つボリュームを属性にします。
メディアコンテンツ
一部のストアでは、カタログが原因で、帯域幅の大部分がメディアとして提供されています。 コンテンツ タイプ別 帯域幅 が大幅なメディア帯域幅を示す場合は、次の緩和策を検討してください。
- Fastlyの非可逆変換を試して、より小さく低画質の画像を提供します。
- Fastly Deep Image Optimizationを調査して、コンテンツ配信ネットワーク（CDN）側でサイズ変更された画像を生成します。
大きなファイル
一部のサイトには、大きなファイルや、特定の多量の応答（ERP （エンタープライズリソースプランニング）の統合や書き出しなど）が含まれています。 帯域幅ごとの URL を使用して、BW列と 平均サイズ 列を確認し、これらの大きなファイルを見つけます。 パスセグメント lvl 1を帯域幅で使用すると、上位レベルのビューを表示できます。
重い404
Adobe Commerce 404 ページが見つかりませんは、通常、重いテーマ形式のページ（～1.5 MB）および キャッシュ不可 であるため、404を繰り返すと異常なトラフィックが発生する可能性があります。 favicon.icoのような些細なリソースでも、小さなファイルではなく、重い404 ページに変わる可能性があります。 404と 404 BW 列を帯域幅ドメイン別の詳細、URL帯域幅の指定、帯域幅の上位IP、IP サブネットの統計で使用すると、一貫して404 ボリュームを生成するクライアント、IP、URLを検索できます。 その後、アクセスを減らすか制限します。例えば、軽量403を返します。
FPC ヒット率が低い
Adobeでは、メインのCDN キャッシュアグリゲーターがオリジンを提供し、クライアントに最も近いローカルのPoint of Presence （POPs）からリクエストが少なくなるように、Fastly シールド を有効にすることをお勧めします。 設定の確認を参照してください。
POP-to-client トラフィックとshield-to-POP トラフィックは個別にカウントされ、クライアントのレスポンスは圧縮されますが、shield-to-POP トラフィック は圧縮されません Edge Side Includes （ESI）のサポートを維持します。 つまり、フルページキャッシュ（FPC）のヒット率が低いと、動的なページの帯域幅が大幅に増加します。 FPC ヒット率、FPC Stats By Domain、CDN ネットワークセグメント帯域幅で症状を確認します。
ヒット率の低下は、多くの場合、大量の検索エンジンweb クローラーによって引き起こされます（検索ボットとweb クローラーを参照）。 また、利用可能な場合は、古いキャッシュをweb クローラーに提供する必要があります。 原因が頻繁にキャッシュが無効化される場合は、Cache Invalidation By Tagsと FPC Age By Top URLs を使用して、解約されたタグ/URLを見つけます。
ボットとweb クローラーの検索
Web クローラーの影響を測定するには、Known Bots By Bandwidthおよび Known Bots Impact Details から開始して、最もアクティブなボットを確認し、そのリクエストのみを調査するために特定のボットで フィルターを実行します。
リクエストが多すぎます
検索ボットが送信するリクエストが多すぎる最も一般的な原因は、<meta name="robots" content="index,follow">を含むページの解析中に発生します。 ボットは、トップナビゲーションと階層化されたナビゲーションリンクを、ほぼ無限のループでフォローできます。 この問題に対処するには、次のオプションを検討してください。
nofollowをトップナビゲーションおよび階層化ナビゲーションリンクに追加します（例：<a rel="nofollow" href="https://example.com/sales.html">Sales</a>）。- ページのメタタグを
index,nofollowに変更します。共通の デザイン構成設定として、またはカスタム拡張機能を使用してページタイプごとに変更します。sitemap.xmlを正確に保ち、ボットが常に最新のページのリストをインデックスに追加できるようにします。 robots.txtを更新して、パスとリソースボットがアクセスできないようにします。crawl-delayディレクティブは公式のRobots Exclusion Protocolの一部ではありませんが、Bingbot、Slurp、SEMrushBotなどの一部のボットでは機能します。 Googlebotはこのディレクティブを無視します。- レート制限ルールの追加。 Fastly モジュールには不正なweb クローラー対策が組み込まれています。 より細かい制御のために、 カスタム Varnish Configuration Language （VCL）スニペット は、個別のレート制限を持つユーザーエージェント正規表現に対して
429（リクエストが多すぎます）または405（メソッドが許可されていません）を返すことができます。 Web クローラーのドキュメントで、推奨される方法と応答コードを確認します。 Fastlyの レート制限VCL ガイダンス を参照してください。 - AIとLLM （大規模言語モデル）web クローラーは、増加する特殊事例です。 VCLは常に自分自身を識別するわけではないので、VCLのユーザーエージェントのルールは遅れることがあります。 Adobeの高度なセキュリティ アドオンには、 ネイティブボット管理があり、VCLだけでは対応できない、エッジのAIの疑いのあるweb クローラーやフェッチャーと検証済みのボットを区別できます。
不要なweb クローラーのブロック
特定の検索エンジンが大きなトラフィックを生み出し、ビジネスにとって重要ではない場合、完全にブロックすることができます。
- 一部のボットは、解析ルールを再読み取りして更新した後、1 ～ 2日後に
robots.txtの変更に従います。 - Web クローラーが
robots.txtを無視する場合は、カスタム VCL スニペット（例）でブロックします。 一部のweb クローラーは、これを周波数制御の好ましい方法または唯一の方法として明示的に文書化しています。
悪意のあるスクリプトとスクレイパー
Traffic Insights アプリを使用して、攻撃の一般的な方向を特定し、必要に応じてフォーカス領域でフィルタリングします。 赤いフラグが付いたリクエストが、主に特定のIP、サブネット、または地域から来る場合（リクエスト数で上位IPs、IP サブネットで統計、国で統計）、カスタム Fastly VCLでそれらをブロックすることを検討してください。
すべてのCloud Infrastructure プロジェクトには、設定に関係なく、自動保護のベースラインが既に用意されています。 同梱のWeb Application Firewall （WAF）は、50 リクエスト/分、350 リクエスト/10分、または1,800 リクエスト/時間を超えると、SQL インジェクションと既知の悪意のあるIP信号（バックドア、攻撃ツール、CMDEXE、Log4J-JNDI、トラバーサル、XSS）を即座にブロックし、その他の悪意のあるIPをレート制限します。 このベースラインは、Requests By WAF Responseと、このアプリのテーブルのWAF シグナル列が示しているものです。 これらの列のスパイクは、必ずしも保護されていないことを意味しません。
- 資格情報の詰め込み、アカウントの乗り継ぎ、偽アカウントの作成、カードテスト、コンテンツスクレイピング、在庫/カートの保管などに注意してください。 これらのボット主導の不正使用パターンは、ボットのアクティビティとリクエスト分析 タブに表示されます。 ログイン、アカウント、チェックアウト、またはカタログのエンドポイントにヒットする大量で多様性の少ないトラフィックは、リクエスト数による上位IPと 既知のボットへの影響の詳細 で検索する署名です。
- Google reCAPTCHAを使用して、チェックアウトおよびチェックアウト API エンドポイントをボット攻撃から保護します。
- Fastly モジュールのネイティブ レート制限 パス保護を使用します。
- コンマ区切りの
Sigsci_Tagsフィールドで次世代WAF シグナル を確認し、関連するシグナルの一致をターゲット ブロック ルールに組み合わせます。 不審なリクエストの値はBOT-ANALYSIS,DATACENTER,SIGSCI-IP,SITE-FLAGGED-IP,SUSPECTED-BAD-BOTのようになります。 WAFは、IPが自動的にブロックを開始する前に、SITE-FLAGGED-IPのしきい値までというラベルを付けます。 WAF Attack & Anomaly Signals、WAF Bots Signals、Requests By WAF Response ウィジェット、およびIP、サブネット、カントリーテーブルのWAF列は、これらを表示します。 - 一般的なアプローチについては、Fastly レベルでのAdobe Commerceの悪意のあるトラフィックのブロック に関するAdobeの記事を参照してください。
- 手動ブロッキングが有効なオプションではない複雑なシナリオ（継続ボットキャンペーン、多数のIP/APIに広がる攻撃、レイヤ 7分散型サービス拒否（DDoS）など）の場合は、最初にAdobeのAdvanced Security アドオンを検討してください（ ネイティブボット管理を参照）。 ストアフロントと同じFastly Edge上で動作します。 そのスコープ外の機能が必要な場合は、DatadomeやHUMAN Bot Defender （旧PerimeterX）などのネイティブ Fastly統合を備えたサードパーティのマネージドボット軽減サービスが推奨されます。 これらのオプションはすべて追加コストです。
高度なセキュリティ：ネイティブボット管理、レイヤー7 DDoS、レート制限
ここでは、Traffic Insights アプリのデータと手動のFastly VCLで何ができるかを説明します。 継続または進化するボットキャンペーン、レイヤー7 （アプリケーションレイヤー） DDoS、または悪用が多くのIPとAPI エンドポイントにわずかに広がる場合、Adobeは高度なセキュリティ を提供します。
Advanced Securityは、Adobe Commerce on Cloud Infrastructure用の有料アドオンで、既にストアフロントにサービスを提供している同じFastly プラットフォームで、エッジボット管理（AIweb クローラーとフェッチャー検出を含む）、レイヤー7 DDoS対策、高度なレート制限を追加します。 完全な機能、現在の制限、およびそのリクエスト方法については、高度なセキュリティ を参照してください。
購入して有効化したら、Traffic Insights アプリを使用して、高度なセキュリティが機能していることを確認します。 その決定は、WAF Attack & Anomaly Signals、WAF Bots Signals、WAF Responseのリクエストの背後にある同じSigsci_TagsおよびAgent_response フィールドを通じて報告されます。 有効化する前と有効化した後のウィジェットを比較して、トラフィックに対してアクティブにアクションを実行していることを確認します。