- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
AIが翻訳した投稿です。
durumis AIが要約した投稿
- Google検索のクロール予算を効率的に活用するために、Webページの転送速度の改善とCloud Runベースのリダイレクトサービスの導入を行いました。
- robots.txt、favicon.icoなどの静的ファイルとリダイレクションロジックをCloud Runに移行することで、従来のGKE Autopilotと比較して応答速度を200msから20msに改善しました。
- 世界中のさまざまなリージョンにCloud Runを展開することで、ユーザーの位置に近いサーバーからサービスを提供し、速度の向上とコスト削減の効果を実現しました。
すべてのコンテンツをメインとするサービスは、Googleの検索に多く表示されることを望んでいます。
しかし、Googleの検索に表示されるためには、クローラーが頻繁にアクセスして最新のデータをクロールし、それを適切に反映する必要があります。
このとき、クローラーがウェブサイトに頻繁にアクセスするためには、「クロール予算"を利用して、予算が高ければ高いほど頻繁にアクセスでき、そのためにはサイトのトラフィックが一定量必要になります。
では、この限られた「クロール予算」をどのように効率的に活用すれば、同じ予算でより頻繁にアクセスしてもらえるのでしょうか?
それは、サイトのウェブページの転送速度が速くなければなりません。例えば、ページのダウンロード時間が200msのサイトよりも20msのサイトの方が、より頻繁にページをクロールしていくのです。
ドゥルミスは基本的に「グローバルサービス」を目指しているため、世界8つのリージョンで基本的なトラフィックをサービスしています。
GCPサーバーリージョン
現在、基本的には当社のサービスはGoogleの40のリージョンのうち、アジアのソウル、シンガポール、ムンバイ、ヨーロッパのベルギー、アメリカのロサンゼルス、サウスカロライナにあるリージョンを利用しています。世界中どこからアクセスしても、ほとんどの場合、遅延なくアクセスできるのです。
しかし、前述した理由から、さらに極限の速度を求めて、少しチューニングすることにしました。
現在、当社のサービスは初期のローンチ時にURL方式から新しいサブドメイン方式に変更するプロセスを経ており、リダイレクトが一部存在し、この部分にGoogleのクローラーが頻繁にアクセスしています。既存のURLを新しいURLにGoogleに迅速に認識させる必要があるのです。
そのため、与えられたクローラー予算を最大限に活用するために、リダイレクト用のトラフィックは可能な限り高速に維持する必要があるのです。
従来は、前述の8つのリージョンにGKEが配置されており、それぞれのGKEはGoogleのGKE Autopilotを利用して、DBと連携しないデータを使用してリダイレクトを実行しています。
そのため、今回、GKEにあるものと、従来から別のCloud Runにあった一部のロジックを新しいCloud Runに移行することにしました。移行しようとしているリストは以下の通りです。
- robots.txt:静的なファイルですが、複数のサブドメインで一定のロジックで内容を提供しています。
- favicon.ico:純粋な静的ファイル
- durumis.com/[lang]/@userId/postID:新しいURLにリダイレクト -> userId.durumis.com/[lang]/postID
従来は、GKE Autopilotにあるやや重いフレームワークで提供していた場合、約200msの応答時間でした。
新しい方法は、Cloud Runを使って実行し、非常にシンプルなロジックなのでフレームワークを使用せず、node:httpを使ってライブラリなしで基本コードを使用しました。
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 生략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
( 上記のコードをそのまま貼り付けると動作しません。大まかな概念だけ理解してください。)
favicon.icoは画像ファイルなので、fileから読み込んでメモリに常駐させ、それを利用して送信する方法を選択しました。
シェルスクリプトを使ってgcloudを利用し、複数のリージョンに同時にデプロイします。
ジャーン…
このようにしてデプロイした結果は次の通りです。
Cloud Run画面
アメリカの「すべてのリージョン」にデプロイし、大陸別にヨーロッパに2つ、アジアに2つ、アフリカに1つ、南米に2つのリージョンにデプロイしました。実際、Serverlessの利点ですが、このようにしてもコストは全く増加しません。(むしろ、近い場所のトラフィックを提供するようになれば、コストが削減される可能性もあります。)
さあ、これで速度はどれくらい速くなったのでしょうか。
従来のサーバー側の応答速度は以下の通りです。
GKE Autopilot
改善された速度は以下の通りです。
Cloud Runを活用した静的ファイル
当然、Cloud RunはServerlessなので、コールドスタート時間があるのではないかと思われるかもしれませんが、一定期間にわたってクローラーが継続的にアクセスする状況では、実際には大きな問題にはなりません。GCPのServerlessの特徴の一つですが、StandbyとIdleを行き来しながら待機しているためです。(コストが増加することもありません)
次回の投稿では、上記のような小さな静的ファイルや301リダイレクトではなく、画像ファイルやその他のファイルに関する部分を説明します。