Bagaimana cara memainkan lalu lintas melawan jaringan bayangan?

Maaf jika ini pertanyaan baru ...

Saya pernah mendengar cerita tentang Netflix dan Twitter yang dapat menduplikasi lalu lintas web di antara dua infrastruktur terpisah: satu adalah yang berwibawa / tepercaya yang kembali ke pengguna; dan yang lainnya adalah 'bayangan' atau menguji infrastruktur yang berpikir itu kembali ke pengguna tetapi tidak. Intinya adalah untuk menguji infrastruktur sekunder pada beban dan pengaturan waktu nyata.

Saya cukup yakin ada kata untuk menggambarkan ini, tetapi 'jembatan' tampaknya tidak tepat, juga tidak 'memutar ulang'.

Adakah yang bisa membantu saya dengan apa teknik ini disebut dan / atau alat apa yang dapat digunakan untuk mencapai ini?

Saya kira saya harus menambahkan bahwa saya pernah mendengar tentang teknik yang secara efektif 'memutar ulang log', tetapi itu benar-benar sulit untuk didapatkan dengan kecepatan / distribusi nyata.

Dan, kami tidak mencoba memverifikasi 'kebenaran' dari output, tetapi pastikan bahwa kami tidak melihat kesalahan / stacktraces / etc di infrastruktur baru.

Saya akan menyebutnya "memuat pengujian melalui sesi replaying", secara pribadi. Saya tidak tahu istilah sederhana apa pun untuk teknik pengujian semacam ini.

Strategi dasar yang saya lihat digunakan untuk pengujian beban semacam ini adalah dengan mengambil file log dari sistem produksi dan memutar ulang mereka pada sistem pengujian.

Anda dapat menggunakan alat seperti JMeter atau Apache Bench untuk memutar ulang permintaan dari file log. Jika Anda ingin memutar ulang interaksi klien / server yang sangat kompleks (dengan detail waktu spesifik berdasarkan aliran log asli) dengan harapan benar-benar menjalankan jeroan aplikasi Anda (mencari kondisi balapan, bug terkait waktu, dll), Anda mungkin lihat menulis alat pengujian khusus aplikasi yang mensimulasikan klien pada skala.

Anda tidak akan bisa dengan mudah menangkap muatan lalu lintas jaringan mentah dan "memutar ulang" dengan protokol berbasis TCP atau IP. Nomor urut TCP tidak akan cocok dengan lalu lintas yang diambil asli dan itu tidak akan berfungsi. Pengambilan layer-IP akan bermasalah karena klien Anda yang disimulasikan perlu menjawab untuk alamat IP pengirim yang ditangkap. Anda akan lebih baik menangkap lalu lintas lebih dekat ke lapisan 7 dan menggunakannya untuk memutar ulang sesi karena, jika tidak, Anda sedang mencari untuk menulis simulator TCP juga. (Saya bisa membayangkan menggunakan sesuatu seperti tsharkmenerobos data layer 7 dan pengaturan waktu dari aliran TCP dan memutar ulang itu, misalnya.)

Memutar ulang lalu lintas jaringan mensimulasikan beban tetapi tidak serta merta menangkap cacat. Klien Anda yang disimulasikan perlu menerima tanggapan dari server uji dan menguraikannya untuk kebenaran jika Anda ingin memuat-menguji setiap tes yang aplikasi merespons dengan baik. Karena aplikasi Anda akan menghasilkan data respons dinamis, kecil kemungkinan klien yang disimulasikan hanya dapat membandingkan respons server uji dengan respons yang dicatat dari server produksi. Di sinilah Anda akan mulai menulis test harness khusus untuk aplikasi Anda dan hasilnya.

Anda menggunakan layanan seperti BrowserMob yang mensimulasikan banyak orang secara bersamaan mengakses situs web Anda sekaligus. Layanan ini tidak memutar ulang lalu lintas yang dicatat, karena Anda akan kehilangan sisi klien dari percakapan. Misalnya, server Anda akan mencoba mengirim paket ke komputer di Internet yang tidak diharapkan untuk menerimanya. Tetapi yang dilakukan oleh perusahaan-perusahaan ini adalah mempelajari log (umumnya pada level aplikasi, bukan level paket) dan menggunakan informasi itu untuk mencari tahu halaman mana yang diklik orang, seberapa sering, dan dalam urutan apa. Data ini digunakan untuk menulis skrip / makro yang kemudian diulangi oleh BrowserMob.

ApacheBench, sebagaimana disebutkan oleh pengguna lain, tidak banyak digunakan akhir-akhir ini. Itu lebih membantu 10 tahun yang lalu ketika Anda hanya perlu mencari tahu seberapa cepat dokumen HTML statis atau JPEG dapat dilayani di bawah beban yang berat. Ini tidak jauh berbeda dari sekelompok orang yang mengklik memuat ulang, memuat ulang, memuat ulang berulang-ulang di browser web mereka. Anda memerlukan sesuatu yang sedikit lebih pintar ketika menguji aplikasi web yang memiliki alur kerja yang lebih kompleks.

Saya tidak berpikir Anda bisa melakukan ini pada lapisan jaringan, meskipun Anda mungkin bisa mendapatkan kernel khusus untuk penyeimbang beban perangkat keras untuk menangani server kedua. Pada dasarnya lalu lintas web (TCP) akan membutuhkan pengakuan dari setiap paket yang dikirim / diterima. Jadi jika pengguna mengirim paket ke jaringan Anda, itu akan diduplikasi ke jaringan prod Anda, dan jaringan bayangan Anda. Server-server di setiap jaringan membalas, dan paket server prod diteruskan kembali ke mesin Anda yang merekam kembali sebuah pengakuan, dan mereka dengan gembira melanjutkan percakapan mereka. Namun jika Anda menjatuhkan paket server bayangan Anda, itu tidak akan melihat pemberitahuan. Jadi, ia akan mencoba mengirim ulang, dan pada saat yang sama memperlambat kecepatan transmisi untuk semua aktivitas jaringan (ini disebut windowing). Itu akan terus mencoba untuk mengirimnya sampai habis, dan sesi dirobohkan. Jujur, Anda bahkan tidak akan bisa menyelesaikan jabat tangan untuk membangun koneksi di tempat pertama.

Tentang yang paling dekat dengan Anda, ini akan meneruskan paket sinkronisasi asli ke server bayangan Anda dan kemudian mengatur gateway default untuk kotak-kotak itu karena beberapa lokasi tidak ada. Lalu kapan saja pengguna akan mencoba untuk membuat koneksi mereka akan mendapatkan server nyata di jaringan prod Anda, dan setidaknya Anda akan mengirim paket syn ke jaringan shadow. Sial, sekarang Anda bertanya-tanya bagaimana Anda bisa membuat ini bekerja juga :)

Saya bisa bertanya kepada @ adrianco tentang hal ini di pertemuan Netflix.

Jawabannya adalah bahwa mereka menulis alat mereka sendiri, yang pada dasarnya adalah ServletFilter (maaf, terminologi khusus Java) yang menciptakan kembali permintaan saat ini dan melakukan doa api dan lupakan asinkron pada server target.

Manfaatnya adalah:

• Pola lalu lintas 'Dunia Nyata' terhadap infrastruktur pengujian Anda ("gelap")
• Tidak perlu merekam dan kemudian memutar ulang

Kekurangannya:

• Harus memiliki siklus thread / CPU untuk cadangan pada kotak produksi Anda
• Latensi pada infrastruktur pengujian Anda dapat membuat cadangan dan memengaruhi kotak produksi Anda