વેબ હાઇલોડ - અમે હજારો ડોમેન્સના ટ્રાફિકને કેવી રીતે મેનેજ કરીએ છીએ

DDoS-Guard નેટવર્ક પર કાયદેસર ટ્રાફિક તાજેતરમાં પ્રતિ સેકન્ડ સો ગીગાબીટ્સને વટાવી ગયો છે. હાલમાં, અમારા તમામ ટ્રાફિકમાંથી 50% ક્લાયંટ વેબ સેવાઓ દ્વારા જનરેટ થાય છે. આ ઘણા હજારો ડોમેન્સ છે, જે ખૂબ જ અલગ છે અને મોટાભાગના કિસ્સાઓમાં વ્યક્તિગત અભિગમની જરૂર છે.

અમે ફ્રન્ટ નોડ્સ કેવી રીતે મેનેજ કરીએ છીએ અને હજારો સાઇટ્સ માટે SSL પ્રમાણપત્રો ઇશ્યૂ કરીએ છીએ તે કટની નીચે છે.

એક સાઇટ માટે ફ્રન્ટ સેટ કરવું, ખૂબ મોટી સાઇટ માટે પણ, સરળ છે. અમે nginx અથવા haproxy અથવા lighttpd લઈએ છીએ, તેને માર્ગદર્શિકાઓ અનુસાર ગોઠવીએ છીએ અને તેના વિશે ભૂલી જઈએ છીએ. જો આપણે કંઈક બદલવાની જરૂર હોય, તો અમે ફરીથી લોડ કરીએ છીએ અને ફરીથી ભૂલી જઈએ છીએ.

જ્યારે તમે ફ્લાય પર મોટા પ્રમાણમાં ટ્રાફિક પર પ્રક્રિયા કરો છો, વિનંતીઓની કાયદેસરતાનું મૂલ્યાંકન કરો છો, વપરાશકર્તા સામગ્રીને સંકુચિત કરો છો અને કેશ કરો છો અને તે જ સમયે સેકન્ડ દીઠ ઘણી વખત પરિમાણો બદલો છો ત્યારે બધું બદલાય છે. વપરાશકર્તા તેના વ્યક્તિગત ખાતામાં સેટિંગ્સ બદલ્યા પછી તરત જ તમામ બાહ્ય નોડ્સ પર પરિણામ જોવા માંગે છે. વપરાશકર્તા API દ્વારા વ્યક્તિગત ટ્રાફિક પ્રોસેસિંગ પરિમાણો સાથે કેટલાક હજાર (અને કેટલીકવાર હજારો) ડોમેન્સ પણ ડાઉનલોડ કરી શકે છે. આ બધું અમેરિકા, અને યુરોપ અને એશિયામાં પણ તરત જ કામ કરવું જોઈએ - કાર્ય સૌથી તુચ્છ નથી, કારણ કે એકલા મોસ્કોમાં જ ઘણા શારીરિક રીતે અલગ ફિલ્ટરેશન નોડ્સ છે.

શા માટે વિશ્વભરમાં ઘણા મોટા વિશ્વસનીય ગાંઠો છે?

• ક્લાયંટ ટ્રાફિક માટે સેવાની ગુણવત્તા - યુએસએ તરફથી વિનંતીઓ પર યુએસએમાં પ્રક્રિયા કરવાની જરૂર છે (હુમલા, પદચ્છેદન અને અન્ય વિસંગતતાઓ સહિત), અને મોસ્કો અથવા યુરોપ તરફ ખેંચાય નહીં, પ્રક્રિયામાં વિલંબમાં અણધારી વધારો થાય છે.

• હુમલાનો ટ્રાફિક સ્થાનિક હોવો જોઈએ - હુમલા દરમિયાન ટ્રાન્ઝિટ ઓપરેટરો અધોગતિ કરી શકે છે, જેનું પ્રમાણ ઘણીવાર 1Tbps કરતાં વધી જાય છે. ટ્રાન્સએટલાન્ટિક અથવા ટ્રાન્સએશિયન લિંક્સ પર એટેક ટ્રાફિકનું પરિવહન કરવું એ સારો વિચાર નથી. અમારી પાસે વાસ્તવિક કિસ્સાઓ હતા જ્યારે ટિયર-1 ઓપરેટરોએ કહ્યું: "તમે પ્રાપ્ત કરેલા હુમલાઓનું પ્રમાણ અમારા માટે જોખમી છે." એટલા માટે અમે ઇનકમિંગ સ્ટ્રીમ્સને તેમના સ્ત્રોતની શક્ય તેટલી નજીક સ્વીકારીએ છીએ.

• સેવાની સાતત્યતા માટેની કડક આવશ્યકતાઓ - સફાઈ કેન્દ્રોએ આપણી ઝડપથી બદલાતી દુનિયામાં એકબીજા પર અથવા સ્થાનિક ઘટનાઓ પર આધાર રાખવો જોઈએ નહીં. શું તમે એક અઠવાડિયા માટે MMTS-11ના તમામ 9 માળની વીજળી કાપી નાખી હતી? - કોઇ વાંધો નહી. એક પણ ક્લાયંટ કે જેની પાસે આ ચોક્કસ સ્થાન પર ભૌતિક જોડાણ નથી તે પીડાશે નહીં, અને વેબ સેવાઓ કોઈપણ સંજોગોમાં પીડાશે નહીં.

આ બધું કેવી રીતે મેનેજ કરવું?

સેવા રૂપરેખાંકનો શક્ય તેટલી ઝડપથી (આદર્શ રીતે તરત જ) તમામ આગળના ગાંઠો પર વિતરિત થવી જોઈએ. તમે ફક્ત ટેક્સ્ટ કન્ફિગ્સ લઈ શકતા નથી અને પુનઃબીલ્ડ કરી શકતા નથી અને દરેક ફેરફાર પર ડિમનને રીબૂટ કરી શકતા નથી - તે જ nginx થોડી વધુ મિનિટો (અથવા લાંબા વેબસોકેટ સત્રો હોય તો કદાચ કલાકો) માટે પ્રક્રિયાઓને શટ ડાઉન (કાર્યકર શટ ડાઉન) રાખે છે.

nginx રૂપરેખાંકનને ફરીથી લોડ કરતી વખતે, નીચેનું ચિત્ર એકદમ સામાન્ય છે:

મેમરીના ઉપયોગ પર:

જૂના કામદારો મેમરીને ખાય છે, જેમાં મેમરીનો સમાવેશ થાય છે જે કનેક્શનની સંખ્યા પર રેખીય રીતે આધાર રાખતી નથી - આ સામાન્ય છે. જ્યારે ક્લાયંટ કનેક્શન્સ બંધ હોય, ત્યારે આ મેમરી મુક્ત કરવામાં આવશે.

જ્યારે nginx હમણાં જ શરૂ થઈ રહ્યું હતું ત્યારે આ કોઈ સમસ્યા કેમ ન હતી? ત્યાં કોઈ HTTP/2 નહોતું, કોઈ વેબસોકેટ નહોતું, કોઈ વિશાળ લાંબા સમય સુધી જીવંત-જીવંત જોડાણો નહોતા. અમારા વેબ ટ્રાફિકનો 70% HTTP/2 છે, જેનો અર્થ ખૂબ લાંબા જોડાણો છે.

ઉકેલ સરળ છે - nginx નો ઉપયોગ કરશો નહીં, ટેક્સ્ટ ફાઇલોના આધારે મોરચાનું સંચાલન કરશો નહીં, અને ચોક્કસપણે ટ્રાન્સપેસિફિક ચેનલો પર ઝિપ કરેલ ટેક્સ્ટ કન્ફિગરેશન્સ મોકલશો નહીં. ચેનલો, અલબત્ત, બાંયધરીકૃત અને આરક્ષિત છે, પરંતુ તે તેમને કોઈ ઓછી ટ્રાન્સકોન્ટિનેન્ટલ બનાવતી નથી.

અમારી પાસે અમારું પોતાનું ફ્રન્ટ સર્વર-બેલેન્સર છે, જેની આંતરિક હું નીચેના લેખોમાં વાત કરીશ. મુખ્ય વસ્તુ જે તે કરી શકે છે તે છે ફ્લાય પર પ્રતિ સેકન્ડ હજારો રૂપરેખાંકન ફેરફારો, પુનઃપ્રારંભ કર્યા વિના, ફરીથી લોડ કર્યા વિના, મેમરી વપરાશમાં અચાનક વધારો અને તે બધું. આ હોટ કોડ રીલોડ જેવું જ છે, ઉદાહરણ તરીકે એર્લાંગમાં. ડેટા ભૌગોલિક-વિતરિત કી-વેલ્યુ ડેટાબેઝમાં સંગ્રહિત થાય છે અને ફ્રન્ટ એક્ટ્યુએટર્સ દ્વારા તરત જ વાંચવામાં આવે છે. તે. તમે SSL પ્રમાણપત્ર વેબ ઈન્ટરફેસ અથવા API દ્વારા મોસ્કોમાં અપલોડ કરો છો અને થોડીવારમાં તે લોસ એન્જલસમાં અમારા સફાઈ કેન્દ્રમાં જવા માટે તૈયાર છે. જો અચાનક વિશ્વયુદ્ધ થાય અને સમગ્ર વિશ્વમાં ઈન્ટરનેટ અદૃશ્ય થઈ જાય, તો અમારા ગાંઠો સ્વાયત્ત રીતે કામ કરવાનું ચાલુ રાખશે અને સમર્પિત ચેનલોમાંથી એક લોસ એન્જલસ-એમ્સ્ટરડેમ-મોસ્કો, મોસ્કો-એમ્સ્ટરડેમ-હોંગકોંગ- જલદી સ્પ્લિટ-બ્રેઈનને રિપેર કરશે. લોસ-લોસ ઉપલબ્ધ થાય છે. એન્જલસ અથવા ઓછામાં ઓછું એક GRE બેકઅપ ઓવરલે.

આ જ મિકેનિઝમ અમને લેટ્સ એન્ક્રિપ્ટ પ્રમાણપત્રોને તરત જ જારી કરવા અને રિન્યૂ કરવાની મંજૂરી આપે છે. ખૂબ જ સરળ રીતે તે આની જેમ કાર્ય કરે છે:

1. જલદી અમે અમારા ક્લાયંટના ડોમેન માટે પ્રમાણપત્ર વિના (અથવા સમાપ્ત થયેલ પ્રમાણપત્ર સાથે) ઓછામાં ઓછી એક HTTPS વિનંતી જોયે છે, બાહ્ય નોડ કે જેણે વિનંતી સ્વીકારી છે તે આંતરિક પ્રમાણપત્ર અધિકારીને તેની જાણ કરે છે.

   

2. જો વપરાશકર્તાએ Let's Encrypt જારી કરવા પર પ્રતિબંધ ન મૂક્યો હોય, તો પ્રમાણપત્ર અધિકારી CSR જનરેટ કરે છે, LE તરફથી પુષ્ટિકરણ ટોકન મેળવે છે અને તેને એન્ક્રિપ્ટેડ ચેનલ પર તમામ મોરચે મોકલે છે. હવે કોઈપણ નોડ LE તરફથી માન્ય વિનંતીની પુષ્ટિ કરી શકે છે.

   

3. થોડીવારમાં, અમે સાચું પ્રમાણપત્ર અને ખાનગી કી પ્રાપ્ત કરીશું અને તે જ રીતે મોરચા પર મોકલીશું. ફરીથી, ડિમનને પુનઃપ્રારંભ કર્યા વિના

   

4. સમાપ્તિ તારીખના 7 દિવસ પહેલા, પ્રમાણપત્ર ફરીથી પ્રાપ્ત કરવાની પ્રક્રિયા શરૂ કરવામાં આવે છે

અત્યારે અમે 350k પ્રમાણપત્રોને વાસ્તવિક સમયમાં ફેરવી રહ્યા છીએ, વપરાશકર્તાઓ માટે સંપૂર્ણપણે પારદર્શક છે.

શ્રેણીના નીચેના લેખોમાં, હું મોટા વેબ ટ્રાફિકની રીઅલ-ટાઇમ પ્રોસેસિંગની અન્ય સુવિધાઓ વિશે વાત કરીશ - ઉદાહરણ તરીકે, ટ્રાન્ઝિટ ક્લાયંટ માટે સેવાની ગુણવત્તા સુધારવા માટે અપૂર્ણ ડેટાનો ઉપયોગ કરીને આરટીટીનું વિશ્લેષણ કરવા વિશે અને સામાન્ય રીતે ટ્રાન્ઝિટ ટ્રાફિકને સુરક્ષિત રાખવા વિશે ટેરાબિટ હુમલાઓ, ટ્રાફિક માહિતીની ડિલિવરી અને એકત્રીકરણ વિશે, 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