Web HighLoad - бид хэдэн арван мянган домэйны урсгалыг хэрхэн удирддаг

DDoS-Guard сүлжээн дэх хууль ёсны траффик саяхан секундэд 50 гигабит давсан. Одоогоор манай нийт траффикийн XNUMX% нь үйлчлүүлэгчийн вэб үйлчилгээнээс бүрддэг. Эдгээр нь маш өөр бөгөөд ихэнх тохиолдолд хувь хүний ​​хандлагыг шаарддаг олон арван мянган домайнууд юм.

Тасалгааны доор бид урд талын зангилаануудыг хэрхэн удирдаж, хэдэн зуун мянган сайтад SSL сертификат олгохыг харуулав.

Web HighLoad - бид хэдэн арван мянган домэйны урсгалыг хэрхэн удирддаг

Нэг сайт, тэр ч байтугай маш том талбайн нүүрэн талыг тохируулах нь хялбар байдаг. Бид nginx эсвэл haproxy эсвэл lighttpd-г авч, зааврын дагуу тохируулаад үүнийг мартдаг. Хэрэв бид ямар нэг зүйлийг өөрчлөх шаардлагатай бол дахин ачаалж, дахин мартдаг.

Их хэмжээний траффикийг шууд боловсруулж, хүсэлтийн хууль ёсны байдлыг үнэлэх, хэрэглэгчийн агуулгыг шахаж, кэш хийх, мөн секундэд хэд хэдэн удаа параметрүүдийг өөрчлөх үед бүх зүйл өөрчлөгддөг. Хэрэглэгч өөрийн хувийн дансны тохиргоог өөрчилсний дараа шууд бүх гадаад зангилааны үр дүнг харахыг хүсч байна. Хэрэглэгч API-ээр дамжуулан хувийн траффик боловсруулах параметр бүхий хэдэн мянган (заримдаа хэдэн арван мянган) домэйныг татаж авах боломжтой. Энэ бүхэн Америк, Европ, Азид нэн даруй ажиллах ёстой - зөвхөн Москвад бие махбодийн хувьд тусгаарлагдсан шүүлтүүрийн зангилаа байдаг тул даалгавар нь хамгийн энгийн зүйл биш юм.

Яагаад дэлхий даяар олон том найдвартай зангилаа байдаг вэ?

  • Үйлчлүүлэгчийн урсгалд үзүүлэх үйлчилгээний чанар - АНУ-аас ирсэн хүсэлтийг АНУ-д боловсруулах шаардлагатай (халдлага, задлан шинжилгээ болон бусад гажиг гэх мэт) бөгөөд Москва эсвэл Европ руу татахгүй байх, боловсруулалтын саатлыг урьдчилан таамаглах аргагүй нэмэгдүүлдэг.

  • Довтолгооны урсгалыг нутагшуулсан байх ёстой - дайралтын үед транзит операторууд доройтож, эзлэхүүн нь ихэвчлэн 1Tbps-ээс их байдаг. Халдлагын урсгалыг Атлантын далай эсвэл Ази дамнасан холбоосоор тээвэрлэх нь тийм ч сайн санаа биш юм. 1-р түвшний операторууд "Таны хүлээн авсан халдлагын хэмжээ нь бидний хувьд аюултай" гэж хэлсэн бодит тохиолдол бидэнд тохиолдсон. Тиймээс бид ирж буй урсгалыг эх сурвалжтай нь аль болох ойртуулдаг.

  • Үйлчилгээний тасралтгүй байдлын хатуу шаардлага - цэвэрлэгээний төвүүд нь бие биенээсээ эсвэл манай хурдацтай өөрчлөгдөж буй ертөнцөд орон нутгийн үйл явдлуудаас хамаарах ёсгүй. ММТС-11-ийн бүх 9 давхарын цахилгааныг долоо хоног тасалсан уу? - асуудалгүй. Энэ байршилд физик холболтгүй нэг ч үйлчлүүлэгч хохирохгүй бөгөөд вэб үйлчилгээ ямар ч тохиолдолд хохирохгүй.

Энэ бүхнийг яаж зохицуулах вэ?

Үйлчилгээний тохиргоог бүх урд зангилаанд аль болох хурдан (хамгийн тохиромжтой) тараах хэрэгтэй. Та зүгээр л текстийн тохиргоог авч, дахин бүтээж, өөрчлөлт болгонд демонуудыг дахин ачаалж болохгүй - ижил nginx процессуудыг дахин хэдэн минут (эсвэл удаан вэбсокет сесс байгаа бол хэдэн цагаар) унтраадаг (ажилчин унтардаг).

Nginx тохиргоог дахин ачаалах үед дараах зураг хэвийн байна.

Web HighLoad - бид хэдэн арван мянган домэйны урсгалыг хэрхэн удирддаг

Санах ойн ашиглалтын талаар:

Web HighLoad - бид хэдэн арван мянган домэйны урсгалыг хэрхэн удирддаг

Хуучин ажилчид санах ой, түүний дотор холболтын тооноос шугаман хамааралгүй санах ойг иддэг - энэ нь хэвийн үзэгдэл юм. Үйлчлүүлэгчийн холболтыг хаах үед энэ санах ой чөлөөлөгдөнө.

Nginx дөнгөж эхэлж байхад яагаад ийм асуудал гараагүй юм бэ? Ямар ч HTTP/2, WebSocket, ямар ч урт удаан амьд холболт байхгүй. Манай вэб траффикийн 70% нь HTTP/2 бөгөөд энэ нь маш урт холболт гэсэн үг.

Шийдэл нь маш энгийн - nginx бүү ашигла, текст файл дээр тулгуурлан фронтуудыг удирдаж болохгүй, мөн дамнуургын сувгуудаар зиплэгдсэн текстийн тохиргоог илгээж болохгүй. Мэдээжийн хэрэг, сувгууд нь баталгаатай бөгөөд нөөцлөгдсөн, гэхдээ энэ нь тэднийг тив дамнасан болгодоггүй.

Бидэнд өөрийн гэсэн сервер тэнцвэржүүлэгч байдаг бөгөөд тэдгээрийн дотоод байдлын талаар би дараагийн нийтлэлүүдэд ярих болно. Үүний хийж чадах гол зүйл бол дахин эхлүүлэх, дахин ачаалах, санах ойн хэрэглээг гэнэт нэмэгдүүлэх гэх мэт бүх зүйлгүйгээр секундэд хэдэн мянган тохиргооны өөрчлөлтийг шууд хийх явдал юм. Энэ нь Hot Code Reload-тай тун төстэй, жишээ нь Erlang-д. Өгөгдөл нь гео тархсан түлхүүр-утгийн мэдээллийн санд хадгалагдаж, урд талын идэвхжүүлэгчид шууд уншина. Тэдгээр. Та Москва дахь вэб интерфэйс эсвэл API-ээр дамжуулан SSL сертификатыг байршуулж, хэдхэн секундын дараа Лос Анжелес дахь манай цэвэрлэх төвд очиход бэлэн болно. Гэнэт дэлхийн дайн болж, интернет дэлхий даяар алга болчихвол Лос Анжелес-Амстердам-Москва, Москва-Амстердам-Хонконг- гэсэн тусгай сувгуудын нэг болмогц манай зангилаанууд бие даасан байдлаар ажиллаж, тархи хуваагдсан хэсгийг засах болно. Лос-Лос боломжтой боллоо. Анжелес эсвэл ядаж 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%Вэб програмын галт хана3

  • 28,6%Шинжилгээ болон товшилтоос хамгаалах 6

21 хэрэглэгч санал өгсөн. 6 хэрэглэгч түдгэлзсэн.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх