CDNについてGoogleが解説

クロールの12月：CDNとクローリング

コンテンツ配信ネットワーク(CDN)は、Webサイトの反応時間を短縮し、Webトラフィック関連の悩みを解消するうえで特に有効な方法です。結局、CDNの主な目的はこれです。つまり、サイトに大量のトラフィックが流入しても、コンテンツを迅速に配信することです。CDNの“D”は、世界中にコンテンツを配信または配布することを意味します。そのため、ユーザーへの転送時間も、どこかの1つのデータセンターでホストするより短時間で済みます。そこで、この記事では、CDNを活用してサイトのクロールとユーザーエクスペリエンスを向上させる方法を模索し、CDNでバックアップされたサイトのクロールに関する意図についてもご説明します。
　

要約：CDNとは何か

CDNは基本的に、オリジンサーバー(Webサイトが存在する場所)とエンドユーザーとの仲介役の存在であり、オリジンサーバーに代わって(一部の)ファイルをエンドユーザーに提供します。これまでの長い目で見ても、CDNの最大の特徴はキャッシュです。つまり、ユーザーがサイトに対してURLを要求すると、CDNはそのURLの内容を一定期間キャッシュに保存するため、オリジンサーバーはしばらくの間そのファイルを再度提供する必要がなくなります。
CDNは、ユーザーに近い場所からサービスを提供することで、サイトの表示速度を大幅に向上させることができます。たとえば、オーストラリアのユーザーがドイツでホストされているサイトにアクセスしている場合、CDNはオーストラリアのキャッシュからそのユーザーにサービスを提供して、地球をまたぐほどの往復時間を短縮することができます。光速であろうとなかろうと、距離というのは依然としてかなり大きいです。
そして最後に、CDNはサイトを過負荷やセキュリティの脅威から守る素晴らしいツールと言えます。CDNが管理するグローバルトラフィックの量に応じて、信頼性の高いトラフィックモデルを構築し、トラフィックの異常を検出し、過剰または悪意のあると思われるアクセスをブロックできます。たとえば、2024年10月21日、Cloudflareのシステムは、約1分間続いた4.2Tbps(編集者注：これはかなり大きいです)のDDoS攻撃を自律的に検出し、軽減しました。
　

CDNがサイトにどう役立つか

最速のサーバーと最高のアップリンクを所有しているから速度を上げる必要はない、と考える人もいるかもしれませんが、CDNは長期的にはコストを節約できます。特にサイトが大きい場合はなおのこと発揮します：

• CDNでのキャッシュ：メディア、JavaScript、CSS、さらにはHTMLなどのリソースがCDNのキャッシュから提供される場合、サーバーはそれらのリソースの提供にコンピューティングと帯域幅を費やす必要がなくなり、その過程でサーバーの負荷が軽減されます。これは通常、ユーザーのブラウザでのページの読み込みが速くなることも意味し、コンバージョンの向上にも繋がるでしょう。
• トラフィックフラッド保護：CDNは、過剰なトラフィックや悪質なトラフィックを識別してブロックするのに特に優れているため、不正なボットや悪質なユーザーがサーバーに過負荷をかけている場合でも、ユーザーがサイトにアクセスできるようにします。
  フラッド保護に加えて、不正なトラフィックをブロックするために使用される同じ制御を使用して、特定のクローラー、特定のパターンに当てはまるクライアント、または同じIPアドレスを使用し続けるトロールなど、単に不要なトラフィックをブロックすることもできます。サーバーやファイアウォールでもこういったことを行うことができますが、通常はCDNのユーザーインターフェイスを使用する方がはるかに簡単です。

• 信頼性：一部のCDNは、サイトがダウンしている場合でも、ユーザーにサイトを提供できます。もちろん、これは静的コンテンツにしか機能しないかもしれませんが、ユーザーが他のサイトに移らないようにするには、それだけでも十分かもしれません。

つまり、CDNはWebサイトの味方であり、サイトが大きい場合や大量のトラフィックが予想される場合(または既に大量のトラフィックを受信して​​いる場合)は、価格、パフォーマンス、信頼性、セキュリティ、カスタマーサポート、スケーラビリティ、将来の拡張などの要素に基づいて、ニーズに合ったCDNを使用することをオススメします。ホスティングプロバイダまたはCMSプロバイダに問い合わせて、オプション(または既に使用しているかどうか)をご確認ください。
　

クロールがCDNを使用するサイトに与える影響

クローリングの面では、CDNも役立ちますが、クローリングの問題を引き起こす可能性があります(稀です)。下記ご覧ください。
　
CDNのクロール率への影響
Googleのクロールインフラストラクチャは、CDNによってサポートされているサイトでより高いクロール率を可能にするように設計されています。これは、クローラーがアクセスするURLを提供しているサービスのIPアドレスから推測されます。これによって、ほとんどの場合はうまく機能します。
例えば、今日ストックフォトサイトを立ち上げたとします。ストック写真が1,000,007枚あります。ランディングページ、カテゴリページ、すべてのアイテムの詳細ページを備えたWebサイトを立ち上げると、当然ページ数が多くなります。クロール容量制限に関するドキュメントでは、Google検索はこれらすべてのページをできるだけ早くクロールしたいと考えますが、クロールによってサーバーが過負荷にならないようにする必要があることを説明しています。クロール リクエストの数が増えてサーバーの応答が遅くなると、サーバーの過負荷を防ぐためにGoogle側でスロットリングが適用されます。このスロットリングに関して、サイトがCDNによってバックアップされていることがクローリングインフラストラクチャによって検出されることで、サーバーが処理できる可能性が高いと判断され同時にリクエストを送信しても問題ないと想定された場合、そのしきい値ははるかに高くなります。これにより、Webサイトへのクロールが高速化されます。
ただし、URLへの最初のアクセスでは、CDNのキャッシュは“コールド”です。つまり、まだ誰もそのURLをリクエストしていないため、そのコンテンツはCDNによってまだキャッシュされていません。そのため、オリジンサーバーは、CDNのキャッシュを“ウォームアップ”するために、そのURLを少なくとも1回は提供する必要があります。これは、HTTPキャッシュの動作と非常によく似ていると言えます。
つまり、WebサイトがCDNによってサポートされている場合でも、サーバーは少なくとも1回は1,000,007個のURLを処理する必要があります。最初の処理が終わって初めて、CDNはキャッシュで対応できるようになります。これは“クロール バジェット”に大きな負担となり、クロール率は数日間高くなる可能性があります。一度に多数の URLを起動する予定がある場合は、この点にご注意ください。
　
CDNのレンダリングへの影響
クロールに関する12月の最初のクロールブログ投稿で説明したように 、リソースを独自のホスト名またはCDNホスト名(cdn.example.com)に分割すると、Webレンダリングサービス(WRS)でページをより効率的にレンダリングできるようになります。ただし、注意点があります。この方法では、別のホスト名への接続の負荷過多によりページのパフォーマンスに悪影響が出る可能性があるため、レンダリングパフォーマンスとページエクスペリエンスを慎重に検討する必要があります。
これは、メインホストをCDNでバックアップすると、問題を回避できます：クエリするホスト名は1つで、重要なレンダリングリソースはCDNのキャッシュから提供される可能性が高いため、サーバーがそれらを提供する必要がありません(ページエクスペリエンスに影響はありません)。
最終的には、ビジネスに最適なソリューションを選択しましょう：静的リソース用に別のホスト名(cdn.example.com)を用意するか、メインのホスト名をCDNでバックアップするか、またはその両方を実行します。Googleのクロールインフラストラクチャは、どちらのオプションも問題なくサポートします。
　

CDNが過剰保護になってしまうと

CDNのフラッド保護とクローラーのクロール方法により、サイトにアクセスしてほしくないボットがCDNのブロックリストーー通常はWebアプリケーションファイアウォール(WAF)、に登録されることがあります。これによりクローラーがサイトにアクセスできなくなり、最終的にはサイトが検索結果に表示されなくなる可能性があります。ブロックはさまざまな方法で発生する可能性があり、Googleの検索結果でのサイトの表示に他の方法よりも悪影響を与えるものもあれば、CDN側で発生するため制御が難しい(または不可能)こともあります。このブログ投稿では、ブロックをハードブロックとソフトブロックの2つのカテゴリに分類しています。
　

ハードブロック
ハードブロックとは、CDNがクロール要求に対して何らかのエラーの応答を送信した場合に発生します。これには次のようなものがあります：

• HTTP503/429ステータス コード：これらのステータスコードを送信することは、一時的なブロックを通知するための推奨される方法です。これにより、CDNによる意図しないブロックに対処する時間が与えられます。
• ネットワークタイムアウト：CDNからのネットワークタイムアウトが発生すると、影響を受けるURLがGoogleの検索インデックスから削除されます。これは、これらのネットワークエラーが致命的な“ハード”エラーと見なされるためです。また、サイトが過負荷になっていることをクローインフラストラクチャに通知するため、サイトのクロール率にも大きな影響を与える可能性があります。
• 200HTTPステータスコード付きのランダムエラーメッセージ：ソフトエラーとも呼ばれるこのエラーメッセージは、特に悪質です。エラーメッセージがGoogle側で“ハード”エラー(HTTP500等)とみなされた場合、Googleは検索からURLを削除します。Googleがエラーメッセージを“ハード”エラーとして検出できなかった場合、同じエラーメッセージを持つすべてのページがGoogleの検索インデックスから重複として削除される可能性があります。Googleのインデックス作成では重複URLの再クロールを要求する動機がほとんどないため、この状態から回復するには時間がかかる可能性があります。

ソフトブロック
CDNが“本当に人間ですか？”というインタースティシャルを表示するときにも、同様の問題が発生する可能性があります(これはしゃれのつもりです)。
実際、当社のクローラーは、自分は人間ではないと理解しており人間を装っているわけでもありません。ただクロールしたいだけです。しかし、インタースティシャルが表示されると、クローラーが目にするのはあなたの素晴らしいサイトではなく、インターステイシャルの表示部分だけです。これらのボット検証インタースティシャルの場合、コンテンツが一時的に利用できないことをクローラーなどの自動クライアントに503 HTTPステータスコードの形式で明確に伝えることを強くお勧めします。これにより、コンテンツがGoogleのインデックスから自動的に削除されなくなります。
　

障害のデバッグ
ハードブロックとソフトブロックの両方において、正しく動作しているかどうかを確認する最も簡単な方法は、Search ConsoleのURL検査ツールを使用してレンダリングされたイメージを確認することです。ページが表示されれば問題ありません。空のページ、エラー、またはボットチャレンジのあるページが表示される場合は、CDN に相談することをお勧めします。
さらに、こうした意図しないブロックに対処するため、Google、その他の検索エンジン、その他のクローラーオペレーターは、当社のIPアドレスを公開して、クローラーを識別できるようにしています。また、適切と思われる場合は、ブロックされたIPをWAFルールから削除したり、許可リストに追加したりすることもできます。これをどこで実行できるかは、使用しているCDNによって異なります。幸い、ほとんどのCDNと単独型WAFには、すばらしいドキュメントがあります。少し検索すると、次のようなドキュメントが見つかります(この記事の公開時点)：

• クラウドフレア：https://developers.cloudflare.com/bots/get-started/free/#visibility
• アカマイ：https://www.akamai.com/products/bot-manager
• ファストリー：https://www.fastly.com/products/bot-management
• F5：https://clouddocs.f5.com/bigip-next/20-2-0/waf_management/waf_bot_protection.html
• Googleクラウド：https://cloud.google.com/armor/docs/bot-management

サイトを検索エンジンに表示する必要がある場合は、重要なクローラーがサイトにアクセスできるかどうかを確認することを強くお勧めします。知らないうちにIPが自動的にブロックリストに登録される可能性があるため、ブロックリストを定期的に確認することで検索エンジンフレンドリーにしておきましょう。ブロックリストが非常に長い場合(このブログ投稿みたいですが)、IP範囲の最初の数セグメントだけを検索するようにしてください。たとえば、192.168.0.101を検索するなら、192.168だけを検索すれば良いです。
この記事は、クロールの12月投稿特集の最後です。私たちが今回のブログを書いたのを楽しんだのと同じくらい、皆様も楽しんでいただければ幸いです。ムニャムニャ…という感じであれば、もうやり方はご存じでしょう。

引用）Search Central Blogより和訳