再開可能なアップロードに必要なリバースプロキシワーカー接続数は？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Many Reverse-Proxy Worker Connections Do Resumable Uploads Need? - Zima Store Online

再開可能なアップロードに安全な汎用ワーカー接続数はありません。再現可能な同時ソケット需要の最大値を基準に設定し、実測した余裕を加えてください。

ホームサーバーでは、画面上は1件のアップロードでも、クライアント接続、アップストリーム接続、ブラウザーがチャンク間で再試行または再開する際のアイドル時間が発生することがあります。通常のアップロードが最も集中する時間帯のライブ接続数から始め、プロキシとOSの上限と比較してください。ファイルディスクリプター、アップストリームワーカー、メモリ、またはアプリケーションが先に障害を起こす場合は、プロキシ設定をこれ以上増やさないでください。

上限を決める前に、実際のアップロード需要を測定する

プロキシがアイドル状態のときではなく、重要な負荷がかかっている間に接続数を数えてください。家庭や小規模チームで実際に行われる可能性のある数のアップロードを同時に開始し、複数の転送を一時停止して再開します。スリープ後に再接続するモバイルクライアントも含めてください。受け入れ済みのクライアントソケット、確立済みのアップストリームソケット、アップストリームの応答を待機している接続を記録します。

ワーカーの上限は、完了したHTTPリクエストだけでなく、そのワーカーが処理するすべてのオープン接続によって消費されます。そのため、プロキシ経由のサーバー接続もクライアント接続と併せて測定に含める必要があります。

繰り返し再現できる合計の最大値を、作業用の基準値にします。再接続の集中時だけ合計が増え、すぐに減少する場合は、そのバーストを継続的な需要とは分けて扱ってください。アップロード速度が横ばいなのに接続数が増え続ける場合、その増加を正当な処理能力とは考えないでください。上限を引き上げる前に、アップストリームのアプリケーション、タイムアウト、停止状態のセッションを調べます。

ソケット需要をワーカーごとの容量に換算する

リバースプロキシでは、1件のアクティブなアップロードが通常、クライアント側の接続とアップストリーム側の接続を同時に1つずつ使用します。HTTPキープアライブ、ヘルスチェック、WebSocketセッション、管理トラフィックも追加のスロットを消費します。同時アップロード数の2倍は出発点となるモデルにすぎず、最終的な答えではありません。経験則よりも、実測したソケット合計を優先してください。

表示されるワーカー接続上限に達すると、確立済みの転送が継続していても新しいクライアントを拒否することがあります。最も忙しいワーカーの使用数を設定済みの上限と比較し、サービスプロセスのオープンファイル上限も確認してください。プロセスに開くことが許可されていないファイルディスクリプターを、より大きなプロキシ値で作り出すことはできません。

繰り返し観測できる最繁忙時のワーカー使用数を上回り、観測された再試行バーストと通常のアップロード以外のトラフィックにも対応できる余裕を持たせて目標値を選びます。同時に存在しない接続を、考えられるすべてのクライアントやチャンクについて掛け合わせないでください。OSの上限が低い場合は、まずその層を調整するか、プロキシの目標値をOSの上限未満に保ちます。

元の再開経路をテストし、障害を読み解く

正確なトリガーを再現します。すべてのアップロードを開始し、複数のクライアントを中断してから、残りの転送がアクティブな状態で再開してください。新しい接続の受け入れ、再試行のタイミング、アップロード速度、プロキシのエラーメッセージ、アップストリームの応答時間、オープンファイルディスクリプターを監視します。本文をアップロードしない合成リクエストでは、同じリソース経路をテストできません。

新しいアップロードが失敗するのと同時に、プロキシがワーカー接続の枯渇を報告する場合、その上限が実際のボトルネックです。接続使用量が上限を下回っているのに、本文サイズ、タイムアウト、アップストリーム利用不可、アプリケーションキューに関するエラーで新しいリクエストが失敗する場合は、ワーカー設定を増やしても解決しません。接続数の計算でも、オープンファイル上限とプロキシの両側で使用するソケットを考慮する必要があります。

一度に変更する層は1つだけにしてください。ログとソケットの証拠からワーカー上限が原因だと特定できた場合にのみ上限を引き上げ、プロキシをリロードして、同じ中断パターンを再実行します。エラーがアップストリームサービスやファイルディスクリプター上限に移った場合は停止してください。プロキシ接続をさらに増やすことが有効だと証明されたのではなく、次の制約に到達したということです。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

十分な余裕を確保し、停止条件を定める

最も忙しいワーカーの観測値と設定上限の間に余裕を確保しますが、その余裕は実際の変動に基づいて決めてください。家庭内のトラフィックが安定している小規模サーバーでは、予測に基づく予備容量は、予測不能なバーストを受ける公開サービスほど必要ありません。基準値、目標値、ワーカー数、プロセスのファイル上限、ピーク時の結果を記録し、次の変更を推測ではなく比較に基づいて判断できるようにします。

接続容量は、アップロード経路の一層にすぎません。ダッシュボードは動作するのに特定の同期またはアップロード経路が失敗する場合は、プロキシが正常だと判断する前に、失敗しているエンドポイントとメソッドを切り分ける必要があります。

完全な再開テストが2回完了し、新しい接続が受け入れられ、エラーログが問題なく、最も忙しいワーカーに安定した余裕が残っていれば、変更は成功です。障害が減らないままメモリ負荷や遅延が悪化した場合は、増加分をロールバックしてください。接続使用量が上限を十分下回っているのにアップロードがキューに入り、タイムアウトし、または再開状態が破損する場合は、アプリケーション層またはストレージ層へ調査を進めます。