Web HighLoad - carane ngatur lalu lintas kanggo puluhan ewu domain

Lalu lintas sing sah ing jaringan DDoS-Guard bubar ngluwihi satus gigabit per detik. Saiki, 50% kabeh lalu lintas digawe dening layanan web klien. Iki akeh puluhan ewu domain, beda banget lan umume mbutuhake pendekatan individu.

Ing ngisor potong yaiku carane ngatur simpul ngarep lan ngetokake sertifikat SSL kanggo atusan ewu situs.

Nyetel ngarep kanggo siji situs, malah sing gedhe banget, gampang. Kita njupuk nginx utawa haproxy utawa lighttpd, ngatur miturut pandhuan lan lali babagan. Yen kita kudu ngganti soko, kita nindakake reload lan lali maneh.

Kabeh owah-owahan nalika sampeyan ngolah volume lalu lintas kanthi cepet, ngevaluasi legitimasi panjalukan, kompres lan isi cache pangguna, lan ing wektu sing padha ngganti paramèter kaping pirang-pirang saben detik. Pangguna pengin ndeleng asil ing kabeh simpul eksternal sanalika sawise ngganti setelan ing akun pribadhi. Pangguna uga bisa ngundhuh sawetara ewu (lan kadhangkala puluhan ewu) domain kanthi paramèter pangolahan lalu lintas individu liwat API. Kabeh iki uga kudu bisa langsung ing Amerika, lan ing Eropah, lan ing Asia - tugas ora paling sepele, considering sing ing Moscow piyambak ana sawetara kelenjar filtrasi kapisah fisik.

Napa ana akeh simpul sing bisa dipercaya ing saindenging jagad?

• Kualitas layanan kanggo lalu lintas klien - panjaluk saka AS kudu diproses ing AS (kalebu serangan, parsing lan anomali liyane), lan ora ditarik menyang Moskow utawa Eropa, kanthi ora bisa diramalake nambah wektu tundha pangolahan.

• Lalu lintas serangan kudu dilokalisasi - operator transit bisa ngrusak sajrone serangan, volume sing asring ngluwihi 1Tbps. Ngangkut lalu lintas serangan liwat pranala transatlantik utawa transasian ora apik. Kita duwe kasus nyata nalika operator Tier-1 ujar: "Volume serangan sing sampeyan tampa mbebayani kanggo kita." Pramila kita nampa aliran sing mlebu kanthi cedhak karo sumbere.

• Syarat ketat kanggo kesinambungan layanan - pusat reresik kudu ora gumantung ing saben liyane utawa ing acara lokal ing jagad sing saya ganti kanthi cepet. Apa sampeyan mateni daya kanggo kabeh 11 jubin MMTS-9 sajrone seminggu? - ora masalah. Ora ana klien siji sing ora duwe sambungan fisik ing lokasi tartamtu iki bakal nandhang sangsara, lan layanan web ora bakal nandhang sangsara ing kahanan apa wae.

Kepiye carane ngatur kabeh iki?

Konfigurasi layanan kudu disebarake menyang kabeh kelenjar ngarep kanthi cepet (saenipun langsung). Sampeyan ora bisa njupuk lan mbangun maneh konfigurasi teks lan urip maneh daemon ing saben owah-owahan - nginx sing padha tetep proses mati (pegawe mateni) sawetara menit maneh (utawa bisa uga jam yen ana sesi websocket sing dawa).

Nalika ngisi ulang konfigurasi nginx, gambar ing ngisor iki cukup normal:

Ing panggunaan memori:

buruh lawas mangan munggah memori, kalebu memori sing ora linearly gumantung ing nomer sambungan - iki normal. Nalika sambungan klien ditutup, memori iki bakal dibebasake.

Napa iki ora dadi masalah nalika nginx lagi wae diwiwiti? Ora ana HTTP / 2, ora ana WebSocket, ora ana sambungan sing dawa banget. 70% saka lalu lintas web kita yaiku HTTP/2, tegese sambungan sing dawa banget.

Solusi kasebut gampang - aja nggunakake nginx, aja ngatur ngarep adhedhasar file teks, lan mesthi ora ngirim konfigurasi teks zip liwat saluran transpacific. Saluran kasebut, mesthi, dijamin lan dilindhungi undhang-undhang, nanging ora nggawe dheweke kurang transcontinental.

Kita duwe server-balancer ngarep dhewe, internal sing bakal dakkandhakake ing artikel ing ngisor iki. Wangsulan: Bab ingkang utama sing bisa nindakake iku aplikasi ewu owah-owahan konfigurasi per detik ing fly ing, tanpa miwiti maneh, reloads, mundhak dadakan ing konsumsi memori, lan kabeh sing. Iki meh padha karo Hot Code Reload, contone ing Erlang. Data kasebut disimpen ing basis data nilai kunci sing disebarake geo lan langsung diwaca dening aktuator ngarep. Sing. sampeyan ngunggah sertifikat SSL liwat antarmuka web utawa API ing Moskow, lan ing sawetara detik wis siyap kanggo pindhah menyang pusat reresik ing Los Angeles. Yen perang donya dumadakan kedadeyan lan Internet ilang ing saindenging jagad, simpul kita bakal terus kerja kanthi mandiri lan ndandani otak pamisah sanalika salah sawijining saluran khusus Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hong Kong- Los-Los kasedhiya. Angeles utawa ing paling siji saka overlay serep GRE.

Mekanisme sing padha iki ngidini kita ngetokake lan gawe anyar sertifikat Ayo Encrypt. Gampang banget kerjane kaya iki:

1. Sanalika kita ndeleng paling ora siji panjalukan HTTPS kanggo domain klien kita tanpa sertifikat (utawa karo sertifikat kadaluwarsa), simpul eksternal sing nampa panjalukan kasebut nglaporake iki menyang otoritas sertifikasi internal.

   

2. Yen pangguna ora nglarang penerbitan Ayo Encrypt, panguwasa sertifikasi ngasilake CSR, nampa token konfirmasi saka LE lan dikirim menyang kabeh ngarep liwat saluran sing ndhelik. Saiki simpul apa wae bisa ngonfirmasi panjaluk validasi saka LE.

   

3. Ing sawetara wektu, kita bakal nampa sertifikat sing bener lan kunci pribadi lan ngirim menyang ngarep kanthi cara sing padha. Maneh, tanpa miwiti maneh daemon

   

4. 7 dina sadurunge tanggal kadaluwarsa, prosedur kanggo nampa maneh sertifikat diwiwiti

Saiki kita muter sertifikat 350k ing wektu nyata, kanthi transparan kanggo pangguna.

Ing artikel seri ing ngisor iki, aku bakal ngomong babagan fitur liyane babagan proses nyata-nyata lalu lintas web gedhe - contone, babagan nganalisa RTT nggunakake data sing ora lengkap kanggo nambah kualitas layanan kanggo klien transit lan umume babagan nglindhungi lalu lintas transit saka serangan terabit, babagan pangiriman lan pengumpulan informasi lalu lintas, babagan WAF, CDN sing meh ora ana watesan lan akeh mekanisme kanggo ngoptimalake pangiriman konten.

Mung pangguna pangguna sing bisa melu survey. mlebunggih.

Apa sampeyan pengin ngerti dhisik?

• 14,3%Algoritma kanggo clustering lan nganalisa kualitas lalu lintas web<3

• 33,3%Internal saka DDoS-Guard7 balancers

• 9,5%Pangreksan lalu lintas L3/L4 transit2

• 0,0%Nglindhungi situs web ing lalu lintas transit0

• 14,3%Firewall Aplikasi Web3

• 28,6%Proteksi marang parsing lan ngeklik6

21 pangguna milih. 6 kedhaftar abstained.

Source: www.habr.com