Web HighLoad - hoe ons die verkeer van tienduisende domeine bestuur

Wettige verkeer op die DDoS-Guard-netwerk het onlangs honderd gigabits per sekonde oorskry. Tans word 50% van al ons verkeer deur kliëntewebdienste gegenereer. Dit is baie tienduisende domeine, baie verskillend en vereis in die meeste gevalle 'n individuele benadering.

Onder die snit is hoe ons voorste nodusse bestuur en SSL-sertifikate vir honderde duisende werwe uitreik.

Dit is maklik om 'n front vir een perseel, selfs 'n baie groot een, op te rig. Ons neem nginx of haproxy of lighttpd, stel dit in volgens die gidse en vergeet daarvan. As ons iets moet verander, doen ons 'n herlaai en vergeet weer.

Alles verander wanneer jy groot volumes verkeer dadelik verwerk, die legitimiteit van versoeke evalueer, gebruikersinhoud saamdruk en kas, en terselfdertyd parameters verskeie kere per sekonde verander. Die gebruiker wil die resultaat op alle eksterne nodusse sien onmiddellik nadat hy die instellings in sy persoonlike rekening verander het. 'n Gebruiker kan ook etlike duisende (en soms tienduisende) domeine aflaai met individuele verkeersverwerkingsparameters via die API. Dit alles behoort ook onmiddellik te werk in Amerika, en in Europa en in Asië - die taak is nie die mees onbenullige nie, aangesien daar in Moskou alleen verskeie fisies geskeide filtrasieknope is.

Hoekom is daar baie groot betroubare nodusse regoor die wêreld?

• Gehalte van diens vir kliëntverkeer - versoeke van die VSA moet in die VSA verwerk word (insluitend vir aanvalle, ontleding en ander afwykings), en nie na Moskou of Europa getrek word nie, wat die verwerkingsvertraging onvoorspelbaar verhoog.

• Aanvalverkeer moet gelokaliseer word - transito-operateurs kan afbreek tydens aanvalle, waarvan die volume dikwels 1Tbps oorskry. Om aanvalsverkeer oor transatlantiese of transasiese skakels te vervoer is nie 'n goeie idee nie. Ons het werklike gevalle gehad toe Tier-1-operateurs gesê het: "Die hoeveelheid aanvalle wat jy ontvang is gevaarlik vir ons." Daarom aanvaar ons inkomende strome so na as moontlik aan hul bronne.

• Streng vereistes vir kontinuïteit van diens - skoonmaaksentrums behoort nie van mekaar of van plaaslike gebeure in ons vinnig veranderende wêreld afhanklik te wees nie. Het jy die krag na al 11 verdiepings van MMTS-9 vir 'n week afgesny? - geen probleem. Nie 'n enkele kliënt wat nie 'n fisiese verbinding in hierdie spesifieke ligging het nie, sal ly nie, en webdienste sal onder geen omstandighede ly nie.

Hoe om dit alles te bestuur?

Dienskonfigurasies moet so vinnig as moontlik (verkieslik onmiddellik) na alle voorknope versprei word. Jy kan nie net tekskonfigurasies neem en herbou en die daemone by elke verandering herlaai nie - dieselfde nginx hou prosesse af (werker sluit af) vir nog 'n paar minute (of dalk ure as daar lang websoksessies is).

Wanneer die nginx-konfigurasie herlaai word, is die volgende prentjie heel normaal:

Oor geheue gebruik:

Ou werkers eet geheue op, insluitend geheue wat nie lineêr afhang van die aantal verbindings nie – dit is normaal. Wanneer kliëntverbindings gesluit is, sal hierdie geheue vrygestel word.

Hoekom was dit nie 'n probleem toe nginx net begin het nie? Daar was geen HTTP/2, geen WebSocket, geen massiewe lang aanhou-verbindings nie. 70% van ons webverkeer is HTTP/2, wat baie lang verbindings beteken.

Die oplossing is eenvoudig - moenie nginx gebruik nie, bestuur nie fronte gebaseer op tekslêers nie, en stuur beslis nie geritste tekskonfigurasies oor transpasifiese kanale nie. Die kanale is natuurlik gewaarborg en gereserveer, maar dit maak hulle nie minder transkontinentaal nie.

Ons het ons eie bediener-balanseerder aan die voorkant, waarvan ek in die volgende artikels sal praat. Die belangrikste ding wat dit kan doen, is om duisende konfigurasieveranderings per sekonde toe te pas, sonder herbegin, herlaai, skielike toename in geheueverbruik, en dit alles. Dit is baie soortgelyk aan Hot Code Reload, byvoorbeeld in Erlang. Die data word gestoor in 'n geo-verspreide sleutel-waarde databasis en word onmiddellik gelees deur die voorste aktueerders. Dié. jy laai die SSL-sertifikaat op via die webkoppelvlak of API in Moskou, en binne 'n paar sekondes is dit gereed om na ons skoonmaaksentrum in Los Angeles te gaan. As 'n wêreldoorlog skielik plaasvind en die internet oor die hele wêreld verdwyn, sal ons nodusse voortgaan om outonoom te werk en die gesplete brein te herstel sodra een van die toegewyde kanale Los Angeles-Amsterdam-Moskou, Moskou-Amsterdam-Hong Kong- Los-Los word beskikbaar. Angeles of ten minste een van die GRE-rugsteun-oorlegsels.

Hierdie selfde meganisme stel ons in staat om onmiddellik Let's Encrypt-sertifikate uit te reik en te hernu. Baie eenvoudig werk dit so:

1. Sodra ons ten minste een HTTPS-versoek vir ons kliënt se domein sien sonder 'n sertifikaat (of met 'n sertifikaat wat verval het), rapporteer die eksterne nodus wat die versoek aanvaar het dit aan die interne sertifiseringsowerheid.

   

2. As die gebruiker nie die uitreiking van Let's Encrypt verbied het nie, genereer die sertifiseringsowerheid 'n CSR, ontvang 'n bevestigingsteken van LE en stuur dit na alle fronte oor 'n geënkripteerde kanaal. Nou kan enige nodus 'n validerende versoek van LE bevestig.

   

3. Oor 'n paar oomblikke sal ons die korrekte sertifikaat en privaat sleutel ontvang en dit op dieselfde manier na die fronte stuur. Weereens, sonder om die daemone weer te begin

   

4. 7 dae voor die vervaldatum word die prosedure vir die herontvang van die sertifikaat begin

Op die oomblik draai ons 350 XNUMX sertifikate in reële tyd, heeltemal deursigtig vir gebruikers.

In die volgende artikels van die reeks sal ek praat oor ander kenmerke van intydse verwerking van groot webverkeer - byvoorbeeld oor die ontleding van RTT met behulp van onvolledige data om die kwaliteit van diens vir publieke vervoerkliënte te verbeter en in die algemeen oor die beskerming van vervoerverkeer teen terabit-aanvalle, oor die lewering en samevoeging van verkeersinligting, oor WAF, byna onbeperkte CDN en baie meganismes vir die optimalisering van inhoudlewering.

Slegs geregistreerde gebruikers kan aan die opname deelneem. Meld aan, asseblief.

Wat wil jy eers weet?

• 14,3%Algoritmes vir groepering en ontleding van die kwaliteit van webverkeer<3

• 33,3%Interns van DDoS-Guard7-balanseerders

• 9,5%Beskerming van transito L3/L4 verkeer2

• 0,0%Beskerming van webwerwe oor vervoerverkeer0

• 14,3%Webtoepassing Firewall3

• 28,6%Beskerming teen ontleding en klik6

21 gebruikers het gestem. 6 gebruikers het buite stemming gebly.

Bron: will.com