スクレイピングチームに状況を尋ねると、たいてい一つの数値が返ってくる。成功率だ。これは分かりやすい指標であり、実際に有用ではあるが、パイプラインの運用単体で見ると、ほとんど役に立たない。なぜなら、チームリーダーが実際に答えを必要としている二つの問いを隠してしまうからだ。収集しているデータは正しいのか、そしてそれを収集するために支払っている費用は妥当なのか、という問いである。
パイプラインは98パーセントの成功率を報告しながら、静かにチャレンジページでウェアハウスを埋めていることがあり得るし、先月と同じ数値を今月も報告しながら、コストが2倍になっていることもあり得る。ここで紹介する指標セットは、その両方を捉えるもので、それぞれの用途ごとに整理してある。
まず、誰もが間違えがちな指標から始める
検証済み成功率。 200を返したリクエストの割合ではなく、欲しかったデータを実際に返したリクエストの割合である。
この区別こそ、ほとんどのチームがモニタリングに加えられる最も価値の高い変更だ。チャレンジページ、空の結果セット、途中で切れたリスト、同意ウォール、一般的な地域リダイレクトは、いずれも200ステータスとともに返ってくる可能性がある。ステータスコードを信頼するカウンターは、データセットが劣化していても健全だと報告してしまい、あなた自身のダッシュボードではなく、グラフがおかしいと尋ねてくるビジネスユーザーからその事実を知ることになる。ターゲットごとの有効性チェックを定義し、期待される要素、妥当なコンテンツ長、JSON内の必須フィールドなどを設け、それに合格したレスポンスのみをカウントすること。詳細はブロックや偽コンテンツの検出方法で解説している。
これはターゲットごと、地域ごとに追跡し、決して単一のグローバルな数値にしないこと。グローバルな95%は、すべてのターゲットが95%である場合もあれば、19個のターゲットが100%で1個が0%である場合もあり、これらはまったく異なる対応を必要とする。
データ品質の指標
有効性を超えて、出力が信頼できるかどうかを教えてくれる3つの数値がある。
カバレッジ。 実行で期待していたレコードのうち、実際にいくつ取得できたか。実行するすべてのリクエストで成功しているにもかかわらず、ページネーションが壊れたり、発見ステップの返却が少なくなったりして、昨日よりリクエスト数自体が少ないジョブは、成功率上は完璧に見えても、実質的には不完全だ。カバレッジはこれを捉える。
鮮度。 ソースごとに、最新のデータはどれくらい古いか。価格や在庫状況のような変化の速い業務では、技術的にすべて成功していても、データが古いこと自体が欠陥となる。そのため、ターゲットごとに直近の成功した収集の経過時間を追跡し、ユースケースが許容する範囲を超えたらアラートを出すこと。
フィールド単位の完全性。 収集したレコードのうち、必要なフィールドをすべて持っているものの割合。あるレイアウト変更が1つの属性を削除しても、リクエスト自体が失敗することはめったになく、単に列が静かにnullになるだけであり、フィールド単位の追跡だけがこれを早期に浮かび上がらせる。
これらを合わせることで「データは正しいか」という問いに答えられる。これは成功率だけでは分からないことだ。
効率とコストの指標
これらは「支払っている金額は妥当か」という問いに答えるものであり、通常最も計測が手薄な領域である。
レコードあたりのバイト数。 このセット全体の中で最も有用なコスト指標。消費した帯域を、ターゲットごとに抽出した有用なレコード数で割ったもの。これはさまざまな規模のジョブを正規化し、ターゲット間の比較を可能にし、この数値の急上昇はほぼ常に、データエンドポイントで済むところをフルページをレンダリングしていることを意味する。レジデンシャルプロキシはデータ転送量に応じて課金されるため、この数値はほぼあなたの単位コストに等しい。これを動かすレバーについては、プロキシ帯域幅コストの削減とヘッドレスブラウザが必要な場合の判断を参照のこと。
1000レコードあたりのコスト。 レコードあたりのバイト数に料金レートを掛けたもので、ターゲットごとに算出する。あるデータソースが収集するに値するかどうかを問う相手に提示すべき数値であり、インフラをビジネス側がすでに使っている言語に変換するものだ。これが月間帯域幅の見積もりにおける予測を具体化する。
リトライ比率。 総リクエストに対するリトライの割合で、ターゲットごとに見る。これは先行指標であり、成功率が下がる前に上昇する。なぜなら、リトライを重ねて正常に見える結果にたどり着くパイプラインは、問題を解決しているのではなく隠しているだけだからだ。また帯域課金型の製品においてはこれが純粋な無駄でもあるため、健全性シグナルであると同時にコスト項目でもあり、だからこそリトライとバックオフの中心に位置している。
ターゲットごとの帯域幅。 実際にお金がどこへ流れているかを示す。あるターゲット1つがプランの大半を消費していることに、チームは往々にして驚かされるが、可視化さえされれば修正は通常安価に済む。
パフォーマンスの指標
平均値ではなく、レイテンシのパーセンタイル。 ターゲットごとにp50、p95、p99を追跡すること。レジデンシャル接続は本質的に直接接続より遅いため、絶対値そのものよりも形状とトレンドが重要になる。平均値はテール部分を完全に隠してしまうが、時間制約のあるジョブが完了するかどうかを決めるのはまさにそのテールである。
計画に対するスループット。 1時間あたりのレコード数を、スケジュールが要求する値と比較する。これにより、より高い並行性が必要か、ペーシングを改善すべきか、あるいは別の収集戦略が必要かが分かる。これは実際に必要なプロキシIP数という配分の問いに対する実践的な入力でもある。
ブロック・チャレンジ率。 失敗したリクエストとは区別される、ブロック、キャプチャ、またはチャレンジであった応答の割合。成功率が安定しているのにチャレンジ率が上昇している場合、同じ出力のためにより多くの労力をかけていることを意味し、ターゲット側の防御が変わった早期警告となる。
追跡すべきでないもの
多く計測されている割に、それに見合う注意を払う価値がない2つのものがある。
プールサイズ。 これはベンダー側の数値であり、パフォーマンス指標ではなく、あなたの結果を予測しない。実際に収集する国々における密度こそが重要であり、それを知る唯一の方法は地域ごとの自社の成功率である。
生のリクエスト数。 有効性を伴わない量は、出力ではなく単なる活動である。同じ数の使用可能なレコードを収集しながらリクエスト数を2倍にしたパイプラインは悪化しているのに、リクエストカウンターはそれを成長だと呼んでしまう。
同様に、稼働率SLAの使い方にも注意が必要だ。プロバイダーの可用性は現実のものであり監視する価値はあるが、それはターゲットがあなたのトラフィックを受け入れるかどうかとは別の軸であり、この2つを混同すると、契約上は保護されているのに運用上は盲目という状態に陥る。これはプロキシのSLAと稼働率保証で論じている境界線である。
指標をアラートに変える
誰も見ないダッシュボードは装飾にすぎない。上記の指標に紐づいた少数のアラートこそが、実際にパイプラインを守るものだ。
検証済み成功率がターゲットごとの閾値を下回った場合にアラートを出すこと。1つの数値がすべてのサイトに当てはまるわけではないからだ。カバレッジが先週の同じ実行に対して低下した場合にアラートを出すこと。これは静かな縮小を捉える。鮮度がユースケースの許容範囲を超えた場合にアラートを出すこと。レコードあたりのバイト数が急激に上昇した場合にアラートを出すこと。これはコストの悪化であり、通常はコード変更が原因だ。そしてリトライ比率の上昇に対してアラートを出すこと。これが最も早く発火するからだ。
これらを運用可能にする実践的なルールが2つある。固定の数値ではなく移動ベースラインと比較すること。ターゲットにはそれぞれ独自のリズムがあり、静的な閾値はオオカミ少年になるか、まったく発火しないかのどちらかになる。そして、単発の悪い区間ではなく持続的な逸脱を要求すること。5分間の悪い区間1つはノイズにすぎない。計測そのものについてはWebスクレイピングパイプラインの監視で扱っている。
最小限の出発点セット
ゼロから計測を組み立てるなら、ターゲットごとの6つの指標でほとんどの価値が得られる。検証済み成功率、期待に対するカバレッジ、最新レコードの鮮度、レコードあたりのバイト数、リトライ比率、そしてp95レイテンシだ。最初の2つには地域を次元として追加すること。複数市場にまたがるパイプラインが静かに失敗するのは、まさに地理の部分だからだ。それ以外はすべて、これら6つのいずれかが答えられない疑問を提起するまで待ってよい。
結論
成功率は、リクエストが完了したかどうかに答えるものであり、チームリーダーが抱える3つの問いのうち最も興味の薄いものだ。返ってきたものを成功としてカウントする前に検証し、データが正しいかを知るためにカバレッジ、鮮度、フィールドの完全性を測り、価格が妥当かを知るためにレコードあたりのバイト数、1000レコードあたりのコスト、リトライ比率を測ること。すべてをグローバルではなくターゲットごと、地域ごとに追跡し、移動ベースラインからの持続的な逸脱に対してアラートを出し、プールサイズや生のリクエスト数でインフラを判断することは避けること。重要な指標とは、判断を変える指標であり、ここに挙げたものがまさにそれである。
ネットワーク自体に対する計測は別の作業であり、速度、成功率、位置精度のテスト方法で扱っている。その基盤となるレジデンシャルプロキシはGBあたりで課金されており、だからこそレコードあたりのバイト数が注視すべきコスト指標なのだ。それは、あなたの請求書がそこから成り立っている数値である。