Як грати на трафіку проти тіньової мережі?

Вибачте, якщо це нове питання ...

Я чув історії про те, що 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, і, принаймні, ви надішлете пакет syn до тіньової мережі. Дарн, тепер ти мені цікаво, як ти можеш зробити цю роботу теж :)

Мені вдалося попросити @adrianco про це на зустрічі в Netflix.

Відповідь полягала в тому, що вони написали власний інструмент, який в основному являє собою ServletFilter (вибачте, специфічна для Java термінологія), який відтворює поточний запит і робить асинхронний виклик вогню та забуття на цільовому сервері.

Переваги:

• "Трафік" в реальному світі щодо вашої тестової ("темної") інфраструктури
• Не потрібно записувати, а потім відтворювати

Недолік:

• У ваших виробничих коробках є запас циклів / циклів процесора
• Затримка вашої тестової інфраструктури може створювати резервні копії та впливати на ваші виробничі коробки