Web HighLoad - sut rydym yn rheoli traffig ar gyfer degau o filoedd o barthau

Yn ddiweddar, aeth traffig cyfreithlon ar rwydwaith DDoS-Guard dros gant gigabits yr eiliad. Ar hyn o bryd, mae 50% o'n holl draffig yn cael ei gynhyrchu gan wasanaethau gwe cleientiaid. Mae'r rhain yn ddegau o filoedd o feysydd, yn wahanol iawn ac yn y rhan fwyaf o achosion yn gofyn am ddull unigol.

Islaw'r toriad mae sut rydym yn rheoli nodau blaen ac yn cyhoeddi tystysgrifau SSL ar gyfer cannoedd o filoedd o safleoedd.

Mae sefydlu blaen ar gyfer un safle, hyd yn oed un mawr iawn, yn hawdd. Rydyn ni'n cymryd nginx neu haproxy neu lighttpd, yn ei ffurfweddu yn ôl y canllawiau ac yn anghofio amdano. Os oes angen i ni newid rhywbeth, rydyn ni'n ail-lwytho ac yn anghofio eto.

Mae popeth yn newid pan fyddwch chi'n prosesu llawer iawn o draffig ar y hedfan, yn gwerthuso cyfreithlondeb ceisiadau, yn cywasgu a storio cynnwys defnyddwyr, ac ar yr un pryd yn newid paramedrau sawl gwaith yr eiliad. Mae'r defnyddiwr eisiau gweld y canlyniad ar bob nod allanol yn syth ar ôl iddo newid y gosodiadau yn ei gyfrif personol. Gall defnyddiwr hefyd lawrlwytho sawl mil (ac weithiau ddegau o filoedd) o barthau gyda pharamedrau prosesu traffig unigol trwy'r API. Dylai hyn i gyd hefyd weithio ar unwaith yn America, ac yn Ewrop, ac yn Asia - nid y dasg yw'r un mwyaf dibwys, gan ystyried bod yna nifer o nodau hidlo wedi'u gwahanu'n gorfforol ym Moscow yn unig.

Pam mae yna lawer o nodau dibynadwy mawr ledled y byd?

• Ansawdd gwasanaeth ar gyfer traffig cleientiaid - mae angen prosesu ceisiadau o UDA yn UDA (gan gynnwys ar gyfer ymosodiadau, dosrannu ac anomaleddau eraill), a pheidio â'u tynnu i Moscow neu Ewrop, gan gynyddu'r oedi prosesu yn anrhagweladwy.

• Rhaid i draffig ymosod fod yn lleol - gall gweithredwyr trafnidiaeth ddiraddio yn ystod ymosodiadau, y mae eu cyfaint yn aml yn fwy na 1Tbps. Nid yw cludo traffig ymosod dros gysylltiadau trawsatlantig neu drawsasaidd yn syniad da. Cawsom achosion go iawn pan ddywedodd gweithredwyr Haen-1: “Mae nifer yr ymosodiadau a gewch yn beryglus i ni.” Dyna pam yr ydym yn derbyn ffrydiau sy'n dod i mewn mor agos â phosibl at eu ffynonellau.

• Gofynion llym ar gyfer parhad gwasanaeth - ni ddylai canolfannau glanhau ddibynnu ar ei gilydd nac ar ddigwyddiadau lleol yn ein byd sy'n newid yn gyflym. A wnaethoch chi dorri pŵer i bob un o'r 11 llawr o MMTS-9 am wythnos? - dim problem. Ni fydd un cleient nad oes ganddo gysylltiad corfforol yn y lleoliad penodol hwn yn dioddef, ac ni fydd gwasanaethau gwe yn dioddef o dan unrhyw amgylchiadau.

Sut i reoli hyn i gyd?

Dylid dosbarthu cyfluniadau gwasanaeth i bob nod blaen cyn gynted â phosibl (yn ddelfrydol ar unwaith). Ni allwch gymryd ac ailadeiladu cyfluniadau testun ac ailgychwyn y daemons ar bob newid - mae'r un nginx yn cadw prosesau i gau (gweithiwr yn cau) am ychydig funudau eraill (neu efallai oriau os oes sesiynau gwe-soced hir).

Wrth ail-lwytho'r cyfluniad nginx, mae'r llun canlynol yn eithaf normal:

Ar ddefnyddio cof:

Mae hen weithwyr yn bwyta cof, gan gynnwys cof nad yw'n dibynnu'n llinol ar nifer y cysylltiadau - mae hyn yn normal. Pan fydd cysylltiadau cleient ar gau, bydd y cof hwn yn cael ei ryddhau.

Pam nad oedd hyn yn broblem pan oedd nginx newydd ddechrau? Nid oedd unrhyw HTTP/2, dim WebSocket, dim cysylltiadau cadw'n fyw hir enfawr. Mae 70% o'n traffig gwe yn HTTP/2, sy'n golygu cysylltiadau hir iawn.

Mae'r ateb yn syml - peidiwch â defnyddio nginx, peidiwch â rheoli blaenau yn seiliedig ar ffeiliau testun, ac yn sicr peidiwch ag anfon ffurfweddiadau testun wedi'u sipio dros sianeli trawsffordd. Mae'r sianeli, wrth gwrs, wedi'u gwarantu a'u cadw, ond nid yw hynny'n eu gwneud yn llai traws-gyfandirol.

Mae gennym ein gweinydd-cydbwysydd blaen ein hunain, y byddaf yn siarad amdano yn yr erthyglau canlynol. Y prif beth y gall ei wneud yw cymhwyso miloedd o newidiadau cyfluniad yr eiliad ar y hedfan, heb ailgychwyn, ail-lwytho, cynnydd sydyn yn y defnydd o gof, a hynny i gyd. Mae hyn yn debyg iawn i Hot Code Reload, er enghraifft yn Erlang. Mae'r data'n cael ei storio mewn cronfa ddata gwerth bysell geo-ddosbarthu ac yn cael ei ddarllen ar unwaith gan yr actiwadyddion blaen. Y rhai. rydych chi'n uwchlwytho'r dystysgrif SSL trwy'r rhyngwyneb gwe neu API ym Moscow, ac mewn ychydig eiliadau mae'n barod i fynd i'n canolfan lanhau yn Los Angeles. Os bydd rhyfel byd yn digwydd yn sydyn a'r Rhyngrwyd yn diflannu ledled y byd, bydd ein nodau'n parhau i weithio'n annibynnol ac yn atgyweirio'r ymennydd hollt cyn gynted ag y bydd un o'r sianeli pwrpasol Los Angeles-Amsterdam-Moscow, Moscow-Amsterdam-Hong Kong- Mae Los-Los ar gael. Angeles neu o leiaf un o'r troshaenau wrth gefn GRE.

Mae'r un mecanwaith hwn yn ein galluogi i gyhoeddi ac adnewyddu tystysgrifau Let's Encrypt ar unwaith. Yn syml iawn mae'n gweithio fel hyn:

1. Cyn gynted ag y gwelwn o leiaf un cais HTTPS ar gyfer parth ein cleient heb dystysgrif (neu gyda thystysgrif sydd wedi dod i ben), mae'r nod allanol a dderbyniodd y cais yn adrodd hyn i'r awdurdod ardystio mewnol.

   

2. Os nad yw'r defnyddiwr wedi gwahardd cyhoeddi Let's Encrypt, mae'r awdurdod ardystio yn cynhyrchu CSR, yn derbyn tocyn cadarnhad gan LE ac yn ei anfon i bob ffrynt dros sianel wedi'i hamgryptio. Nawr gall unrhyw nod gadarnhau cais dilysu gan LE.

   

3. Mewn ychydig eiliadau, byddwn yn derbyn y dystysgrif gywir a'r allwedd breifat ac yn ei hanfon at y blaen yn yr un modd. Eto, heb ailgychwyn y daemons

   

4. 7 diwrnod cyn y dyddiad dod i ben, mae'r weithdrefn ar gyfer ail-dderbyn y dystysgrif yn cael ei rhoi ar waith

Ar hyn o bryd rydym yn cylchdroi tystysgrifau 350k mewn amser real, yn gwbl dryloyw i ddefnyddwyr.

Yn yr erthyglau canlynol o'r gyfres, byddaf yn siarad am nodweddion eraill o brosesu amser real o draffig gwe mawr - er enghraifft, am ddadansoddi RTT gan ddefnyddio data anghyflawn i wella ansawdd y gwasanaeth ar gyfer cleientiaid tramwy ac yn gyffredinol am ddiogelu traffig cludo rhag ymosodiadau terabit, am gyflwyno a chydgrynhoi gwybodaeth traffig, am WAF, CDN diderfyn bron a llawer o fecanweithiau ar gyfer optimeiddio cyflwyno cynnwys.

Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. Mewngofnodios gwelwch yn dda.

Beth hoffech chi ei wybod gyntaf?

• 14,3%Algorithmau ar gyfer clystyru a dadansoddi ansawdd traffig gwe<3

• 33,3%Mewnoli balanswyr DDoS-Guard7

• 9,5%Diogelu traffig tramwy L3/L4

• 0,0%Diogelu gwefannau ar draffig cludo0

• 14,3%Wal Dân Cymhwysiad Gwe3

• 28,6%Amddiffyniad rhag dosrannu a chlicio6

Pleidleisiodd 21 o ddefnyddwyr. Ymataliodd 6 o ddefnyddwyr.

Ffynhonnell: hab.com