aiohttp とは何か？

Scrapeless Proxies は、aiohttp クライアントが非同期の公開 Web リクエストに利用できるネットワーク経路を提供します。

aiohttp は、asyncio を中心に構築された非同期 HTTP クライアントおよびサーバー向けの Python ライブラリです。クライアント側はリクエストを送信し、各待機処理ごとに別個のアプリケーションスレッドを占有することなくレスポンスを公開します。また、このライブラリはサーバーや WebSocket のユースケースもサポートしており、その範囲はページのダウンロードを超えています。

コレクションサービスにおいて、aiohttp は独立したネットワーク処理を重ね合わせられる場合に有用です。その利点は、作業の受け入れ方法、レスポンスの消費方法、およびアプリケーションの残りの部分がイベントループと協調するかどうかに依存します。async 構文を追加するだけでは、境界が明確で責任あるコレクションシステムにはなりません。

asyncio は待機を調停し、aiohttp は HTTP を提供する

asyncio は、互換性のある非同期処理で使用されるイベントループとタスク調整を提供します。 Python の非同期 I/O モデル では、コルーチンが待機中に一時停止し、他の準備のできた処理を先に進めることができます。aiohttp は、そのモデルに参加する HTTP 処理を提供します。

並行性は、リモートサーバーの応答時間を短縮することとは異なります。独立したリクエストがネットワーク活動の待機に時間を費やすのであれば、アプリケーションはそれらの待ち時間を重ね合わせることができます。遅いソースは、そのソース自身のリクエストに対しては依然として遅く、サービス側にはソースの能力とローカルリソースを尊重する制限が必要です。

CPU 集約的な処理は別の振る舞いを持ちます。イベントループスレッド上で動作する同期パーサーや変換処理は、すべてのネットワーク呼び出しが非同期であっても、他のタスクを遅延させる可能性があります。リクエストの並行数を増やす前に、時間がどこで費やされているかを計測してください。より多くのレスポンスをアクティブにしても、受け入れ済み出力のスループットを改善しないまま、パースのバックログを大きくするだけの場合があります。

アプリケーションの非同期境界を理解しやすく保ちましょう。すでに asyncio を中心に構築されたサービスであれば、aiohttp と首尾一貫したライフサイクルを共有できます。一方で、小さな同期スクリプトは、処理の重ね合わせによる実利がない限り、同期クライアントを使う方が運用しやすい場合があります。ライブラリの選択は、一般的な「async 好き」ではなく、プログラムの実行モデルに従うべきです。

ClientSession は再利用可能なリクエストコンテキストを所有する

aiohttp の ClientSession は、再利用可能なコネクションや Cookie を含む関連するリクエスト状態をまとめます。 aiohttp client lifecycle は、リクエストごとに新しいセッションを作るのではなく、セッションの再利用を推奨します。再利用により、関連するリクエストが意図したコネクション基盤を共有できます。

アプリケーションの非同期ライフサイクルの中でセッションを作成し、そのスコープが終わるときにクローズしてください。有限なコレクタであればバッチ処理の周囲にセッションを配置でき、サービスであれば起動と停止の流れの中で管理できます。セッションの所有関係を暗黙にしたままにすると、どのコンポーネントがリソースを解放すべきか説明しづらくなります。

共有状態には意図的な境界が必要です。異なるアカウントや Cookie コンテキストに結びついたリクエストは、宛先ホストが同一であっても、別々のセッションを必要とする場合があります。逆に、1 つの連続したソースとの対話を表すリクエストは、同じコンテキストを維持することで恩恵を受けられます。

認証情報は便宜のために拡散させるべきではありません。機微なヘッダーを保持するクライアントを、任意に見つかった宛先向けの汎用ダウンローダとしても使うべきではありません。承認されたホストの識別情報や有用な結果フィールドは記録しつつ、認可値や Cookie の内容は通常の診断情報からは除外してください。

レスポンスにはヘッダーのフェーズとボディのライフサイクルがある

HTTP レスポンスは、ボディが完全に消費される前にステータスとヘッダーを公開できます。アプリケーションは依然としてボディを読み、適切にデコードするか、あるいはどこかへストリーミングする必要があります。これらの処理には、それ自体のリソースおよび正しさに関する影響があります。

この HTTP 表現モデル では、レスポンスのステータスと転送されるコンテンツが区別されています。成功ステータスは有用な伝送上の証拠ですが、ボディには依然として予期しないドキュメントやアプリケーションレベルのエラーが含まれる可能性があります。受け入れには、意図したコンテンツの同一性も含めなければなりません。

テキストを読むにはエンコーディングの決定が必要です。JSON のデコードには、有効な構文だけでなく、利用者に適したスキーマチェックも必要です。いずれも、レスポンスが要求されたソースエンティティや報告期間に属することを確立したり、そのように報告したりするための近道として使うべきではありません。

ボディの消費戦略は 1 つを意図的に選んでください。小さなページをメモリに読み込むことはパースを簡素にしますが、大きなダウンロードではストリーミングが必要になることが多いです。部分的にしか消費されていないレスポンスを、「完全なボディを所有している」と想定する別コンポーネントに渡すのは避けてください。所有権は関数境界ではっきりさせる必要があります。

ストリーミングは、宛先が追いついている場合にのみメモリを制御できる

ストリーミングは、ボディ全体をメモリに集めるのではなく、到着したボディを部分ごとに処理します。これにより大きなリソースに対するバッファリングを減らせますが、それが有効なのは、後段の処理もまた境界のある作業フローを守る場合に限られます。

チャンクを読み込んですぐに上限のないメモリ上のリストに追加するだけのダウンローダは、単にバッファを移動しただけです。信頼できるストリームは、追いつける宛先へ書き込むか、宛先が遅くなったときにバックプレッシャーを適用します。予想外に大きなリソースが無制限にストレージを消費できないよう、明示的なサイズ方針を含めてください。

部分的な出力には、それ自体の同一性が必要です。大きな成果物は、必要な転送および検証条件が満たされるまでは「不完全」として書き込みます。そのうえで初めて、受け入れ済み出力の参照を通じて公開します。ディスク上にファイルが存在することは、ソースからの転送が完了したことや、その内容が後段の利用に適していることの証拠にはなりません。

成果物を説明できるだけのメタデータを保持してください。ソースのコンテキスト、コンテンツの種類、完了結果、適切な完全性参照などは、保存されたバイト列をそれを生成したリクエストに結び付けるのに役立ちます。資格情報や不要なヘッダーを、単にそのフィールドが利用可能だったという理由だけでファイルと一緒に保存することは避けてください。

保留中の作業とアクティブな接続の両方を制限する

接続数制限は接続の利用を制御し、アプリケーションキューはアクティブになるまで待機する作業量を制御します。巨大なタスク集合を作成すると、同時に実行を許可されている接続数が少数であってもメモリを消費する可能性があります。

プロデューサーとワーカーの設計により、その境界を明示できます。プロデューサーは承認された URL を制限付きキューに投入し、固定ワーカーグループがそれらを処理します。キューが一杯になった場合、無制限に保留タスクを作成するのではなく、探索側が待機します。宛先への書き込み側にも互換性のある上限が必要で、完了したレスポンスが他所に蓄積されないようにします。

グローバルな制限とソース固有の制限は、異なる問いに答えるものです。サービス側には複数のアクティブなホストのためのメモリがある一方で、あるソースはごく限られたリクエストパターンしか許可しないかもしれません。これらの境界は別々にモデル化し、レート制限レスポンスはソースへの受け入れを見直す必要があるという証拠として扱い、単に空のソースコンテンツとして黙って解釈しないでください。

キャンセルも、すでに受け入れた作業を考慮に入れなければなりません。シャットダウン時には新しいアイテムの受付を停止し、アクティブな処理を完了させるかどうかを決め、リソースを解放する前に未完了アイテムを記録します。キューの内容を精算せずにプロセスが終了してしまうと、意図したソース範囲を収集できたと信頼して主張することはできません。

プロキシルーティングはパーサーの境界を変えない

プロキシはリクエストに使用されるネットワーク経路を変更します。 Scrapeless Proxies は aiohttp クライアント向けにその経路を提供できますが、リクエストの構築、レスポンスの消費、およびアプリケーションでの検証は依然としてクライアントが保持します。 Scrapeless Proxies capabilities は利用可能なプロキシファミリーとその役割を説明します。

アプリケーションが観測しようとしているソース表現に基づいてルーティングコンテキストを選択してください。地理的コンテキストやセッションの継続性はコンテンツに影響し得ます。後続の利用者が、ソース自体の変更なのか収集コンテキストの変更なのかを区別できるように、観測とともにそれらの入力を保持してください。

aiohttp は Web サイトのページスクリプトを実行しません。プロキシは、経路を変えるだけではクライアントレンダリングされたドキュメントを埋めることはできません。選択結果が空だからといってソースにレコードが存在しないと決めつける前に、実際のレスポンスを検査してください。必要なコンテンツは HTTP 表現には存在しない可能性があります。

ここで説明した Python HTTP client tradeoffs では、クライアントの実行モデルと境界を比較しています。その比較を用いて、既に持っているアプリケーションの周りに据えるライブラリを選んでください。収集でマネージドルーティングを利用する場合は Scrapeless pricing も含め、単に同時リクエスト数を最大化するのではなく、承認済みのソース範囲に対して予算を立ててください。

失敗カテゴリは欠損データの意味を保持する

コレクターは、ネットワーク結果、拒否ステータス、無効な表現、受け入れた空結果を区別すべきです。これらの状態は、たとえすべてが新しい受け入れ行がゼロという結果になったとしても、利用者にとって異なるアクションを意味します。

例えば、公開ディレクトリがある特定の期間についてエントリを全く含まないのは正当な場合があります。その結論には、既知の空状態をもつ正しく認識されたディレクトリが必要です。同意ページや不正なレスポンスは、HTML パーサーが公開要素を一つも返さなかったとしても、同じ結論を支持しません。

ソースの同一性と観測コンテキストを保持する明示的な結果を使ってください。そうすれば下流のレポートは、あるソースは利用不可だった一方で別のソースはエントリなしとして受け入れられた、ということを示せます。この区別を隠してしまうと、集計カバレッジが実際の証拠以上に良く見えてしまいます。

タイムアウトは、より広い作業単位のライフタイムの中に位置付ける必要があります。アプリケーションには、結果を分類し、レスポンスリソースを解放し、未完了作業を記録するのに十分な時間を与えてください。リクエストのタイムアウトは完了記録ではなく、例外メッセージをソース記事のコンテンツであるかのように保存すべきではありません。

結論

aiohttp は Python の asyncio モデルの中で非同期 HTTP 通信を提供します。信頼できる収集は、セッションの所有、完全なレスポンス処理、制限付きの受け入れ、および明示的な結果に依存します。リクエストから受け入れ出力まで、受け入れたすべての URL を説明できるライフサイクルから始めてください。メモリ使用量、ソース制限、および下流処理が代表的なワークロード下でも理解可能なまま保たれていることを確認してから、同時実行数を増やしてください。