Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

DDoS-Guard тармагындагы мыйзамдуу трафик жакында секундасына жүз гигабиттен ашты. Учурда биздин трафиктин 50% кардарлардын веб-кызматтарынан түзүлөт. Бул көптөгөн он миңдеген домендер, алар абдан ар түрдүү жана көпчүлүк учурда жеке мамилени талап кылат.

Төмөндө биз алдыңкы түйүндөрдү кантип башкарарыбыз жана жүз миңдеген сайттар үчүн SSL сертификаттарын чыгарабыз.

Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

Бир сайттын, атүгүл абдан чоң сайттын алдынан орнотуу оңой. Биз nginx же haproxy же lighttpd алып, аны жетектөөлөргө ылайык конфигурациялап, аны унутуп коёбуз. Биз бир нерсени өзгөртүү керек болсо, биз кайра жүктөө жана кайра унутуп.

Чоң көлөмдөгү трафикти тез иштеп чыкканда, сурамдардын мыйзамдуулугун баалаганыңызда, колдонуучунун мазмунун кысып, кэш кылганыңызда жана ошол эле учурда секундасына бир нече жолу параметрлерди өзгөрткөнүңүздө баары өзгөрөт. Колдонуучу жеке аккаунтундагы орнотууларды өзгөрткөндөн кийин дароо бардык тышкы түйүндөрдөгү натыйжаны көргүсү келет. Колдонуучу ошондой эле API аркылуу трафикти иштетүүнүн жеке параметрлери менен бир нече миң (жана кээде он миңдеген) домендерди жүктөй алат. Мунун баары Америкада да, Европада да, Азияда да дароо иштеши керек - Москвада эле бир нече физикалык жактан бөлүнгөн чыпкалоо түйүндөрү бар экенин эске алганда, милдет өтө маанилүү эмес.

Эмне үчүн дүйнө жүзү боюнча көптөгөн ири ишенимдүү түйүндөр бар?

  • Кардар трафиги үчүн тейлөөнүн сапаты - АКШдан келген суроо-талаптар АКШда иштелип чыгышы керек (анын ичинде чабуулдар, талдоо жана башка аномалиялар үчүн) жана Москвага же Европага тартпастан, кайра иштетүү кечиктирилиши күтүүсүз көбөйөт.

  • Чабуул трафиги локализацияланышы керек - транзиттик операторлор чабуул учурунда начарлашы мүмкүн, алардын көлөмү көбүнчө 1Тбит/сек ашат. Чабуул трафигин трансатлантикалык же трансазиялык байланыштар аркылуу ташуу жакшы идея эмес. Бизде Tier-1 операторлору: "Сиз алган чабуулдардын көлөмү биз үчүн коркунучтуу" деп айткан учурлар болгон. Ошондуктан биз келген агымдарды мүмкүн болушунча булактарына жакын кабыл алабыз.

  • Кызмат көрсөтүүнүн үзгүлтүксүздүгүнө карата катуу талаптар – тазалоо борборлору бири-биринен же биздин тез өзгөрүп жаткан дүйнөбүздөгү жергиликтүү окуялардан көз каранды болбошу керек. ММТС-11дун бардык 9 кабатына бир жумага электр жарыгын өчүрдүңүзбү? - көйгөй жок. Бул жерде физикалык байланышы жок бир дагы кардар жабыр тартпайт жана веб-кызматтар эч кандай шартта жабыр тартпайт.

Мунун баарын кантип башкаруу керек?

Кызматтын конфигурациялары бардык алдыңкы түйүндөргө мүмкүн болушунча тезирээк (идеалдуу түрдө заматта) бөлүштүрүлүшү керек. Сиз жөн гана текст конфигурацияларын алып, кайра түзө албайсыз жана ар бир өзгөртүүдө демондорду кайра жүктөй албайсыз - ошол эле nginx процесстерди дагы бир нече мүнөткө (же бир нече саатка чейин веб-розетка сеанстары болсо) өчүрүп турат (жумушчу жабылат).

Nginx конфигурациясын кайра жүктөөдө, төмөнкү сүрөт нормалдуу көрүнүш:

Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

Эстутумду пайдалануу боюнча:

Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

Эски жумушчулар эстутумду, анын ичинде байланыштардын санына сызыктуу көз каранды эмес эс тутумун жешет - бул нормалдуу көрүнүш. Кардар байланыштары жабылганда, бул эстутум бошотулат.

Эмне үчүн nginx жаңыдан башталып жатканда бул маселе болгон эмес? Эч кандай HTTP/2, WebSocket, эч кандай массалык узак тирүү байланыштар болгон эмес. Биздин веб-трафиктин 70% HTTP/2, бул өтө узун байланыштарды билдирет.

Чечим жөнөкөй - nginx колдонбоңуз, текст файлдарынын негизинде фронтторду башкарбаңыз жана, албетте, транспацификалык каналдар аркылуу zip текст конфигурацияларын жөнөтпөңүз. Каналдар, албетте, кепилденген жана корголгон, бирок бул аларды трансконтиненталдуу кылбайт.

Бизде өзүбүздүн алдыңкы сервер-балансаторубуз бар, анын ички түзүлүштөрү жөнүндө мен кийинки макалаларда айтам. Эң негизгиси, ал жасай турган нерсе - секундасына миңдеген конфигурациялык өзгөрүүлөрдү кайра күйгүзүүсүз, кайра жүктөөсүз, эстутум керектөөнүн күтүлбөгөн жерден көбөйүшүнө жана башкалардын бардыгына колдонуу. Бул, мисалы, Эрлангдагы Hot Code Reload менен абдан окшош. Маалыматтар гео-бөлүштүрүлгөн ачкыч-маанилер базасында сакталат жана алдыңкы кыймылдаткычтар тарабынан дароо окулат. Ошол. сиз SSL сертификатын Москвадагы веб-интерфейс же API аркылуу жүктөсөңүз, ал бир нече секунданын ичинде Лос-Анжелестеги тазалоо борборубузга барууга даяр. Эгер күтүлбөгөн жерден дүйнөлүк согуш болуп, бүткүл дүйнө жүзү боюнча Интернет жок болуп кетсе, анда биздин түйүндөр өз алдынча иштөөнү уланта берет жана атайын каналдардын бири Лос-Анджелес-Амстердам-Москва, Москва-Амстердам-Гонконг- дароо эле экиге бөлүнөт. Лос-Лос жеткиликтүү болот. Анжелес же жок дегенде GRE камдык катмарларынын бири.

Ушул эле механизм бизге Let's Encrypt сертификаттарын дароо чыгарууга жана жаңылоого мүмкүндүк берет. Абдан жөнөкөй, ал төмөнкүдөй иштейт:

  1. Кардарыбыздын доменине сертификаты жок (же мөөнөтү бүткөн сертификаты бар) жок дегенде бир HTTPS өтүнүчүн көрөөрүбүз менен, сурамды кабыл алган тышкы түйүн бул тууралуу ички сертификаттоо органына кабарлайт.

    Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

  2. Колдонуучу Let's Encrypt чыгарууга тыюу салбаса, сертификациялык орган CSR түзөт, LEден ырастоо белгисин алат жана аны шифрленген канал аркылуу бардык фронтторго жөнөтөт. Эми каалаган түйүн LEден текшерүү өтүнүчүн ырастай алат.

    Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

  3. Бир нече көз ирмемден кийин биз туура сертификатты жана купуя ачкычты алып, ошол эле жол менен фронтторго жөнөтөбүз. Дагы, демондорду кайра иштетпестен

    Web HighLoad - он миңдеген домендер үчүн трафикти кантип башкарабыз

  4. Жарамдуулук мөөнөтү бүтөөрүнө 7 күн калганда сертификатты кайра алуу процедурасы башталат

Азыр биз реалдуу убакыт режиминде 350 миң сертификатты айландырып жатабыз, колдонуучулар үчүн ачык-айкын.

Сериянын кийинки макалаларында мен чоң веб-трафикти реалдуу убакыт режиминде иштетүүнүн башка өзгөчөлүктөрү жөнүндө сөз кылам - мисалы, транзиттик кардарлар үчүн тейлөөнүн сапатын жакшыртуу үчүн толук эмес маалыматтарды колдонуу менен RTT талдоо жана жалпысынан транзиттик трафикти коргоо жөнүндө. terabit чабуулдары, трафик маалыматын жеткирүү жана топтоо жөнүндө, WAF жөнүндө, дээрлик чексиз CDN жана мазмунду жеткирүүнүн оптималдаштыруу механизмдери.

Сурамжылоого катталган колдонуучулар гана катыша алышат. Кирүү, өтүнөмүн.

Сиз биринчи эмнени билгиңиз келет?

  • 14,3%Веб трафиктин сапатын кластерлөө жана талдоо алгоритмдери<3

  • 33,3%DDoS-Guard7 баланстоочуларынын ички түзүлүштөрү

  • 9,5%L3/L4 транзиттик трафикти коргоо2

  • 0,0%Транзиттик трафик боюнча веб-сайттарды коргоо0

  • 14,3%Web Application Firewall3

  • 28,6%Талдоодон жана чыкылдатуудан коргоо6

21 колдонуучу добуш берди. 6 колдонуучу добуш берүүдөн баш тартты.

Source: www.habr.com

Комментарий кошуу