収集パイプラインを本番環境に移行する前に、フルボリュームでも持つのかと誰かが尋ねるのは合理的なことだ。負荷テストを実行しようという発想は正しいが、プロキシの負荷テストには通常の負荷テストにはない制約がある。トラフィックを送り込む対象が、たいていは他人のものだという点だ。
この一点が、この作業のあり方を変える。あなたはシステムがあなたの負荷を吸収できるかどうかをテストしているのではなく、第三者に対して無断でストレステストを行うことなく、自分自身のパイプラインの挙動を特性づけ、自分の上限を見つけているのだ。以下に、それを適切に行う方法を示す。
実際にテストしていること
4つの問いを分けて考えること。それぞれ異なるテストが必要であり、実際のターゲットが関わるのはそのうち1つだけだ。
自分自身のパイプラインの容量。 ワーカー、コネクション処理、パース、ストレージが何かが飽和する前にどれだけの同時リクエストに耐えられるか。これはあなたのコードとインフラをテストするものであり、他人のサイトに触れずに実行できる。
同時実行下でのプロキシパスの挙動。 ゲートウェイを通る実行中のリクエストを増やすにつれ、レイテンシと成功率がどう変化するか。これも大部分は特定のターゲットに依存しない。
ターゲットの許容度。 特定のサイトがスロットリングやチャレンジを課す前に、どのペースまで受け入れるか。これは負荷生成器ではなく、慎重かつ段階的にアプローチしなければならないものだ。
エンドツーエンドのスループット。 上記すべてが合わさって生み出すもので、あなたのスケジュールが実際に依存している数字だ。
これらを混同すると、典型的な悪い結果が生まれる。1つのターゲットを叩きまくる「負荷テスト」がブロックされ、ブロックされ得ることしか教えてくれない、というものだ。
まず自分が所有するものに対してテストする
現実的なサイズのレスポンスを返す、自分が管理するターゲットを立ち上げ、プロキシ経由でパイプラインをそこに向ける。これにより、第三者に関わるものを除いたすべてを分離できる。
ここで意外なほど多くのことがわかる。ワーカープールが設定した並行度に実際に到達しているかどうか。プールされたコネクションはゲートウェイ経由では異なる振る舞いをするため、コネクション処理が想定通りに動作しているかどうか(IPがローテーションしないを参照)。パースやストレージがどこでボトルネックになるか。そして、ターゲット自体のばらつきが混ざらない状態で、プロキシパスがどのようなレイテンシ分布を追加するか。
現実的なペイロードサイズを使うこと。小さなエンドポイントに対するテストはスループットを大きく過大評価する。帯域幅とパースの両方がレスポンスサイズに応じてスケールし、レジデンシャルのレイテンシはペイロードサイズによって異なる支配的挙動を示すためだ。
正しいものを測定する
スループットだけでは要約として不十分だ。5つの測定値によって負荷テストが解釈可能になる。
検証済み成功率、HTTPの成功ではない。チャレンジページを返しながら100%の成功を報告するテストは、間違ったものを測定している(ブロックされた、または偽のコンテンツを検出するを参照)。
レイテンシのパーセンタイル、具体的にはp50、p95、p99。レジデンシャルのレイテンシは分布が広いため、平均は、時間制約のあるジョブが完了するかどうかを実際に決めるテール部分を隠してしまう。
並行度の関数としてのスループット、1点でサンプリングするのではなくプロットすること。興味深い特徴は曲線が平坦化する場所であり、それを超えると完了数を増やさずに実行中のリクエストだけを増やしていることになる。
エラークラスの分布、その混在具合が何が制限要因になっているかを教えてくれる。タイムアウトはある方向を、レート信号は別の方向を、チャレンジはさらに別の方向を示す(よくあるレジデンシャルプロキシのエラーを参照)。
リクエストあたりのバイト数、これは本番ボリュームでのコストを決定し、今のうちに測るのは簡単だが後で発見するのは高くつく(月間帯域幅の見積もりを参照)。
徐々に上げる、急上昇させない
並行度を段階的に増やし、各段階を数値が安定するまで十分に保持し、各レベルで測定値全体を記録する。スパイクテストはここではほとんど有用な情報を教えてくれない。それが生み出す失敗は、バーストに反応しているターゲットと区別がつかないからだ。
探すべき形は、スループットが並行度とともに上昇しなくなる箇所と、p95レイテンシが急激に上昇し始める箇所だ。これら2つは通常一致し、実用上の上限を示す。本番のジョブはその上限を超えたところで実行するのではなく、それより下で実行すること。上限はターゲットの挙動、時間帯、プール状況によって変動するからだ。
for concurrency in [5, 10, 20, 40, 80]: stats = run_step(concurrency, duration_seconds=180) # hold, then record print(concurrency, stats.validated_success, stats.p50, stats.p95, stats.rps, stats.bytes_per_req, stats.error_mix) if stats.validated_success < 0.9 or stats.p95 > LATENCY_BUDGET: break # found the knee実際のターゲットに対して、慎重にキャリブレーションする
最終的には、実際のソースが何を許容するのかを知る必要があり、それはモックからは学べない。負荷テストとしてではなく、キャリブレーションとして行うこと。
意図するレートよりかなり低いところから始め、徐々に増やし、ステータスコードではなく検証済み成功率を観察する。劣化の最初の兆候で増加を止め、失敗するまで押し込まないこと。目的は持続可能なペースを見つけることであり、限界点を見つけることではないからだ。キャリブレーションは必要と感じられるよりも長い期間にわたって分散させること。スロットリングはしばしばローリングウィンドウで適用され、短いバーストは通過しても持続的なレートは通過しないことがあるためだ。
ターゲットが伝えてくることを尊重する。429やRetry-Afterは直接的な指示であり、正しい対応はペースを維持するためにアドレスをローテーションすることではなく、速度を落とすことだ。これはレート制限とスロットリングにおける区別だ。
そして、規模に見合ったものにすること。キャリブレーショントラフィックは、そのサイトの通常の負荷に対して誤差程度であるべきだ。第三者のインフラに意図的にストレステストを行うことは無害なエンジニアリング作業ではなく、規模と意図によっては干渉に踏み込むこともある。パートナーの限界を正確に知る必要があるなら、彼らに尋ねること。
結果の読み方
曲線を、本番構成に必要な2つの数字に変換する。ターゲットごとの並行度上限とターゲットごとのレートであり、どちらも余裕を持って知点(ニー)より下に設定する。
次に、スケジュールと整合するか確認する。並行度はレートとレイテンシから導かれるため、測定されたp50レイテンシが想定より高い場合、所定の締め切りに必要な並行度もそれに応じて上昇する。これはリクエストボリュームと並行度の計画における算術だ。
最後に、結果を消耗品として扱うこと。ターゲットの防御は変化し、プール状況は時間帯や市場によって変わり、静かな週に測定した数字はピーク時には成立しない。定期的にキャリブレーションを再実行し、さらに重要なことに、同じ測定を本番環境で継続的に実行し、上限を想定ではなく観測すること(大規模なプロキシの健全性監視を参照)。
結論
プロキシの負荷テストは容量の特性づけであり、第三者への攻撃ではない。4つの問いを分け、最初の2つは現実的なペイロードサイズで自分が所有するインフラに対してテストする。これにより、あなたのパイプラインの実際のボトルネックをターゲットのばらつきから分離できる。検証済み成功率、レイテンシのパーセンタイル、並行度に対するスループット、エラークラスの混在、リクエストあたりのバイト数を測定し、段階的に上げてスループットが平坦化しp95が上昇する知点(ニー)を探す。実際のターゲットに対してはゆっくりとキャリブレーションし、失敗するまで押し込むのではなく最初の劣化で止め、レート信号を尊重してローテーションではなく速度を落とすこと。本番の上限は知点より下に設定し、測定されたレイテンシから並行度を再導出し、上限は変動するため本番環境での測定を続けること。
テストされている経路はレジデンシャルプロキシであり、並行度と地理はプラン設定ではなくリクエストごとのパラメータであり、GBあたりで課金されるため、適切に範囲設定された負荷テストのコストはおおよそその帯域幅のコストに等しくなる。