Web HighLoad - cara kami mengelola lalu lintas untuk puluhan ribu domain

Lalu lintas sah di jaringan DDoS-Guard baru-baru ini melebihi seratus gigabit per detik. Saat ini, 50% dari seluruh lalu lintas kami dihasilkan oleh layanan web klien. Ini adalah puluhan ribu domain, sangat berbeda dan dalam banyak kasus memerlukan pendekatan individual.

Di bawah ini adalah cara kami mengelola node depan dan menerbitkan sertifikat SSL untuk ratusan ribu situs.

Menyiapkan tampilan depan untuk satu situs, bahkan situs yang sangat besar, sangatlah mudah. Kami mengambil nginx atau haproxy atau lighttpd, mengkonfigurasinya sesuai dengan panduan dan melupakannya. Jika kami perlu mengubah sesuatu, kami memuat ulang dan melupakannya lagi.

Semuanya berubah saat Anda memproses lalu lintas dalam jumlah besar dengan cepat, mengevaluasi keabsahan permintaan, mengompresi dan menyimpan konten pengguna dalam cache, dan pada saat yang sama mengubah parameter beberapa kali per detik. Pengguna ingin melihat hasilnya di semua node eksternal segera setelah dia mengubah pengaturan di akun pribadinya. Seorang pengguna juga dapat mengunduh beberapa ribu (dan terkadang puluhan ribu) domain dengan parameter pemrosesan lalu lintas individual melalui API. Semua ini juga harus segera berfungsi di Amerika, dan di Eropa, dan di Asia - tugas ini bukanlah tugas yang paling sepele, mengingat di Moskow saja terdapat beberapa titik penyaringan yang terpisah secara fisik.

Mengapa ada banyak node besar yang dapat diandalkan di seluruh dunia?

• Kualitas layanan untuk lalu lintas klien - permintaan dari AS perlu diproses di AS (termasuk untuk serangan, penguraian, dan anomali lainnya), dan tidak ditarik ke Moskow atau Eropa, sehingga meningkatkan penundaan pemrosesan secara tidak terduga.

• Lalu lintas serangan harus dilokalisasi - operator transit dapat mengalami penurunan selama serangan, yang volumenya seringkali melebihi 1Tbps. Mengangkut lalu lintas serangan melalui jalur transatlantik atau transasian bukanlah ide yang baik. Kami memiliki kasus nyata ketika operator Tingkat 1 mengatakan: “Volume serangan yang Anda terima berbahaya bagi kami.” Itu sebabnya kami menerima aliran masuk sedekat mungkin dengan sumbernya.

• Persyaratan ketat untuk kesinambungan layanan - pusat kebersihan tidak boleh bergantung satu sama lain atau pada acara lokal di dunia kita yang berubah dengan cepat. Apakah Anda memutus aliran listrik ke 11 lantai MMTS-9 selama seminggu? - Tidak masalah. Tidak ada satu pun klien yang tidak memiliki koneksi fisik di lokasi tertentu yang akan dirugikan, dan layanan web tidak akan dirugikan dalam kondisi apa pun.

Bagaimana cara mengelola semua ini?

Konfigurasi layanan harus didistribusikan ke semua node depan secepat mungkin (idealnya secara instan). Anda tidak bisa begitu saja mengambil dan membangun kembali konfigurasi teks dan me-reboot daemon di setiap perubahan - nginx yang sama membuat proses tetap terhenti (pekerja dimatikan) selama beberapa menit lagi (atau mungkin berjam-jam jika ada sesi soket web yang panjang).

Saat memuat ulang konfigurasi nginx, gambar berikut cukup normal:

Tentang pemanfaatan memori:

Pekerja lama memakan memori, termasuk memori yang tidak bergantung secara linier pada jumlah koneksi - ini normal. Ketika koneksi klien ditutup, memori ini akan dibebaskan.

Mengapa ini tidak menjadi masalah ketika nginx baru saja dimulai? Tidak ada HTTP/2, tidak ada WebSocket, tidak ada koneksi besar yang tetap hidup. 70% lalu lintas web kami adalah HTTP/2, yang berarti koneksi sangat panjang.

Solusinya sederhana - jangan gunakan nginx, jangan kelola front berdasarkan file teks, dan tentunya jangan mengirim konfigurasi teks zip melalui saluran transpasifik. Saluran-saluran tersebut, tentu saja, dijamin dan dilindungi undang-undang, namun hal itu tidak berarti bahwa saluran-saluran tersebut tidak bersifat lintas benua.

Kami memiliki penyeimbang server depan kami sendiri, yang internalnya akan saya bahas di artikel berikut. Hal utama yang dapat dilakukannya adalah menerapkan ribuan perubahan konfigurasi per detik dengan cepat, tanpa memulai ulang, memuat ulang, peningkatan konsumsi memori secara tiba-tiba, dan sebagainya. Ini sangat mirip dengan Hot Code Reload, misalnya di Erlang. Data disimpan dalam database nilai kunci yang terdistribusi secara geografis dan segera dibaca oleh aktuator depan. Itu. Anda mengunggah sertifikat SSL melalui antarmuka web atau API di Moskow, dan dalam beberapa detik sertifikat tersebut siap dikirim ke pusat pembersihan kami di Los Angeles. Jika perang dunia tiba-tiba terjadi dan Internet menghilang di seluruh dunia, node kami akan terus bekerja secara mandiri dan memperbaiki otak yang terbelah segera setelah salah satu saluran khusus Los Angeles-Amsterdam-Moskow, Moskow-Amsterdam-Hong Kong- Los-Los menjadi tersedia Angeles atau setidaknya salah satu dari overlay cadangan GRE.

Mekanisme yang sama memungkinkan kami menerbitkan dan memperbarui sertifikat Let's Encrypt secara instan. Sederhananya cara kerjanya seperti ini:

1. Segera setelah kami melihat setidaknya satu permintaan HTTPS untuk domain klien kami tanpa sertifikat (atau dengan sertifikat yang kedaluwarsa), node eksternal yang menerima permintaan tersebut melaporkan hal ini ke otoritas sertifikasi internal.

   

2. Jika pengguna tidak melarang penerbitan Let's Encrypt, otoritas sertifikasi menghasilkan CSR, menerima token konfirmasi dari LE dan mengirimkannya ke semua lini melalui saluran terenkripsi. Sekarang node mana pun dapat mengonfirmasi permintaan validasi dari LE.

   

3. Dalam beberapa saat, kami akan menerima sertifikat dan kunci pribadi yang benar dan mengirimkannya ke depan dengan cara yang sama. Sekali lagi, tanpa me-restart daemon

   

4. 7 hari sebelum tanggal kadaluarsa, prosedur penerimaan kembali sertifikat dimulai

Saat ini kami merotasi 350 ribu sertifikat secara real time, sepenuhnya transparan bagi pengguna.

Dalam artikel seri berikutnya, saya akan berbicara tentang fitur lain dari pemrosesan lalu lintas web besar secara real-time - misalnya, tentang menganalisis RTT menggunakan data yang tidak lengkap untuk meningkatkan kualitas layanan bagi klien angkutan umum dan secara umum tentang melindungi lalu lintas angkutan umum dari serangan terabit, tentang pengiriman dan agregasi informasi lalu lintas, tentang WAF, CDN yang hampir tidak terbatas dan banyak mekanisme untuk mengoptimalkan pengiriman konten.

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. Masuk, silakan.

Apa yang ingin Anda ketahui terlebih dahulu?

• 14,3%Algoritma untuk mengelompokkan dan menganalisis kualitas lalu lintas web<3

• 33,3%Internal penyeimbang DDoS-Guard7

• 9,5%Perlindungan lalu lintas transit L3/L4

• 0,0%Melindungi situs web pada lalu lintas transit0

• 14,3%Firewall Aplikasi Web3

• 28,6%Perlindungan terhadap parsing dan klik6

21 pengguna memilih. 6 pengguna abstain.

Sumber: www.habr.com