シャドウネットワークに対してトラフィックを再生する方法は？

これが初心者の質問ならごめんなさい...

NetflixとTwitterが2つの独立したインフラストラクチャ間でWebトラフィックを複製できるという話を聞いたことがあります。もう1つは「シャドウ」またはテストインフラストラクチャであり、ユーザーに戻ってきていると考えていますが、そうではありません。ポイントは、実際の負荷とタイミングでセカンダリインフラストラクチャをテストすることです。

これを説明する言葉があると確信していますが、「ブリッジ」は正しいものではなく、「リプレイ」もありません。

このテクニックが何と呼ばれているのか、これを達成するためにどのツールを使用できるのか、誰でも私を助けることができますか？

効果的に「ログを再生する」技術について聞いたことがあると付け加えるべきだと思いますが、実際の速度/配信でそれを得るのは本当に難しいです。

また、出力の「正確性」を検証しようとはしていませんが、新しいインフラストラクチャでエラー/スタックトレースなどが表示されないようにしてください。

個人的には、「セッションのリプレイによる負荷テスト」と呼びます。この種のテスト手法の簡単なキャッチオール用語は知りません。

私がこの種の負荷テストに採用しているのを見た基本的な戦略は、運用システムからログファイルを取り込み、テストシステムでそれらを再生することです。

JMeterやApache Benchなどのツールを使用して、ログファイルからリクエストを再生できます。非常に複雑なクライアント/サーバー相互作用（元のログストリームに基づく特定のタイミングの詳細）をアプリケーションの内部を実際に実行することを望んでいる場合（競合状態、タイミング関連のバグなどを探す）大規模なクライアントをシミュレートするアプリケーション固有のテストツールの作成を検討してください。

生のネットワークトラフィックを大量にキャプチャして、TCPまたはIPベースのプロトコルで「リプレイ」することはできません。TCPシーケンス番号は、キャプチャされた元のトラフィックと一致せず、機能しません。シミュレートされたクライアントは、キャプチャされた送信者のIPアドレスに応答する必要があるため、IP層のキャプチャは問題になります。レイヤー7に近いトラフィックをキャプチャし、それを使用してセッションをリプレイする方が良いでしょう。（tsharkたとえば、TCPストリームからレイヤー7データとタイミングを破壊し、それを再生するようなものを使用することを想像できます。）

単にネットワークトラフィックを再生するだけで負荷をシミュレートできますが、必ずしも障害をキャプチャするわけではありません。あなたのシミュレートされたクライアントは、テストサーバーからの応答を受信し、負荷テストに望んでいた場合には正しさのためにそれらを解析する必要があります任意のアプリケーションが適切に応答していることをテストします。アプリケーションは動的な応答データを生成するため、シミュレートされたクライアントがテストサーバーの応答と運用サーバーからのログに記録された応答を単純に比較することはほとんどありません。ここで、アプリケーションとその出力に固有のテストハーネスを記述します。

多くの人が同時にあなたのウェブサイトに同時にアクセスすることをシミュレートするBrowserMobのようなサービスを使用します。これらのサービスは、ログに記録されたトラフィックを再生しません。なぜなら、会話のクライアント側が失われるからです。たとえば、サーバーは、受信を予期していないインターネット上のコンピューターにパケットを送信しようとします。しかし、これらの企業が行うことは、ログ（一般にパケットレベルではなくアプリケーションレベル）を調べ、その情報を使用して、ユーザーがクリックしているページ、頻度、順序を把握することです。このデータは、BrowserMobが繰り返すスクリプト/マクロを記述するために使用されます。

ApacheBenchは、別のユーザーが述べたように、最近ではあまり使用されていません。10年前、静的なHTMLドキュメントまたはJPEGが重い負荷の下でどれだけ速く提供されるかを知る必要があったとき、それはより役に立ちました。Webブラウザでリロード、リロード、リロードを何度もクリックする人と大差ありません。より複雑なワークフローを持つWebアプリをテストするときは、もう少しスマートなものが必要です。

ネットワーク層でこれを行うことができるとは思いませんが、ハードウェアロードバランサー用に特別なカーネルを取得して、2番目のサーバーを処理することもできます。基本的に、Webトラフィック（TCP）には、送受信される各パケットの確認が必要です。そのため、ユーザーがネットワークにパケットを送信すると、prodネットワークとシャドウネットワークの両方に複製されます。各ネットワーク内のサーバーが応答し、prodサーバーのパケットがマシンに転送されて確認応答が返され、それらは会話を快く続行します。ただし、シャドウサーバーのパケットをドロップしても、確認は表示されません。そのため、再送信を試み、同時にすべてのネットワークアクティビティの送信速度を低下させます（これをウィンドウイングと呼びます）。タイムアウトするまで送信を再試行し続けますが、セッションは破棄されます。正直なところ、そもそも接続を確立するためにハンドシェイクを完了することさえできません。

これに最も近い方法は、元の同期パケットをシャドウサーバーに転送し、それらのボックスのデフォルトゲートウェイを存在しない場所として設定することです。次に、ユーザーが接続を設定しようとすると、prodネットワークで実際のサーバーを取得し、少なくともシャドウネットワークにsynパケットを送信します。くそー、この作品もどうやって作れるのか不思議に思うよ。

私が尋ねることができた@adrianco Netflixのミートアップでこのことについて。

答えは、彼らが独自のツールを書いたということでした。これは基本的に、現在のリクエストを再作成し、ターゲットサーバー上で非同期の起動を忘れるServletFilter（ごめん、Java固有の用語）です。

利点は次のとおりです。

• テスト（「ダーク」）インフラストラクチャに対する「Real World」トラフィックパターン
• 記録してから再生する必要はありません

欠点：

• プロダクションボックスに余裕のあるスレッド/ CPUサイクルを用意する
• テストインフラストラクチャの遅延により、運用環境がバックアップされ、影響を受ける可能性があります