Как воспроизвести трафик против теневой сети?

Извините, если это новый вопрос ...

Я слышал истории о том, что Netflix и Twitter способны дублировать веб-трафик между двумя отдельными инфраструктурами: одна - авторитетная / доверенная, которая восходит к пользователю; а другая - это «теневая» или тестовая инфраструктура, которая думает, что возвращает пользователю, но не делает. Суть в том, чтобы проверить вторичную инфраструктуру при реальной нагрузке и времени.

Я почти уверен, что есть слово, чтобы описать это, но «мостик», кажется, не является правильным, как и «повтор».

Может ли кто-нибудь помочь мне с тем, как называется эта техника и / или какие инструменты могут быть использованы для достижения этой цели?

Думаю, мне следует добавить, что я слышал о методах, которые эффективно «воспроизводят журналы», но это действительно трудно получить при реальных скоростях / распределениях.

И мы не пытаемся проверить «правильность» вывода, а просто следим за тем, чтобы в новой инфраструктуре мы не видели ошибок / трассировок стека / и т.д.

Я бы назвал это «нагрузочным тестированием через воспроизведение сессии», лично. Я не знаю ни одного простого всеобъемлющего термина для такого рода техники тестирования.

Базовая стратегия, которую я видел для такого нагрузочного тестирования, состоит в том, чтобы загружать файлы журналов из производственной системы и воспроизводить их в тестовой системе.

Вы можете использовать такие инструменты, как JMeter или Apache Bench для воспроизведения запросов из файлов журнала. Если вы хотите воспроизвести очень сложные взаимодействия клиент-сервер (с конкретными сведениями о синхронизации, основанными на исходном потоке журналов) в надежде на реальное использование внутренних возможностей вашего приложения (поиск условий гонки, ошибок, связанных с синхронизацией и т. Д.), Вы можете посмотрите на написание инструментов тестирования для конкретных приложений, которые моделируют клиентов в масштабе.

Вы не сможете просто перехватывать загрузку сетевого трафика и «воспроизводить» его с помощью любого протокола TCP или IP. Порядковые номера TCP не соответствуют исходному захваченному трафику и не будут работать. Захват IP-уровня будет проблематичным, потому что ваши симулированные клиенты должны будут отвечать за IP-адрес перехваченного отправителя. Лучше было бы захватывать трафик ближе к 7-му уровню и использовать его для воспроизведения сеансов, потому что в противном случае вы также пытаетесь написать симулятор TCP. (Я мог бы представить, что можно использовать что-то вроде tsharkсброса данных и синхронизации уровня 7 из потока TCP и воспроизведения этого, например.)

Простое воспроизведение сетевого трафика имитирует нагрузку, но не обязательно фиксирует дефекты. Ваш симулированный клиент должен будет получать ответы от тестового сервера и анализировать их на предмет корректности, если вы хотите выполнить нагрузочный тест любого теста, чтобы приложение отвечало правильно. Поскольку ваше приложение будет генерировать данные динамического ответа, маловероятно, что ваш симулированный клиент сможет просто сравнить ответ тестового сервера с зарегистрированным ответом рабочего сервера. Именно здесь вы собираетесь написать тестовый комплект, специфичный для вашего приложения и его результатов.

Вы используете сервис, такой как BrowserMob, который одновременно имитирует доступ к вашему веб-сайту многих людей. Эти сервисы не воспроизводят зарегистрированный трафик, потому что тогда вам будет не хватать клиентской части диалога. Например, ваши серверы будут пытаться отправлять пакеты на компьютеры в Интернете, которые не ожидают их получения. Но то, что делают эти компании, это изучает журналы (обычно на уровне приложений, а не на уровне пакетов) и использует эту информацию, чтобы выяснить, на какие страницы люди нажимают, как часто и в какой последовательности. Эти данные используются для написания скриптов / макросов, которые затем повторяет BrowserMob.

ApacheBench, как упомянул другой пользователь, в наши дни практически не используется. Это было более полезно 10 лет назад, когда вам просто нужно было выяснить, как быстро можно обрабатывать статический HTML-документ или JPEG при большой нагрузке. Это не сильно отличается от того, что группа людей нажимает «перезагрузить», «перезагрузить», «перезагрузить» снова и снова в своем веб-браузере. Вам нужно что-то более умное при тестировании веб-приложения с более сложным рабочим процессом.

Я не думаю, что вы могли бы сделать это на сетевом уровне, хотя вы могли бы получить специализированное ядро ​​для аппаратного балансировщика нагрузки для обработки второго сервера. В основном веб-трафик (TCP) потребует подтверждения каждого отправленного / полученного пакета. Таким образом, если пользователь отправляет пакет в вашу сеть, он дублируется как в вашей сети Prod, так и в вашей теневой сети. Серверы в каждой сети отвечают, и пакет сервера prod перенаправляется обратно на ваш компьютер, который возвращает подтверждение, и они весело продолжают свой разговор. Однако если вы отбросите пакет своего теневого сервера, он не увидит подтверждения. Таким образом, он попытается повторно отправить его и в то же время замедлить скорость его передачи для всей сетевой активности (это называется оконным режимом). Он будет пытаться отправить его до истечения времени ожидания, и сессия сорвана. Честно говоря, вы даже не смогли бы завершить рукопожатие, чтобы установить соединение в первую очередь.

Самое близкое, к чему вы могли бы прийти - это переслать исходный пакет синхронизации на ваш теневой сервер, а затем установить шлюз по умолчанию для этих блоков в качестве некоторого несуществующего местоположения. Затем каждый раз, когда пользователь будет пытаться установить соединение, он получит настоящий сервер в вашей сети prod, и, по крайней мере, вы отправите пакет синхронизации в теневую сеть. Черт возьми, теперь ты меня удивляешь, как ты мог сделать эту работу тоже :)

Я смог спросить об этом @adrianco на встрече Netflix.

Ответ состоял в том, что они написали свой собственный инструмент, который по сути является ServletFilter (извините, терминология, специфичная для Java), который воссоздает текущий запрос и выполняет асинхронный вызов fire-and-Forgot на целевом сервере.

Преимущества:

• Шаблоны трафика реального мира против вашей тестовой («темной») инфраструктуры
• Нет необходимости записывать, а затем повторить

Недостаток:

• Должен иметь потоки / циклы процессора, чтобы сэкономить на ваших производственных коробках
• Задержка в вашей тестовой инфраструктуре может создать резервную копию и повлиять на ваши производственные системы