Web HighLoad - cara kami mengurus trafik untuk puluhan ribu domain

Trafik yang sah pada rangkaian DDoS-Guard baru-baru ini melebihi seratus gigabit sesaat. Pada masa ini, 50% daripada semua trafik kami dihasilkan oleh perkhidmatan web pelanggan. Ini adalah berpuluh-puluh ribu domain, sangat berbeza dan dalam kebanyakan kes memerlukan pendekatan individu.

Di bawah potongan ialah cara kami mengurus nod hadapan dan mengeluarkan sijil SSL untuk ratusan ribu tapak.

Menyediakan bahagian hadapan untuk satu tapak, walaupun yang sangat besar, adalah mudah. Kami mengambil nginx atau haproxy atau lighttpd, konfigurasikannya mengikut panduan dan lupakannya. Jika kita perlu menukar sesuatu, kita lakukan tambah nilai dan lupakan semula.

Segala-galanya berubah apabila anda memproses jumlah trafik yang besar dengan cepat, menilai kesahihan permintaan, memampatkan dan menyimpan kandungan pengguna, dan pada masa yang sama menukar parameter beberapa kali sesaat. Pengguna ingin melihat keputusan pada semua nod luaran serta-merta selepas dia menukar tetapan dalam akaun peribadinya. Pengguna juga boleh memuat turun beberapa ribu (dan kadangkala puluhan ribu) domain dengan parameter pemprosesan trafik individu melalui API. Semua ini juga harus berfungsi dengan segera di Amerika, dan di Eropah, dan di Asia - tugas itu bukanlah yang paling remeh, memandangkan di Moscow sahaja terdapat beberapa nod penapisan yang dipisahkan secara fizikal.

Mengapakah terdapat banyak nod besar yang boleh dipercayai di seluruh dunia?

• Kualiti perkhidmatan untuk trafik pelanggan - permintaan dari Amerika Syarikat perlu diproses di Amerika Syarikat (termasuk untuk serangan, penghuraian dan anomali lain), dan tidak ditarik ke Moscow atau Eropah, secara tidak menentu meningkatkan kelewatan pemprosesan.

• Trafik serangan mesti disetempatkan - pengendali transit boleh merosot semasa serangan, volumnya selalunya melebihi 1Tbps. Mengangkut trafik serangan melalui pautan transatlantik atau transasian bukanlah idea yang baik. Kami mempunyai kes sebenar apabila pengendali Tahap-1 berkata: "Jumlah serangan yang anda terima berbahaya bagi kami." Itulah sebabnya kami menerima aliran masuk sedekat mungkin dengan sumbernya.

• Keperluan ketat untuk kesinambungan perkhidmatan - pusat pembersihan tidak boleh bergantung sama ada pada satu sama lain atau pada acara tempatan dalam dunia kita yang berubah dengan pantas. Adakah anda memutuskan kuasa ke semua 11 tingkat MMTS-9 selama seminggu? - tiada masalah. Tidak seorang pun pelanggan yang tidak mempunyai sambungan fizikal di lokasi tertentu akan menderita, dan perkhidmatan web tidak akan menderita dalam apa jua keadaan.

Bagaimana untuk menguruskan semua ini?

Konfigurasi perkhidmatan harus diedarkan kepada semua nod hadapan secepat mungkin (ideal serta-merta). Anda tidak boleh hanya mengambil dan membina semula konfigurasi teks dan but semula daemon pada setiap perubahan - nginx yang sama memastikan proses dimatikan (pekerja menutup) selama beberapa minit lagi (atau mungkin berjam-jam jika terdapat sesi websocket yang panjang).

Apabila memuatkan semula konfigurasi nginx, gambar berikut adalah perkara biasa:

Mengenai penggunaan memori:

Pekerja lama memakan ingatan, termasuk ingatan yang tidak bergantung secara linear pada bilangan sambungan - ini adalah perkara biasa. Apabila sambungan pelanggan ditutup, memori ini akan dibebaskan.

Mengapa ini tidak menjadi isu semasa nginx baru bermula? Tiada HTTP/2, tiada WebSocket, tiada sambungan besar-besaran yang terus hidup. 70% daripada trafik web kami ialah HTTP/2, yang bermaksud sambungan yang sangat panjang.

Penyelesaiannya adalah mudah - jangan gunakan nginx, jangan urus bahagian hadapan berdasarkan fail teks, dan sudah tentu jangan hantar konfigurasi teks berzip melalui saluran transpasifik. Saluran itu, sudah tentu, dijamin dan dikhaskan, tetapi itu tidak menjadikan saluran itu kurang merentasi benua.

Kami mempunyai pengimbang pelayan hadapan kami sendiri, bahagian dalaman yang akan saya bincangkan dalam artikel berikut. Perkara utama yang boleh dilakukan ialah menggunakan beribu-ribu perubahan konfigurasi sesaat dengan cepat, tanpa dimulakan semula, tambah nilai, peningkatan mendadak dalam penggunaan memori, dan semua itu. Ini sangat serupa dengan Hot Code Reload, contohnya dalam Erlang. Data disimpan dalam pangkalan data nilai kunci teragih geo dan dibaca serta-merta oleh penggerak hadapan. Itu. anda memuat naik sijil SSL melalui antara muka web atau API di Moscow, dan dalam beberapa saat ia bersedia untuk pergi ke pusat pembersihan kami di Los Angeles. Jika perang dunia tiba-tiba berlaku dan Internet hilang di seluruh dunia, nod kami akan terus berfungsi secara autonomi dan membaiki otak terpecah sebaik sahaja salah satu saluran khusus Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hong Kong- Los-Los tersedia. Angeles atau sekurang-kurangnya satu tindanan sandaran GRE.

Mekanisme yang sama ini membolehkan kami mengeluarkan dan memperbaharui sijil Let's Encrypt serta-merta. Sangat mudah ia berfungsi seperti ini:

1. Sebaik sahaja kami melihat sekurang-kurangnya satu permintaan HTTPS untuk domain pelanggan kami tanpa sijil (atau dengan sijil tamat tempoh), nod luaran yang menerima permintaan melaporkan perkara ini kepada pihak berkuasa pensijilan dalaman.

   

2. Jika pengguna tidak melarang pengeluaran Let's Encrypt, pihak berkuasa pensijilan menjana CSR, menerima token pengesahan daripada LE dan menghantarnya ke semua bahagian melalui saluran yang disulitkan. Kini mana-mana nod boleh mengesahkan permintaan pengesahan daripada LE.

   

3. Dalam beberapa saat, kami akan menerima sijil dan kunci peribadi yang betul dan menghantarnya ke bahagian hadapan dengan cara yang sama. Sekali lagi, tanpa memulakan semula daemon

   

4. 7 hari sebelum tarikh tamat tempoh, prosedur untuk menerima semula sijil dimulakan

Pada masa ini kami sedang memutarkan 350k sijil dalam masa nyata, telus sepenuhnya kepada pengguna.

Dalam artikel siri berikut, saya akan bercakap tentang ciri lain pemprosesan masa nyata trafik web yang besar - contohnya, tentang menganalisis RTT menggunakan data yang tidak lengkap untuk meningkatkan kualiti perkhidmatan untuk pelanggan transit dan secara umum tentang melindungi trafik transit daripada serangan terabit, tentang penghantaran dan pengagregatan maklumat trafik, tentang WAF, CDN yang hampir tidak terhad dan banyak mekanisme untuk mengoptimumkan penghantaran kandungan.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Apa yang anda ingin tahu dahulu?

• 14,3% Algoritma untuk mengelompokkan dan menganalisis kualiti trafik web<3

• 33,3% Bahagian dalaman pengimbang DDoS-Guard7

• 9,5% Perlindungan trafik L3/L4 transit2

• 0,0% Melindungi tapak web pada trafik transit0

• 14,3% Firewall Aplikasi Web3

• 28,6% Perlindungan terhadap penghuraian dan klik6

21 pengguna mengundi. 6 pengguna berpantang.

Sumber: www.habr.com