Bitrix24: "જે ઝડપથી ઊભું થાય છે તેને પડી ગયેલું માનવામાં આવતું નથી"

આજે, Bitrix24 સેવામાં સેંકડો ગીગાબિટ્સ ટ્રાફિક નથી, કે તેની પાસે સર્વરોનો વિશાળ કાફલો નથી (જોકે, અલબત્ત, ત્યાં ઘણા બધા અસ્તિત્વમાં છે). પરંતુ ઘણા ગ્રાહકો માટે તે કંપનીમાં કામ કરવા માટેનું મુખ્ય સાધન છે; તે એક વાસ્તવિક વ્યવસાય-નિર્ણાયક એપ્લિકેશન છે. તેથી, પડવાનો કોઈ રસ્તો નથી. જો ક્રેશ થયું હોત, પરંતુ સેવા એટલી ઝડપથી "પુનઃપ્રાપ્ત" થઈ ગઈ કે કોઈએ કંઈપણ જોયું નહીં? અને કામની ગુણવત્તા અને ગ્રાહકોની સંખ્યા ગુમાવ્યા વિના ફેલઓવરનો અમલ કેવી રીતે શક્ય છે? Bitrix24 ખાતે ક્લાઉડ સેવાઓના ડિરેક્ટર એલેક્ઝાન્ડર ડેમિડોવ, અમારા બ્લોગ માટે ઉત્પાદનના અસ્તિત્વના 7 વર્ષોમાં આરક્ષણ પ્રણાલી કેવી રીતે વિકસિત થઈ છે તે વિશે વાત કરી હતી.

“અમે 24 વર્ષ પહેલાં SaaS તરીકે Bitrix7 લોન્ચ કર્યું હતું. મુખ્ય મુશ્કેલી કદાચ નીચે મુજબ હતી: SaaS તરીકે સાર્વજનિક રૂપે લોન્ચ કરવામાં આવે તે પહેલાં, આ ઉત્પાદન ફક્ત બોક્સવાળા સોલ્યુશનના ફોર્મેટમાં અસ્તિત્વમાં હતું. ગ્રાહકોએ તે અમારી પાસેથી ખરીદ્યું, તેને તેમના સર્વર પર હોસ્ટ કર્યું, કોર્પોરેટ પોર્ટલ સેટ કર્યું - કર્મચારી સંચાર, ફાઇલ સ્ટોરેજ, ટાસ્ક મેનેજમેન્ટ, CRM, આટલું જ સામાન્ય ઉકેલ. અને 2012 સુધીમાં, અમે નક્કી કર્યું કે અમે તેને SaaS તરીકે લોન્ચ કરવા માગીએ છીએ, તેને જાતે જ સંચાલિત કરીએ છીએ, દોષ સહિષ્ણુતા અને વિશ્વસનીયતાની ખાતરી કરીએ છીએ. અમે રસ્તામાં અનુભવ મેળવ્યો, કારણ કે ત્યાં સુધી અમારી પાસે તે નહોતું - અમે ફક્ત સોફ્ટવેર ઉત્પાદકો હતા, સેવા પ્રદાતાઓ નહીં.

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

Bitrix.24 SaaS તરીકે

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

તે સમયે એક સામાન્ય વેબ એપ્લિકેશન એ એક સર્વર હતું જેના પર કેટલાક PHP કોડ ચાલે છે, એક mysql ડેટાબેઝ, ફાઇલો અપલોડ કરવામાં આવે છે, દસ્તાવેજો, ચિત્રો અપલોડ ફોલ્ડરમાં મૂકવામાં આવે છે - સારું, તે બધું કામ કરે છે. અરે, આનો ઉપયોગ કરીને વિવેચનાત્મક રીતે સ્થિર વેબ સેવા શરૂ કરવી અશક્ય છે. ત્યાં, વિતરિત કેશ સમર્થિત નથી, ડેટાબેઝ પ્રતિકૃતિ સમર્થિત નથી.

અમે આવશ્યકતાઓ ઘડી છે: આ વિવિધ સ્થળોએ સ્થિત રહેવાની ક્ષમતા છે, પ્રતિકૃતિને સમર્થન આપે છે અને આદર્શ રીતે વિવિધ ભૌગોલિક રીતે વિતરિત ડેટા કેન્દ્રોમાં સ્થિત છે. ઉત્પાદન તર્ક અને હકીકતમાં, ડેટા સ્ટોરેજને અલગ કરો. લોડ અનુસાર ગતિશીલ રીતે સ્કેલ કરવામાં સક્ષમ બનો અને સ્ટેટિક્સને એકસાથે સહન કરો. આ વિચારણાઓમાંથી, વાસ્તવમાં, ઉત્પાદન માટેની આવશ્યકતાઓ ઉભરી આવી, જેને અમે વર્ષ દરમિયાન સુધારી. આ સમય દરમિયાન, પ્લેટફોર્મમાં, જે એકીકૃત બન્યું - બોક્સવાળા સોલ્યુશન્સ માટે, અમારી પોતાની સેવા માટે - અમે તે વસ્તુઓ માટે સપોર્ટ બનાવ્યો જેની અમને જરૂર હતી. ઉત્પાદનના સ્તરે જ mysql પ્રતિકૃતિ માટે સપોર્ટ: એટલે કે, જે વિકાસકર્તા કોડ લખે છે તે તેની વિનંતીઓ કેવી રીતે વિતરિત કરવામાં આવશે તે વિશે વિચારતો નથી, તે અમારા apiનો ઉપયોગ કરે છે, અને અમે માસ્ટર્સ વચ્ચે લખવા અને વાંચવાની વિનંતીઓને યોગ્ય રીતે કેવી રીતે વિતરિત કરવી તે જાણીએ છીએ. અને ગુલામો.

અમે વિવિધ ક્લાઉડ ઑબ્જેક્ટ સ્ટોરેજ માટે પ્રોડક્ટ લેવલ પર સપોર્ટ કર્યો છે: ગૂગલ સ્ટોરેજ, એમેઝોન એસ3, ઉપરાંત ઓપન સ્ટેક સ્વિફ્ટ માટે સપોર્ટ. તેથી, આ અમારા માટે સેવા તરીકે અને પેકેજ્ડ સોલ્યુશન સાથે કામ કરતા વિકાસકર્તાઓ બંને માટે અનુકૂળ હતું: જો તેઓ ફક્ત કાર્ય માટે અમારા API નો ઉપયોગ કરે છે, તો તેઓ ફાઈલ આખરે ક્યાં સાચવવામાં આવશે તે વિશે વિચારતા નથી, સ્થાનિક રીતે ફાઇલ સિસ્ટમ પર અથવા ઑબ્જેક્ટ ફાઇલ સ્ટોરેજમાં.

પરિણામે, અમે તરત જ નક્કી કર્યું કે અમે સમગ્ર ડેટા સેન્ટરના સ્તરે અનામત રાખીશું. 2012 માં, અમે સંપૂર્ણપણે એમેઝોન AWS પર લોન્ચ કર્યું કારણ કે અમને આ પ્લેટફોર્મનો અનુભવ પહેલેથી જ હતો - અમારી પોતાની વેબસાઇટ ત્યાં હોસ્ટ કરવામાં આવી હતી. અમે એ હકીકત દ્વારા આકર્ષિત થયા કે દરેક પ્રદેશમાં એમેઝોન પાસે ઘણા ઉપલબ્ધતા ઝોન છે - હકીકતમાં, (તેમની પરિભાષામાં) ઘણા ડેટા કેન્દ્રો જે એકબીજાથી વધુ કે ઓછા સ્વતંત્ર છે અને અમને સંપૂર્ણ ડેટા સેન્ટરના સ્તરે અનામત રાખવાની મંજૂરી આપે છે: જો તે અચાનક નિષ્ફળ જાય, તો ડેટાબેસેસ માસ્ટર-માસ્ટરની નકલ કરવામાં આવે છે, વેબ એપ્લિકેશન સર્વર્સનો બેકઅપ લેવામાં આવે છે, અને સ્ટેટિક ડેટાને s3 ઑબ્જેક્ટ સ્ટોરેજમાં ખસેડવામાં આવે છે. ભાર સંતુલિત છે - તે સમયે એમેઝોન એલ્બ દ્વારા, પરંતુ થોડા સમય પછી અમે અમારા પોતાના લોડ બેલેન્સર્સ પર આવ્યા, કારણ કે અમને વધુ જટિલ તર્કની જરૂર હતી.

તેઓ જે ઇચ્છતા હતા તે જ તેમને મળ્યું...

બધી મૂળભૂત બાબતો કે જે અમે સુનિશ્ચિત કરવા માગીએ છીએ - સર્વરની પોતાની ખામી સહિષ્ણુતા, વેબ એપ્લિકેશન્સ, ડેટાબેસેસ - બધું બરાબર કામ કર્યું. સૌથી સરળ દૃશ્ય: જો અમારી વેબ એપ્લિકેશનોમાંથી કોઈ એક નિષ્ફળ જાય, તો બધું સરળ છે - તે સંતુલિત થવાથી બંધ છે.

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

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

તે બધું કેવી રીતે કામ કરે છે? — અમે ટ્રાફિકને વર્કિંગ ડેટા સેન્ટર પર સ્વિચ કરીએ છીએ - જો ડેટા સેન્ટર પર કોઈ અકસ્માત થાય, તો સંપૂર્ણ રીતે, જો આ એક ડેટાબેઝ સાથેનું અમારું આયોજિત કાર્ય છે, તો અમે આ ક્લાયન્ટ્સને સેવા આપતા ટ્રાફિકના ભાગને સ્થગિત કરીને બીજા ડેટા સેન્ટર પર સ્વિચ કરીએ છીએ. તેની નકલ. જો વેબ એપ્લીકેશન માટે નવા મશીનોની જરૂર પડશે કારણ કે બીજા ડેટા સેન્ટર પરનો ભાર વધી ગયો છે, તો તે આપમેળે શરૂ થશે. અમે કાર્ય સમાપ્ત કરીએ છીએ, પ્રતિકૃતિ પુનઃસ્થાપિત કરવામાં આવે છે, અને અમે સંપૂર્ણ લોડ પાછું આપીએ છીએ. જો આપણે બીજા ડીસીમાં કેટલાક કાર્યને પ્રતિબિંબિત કરવાની જરૂર હોય, ઉદાહરણ તરીકે, બીજા ડેટાબેઝમાં સિસ્ટમ અપડેટ્સ ઇન્સ્ટોલ કરો અથવા સેટિંગ્સ બદલો, તો પછી, સામાન્ય રીતે, અમે તે જ વસ્તુનું પુનરાવર્તન કરીએ છીએ, ફક્ત બીજી દિશામાં. અને જો આ અકસ્માત છે, તો અમે બધું જ તુચ્છ રીતે કરીએ છીએ: અમે મોનિટરિંગ સિસ્ટમમાં ઇવેન્ટ-હેન્ડલર્સ મિકેનિઝમનો ઉપયોગ કરીએ છીએ. જો અનેક તપાસો ટ્રિગર થાય છે અને સ્થિતિ ગંભીર થઈ જાય છે, તો અમે આ હેન્ડલર ચલાવીએ છીએ, એક હેન્ડલર જે આ અથવા તે તર્કને એક્ઝિક્યુટ કરી શકે છે. દરેક ડેટાબેઝ માટે, અમે સ્પષ્ટ કરીએ છીએ કે કયું સર્વર તેના માટે ફેલઓવર છે અને જો તે અનુપલબ્ધ હોય તો ક્યાં ટ્રાફિકને સ્વિચ કરવાની જરૂર છે. ઐતિહાસિક રીતે, આપણે એક અથવા બીજા સ્વરૂપમાં નાગીઓ અથવા તેના કેટલાક કાંટોનો ઉપયોગ કરીએ છીએ. સૈદ્ધાંતિક રીતે, લગભગ કોઈપણ મોનિટરિંગ સિસ્ટમમાં સમાન મિકેનિઝમ્સ અસ્તિત્વમાં છે; અમે હજી સુધી વધુ જટિલ કંઈપણનો ઉપયોગ કરતા નથી, પરંતુ કદાચ કોઈ દિવસ આપણે કરીશું. હવે મોનિટરિંગ અનુપલબ્ધતા દ્વારા ટ્રિગર થાય છે અને કંઈક સ્વિચ કરવાની ક્ષમતા ધરાવે છે.

શું આપણે બધું અનામત રાખ્યું છે?

અમારી પાસે યુએસએથી ઘણા ક્લાયન્ટ્સ છે, યુરોપના ઘણા ક્લાયન્ટ્સ છે, ઘણા ક્લાયન્ટ્સ છે જે પૂર્વની નજીક છે - જાપાન, સિંગાપોર અને તેથી વધુ. અલબત્ત, ગ્રાહકોનો મોટો હિસ્સો રશિયામાં છે. એટલે કે કામ એક પ્રદેશમાં નથી. વપરાશકર્તાઓ ઝડપી પ્રતિસાદ ઇચ્છે છે, વિવિધ સ્થાનિક કાયદાઓનું પાલન કરવાની આવશ્યકતાઓ છે, અને દરેક પ્રદેશમાં અમે બે ડેટા કેન્દ્રો અનામત રાખીએ છીએ, ઉપરાંત કેટલીક વધારાની સેવાઓ છે, જે ફરીથી, એક પ્રદેશમાં મૂકવા માટે અનુકૂળ છે - જે ગ્રાહકો માટે આ પ્રદેશ કાર્યરત છે. REST હેન્ડલર્સ, ઓથોરાઈઝેશન સર્વર્સ, તેઓ સમગ્ર ક્લાયંટના સંચાલન માટે ઓછા મહત્વપૂર્ણ છે, તમે તેમના દ્વારા સ્વીકાર્ય વિલંબ સાથે સ્વિચ કરી શકો છો, પરંતુ તમે તેમનું નિરીક્ષણ કેવી રીતે કરવું અને શું કરવું તે અંગે ચક્રને ફરીથી શોધવા માંગતા નથી. તેમની સાથે. તેથી, અમે વધારાના ઉત્પાદનોમાં અમુક પ્રકારની યોગ્યતા વિકસાવવાને બદલે વર્તમાન ઉકેલોનો મહત્તમ ઉપયોગ કરવાનો પ્રયાસ કરી રહ્યા છીએ. અને ક્યાંક આપણે DNS સ્તર પર સ્વિચિંગનો નજીવો ઉપયોગ કરીએ છીએ, અને અમે સમાન DNS દ્વારા સેવાની જીવંતતા નક્કી કરીએ છીએ. એમેઝોન પાસે રૂટ 53 સેવા છે, પરંતુ તે માત્ર એક DNS નથી જેમાં તમે એન્ટ્રી કરી શકો છો અને તે જ છે - તે વધુ લવચીક અને અનુકૂળ છે. તેના દ્વારા તમે ભૌગોલિક સ્થાનો સાથે ભૌગોલિક-વિતરિત સેવાઓ બનાવી શકો છો, જ્યારે તમે તેનો ઉપયોગ ક્લાયંટ ક્યાંથી આવ્યો છે તે નિર્ધારિત કરવા અને તેને ચોક્કસ રેકોર્ડ્સ આપવા માટે કરો છો - તેની સહાયથી તમે ફેલઓવર આર્કિટેક્ચર્સ બનાવી શકો છો. સમાન આરોગ્ય-તપાસ રૂટ 53 માં જ ગોઠવેલ છે, તમે મોનિટર કરવામાં આવે છે તે અંતિમ બિંદુઓ સેટ કરો, મેટ્રિક્સ સેટ કરો, સેવાની "જીવંતતા" નક્કી કરવા માટે કયા પ્રોટોકોલ સેટ કરો - tcp, http, https; તપાસની આવર્તન સેટ કરો જે નિર્ધારિત કરે છે કે સેવા જીવંત છે કે નહીં. અને DNS માં જ તમે સ્પષ્ટ કરો છો કે શું પ્રાથમિક હશે, શું ગૌણ હશે, જો રૂટ 53 ની અંદર હેલ્થ-ચેક ટ્રિગર થાય તો ક્યાં સ્વિચ કરવું. એકવાર ઉપર અને પછી તેના વિશે બિલકુલ વિચારશો નહીં કે આપણે કેવી રીતે તપાસ કરીએ છીએ, આપણે કેવી રીતે સ્વિચ કરીએ છીએ: બધું તેની પોતાની રીતે કાર્ય કરે છે.

પ્રથમ "પરંતુ": રૂટ 53 ને કેવી રીતે અને શું સાથે આરક્ષિત કરવું? કોને ખબર, તેને કંઈક થઈ જાય તો? સદનસીબે, અમે ક્યારેય આ રેક પર પગ મૂક્યો નથી, પરંતુ ફરીથી, મારી પાસે એક વાર્તા હશે કે અમે શા માટે વિચાર્યું કે અમારે હજુ પણ આરક્ષણ કરવાની જરૂર છે. અહીં અમે અમારા માટે અગાઉથી સ્ટ્રો નાખ્યા છે. દિવસમાં ઘણી વખત અમે રૂટ 53 માં રહેલા તમામ ઝોનને સંપૂર્ણ અનલોડ કરીએ છીએ. એમેઝોનનું API તમને JSON માં સરળતાથી મોકલવાની મંજૂરી આપે છે, અને અમારી પાસે ઘણા બેકઅપ સર્વર્સ છે જ્યાં અમે તેને કન્વર્ટ કરીએ છીએ, તેને રૂપરેખાઓના રૂપમાં અપલોડ કરીએ છીએ અને લગભગ કહીએ તો, બેકઅપ ગોઠવણી છે. જો કંઈક થાય, તો અમે DNS સેટિંગ્સ ડેટા ગુમાવ્યા વિના તેને ઝડપથી મેન્યુઅલી જમાવી શકીએ છીએ.

બીજું "પરંતુ": આ ચિત્રમાં શું હજુ સુધી અનામત નથી? બેલેન્સર પોતે! પ્રદેશ દ્વારા અમારા ગ્રાહકોનું વિતરણ ખૂબ જ સરળ બનાવવામાં આવ્યું છે. અમારી પાસે bitrix24.ru, bitrix24.com, .de ડોમેન્સ છે - હવે ત્યાં 13 અલગ અલગ છે, જે વિવિધ ઝોનમાં કાર્ય કરે છે. અમે નીચેના પર આવ્યા: દરેક પ્રદેશના પોતાના બેલેન્સર છે. આ નેટવર્ક પર પીક લોડ ક્યાં છે તેના આધારે સમગ્ર પ્રદેશોમાં વિતરિત કરવાનું વધુ અનુકૂળ બનાવે છે. જો આ સિંગલ બેલેન્સરના સ્તરે નિષ્ફળતા છે, તો તેને ફક્ત સેવામાંથી બહાર કાઢવામાં આવે છે અને ડીએનએસમાંથી દૂર કરવામાં આવે છે. જો બેલેન્સર્સના જૂથમાં કોઈ સમસ્યા હોય, તો તે અન્ય સાઇટ્સ પર બેકઅપ લેવામાં આવે છે, અને તેમની વચ્ચે સ્વિચિંગ સમાન રૂટ53નો ઉપયોગ કરીને કરવામાં આવે છે, કારણ કે ટૂંકા TTLને કારણે, સ્વિચિંગ મહત્તમ 2, 3, 5 મિનિટની અંદર થાય છે. .

ત્રીજો "પરંતુ": હજુ સુધી શું અનામત નથી? S3, સાચું. જ્યારે અમે s3 માં વપરાશકર્તાઓ માટે સંગ્રહિત કરેલી ફાઇલો મૂકી, ત્યારે અમે નિષ્ઠાપૂર્વક માનીએ છીએ કે તે બખ્તર-વેધન છે અને ત્યાં કંઈપણ અનામત રાખવાની જરૂર નથી. પરંતુ ઇતિહાસ બતાવે છે કે વસ્તુઓ જુદી રીતે થાય છે. સામાન્ય રીતે, એમેઝોન S3 ને મૂળભૂત સેવા તરીકે વર્ણવે છે, કારણ કે એમેઝોન પોતે S3 નો ઉપયોગ મશીન ઈમેજીસ, રૂપરેખાઓ, AMI ઈમેજીસ, સ્નેપશોટ સ્ટોર કરવા માટે કરે છે... અને જો s3 ક્રેશ થાય છે, જેમ કે આ 7 વર્ષ દરમિયાન એક વાર બન્યું છે, જ્યાં સુધી આપણે ઉપયોગ કરી રહ્યા છીએ. bitrix24, તે ચાહકની જેમ તેને અનુસરે છે ત્યાં ઘણી બધી વસ્તુઓ છે જે આવે છે - વર્ચ્યુઅલ મશીનો શરૂ કરવામાં અસમર્થતા, એપીઆઈ નિષ્ફળતા, વગેરે.

અને S3 પડી શકે છે - તે એકવાર થયું. તેથી, અમે નીચેની યોજના પર આવ્યા: થોડા વર્ષો પહેલા રશિયામાં કોઈ ગંભીર સાર્વજનિક ઑબ્જેક્ટ સ્ટોરેજ સુવિધાઓ ન હતી, અને અમે અમારી પોતાની રીતે કંઈક કરવાનો વિકલ્પ ધ્યાનમાં લીધો... સદનસીબે, અમે આ કરવાનું શરૂ કર્યું ન હતું, કારણ કે અમે અમારી પાસે ન હોય તેવી કુશળતામાં ખોદકામ કર્યું છે, અને કદાચ ગડબડ કરશે. હવે Mail.ru પાસે s3-સુસંગત સ્ટોરેજ છે, યાન્ડેક્સ પાસે છે, અને સંખ્યાબંધ અન્ય પ્રદાતાઓ પાસે છે. અમે આખરે વિચાર પર આવ્યા કે અમે ઇચ્છીએ છીએ, પ્રથમ, બેકઅપ, અને બીજું, સ્થાનિક નકલો સાથે કામ કરવાની ક્ષમતા. ખાસ કરીને રશિયન પ્રદેશ માટે, અમે Mail.ru Hotbox સેવાનો ઉપયોગ કરીએ છીએ, જે API s3 સાથે સુસંગત છે. અમને એપ્લિકેશનની અંદરના કોડમાં કોઈ મોટા ફેરફારોની જરૂર નહોતી, અને અમે નીચેની મિકેનિઝમ બનાવી છે: s3 માં એવા ટ્રિગર્સ છે જે ઑબ્જેક્ટના સર્જન/ડિલીટને ટ્રિગર કરે છે, એમેઝોન પાસે લેમ્બડા નામની સેવા છે - આ કોડનું સર્વર વિનાનું લોન્ચિંગ છે. જ્યારે ચોક્કસ ટ્રિગર્સ ટ્રિગર થાય ત્યારે જ એક્ઝિક્યુટ કરવામાં આવશે.

અમે તે ખૂબ જ સરળ રીતે કર્યું: જો અમારું ટ્રિગર ફાયર થાય, તો અમે કોડ એક્ઝિક્યુટ કરીએ છીએ જે ઑબ્જેક્ટને Mail.ru સ્ટોરેજમાં કૉપિ કરશે. ડેટાની સ્થાનિક નકલો સાથે સંપૂર્ણ રીતે કામ શરૂ કરવા માટે, અમને રિવર્સ સિંક્રોનાઇઝેશનની પણ જરૂર છે જેથી રશિયન સેગમેન્ટમાં હોય તેવા ક્લાયન્ટ તેમની નજીકના સ્ટોરેજ સાથે કામ કરી શકે. મેઇલ તેના સ્ટોરેજમાં ટ્રિગર્સ પૂર્ણ કરવા જઈ રહ્યો છે - ઇન્ફ્રાસ્ટ્રક્ચર સ્તરે રિવર્સ સિંક્રોનાઇઝેશન કરવું શક્ય બનશે, પરંતુ અત્યારે અમે આ અમારા પોતાના કોડના સ્તરે કરી રહ્યા છીએ. જો આપણે જોઈએ કે ક્લાયન્ટે ફાઇલ પોસ્ટ કરી છે, તો કોડ લેવલ પર આપણે ઇવેન્ટને કતારમાં મૂકીએ છીએ, તેની પ્રક્રિયા કરીએ છીએ અને રિવર્સ રિપ્લિકેશન કરીએ છીએ. તે શા માટે ખરાબ છે: જો આપણે આપણા ઉત્પાદનની બહારના આપણા પદાર્થો સાથે અમુક પ્રકારનું કામ કરીએ છીએ, એટલે કે, અમુક બાહ્ય માધ્યમો દ્વારા, તો અમે તેને ધ્યાનમાં લઈશું નહીં. તેથી, અમે અંત સુધી રાહ જોઈએ છીએ, જ્યારે સ્ટોરેજ સ્તર પર ટ્રિગર્સ દેખાય છે, જેથી અમે કોડ ક્યાંથી એક્ઝિક્યુટ કરીએ તે મહત્વનું નથી, અમારી પાસે જે ઑબ્જેક્ટ આવે છે તે બીજી દિશામાં કૉપિ કરવામાં આવે છે.

કોડ સ્તરે, અમે દરેક ક્લાયંટ માટે બંને સ્ટોરેજની નોંધણી કરીએ છીએ: એકને મુખ્ય ગણવામાં આવે છે, બીજાને બેકઅપ ગણવામાં આવે છે. જો બધું સારું હોય, તો અમે અમારી નજીકના સ્ટોરેજ સાથે કામ કરીએ છીએ: એટલે કે, અમારા ક્લાયન્ટ જેઓ એમેઝોનમાં છે, તેઓ S3 સાથે કામ કરે છે, અને જેઓ રશિયામાં કામ કરે છે, તેઓ Hotbox સાથે કામ કરે છે. જો ધ્વજ ટ્રિગર થાય, તો ફેલઓવર કનેક્ટ થવો જોઈએ, અને અમે ક્લાયન્ટ્સને બીજા સ્ટોરેજ પર સ્વિચ કરીએ છીએ. અમે આ બૉક્સને પ્રદેશ દ્વારા સ્વતંત્ર રીતે ચેક કરી શકીએ છીએ અને તેને આગળ અને પાછળ બદલી શકીએ છીએ. અમે હજી સુધી આનો વ્યવહારમાં ઉપયોગ કર્યો નથી, પરંતુ અમે આ પદ્ધતિ પ્રદાન કરી છે અને અમને લાગે છે કે કોઈ દિવસ અમને આ સ્વિચની જરૂર પડશે અને તે કામમાં આવશે. આવું પહેલેથી જ એક વાર બન્યું છે.

ઓહ, અને એમેઝોન ભાગી ગયો...

આ એપ્રિલમાં રશિયામાં ટેલિગ્રામ બ્લોકિંગની શરૂઆતની વર્ષગાંઠ છે. આ હેઠળ સૌથી વધુ અસરગ્રસ્ત પ્રદાતા એમેઝોન છે. અને, કમનસીબે, સમગ્ર વિશ્વ માટે કામ કરતી રશિયન કંપનીઓને વધુ નુકસાન થયું.

જો કંપની વૈશ્વિક છે અને રશિયા તેના માટે ખૂબ જ નાનો સેગમેન્ટ છે, 3-5% - સારું, એક રીતે અથવા અન્ય, તમે તેમને બલિદાન આપી શકો છો.

જો આ સંપૂર્ણપણે રશિયન કંપની છે - મને ખાતરી છે કે તેને સ્થાનિક રીતે સ્થિત કરવાની જરૂર છે - સારું, તે ફક્ત વપરાશકર્તાઓ માટે અનુકૂળ હશે, આરામદાયક હશે, અને ઓછા જોખમો હશે.

જો આ એવી કંપની છે જે વૈશ્વિક સ્તરે કામ કરે છે અને રશિયા અને વિશ્વભરના લગભગ સમાન સંખ્યામાં ગ્રાહકો ધરાવે છે તો શું? સેગમેન્ટ્સની કનેક્ટિવિટી મહત્વપૂર્ણ છે, અને તેઓએ એક અથવા બીજી રીતે એકબીજા સાથે કામ કરવું જોઈએ.

માર્ચ 2018 ના અંતમાં, Roskomnadzor એ સૌથી મોટા ઓપરેટરોને એક પત્ર મોકલ્યો જેમાં જણાવ્યું હતું કે તેઓ... Zello મેસેન્જરને બ્લોક કરવા માટે ઘણા મિલિયન Amazon IP ને બ્લોક કરવાની યોજના ધરાવે છે. આ જ પ્રદાતાઓનો આભાર - તેઓએ દરેકને સફળતાપૂર્વક પત્ર લીક કર્યો, અને એક સમજણ હતી કે એમેઝોન સાથેનું જોડાણ અલગ પડી શકે છે. તે શુક્રવાર હતો, અમે ગભરાઈને servers.ru પરથી અમારા સાથીદારોને કહ્યું: "મિત્રો, અમને ઘણા સર્વર્સની જરૂર છે જે રશિયામાં નહીં, એમેઝોનમાં નહીં, પરંતુ, ઉદાહરણ તરીકે, એમ્સ્ટરડેમમાં ક્યાંક સ્થિત હશે," ક્રમમાં. ઓછામાં ઓછા કોઈક રીતે આપણું પોતાનું VPN અને પ્રોક્સી ઇન્સ્ટોલ કરવા માટે સક્ષમ થવા માટે કેટલાક એન્ડપોઇન્ટ્સ માટે કે જેને આપણે કોઈપણ રીતે પ્રભાવિત કરી શકતા નથી, ઉદાહરણ તરીકે સમાન s3 ના એન્ડપોન્ટ્સ - અમે નવી સેવા વધારવા અને અલગ ip મેળવવાનો પ્રયાસ કરી શકતા નથી, અમારે તમારે હજી ત્યાં પહોંચવાની જરૂર છે. માત્ર થોડા જ દિવસોમાં, અમે આ સર્વર્સ સેટ કર્યા, તેને ચાલુ કરી દીધા અને સામાન્ય રીતે, બ્લોકિંગ શરૂ થઈ તે ક્ષણ માટે તૈયાર. તે વિચિત્ર છે કે RKN, ગભરાટ અને ગભરાટને જોઈને કહ્યું: "ના, અમે હવે કંઈપણ અવરોધિત કરીશું નહીં." (પરંતુ આ તે ક્ષણ સુધી છે જ્યારે ટેલિગ્રામને અવરોધિત કરવાનું શરૂ થયું હતું.) બાયપાસ ક્ષમતાઓ સેટ કર્યા પછી અને સમજાયું કે બ્લોકિંગ રજૂ કરવામાં આવ્યું નથી, તેમ છતાં, અમે સમગ્ર મામલાને ઉકેલવાનું શરૂ કર્યું નથી. હા, માત્ર કિસ્સામાં.

અને 2019 માં, અમે હજી પણ અવરોધિત સ્થિતિમાં જીવીએ છીએ. મેં ગઈકાલે રાત્રે જોયું: લગભગ એક મિલિયન આઈપી અવરોધિત થવાનું ચાલુ રાખે છે. સાચું છે, એમેઝોન લગભગ સંપૂર્ણપણે અનાવરોધિત હતું, તેની ટોચ પર તે 20 મિલિયન સરનામાં પર પહોંચી ગયું હતું... સામાન્ય રીતે, વાસ્તવિકતા એ છે કે સુસંગતતા, સારી સુસંગતતા ન હોઈ શકે. અચાનક. તે તકનીકી કારણોસર અસ્તિત્વમાં ન હોઈ શકે - આગ, ઉત્ખનન, તે બધું. અથવા, આપણે જોયું તેમ, સંપૂર્ણપણે તકનીકી નથી. તેથી, કોઈ મોટું અને મોટું, તેમના પોતાના AS સાથે, કદાચ આને અન્ય રીતે સંચાલિત કરી શકે છે - ડાયરેક્ટ કનેક્ટ અને અન્ય વસ્તુઓ પહેલેથી જ l2 સ્તર પર છે. પરંતુ એક સરળ સંસ્કરણમાં, અમારા જેવા અથવા તેનાથી પણ નાના, તમે, તે સેગમેન્ટ્સમાં રૂપરેખાંકનને ઝડપથી તેમના પર સ્વિચ કરવાની ક્ષમતા સાથે, અગાઉથી ગોઠવેલ vpn, પ્રોક્સી, બીજે ક્યાંક ઉભા કરાયેલ સર્વરના સ્તરે રીડન્ડન્સી હોઈ શકે છે. જે તમારી કનેક્ટિવિટી માટે મહત્વપૂર્ણ છે. આ અમારા માટે એક કરતા વધુ વખત કામમાં આવ્યું, જ્યારે એમેઝોનનું બ્લોકિંગ શરૂ થયું; સૌથી ખરાબ પરિસ્થિતિમાં, અમે તેમના દ્વારા ફક્ત S3 ટ્રાફિકને મંજૂરી આપી હતી, પરંતુ ધીમે ધીમે આ બધું ઉકેલાઈ ગયું.

કેવી રીતે આરક્ષિત કરવું... સમગ્ર પ્રદાતા?

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

અનુમાનિત રીતે, એમેઝોન માટે અમે અન્ય પ્રદાતાના સ્તરે આરક્ષણની શક્યતાને ધ્યાનમાં લઈએ છીએ; કદાચ ગૂગલ, કદાચ કોઈ અન્ય... પરંતુ અત્યાર સુધી આપણે વ્યવહારમાં જોયું છે કે જ્યારે એમેઝોન એક પ્રાપ્યતા ક્ષેત્રના સ્તરે અકસ્માતો ધરાવે છે, ત્યારે સમગ્ર પ્રદેશના સ્તરે અકસ્માતો ખૂબ જ ઓછા છે. તેથી, અમારી પાસે સૈદ્ધાંતિક રીતે એવો વિચાર છે કે અમે "Amazon is not Amazon" આરક્ષણ કરી શકીએ છીએ, પરંતુ વ્યવહારમાં હજી સુધી એવું નથી.

ઓટોમેશન વિશે થોડાક શબ્દો

શું ઓટોમેશન હંમેશા જરૂરી છે? અહીં ડનિંગ-ક્રુગર અસરને યાદ કરવી યોગ્ય છે. "x" અક્ષ પર આપણું જ્ઞાન અને અનુભવ છે જે આપણે મેળવીએ છીએ, અને "y" અક્ષ પર આપણી ક્રિયાઓમાં વિશ્વાસ છે. શરૂઆતમાં આપણે કંઈ જાણતા નથી અને બિલકુલ ખાતરી નથી. પછી આપણે થોડું જાણીએ છીએ અને મેગા-આત્મવિશ્વાસ બનીએ છીએ - આ કહેવાતા "મૂર્ખતાની ટોચ" છે, જે ચિત્ર "ઉન્માદ અને હિંમત" દ્વારા સારી રીતે દર્શાવવામાં આવ્યું છે. પછી આપણે થોડું શીખ્યા છીએ અને યુદ્ધમાં જવા માટે તૈયાર છીએ. પછી આપણે કેટલીક મેગા-ગંભીર ભૂલો પર પગ મુકીએ છીએ અને નિરાશાની ખીણમાં આપણી જાતને શોધીએ છીએ, જ્યારે આપણે કંઈક જાણતા હોઈએ છીએ, પરંતુ હકીકતમાં આપણે ઘણું જાણતા નથી. પછી, જેમ જેમ આપણે અનુભવ મેળવતા હોઈએ છીએ તેમ તેમ આપણે વધુ આત્મવિશ્વાસ પામીએ છીએ.

ચોક્કસ અકસ્માતોમાં વિવિધ સ્વચાલિત સ્વિચ વિશે અમારું તર્ક આ ગ્રાફ દ્વારા ખૂબ જ સારી રીતે વર્ણવવામાં આવ્યું છે. અમે શરૂ કર્યું - અમને કંઈપણ કેવી રીતે કરવું તે ખબર ન હતી, લગભગ તમામ કામ હાથથી કરવામાં આવ્યું હતું. પછી અમને સમજાયું કે અમે દરેક વસ્તુ સાથે ઓટોમેશન જોડી શકીએ છીએ અને, જેમ કે, શાંતિથી સૂઈ શકીએ છીએ. અને અચાનક અમે એક મેગા-રેક પર પગ મુકીએ છીએ: ખોટા સકારાત્મક ટ્રિગર થાય છે, અને અમે ટ્રાફિકને આગળ અને પાછળ બદલીએ છીએ જ્યારે, સારી રીતે, અમારે આ ન કરવું જોઈએ. પરિણામે, પ્રતિકૃતિ તૂટી જાય છે અથવા બીજું કંઈક - આ નિરાશાની ખીણ છે. અને પછી આપણે સમજણ પર આવીએ છીએ કે આપણે દરેક વસ્તુનો સમજદારીપૂર્વક સંપર્ક કરવો જોઈએ. એટલે કે, ખોટા એલાર્મની શક્યતા પૂરી પાડતા, ઓટોમેશન પર આધાર રાખવો અર્થપૂર્ણ છે. પણ! જો પરિણામો વિનાશક હોઈ શકે છે, તો તેને ડ્યુટી શિફ્ટ પર, ફરજ પરના એન્જિનિયરો પર છોડી દેવું વધુ સારું છે, જેઓ ખાતરી કરશે કે ખરેખર કોઈ અકસ્માત છે કે નહીં તેની દેખરેખ રાખશે, અને જરૂરી પગલાં જાતે હાથ ધરશે...

નિષ્કર્ષ

7 વર્ષ દરમિયાન, અમે એ હકીકતથી આગળ વધીએ છીએ કે જ્યારે કંઈક પડી જાય છે, ત્યારે ગભરાટ-ગભરાટ હતો, તે સમજણ સુધી કે સમસ્યાઓ અસ્તિત્વમાં નથી, ત્યાં ફક્ત કાર્યો જ છે, તે ઉકેલવા જોઈએ - અને કરી શકાય છે. જ્યારે તમે કોઈ સેવાનું નિર્માણ કરો છો, ત્યારે તેને ઉપરથી જુઓ, બની શકે તેવા તમામ જોખમોનું મૂલ્યાંકન કરો. જો તમે તેમને તરત જ જોશો, તો અગાઉથી નિરર્થકતા અને ખામી-સહિષ્ણુ ઈન્ફ્રાસ્ટ્રક્ચર બનાવવાની સંભાવના માટે પ્રદાન કરો, કારણ કે કોઈપણ બિંદુ જે નિષ્ફળ થઈ શકે છે અને સેવાની અસમર્થતા તરફ દોરી શકે છે તે ચોક્કસપણે આમ કરશે. અને જો તમને લાગે કે ઈન્ફ્રાસ્ટ્રક્ચરના કેટલાક ઘટકો ચોક્કસપણે નિષ્ફળ જશે નહીં - સમાન s3 ની જેમ, હજી પણ ધ્યાનમાં રાખો કે તેઓ કરી શકે છે. અને ઓછામાં ઓછું સિદ્ધાંતમાં, જો કંઈક થાય તો તમે તેમની સાથે શું કરશો તેનો ખ્યાલ રાખો. જોખમ વ્યવસ્થાપન યોજના રાખો. જ્યારે તમે બધું ઑટોમૅટિક રીતે અથવા મેન્યુઅલી કરવાનું વિચારી રહ્યાં હોવ, ત્યારે જોખમોનું મૂલ્યાંકન કરો: જો ઑટોમેશન બધું સ્વિચ કરવાનું શરૂ કરે તો શું થશે - શું આ અકસ્માતની સરખામણીમાં વધુ ખરાબ પરિસ્થિતિ તરફ દોરી જશે નહીં? કદાચ ક્યાંક ઓટોમેશનના ઉપયોગ અને ફરજ પરના એન્જિનિયરની પ્રતિક્રિયા વચ્ચે વાજબી સમાધાનનો ઉપયોગ કરવો જરૂરી છે, જે વાસ્તવિક ચિત્રનું મૂલ્યાંકન કરશે અને સમજશે કે સ્થળ પર કંઈક બદલવાની જરૂર છે કે "હા, પણ હમણાં નહીં."

પૂર્ણતાવાદ અને વાસ્તવિક પ્રયત્નો, સમય, પૈસા વચ્ચે વાજબી સમાધાન કે જે તમે આખરે તમારી પાસે હશે તે યોજના પર ખર્ચ કરી શકો છો.

આ ટેક્સ્ટ કોન્ફરન્સમાં એલેક્ઝાન્ડર ડેમિડોવના અહેવાલનું અપડેટ અને વિસ્તૃત સંસ્કરણ છે અપટાઇમ દિવસ 4.

સોર્સ: www.habr.com