← すべての記事
プロダクトアップデート 読了時間 2 分

Autoの紹介: あらゆるターゲットに対応する単一のendpoint

Auto endpointは、各requestに対してSingle、Proxy Finder、またはBrowserを選択し、アンチボットのチャレンジを処理して、次の呼び出しで再利用可能なsessionを返します。

autoapiorchestrationsessionsanti-bot

新機能

/api/auto endpointは、あらゆるURLから有効なresponseを取得するための最短ルートになりました。ターゲットを指定するだけで、AutoがrequestをSingle、Proxy Finder、Browserのどれで実行するかを選択し、anti-botのチャレンジに遭遇した場合は処理を行い、次の呼び出しで再利用可能なセッションを返します。

単一のendpoint。あらゆるターゲット。ユーザー側でのモード切り替えは不要です。

これが全体像です。本記事の残りの部分では、その仕組み、コスト、および注意点について説明します。

仕組み

Autoの背後には、階層(低コストから高コストの順)が存在します。各requestにおいて、Autoはvalidateルールが許容するresponseを返す階層に到達するまで順に実行します。

各階層の順序は以下の通りです。

  1. Cached session. 以前の呼び出しからこのホストのウォームセッションがAutoにある場合、まずそれを利用して再試行します。最も低コストな経路です。
  2. Proxy Finder. ローテーションされたproxy request。主にIPレピュテーションで保護されているサイトに適しています。
  3. Browser. JavaScriptを実行し、anti-botのチャレンジを解決し、サイトが発行するcookieを収集する完全なレンダリング。

ある階層が成功すると、Autoは取得したセッション(使用したproxyのID、サイトが発行したcookie、およびUser-Agent)を保存します。同じホストへの次回の呼び出しでは、Autoはまずそのセッションを試します。それが引き続き機能する場合、高コストな階層ではなく、低コストな階層の料金が適用されます。

最小限の呼び出し例:

curl -X POST "https://api.foura.ai/api/auto" \
  -H "Authorization: Bearer pk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/data",
    "validate": { "status": { "accept": [200] } }
  }'

トリミングされた response:

{
  "status": 200,
  "data": "...",
  "headers": [...],
  "meta": {
    "rung": "cache",
    "solved": false,
    "attempts": 1,
    "credits": 2
  },
  "session": {
    "proxy": "CLN1B8",
    "cookies": [{ "name": "cf_clearance", "value": "..." }],
    "userAgent": "..."
  }
}

次に構築するものにとって2つのフィールドが重要です。meta.rungはどのパスが成功したかを示します。sessionは、同じexitを自分で再実行するために/api/single呼び出しに渡すことができるトリプルです。proxyフィールドは不透明なbase36 ID(生のIPではありません)であり、ログ記録やシステム間の受け渡しに安全です。

Impact

ここでは2つの数字が重要です。

保護されたサイトへの最初の呼び出しではBrowserラングが実行されます。レンダリング、解決、cookieの収集を行い、ページを返します。これには約10クレジットかかります。Autoがそのホストの有効なセッションをキャッシュすると、後続の呼び出しはSingleを通じて2クレジットで実行されます。そのため、2回目の呼び出しは最初の呼び出しの5分の1のコストになり、セッションが維持される限り、それ以降の呼び出しも低コストで実行されます。ロールアウト中の本番環境でこれを測定しました。cookieなしのexit(一度見つかれば)は、すべてのリクエストがProxy Finderを経由していた時の10クレジットに対し、正確に1コールあたり2クレジットで再実行されます。

2つ目の数字について説明します。失敗したラングには課金されません。Autoが3つのプロキシを試行し、4つ目が配信する前にそれぞれが403を返した場合、4つ目のクレジットのみがカウントされます。検索ではなく、配信されたコンテンツに対して支払います。

これが中心となる価値です。高価なラングは一度だけ実行され、安価なラングはその後継続して実行されます。自分でキャッシュロジックを記述する必要はありません。

実際の運用上の問題を解決するため、他に2つの動作に注目する価値があります。

ジオフェンスされたターゲットによるexitの浪費を停止します。 サイトがほとんどのexitに対して451(または法的にブロックされたインタースティシャル)を返す場合、Autoはどの国が実際にコンテンツを配信したかを学習します。次の呼び出しでは、まずそれらの国から新しいexitを取得し、同時負荷をそれらに分散させます。そのため、単一の幸運なexitに負荷が集中してレート制限されることはありません。

Validateはすべてのラングで実行されます。 誤ったコンテンツのページ(本文に法的通知を含みステータス200を返すジオブロック)がヒットとしてカウントされることはありません。validate.data.failに「legal reasons」と記載されている場合、Autoはラングがそれをパスするまで試行を続けます。キャッシュされたラングではありません。どのラングでもありません。何もパスしない場合は、本当の理由とともに正確な失敗が返されます。

For Power Users

Autoで大量のボリュームを処理する際に重要となるいくつかの設定があります。

timeout_msはラング単位ではなく、操作全体の予算です。デフォルトは120秒です。Autoはこれを分割します。各サブコールは、固有のタイムアウトと残りの予算のいずれか短い方を取得します。残り時間が少なくなると、ラダーは新しいラングの起動を停止します。インタラクティブなレイテンシの処理には20,000を設定してください。長いテールを許容するバルククロールにはデフォルトのままにしてください。

forceProxyはデフォルトでオンになっています。forceProxy: falseを設定しない限り、AutoがFourAのオリジンIPからターゲットに接触することはありません。1つ注意点があります。一部のサイト(IP信頼性ゲーティングを持つインタラクティブなCloudflare)は、信頼性の低い住宅用exitよりも、クリーンなデータセンターIPからの方が実際にうまく機能します。そのため、forceProxy: falseは特定のターゲットをより困難にするのではなく、より容易にする可能性があります。特定のホストで繰り返しチャレンジが発生している場合は、これをオフにしてみる価値があります。

ignoreProxiesはクライアント側の回避リストです。(過去のsession.proxyでrate limitに達したなど)無効になったと分かっているproxy IDを渡すことで、Autoはウォームセッションの再利用、exitの検索、Proxy Finderへのサブコールのすべてにおいてそれらをスキップします。つまりAutoは、回避するように指定されたexitを再び選択することはありません。

metaを使用すると、独自のダッシュボードを構築することもできます。今日どのホストがブラウザ層に到達したか、配信あたりの平均試行回数、解決済みのチャレンジフェッチとクリーンなフェッチの比率などを確認できます。特定のホストが突然2クレジットから10クレジットに上昇した場合、それはセッション劣化のシグナルであり、請求額が膨れ上がる前に対処できます。

これら4つをすべて組み合わせた例を以下に示します。

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://example.com/product/9876",
        "timeout_ms": 30000,
        "forceProxy": True,
        "ignoreProxies": ["CLN1B8", "K7X9AB"],
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
        }
    }
).json()

# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
    session = r["session"]                              # {proxy, cookies, userAgent}
    print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])

validateスキーマ自体については、以前の解説であるValidate Rules Now Decide What Counts as Successを参照してください。

今後の予定

現在、Autoのロードマップには2つの項目があります。

次にDashboardにセッション検査機能が導入されます。現状、Autoがホストごとに保持するセッションはサービス内に存在し、ユーザー側から問題のデバッグを行う際に確認できるものがありません。現在ホストごとのセッションビューを構築しており、キャッシュされたセッション、その経過時間、有効期間、およびそれぞれの背後にあるrung履歴を確認できるようになります。また、ターゲットが変更されキャッシュが不適切であることがわかっている場合に、手動でセッションを破棄するボタンも追加されます。

その後は、より厳格なコスト管理機能です。リクエストごとの厳密なクレジット上限(この呼び出しでX以上は消費せず、超過する場合は素直に失敗させる)と、ブラウザのrungを必要としないターゲットを持つチーム向けの「single-only」モードです。現在、どちらもフラグ機能として提供されています。

Autoの目的は、どのプロダクトを呼び出すかを意識させないことです。しかし、それは何が起きたかを検査できないという意味ではありません。すべてのレスポンスには、使用したrungと構築されたセッションが含まれます。これら2つのフィールドを確認すれば、なぜその呼び出しにそのコストがかかったのかを正確に把握できます。