Web HighLoad - on binlerce alanın trafiğini nasıl yönetiyoruz?

DDoS-Guard ağındaki meşru trafik yakın zamanda saniyede yüz gigabiti aştı. Şu anda tüm trafiğimizin %50'si istemci web hizmetleri tarafından oluşturulmaktadır. Bunlar birbirinden çok farklı ve çoğu durumda bireysel bir yaklaşım gerektiren onbinlerce alandır.

Kesimin altında ön düğümleri nasıl yönettiğimiz ve yüz binlerce site için SSL sertifikalarını nasıl verdiğimiz yer alıyor.

Tek bir alan için, çok büyük bir alan için bile bir cephe oluşturmak kolaydır. Nginx veya haproxy veya lighttpd'yi alıyoruz, kılavuzlara göre yapılandırıyoruz ve unutuyoruz. Bir şeyi değiştirmemiz gerekirse, yeniden yükleyip tekrar unuturuz.

Büyük miktarda trafiği anında işlediğinizde, isteklerin meşruiyetini değerlendirdiğinizde, kullanıcı içeriğini sıkıştırıp önbelleğe aldığınızda ve aynı zamanda parametreleri saniyede birkaç kez değiştirdiğinizde her şey değişir. Kullanıcı, kişisel hesabındaki ayarları değiştirdikten hemen sonra sonucu tüm harici düğümlerde görmek ister. Bir kullanıcı ayrıca API aracılığıyla bireysel trafik işleme parametrelerine sahip birkaç bin (ve bazen onbinlerce) alan adını indirebilir. Bütün bunlar aynı zamanda Amerika'da, Avrupa'da ve Asya'da da hemen çalışmalıdır - yalnızca Moskova'da fiziksel olarak ayrılmış birkaç filtreleme düğümü olduğu göz önüne alındığında, görev en önemsiz değildir.

Neden dünya çapında birçok büyük güvenilir düğüm var?

• Müşteri trafiği için hizmet kalitesi - ABD'den gelen taleplerin ABD'de işlenmesi gerekir (saldırılar, ayrıştırma ve diğer anormallikler dahil) ve Moskova'ya veya Avrupa'ya çekilmemelidir, bu da işlem gecikmesini tahmin edilemeyecek şekilde artırır.

• Saldırı trafiği yerelleştirilmelidir; toplu taşıma operatörleri, hacmi genellikle 1 Tbps'yi aşan saldırılar sırasında bozulabilir. Saldırı trafiğinin transatlantik veya transasya bağlantıları üzerinden taşınması iyi bir fikir değildir. Seviye 1 operatörlerinin şunları söylediği gerçek vakalar yaşadık: "Aldığınız saldırıların hacmi bizim için tehlikelidir." Bu nedenle gelen akışları kaynaklarına mümkün olduğunca yakın kabul ediyoruz.

• Hizmetin sürekliliği için katı gereklilikler - hızla değişen dünyamızda temizlik merkezleri ne birbirine ne de yerel olaylara bağlı olmamalıdır. Bir hafta boyunca MMTS-11'un 9 katının elektriğini kestiniz mi? - Sorun değil. Bu belirli konumda fiziksel bağlantısı olmayan tek bir müşteri zarar görmeyecek ve web hizmetleri de hiçbir koşulda zarar görmeyecektir.

Bütün bunlar nasıl yönetilir?

Hizmet yapılandırmaları tüm ön düğümlere mümkün olduğu kadar hızlı (ideal olarak anında) dağıtılmalıdır. Her değişiklikte metin yapılandırmalarını alıp yeniden oluşturamaz ve arka plan programlarını yeniden başlatamazsınız - aynı nginx, süreçlerin birkaç dakika daha (veya uzun websocket oturumları varsa belki saatlerce) kapatılmasını (işçinin kapanmasını) sürdürür.

Nginx yapılandırmasını yeniden yüklerken aşağıdaki resim oldukça normaldir:

Bellek kullanımı hakkında:

Eski çalışanlar, bağlantı sayısına doğrusal olarak bağlı olmayan hafıza da dahil olmak üzere hafızayı yerler - bu normaldir. İstemci bağlantıları kapatıldığında bu hafıza serbest bırakılacaktır.

Nginx daha yeni başladığında bu neden bir sorun değildi? HTTP/2, WebSocket, uzun süreli canlı tutma bağlantıları yoktu. Web trafiğimizin %70'i HTTP/2'dir, bu da çok uzun bağlantılar anlamına gelir.

Çözüm basit; nginx kullanmayın, cepheleri metin dosyalarına göre yönetmeyin ve sıkıştırılmış metin yapılandırmalarını kesinlikle transpasifik kanallar üzerinden göndermeyin. Kanallar elbette garantili ve saklıdır, ancak bu onları daha az kıtalararası yapmaz.

İlerleyen yazılarda iç kısımlarından bahsedeceğim kendi ön sunucu dengeleyicimiz var. Yapabileceği en önemli şey, yeniden başlatmalar, yeniden yüklemeler, bellek tüketiminde ani artışlar ve benzeri şeyler olmadan, saniyede binlerce yapılandırma değişikliğini anında uygulamaktır. Bu, örneğin Erlang'daki Hot Code Reload'a çok benzer. Veriler coğrafi olarak dağıtılmış bir anahtar/değer veri tabanında depolanır ve ön aktüatörler tarafından anında okunur. Onlar. SSL sertifikasını Moskova'daki web arayüzü veya API aracılığıyla yüklersiniz ve birkaç saniye içinde Los Angeles'taki temizlik merkezimize gitmeye hazır hale gelir. Aniden bir dünya savaşı çıkarsa ve tüm dünyada internet kaybolursa, Los Angeles-Amsterdam-Moskova, Moskova-Amsterdam-Hong Kong- özel kanallardan biri devreye girdiğinde düğümlerimiz otonom olarak çalışmaya devam edecek ve bölünmüş beyni onaracaktır. Los-Los, Angeles veya GRE yedek katmanlarından en az biri kullanılabilir hale gelir.

Aynı mekanizma, Let's Encrypt sertifikalarını anında yayınlamamıza ve yenilememize olanak tanır. Çok basit bir şekilde şu şekilde çalışır:

1. Müşterimizin etki alanı için sertifikası olmayan (veya süresi dolmuş bir sertifikaya sahip) en az bir HTTPS isteği gördüğümüzde, isteği kabul eden harici düğüm bunu dahili sertifika yetkilisine bildirir.

   

2. Kullanıcı Let's Encrypt'in verilmesini yasaklamadıysa, sertifika yetkilisi bir CSR oluşturur, LE'den bir onay tokenı alır ve bunu şifrelenmiş bir kanal üzerinden tüm cephelere gönderir. Artık herhangi bir düğüm LE'den gelen doğrulama isteğini onaylayabilir.

   

3. Birkaç dakika içerisinde doğru sertifikayı ve özel anahtarı alıp aynı şekilde cephelere göndereceğiz. Yine, cinleri yeniden başlatmadan

   

4. Son kullanma tarihine 7 gün kala sertifikanın tekrar alınmasına ilişkin prosedür başlatılır.

Şu anda 350 sertifikayı gerçek zamanlı olarak kullanıcılara tamamen şeffaf bir şekilde döndürüyoruz.

Serinin sonraki makalelerinde, büyük web trafiğinin gerçek zamanlı işlenmesinin diğer özellikleri hakkında konuşacağım - örneğin, toplu taşıma müşterileri için hizmet kalitesini artırmak için eksik verileri kullanarak RTT'yi analiz etme ve genel olarak toplu taşıma trafiğini koruma hakkında konuşacağım. trafik bilgilerinin teslimi ve toplanması, WAF, neredeyse sınırsız CDN ve içerik dağıtımını optimize etmeye yönelik birçok mekanizma hakkında terabit saldırıları.

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

İlk önce neyi bilmek istersiniz?

• %14,3Web trafiğinin kalitesini kümelemeye ve analiz etmeye yönelik algoritmalar<3

• %33,3DDoS-Guard7 dengeleyicilerin dahili bileşenleri

• %9,5Transit L3/L4 trafiğinin korunması2

• %0,0Toplu taşıma trafiğinde web sitelerinin korunması0

• %14,3Web Uygulaması Güvenlik Duvarı3

• %28,6Ayrıştırma ve tıklamaya karşı koruma6

21 kullanıcı oy kullandı. 6 kullanıcı çekimser kaldı.

Kaynak: habr.com