Cutter 8
合計$96.90 · 5%割引
- vCPU
- 4 × 専用
- RAM
- 8 GB
- ストレージ
- 160 GB NVMe SSD
- 転送量
- 10 TB
- IPv4 / IPv6
- 1 / /64 routed
解決策
スクレイピングはCPUバウンドではなくメモリバウンドです。ヘッドレスChromiumのタブ1つで約300MB消費するため、並行性に基づいて計画します。4コアと8GBで約20の並行ブラウザコンテキストが実行できます。実際に成功を左右するのはIPの多様性と管轄権です—クリーンなアドレス空間、複数のIPv4アドレス、そしてクロールレートに関する単一の苦情でアカウントを停止しないプロバイダーが必要です。
| リソース | 実際に必要なもの |
|---|---|
| CPU | 約20の並行ヘッドレスブラウザ用に4コア |
| RAM | 最小8 GB。大規模にJavaScriptをレンダリングする場合は16 GB |
| ディスク | キャッシュと成果物用に160 GB NVMe |
| IP | 追加IPv4アドレス。パネルからインスタンスごとに追加 |
| 転送量 | 10 TB—レンダリングされたページは思ったより重い |
合計$96.90 · 5%割引
合計$176.70 · 5%割引
合計$262.20 · 5%割引
このワークロードでは、通常ロケーションの選択が最も重要です—レイテンシが支配的になるか、管轄権が支配的になるかのどちらかだからです。
専用コア4つと8GBが実用的な出発点です。
Playwright または Puppeteer と同梱の Chromium を、Docker 内で実行してクリーンに破棄します。
各ワーカーを SO_BINDTODEVICE またはアウトバウンドプロキシで異なる送信元アドレスにバインドします。
ポライトネス遅延により、ブロックリスト入りを防ぎ、プロジェクトを持続可能に保ちます。
オブジェクトストレージまたは Hold インスタンスにストリーミングすることで、再構築にかかるコストをゼロにします。
はい、合法的にアクセス可能な公開データについて、ターゲットを劣化させないレートで許可します。資格情報の stuffing、ペイウォールや認証の回避、または不正アクセスを構成するスクレイピングは許可しません。
パネルからインスタンスごとに最大8つの追加 IPv4 アドレスに加え、ルーティングされた IPv6 /64 を利用できます。
法的分離のためターゲットの管轄外、かつレイテンシのためターゲットに近い場所です。欧州のターゲットにはアムステルダム、モルドバ、ソフィアが通常の妥協点です。