Gölge ağına karşı trafik nasıl oynanır?

Bu yeni bir soru ise üzgünüm ...

Netflix ve Twitter'ın iki ayrı altyapı arasında web trafiğini çoğaltabildiğini duydum: biri, kullanıcıya geri dönen yetkili / güvenilir olanı; diğeri ise kullanıcıya geri döndüğünü düşünen ancak geri dönmeyen bir 'gölge' veya test altyapısıdır. Mesele, ikincil altyapıyı gerçek hayat yükü ve zamanlamasında test etmektir.

Eminim bunu tarif edecek bir kelime vardır, ama 'köprü' doğru gibi görünmüyor ya da 'tekrar' değil.

Herkes bana bu tekniğin adı ve / veya bunu gerçekleştirmek için hangi araçlar kullanılabilir?

Sanırım şunu eklemeliyim ki, etkili bir şekilde 'günlükleri tekrarlayan' teknikler hakkında bir şeyler duydum, ama bu gerçek hızlarda / dağılımlarda elde etmek gerçekten zor.

Çıktının 'doğruluğunu' doğrulamaya çalışmıyoruz, ancak yeni altyapıda hataları / yığın izlerini / vb. Görmediğimizden emin olun.

Ben şahsen "oturum tekrar yoluyla yük testi" derdim. Bu tür bir test tekniği için basit bir yakalama terimi bilmiyorum.

Bu tür bir yük testi için kullandığım temel strateji, günlük dosyalarını üretim sisteminden alıp bir test sisteminde tekrar oynatmaktır.

Günlük dosyalarından gelen istekleri yeniden yürütmek için JMeter veya Apache Bench gibi araçları kullanabilirsiniz . Uygulamanızın iç kısımlarını (yarış koşulları, zamanlama ile ilgili hatalar vb. istemcileri ölçekte taklit eden uygulamaya özel test araçları yazmaya bakın.

Ham ağ trafiğinin tekne yüklerini yakalayamayacak ve bunu herhangi bir TCP veya IP tabanlı protokolle "tekrarlayamayacaksınız". TCP sıra numaraları orijinal yakalanan trafiğe uymayacak ve işe yaramayacak. IP katmanı yakalamaları sorunlu olacaktır çünkü simüle edilmiş istemcilerinizin yakalanan gönderenin IP adresini yanıtlaması gerekecektir. Katman 7'ye yakın trafiği yakalamakta ve oturumları yeniden oynatmak için bunu kullanmanız daha iyi olur çünkü aksi halde bir TCP simülatörü de yazıyorsunuz demektir. ( tsharkKatman 7 verilerini ve bir TCP akışından zamanlamayı çıkarmak ve örneğin yeniden oynatmak gibi bir şey kullanmayı hayal edebilirim .)

Ağ trafiğini tekrar oynatmak yükü simüle eder, ancak mutlaka hataları yakalamaz. Sizin simüle istemci testi sunucudan yanıtları almak ve yük testi istiyorsa doğruluğundan onları ayrıştırmak gerekir herhangi bir uygulama şekilde yanıt verdiğinden testi. Uygulamanız dinamik yanıt verileri üreteceğinden, simüle edilmiş istemcinizin test sunucusunun yanıtını üretim sunucusundan kaydedilen yanıtla karşılaştırması pek olası değildir. Bu, uygulamanıza ve çıktısına özgü bir test takımı yazacağınız yerdir.

Web sitenize aynı anda erişen birçok insanı simüle eden BrowserMob gibi bir hizmet kullanıyorsunuz . Bu hizmetler günlüğe kaydedilmiş trafiği yeniden oynatmaz, çünkü o zaman konuşmanın istemci tarafını kaçırırsınız. Örneğin, sunucularınız İnternet'te onları almayı beklemeyen bilgisayarlara paket göndermeye çalışıyor olabilir. Ancak bu şirketlerin yaptığı günlükleri incelemek (genellikle paket düzeyinde değil, uygulama düzeyinde) ve bu bilgileri insanların hangi sayfaları tıkladıklarını, ne sıklıkta ve hangi sırayla kullandıklarını bulmak için kullanmaktır. Bu veriler, BrowserMob'un tekrarladığı komut dosyaları / makrolar yazmak için kullanılır.

ApacheBench, başka bir kullanıcı tarafından belirtildiği gibi, bu günlerde çok fazla kullanılmıyor. 10 yıl önce, statik bir HTML belgesinin veya JPEG'in ağır bir yük altında ne kadar hızlı sunulabileceğini anlamanız gerektiğinde daha yararlı oldu. Web tarayıcılarında yeniden yükle, yeniden yükle, tekrar yükle'yi tıklayan bir grup insandan çok farklı değil. Daha karmaşık bir iş akışına sahip bir web uygulamasını test ederken biraz daha akıllıca bir şeye ihtiyacınız var.

Bunu bir ağ katmanında yapabileceğinizi sanmıyorum, ancak ikinci sunucuyu işlemek için bir donanım yük dengeleyicisi için özel bir çekirdek alabilirsiniz. Temel olarak web trafiği (TCP) gönderilen / alınan her paketin onaylanmasını gerektirir. Bir kullanıcı ağınıza bir paket gönderirse, hem ürün ağınıza hem de gölge ağınıza çoğaltılır. Her ağdaki sunucular yanıt verir ve prod sunucusunun paketi, bir geri bildirim çeken makinenize geri yönlendirilir ve konuşmaları nadiren devam eder. Ancak, gölge sunucunuzun paketini düşürürseniz, bir onay görmez. Böylece, yeniden göndermeyi deneyecek ve aynı zamanda tüm ağ etkinliği için iletim hızlarını yavaşlatacaktır (buna pencereleme denir). Zaman aşımına uğrayana kadar göndermeyi denemeye devam edecek, ve oturum bozuldu. Dürüst olmak gerekirse, ilk etapta bağlantı kurmak için bir el sıkışma bile tamamlayamazsınız.

Buraya gelebileceğiniz en yakın şey, orijinal senkronizasyon paketini gölge sunucunuza iletmek ve daha sonra bu kutular için varsayılan ağ geçidini var olmayan bir konum olarak ayarlamak olacaktır. Daha sonra bir kullanıcı bağlantı kurmaya çalıştığında ürün ağınızda gerçek bir sunucu alır ve en azından gölge ağa bir senkronizasyon paketi gönderirsiniz. Lanet olsun, şimdi bu işi nasıl yapabileceğini merak ediyorsun :)

Sormak başardı @adrianco Netflix buluşmada gerçekleşen bu konuda.

Cevap, temelde mevcut isteği yeniden yaratan ve bir hedef sunucuda eşzamansız bir ateşle ve unut çağrısı yapan bir ServletFilter (üzgünüm, Java'ya özgü terminoloji) olan kendi araçlarını yazmalarıydı.

Avantajları:

• Test ("karanlık") altyapınıza karşı 'Gerçek Dünya' trafik modelleri
• Kaydetmeye ve sonra tekrar oynatmaya gerek yok

Dezavantajı:

• Üretim kutularınıza yedeklemek için iş parçacığı / CPU döngüsü olmalı
• Test altyapınızdaki gecikme, üretim kutularınızı yedekleyebilir ve etkileyebilir