இன்று, பிட்ரிக்ஸ் 24 சேவையில் நூற்றுக்கணக்கான ஜிகாபிட் போக்குவரத்து இல்லை, அல்லது பெரிய அளவிலான சேவையகங்கள் இல்லை (இருப்பினும், ஏற்கனவே சில உள்ளன). ஆனால் பல வாடிக்கையாளர்களுக்கு இது நிறுவனத்தில் பணிபுரிவதற்கான முக்கிய கருவியாகும்; இது ஒரு உண்மையான வணிக-முக்கியமான பயன்பாடாகும். எனவே, விழ வழி இல்லை. விபத்து நடந்தால் என்ன செய்வது, ஆனால் யாரும் எதையும் கவனிக்காத அளவுக்கு சேவை விரைவாக "மீண்டும்"? வேலையின் தரம் மற்றும் வாடிக்கையாளர்களின் எண்ணிக்கையை இழக்காமல் தோல்வியை எவ்வாறு செயல்படுத்துவது? Bitrix24 இல் கிளவுட் சேவைகளின் இயக்குனர் அலெக்சாண்டர் டெமிடோவ், தயாரிப்பு இருந்த 7 ஆண்டுகளில் முன்பதிவு முறை எவ்வாறு உருவாகியுள்ளது என்பதைப் பற்றி எங்கள் வலைப்பதிவில் பேசினார்.
"நாங்கள் 24 ஆண்டுகளுக்கு முன்பு Bitrix7 ஐ SaaS ஆக அறிமுகப்படுத்தினோம். முக்கிய சிரமம் அநேகமாக பின்வருவனவாக இருக்கலாம்: இது SaaS என பொதுவில் தொடங்கப்படுவதற்கு முன்பு, இந்த தயாரிப்பு ஒரு பெட்டி தீர்வு வடிவத்தில் இருந்தது. வாடிக்கையாளர்கள் அதை எங்களிடமிருந்து வாங்கி, அதை தங்கள் சேவையகங்களில் ஹோஸ்ட் செய்தனர், கார்ப்பரேட் போர்ட்டலை அமைத்தனர் - பணியாளர் தொடர்பு, கோப்பு சேமிப்பு, பணி மேலாண்மை, CRM, அவ்வளவுதான். 2012 ஆம் ஆண்டளவில், அதை SaaS ஆகத் தொடங்க முடிவு செய்தோம், அதை நாமே நிர்வகித்து, தவறு சகிப்புத்தன்மை மற்றும் நம்பகத்தன்மையை உறுதி செய்தோம். நாங்கள் வழியில் அனுபவத்தைப் பெற்றோம், ஏனென்றால் அதுவரை எங்களிடம் அது இல்லை - நாங்கள் மென்பொருள் உற்பத்தியாளர்கள் மட்டுமே, சேவை வழங்குநர்கள் அல்ல.
சேவையைத் தொடங்கும்போது, தவறு சகிப்புத்தன்மை, நம்பகத்தன்மை மற்றும் சேவையின் நிலையான கிடைக்கும் தன்மை ஆகியவற்றை உறுதி செய்வதே மிக முக்கியமான விஷயம் என்பதை நாங்கள் புரிந்துகொண்டோம், ஏனென்றால் உங்களிடம் ஒரு எளிய சாதாரண வலைத்தளம், ஒரு கடை இருந்தால், எடுத்துக்காட்டாக, அது உங்கள் மீது விழுந்து அங்கேயே அமர்ந்திருக்கும். ஒரு மணி நேரம், நீங்கள் மட்டும் கஷ்டப்படுகிறீர்கள், ஆர்டர்களை இழக்கிறீர்கள், வாடிக்கையாளர்களை இழக்கிறீர்கள், ஆனால் உங்கள் வாடிக்கையாளருக்கு இது மிகவும் முக்கியமானதல்ல. அவர் வருத்தப்பட்டார், ஆனால் அவர் அதை வேறு தளத்தில் வாங்கினார். இது நிறுவனத்தில் உள்ள அனைத்து வேலைகளும், தகவல்தொடர்புகளும், முடிவுகளும் இணைக்கப்பட்ட ஒரு பயன்பாடாக இருந்தால், மிக முக்கியமான விஷயம் பயனர்களின் நம்பிக்கையைப் பெறுவது, அதாவது, அவர்களைத் தாழ்த்தாமல், விழக்கூடாது. ஏனென்றால் உள்ளே ஏதாவது வேலை செய்யவில்லை என்றால் எல்லா வேலைகளும் நின்றுவிடும்.
பிட்ரிக்ஸ்.24 SaaS ஆக
2011 இல், பொது வெளியீட்டிற்கு ஒரு வருடம் முன்பு முதல் முன்மாதிரியை நாங்கள் சேகரித்தோம். நாங்கள் ஒரு வாரத்தில் அதைச் சேகரித்தோம், அதைப் பார்த்தோம், சுழற்றினோம் - அது கூட வேலை செய்கிறது. அதாவது, நீங்கள் படிவத்திற்குச் செல்லலாம், அங்கு போர்ட்டலின் பெயரை உள்ளிடலாம், ஒரு புதிய போர்டல் திறக்கப்படும், மேலும் ஒரு பயனர் தளம் உருவாக்கப்படும். நாங்கள் அதைப் பார்த்தோம், தயாரிப்பை கொள்கையளவில் மதிப்பிட்டு, அதை அகற்றி, ஒரு வருடம் முழுவதும் அதைச் செம்மைப்படுத்தினோம். எங்களிடம் ஒரு பெரிய பணி இருப்பதால்: நாங்கள் இரண்டு வெவ்வேறு குறியீடு அடிப்படைகளை உருவாக்க விரும்பவில்லை, நாங்கள் ஒரு தனி தொகுக்கப்பட்ட தயாரிப்பு, தனி கிளவுட் தீர்வுகளை ஆதரிக்க விரும்பவில்லை - அனைத்தையும் ஒரே குறியீட்டில் செய்ய விரும்புகிறோம்.
அந்த நேரத்தில் ஒரு பொதுவான வலை பயன்பாடு ஒரு சேவையகமாகும், அதில் சில PHP குறியீடு இயங்குகிறது, ஒரு mysql தரவுத்தளம், கோப்புகள் பதிவேற்றப்படுகின்றன, ஆவணங்கள், படங்கள் பதிவேற்ற கோப்புறையில் வைக்கப்படுகின்றன - சரி, இது அனைத்தும் வேலை செய்கிறது. ஐயோ, இதைப் பயன்படுத்தி சிக்கலான நிலையான இணைய சேவையைத் தொடங்குவது சாத்தியமில்லை. அங்கு, விநியோகிக்கப்பட்ட கேச் ஆதரிக்கப்படவில்லை, தரவுத்தள நகலெடுப்பு ஆதரிக்கப்படவில்லை.
நாங்கள் தேவைகளை வகுத்துள்ளோம்: இது வெவ்வேறு இடங்களில் அமைந்திருக்கும் திறன், பிரதியெடுப்பை ஆதரிக்கும் திறன் மற்றும் வெவ்வேறு புவியியல் ரீதியாக விநியோகிக்கப்பட்ட தரவு மையங்களில் சிறப்பாக அமைந்திருக்கும். தயாரிப்பு தர்க்கத்தையும், உண்மையில், தரவு சேமிப்பகத்தையும் பிரிக்கவும். சுமைக்கு ஏற்ப மாறும் வகையில் அளவிட முடியும், மேலும் நிலைகளை முழுவதுமாக பொறுத்துக்கொள்ளவும். இந்த பரிசீலனைகளிலிருந்து, உண்மையில், தயாரிப்புக்கான தேவைகள் வெளிப்பட்டன, அதை நாங்கள் ஆண்டு முழுவதும் மேம்படுத்தினோம். இந்த நேரத்தில், ஒருங்கிணைந்ததாக மாறிய மேடையில் - பெட்டி தீர்வுகளுக்காக, எங்கள் சொந்த சேவைக்காக - எங்களுக்குத் தேவையான விஷயங்களுக்கு நாங்கள் ஆதரவை வழங்கினோம். தயாரிப்பின் மட்டத்தில் mysql பிரதியெடுப்புக்கான ஆதரவு: அதாவது, குறியீட்டை எழுதும் டெவலப்பர் தனது கோரிக்கைகள் எவ்வாறு விநியோகிக்கப்படும் என்பதைப் பற்றி சிந்திக்கவில்லை, அவர் எங்கள் API ஐப் பயன்படுத்துகிறார், மேலும் எஜமானர்களிடையே எழுத மற்றும் படிக்க கோரிக்கைகளை எவ்வாறு சரியாக விநியோகிப்பது என்பது எங்களுக்குத் தெரியும். மற்றும் அடிமைகள்.
பல்வேறு கிளவுட் ஆப்ஜெக்ட் ஸ்டோரேஜ்களுக்கு தயாரிப்பு மட்டத்தில் ஆதரவை வழங்கியுள்ளோம்: கூகுள் ஸ்டோரேஜ், அமேசான் எஸ்3 மற்றும் ஓபன் ஸ்டாக் ஸ்விஃப்டிற்கான ஆதரவு. எனவே, இது ஒரு சேவையாக எங்களுக்கும், தொகுக்கப்பட்ட தீர்வுடன் பணிபுரியும் டெவலப்பர்களுக்கும் வசதியாக இருந்தது: அவர்கள் எங்கள் API ஐ வேலைக்குப் பயன்படுத்தினால், கோப்பு இறுதியில் எங்கே சேமிக்கப்படும், கோப்பு முறைமையில் அல்லது பொருள் கோப்பு சேமிப்பகத்தில்.
இதன் விளைவாக, முழு தரவு மையத்தின் மட்டத்தில் நாங்கள் முன்பதிவு செய்வோம் என்று உடனடியாக முடிவு செய்தோம். 2012 இல், நாங்கள் முற்றிலும் Amazon AWS இல் தொடங்கினோம், ஏனெனில் இந்த தளத்துடன் எங்களுக்கு ஏற்கனவே அனுபவம் இருந்தது - எங்கள் சொந்த வலைத்தளம் அங்கு ஹோஸ்ட் செய்யப்பட்டது. ஒவ்வொரு பிராந்தியத்திலும் Amazon பல கிடைக்கும் மண்டலங்களைக் கொண்டிருப்பதால் நாங்கள் ஈர்க்கப்பட்டோம் - உண்மையில், (அவற்றின் சொற்களில்) பல தரவு மையங்கள் ஒருவருக்கொருவர் அதிகமாகவோ அல்லது குறைவாகவோ சுயாதீனமாக உள்ளன மற்றும் முழு தரவு மையத்தின் மட்டத்தில் முன்பதிவு செய்ய அனுமதிக்கின்றன: அது திடீரென்று தோல்வியுற்றால், தரவுத்தளங்கள் மாஸ்டர்-மாஸ்டர் பிரதியெடுக்கப்படும், வலை பயன்பாட்டு சேவையகங்கள் காப்புப் பிரதி எடுக்கப்படும், மேலும் நிலையான தரவு s3 பொருள் சேமிப்பகத்திற்கு நகர்த்தப்படும். சுமை சீரானது - அந்த நேரத்தில் அமேசான் எல்ப் மூலம், ஆனால் சிறிது நேரம் கழித்து நாங்கள் எங்கள் சொந்த சுமை பேலன்சர்களுக்கு வந்தோம், ஏனென்றால் எங்களுக்கு மிகவும் சிக்கலான தர்க்கம் தேவைப்பட்டது.
அவர்கள் விரும்பியது கிடைத்தது...
நாங்கள் உறுதிப்படுத்த விரும்பிய அனைத்து அடிப்படை விஷயங்களும் - சேவையகங்களின் தவறு சகிப்புத்தன்மை, வலை பயன்பாடுகள், தரவுத்தளங்கள் - அனைத்தும் நன்றாக வேலை செய்தன. எளிமையான சூழ்நிலை: எங்கள் வலை பயன்பாடுகளில் ஒன்று தோல்வியுற்றால், எல்லாம் எளிது - அவை சமநிலையில் இருந்து அணைக்கப்படும்.
பேலன்சர் (அந்த நேரத்தில் அது அமேசானின் எல்ப்) ஒழுங்கற்ற இயந்திரங்களை ஆரோக்கியமற்றதாகக் குறித்தது மற்றும் அவற்றில் சுமை விநியோகத்தை முடக்கியது. அமேசான் ஆட்டோஸ்கேலிங் வேலை செய்தது: சுமை அதிகரித்தபோது, ஆட்டோஸ்கேலிங் குழுவில் புதிய இயந்திரங்கள் சேர்க்கப்பட்டன, சுமை புதிய இயந்திரங்களுக்கு விநியோகிக்கப்பட்டது - எல்லாம் நன்றாக இருந்தது. எங்களின் பேலன்சர்களுடன், தர்க்கம் தோராயமாக ஒன்றுதான்: பயன்பாட்டுச் சேவையகத்திற்கு ஏதாவது நேர்ந்தால், அதிலிருந்து கோரிக்கைகளை அகற்றி, இந்த இயந்திரங்களைத் தூக்கி எறிந்துவிட்டு, புதியவற்றைத் தொடங்கி தொடர்ந்து வேலை செய்கிறோம். இந்த திட்டம் பல ஆண்டுகளாக சிறிது மாறிவிட்டது, ஆனால் தொடர்ந்து செயல்படுகிறது: இது எளிமையானது, புரிந்துகொள்ளக்கூடியது மற்றும் அதில் எந்த சிரமமும் இல்லை.
நாங்கள் உலகம் முழுவதும் பணிபுரிகிறோம், வாடிக்கையாளர்களின் சுமைகள் முற்றிலும் வேறுபட்டவை, மேலும் ஒரு இணக்கமான வழியில், எந்த நேரத்திலும் எங்கள் கணினியின் எந்தவொரு கூறுகளிலும் சில சேவைப் பணிகளைச் செய்ய முடியும் - வாடிக்கையாளர்களால் கவனிக்கப்படாமல். எனவே, செயல்பாட்டிலிருந்து தரவுத்தளத்தை அணைக்க எங்களுக்கு வாய்ப்பு உள்ளது, சுமைகளை இரண்டாவது தரவு மையத்திற்கு மறுபகிர்வு செய்கிறது.
எப்படி எல்லாம் வேலை செய்கிறது? — நாங்கள் போக்குவரத்தை வேலை செய்யும் தரவு மையத்திற்கு மாற்றுகிறோம் - தரவு மையத்தில் விபத்து ஏற்பட்டால், இது ஒரு தரவுத்தளத்துடன் நாங்கள் திட்டமிட்ட வேலையாக இருந்தால், இந்த வாடிக்கையாளர்களுக்கு சேவை செய்யும் போக்குவரத்தின் ஒரு பகுதியை இரண்டாவது தரவு மையத்திற்கு மாற்றி, இடைநிறுத்துகிறோம். அதன் பிரதிபலிப்பு. இரண்டாவது டேட்டா சென்டரில் சுமை அதிகரித்துள்ளதால், இணையப் பயன்பாடுகளுக்கு புதிய இயந்திரங்கள் தேவைப்பட்டால், அவை தானாகவே தொடங்கும். நாங்கள் வேலையை முடிக்கிறோம், நகலெடுப்பு மீட்டமைக்கப்படுகிறது, மேலும் முழு சுமையையும் திருப்பித் தருகிறோம். இரண்டாவது DC இல் சில வேலைகளை நாம் பிரதிபலிக்க வேண்டும் என்றால், எடுத்துக்காட்டாக, கணினி புதுப்பிப்புகளை நிறுவவும் அல்லது இரண்டாவது தரவுத்தளத்தில் அமைப்புகளை மாற்றவும், பின்னர், பொதுவாக, நாங்கள் அதையே மற்ற திசையில் மீண்டும் செய்கிறோம். இது ஒரு விபத்து என்றால், நாங்கள் எல்லாவற்றையும் அற்பமாகச் செய்கிறோம்: கண்காணிப்பு அமைப்பில் நிகழ்வு-கையாளுநர்கள் பொறிமுறையைப் பயன்படுத்துகிறோம். பல காசோலைகள் தூண்டப்பட்டு, நிலை முக்கியமான நிலைக்குச் சென்றால், இந்த அல்லது அந்த தர்க்கத்தைச் செய்யக்கூடிய ஹேண்ட்லரை நாங்கள் இயக்குகிறோம். ஒவ்வொரு தரவுத்தளத்திற்கும், எந்தச் சேவையகம் தோல்வியுற்றது என்பதையும், டிராஃபிக் கிடைக்காவிட்டால் எங்கு மாற்றப்பட வேண்டும் என்பதையும் நாங்கள் குறிப்பிடுகிறோம். வரலாற்று ரீதியாக, நாம் நாகியோஸ் அல்லது அதன் சில முட்கரண்டிகளை ஒரு வடிவத்தில் அல்லது மற்றொரு வடிவத்தில் பயன்படுத்துகிறோம். கொள்கையளவில், ஏறக்குறைய எந்த கண்காணிப்பு அமைப்பிலும் இதே போன்ற வழிமுறைகள் உள்ளன; நாங்கள் இன்னும் சிக்கலான எதையும் பயன்படுத்தவில்லை, ஆனால் ஒருவேளை ஒருநாள் நாம் பயன்படுத்துவோம். இப்போது கண்காணிப்பு கிடைக்காததால் தூண்டப்படுகிறது மற்றும் எதையாவது மாற்றும் திறனைக் கொண்டுள்ளது.
நாம் எல்லாவற்றையும் முன்பதிவு செய்திருக்கிறோமா?
எங்களிடம் அமெரிக்காவிலிருந்து பல வாடிக்கையாளர்கள், ஐரோப்பாவிலிருந்து பல வாடிக்கையாளர்கள், கிழக்கிற்கு நெருக்கமான பல வாடிக்கையாளர்கள் - ஜப்பான், சிங்கப்பூர் மற்றும் பல. நிச்சயமாக, வாடிக்கையாளர்களில் பெரும் பங்கு ரஷ்யாவில் உள்ளது. அதாவது, வேலை ஒரு பிராந்தியத்தில் இல்லை. பயனர்கள் விரைவான பதிலை விரும்புகிறார்கள், பல்வேறு உள்ளூர் சட்டங்களுக்கு இணங்க வேண்டிய தேவைகள் உள்ளன, மேலும் ஒவ்வொரு பிராந்தியத்திலும் நாங்கள் இரண்டு தரவு மையங்களை ஒதுக்குகிறோம், மேலும் சில கூடுதல் சேவைகள் உள்ளன, அவை மீண்டும் ஒரு பிராந்தியத்திற்குள் வைக்க வசதியாக இருக்கும் - வாடிக்கையாளர்களுக்கு இந்த பகுதி வேலை செய்கிறது. REST கையாளுபவர்கள், அங்கீகார சேவையகங்கள், ஒட்டுமொத்த கிளையண்டின் செயல்பாட்டிற்கு அவை குறைவான முக்கியத்துவம் வாய்ந்தவை, நீங்கள் ஒரு சிறிய ஏற்றுக்கொள்ளக்கூடிய தாமதத்துடன் அவற்றை மாற்றலாம், ஆனால் அவற்றை எவ்வாறு கண்காணிப்பது மற்றும் என்ன செய்வது என்பதில் நீங்கள் சக்கரத்தை மீண்டும் கண்டுபிடிக்க விரும்பவில்லை. அவர்களுடன். எனவே, கூடுதல் தயாரிப்புகளில் சில வகையான திறனை வளர்த்துக் கொள்வதற்குப் பதிலாக, இருக்கும் தீர்வுகளை அதிகபட்சமாகப் பயன்படுத்த முயற்சிக்கிறோம். மேலும் எங்காவது டிஎன்எஸ் மட்டத்தில் மாறுவதை அற்பமாகப் பயன்படுத்துகிறோம், அதே டிஎன்எஸ் மூலம் சேவையின் உயிரோட்டத்தை நாங்கள் தீர்மானிக்கிறோம். அமேசான் ரூட் 53 சேவையைக் கொண்டுள்ளது, ஆனால் நீங்கள் உள்ளீடுகளைச் செய்யக்கூடிய டிஎன்எஸ் மட்டுமல்ல, அது மிகவும் நெகிழ்வானது மற்றும் வசதியானது. அதன் மூலம் நீங்கள் ஜியோ-விநியோக சேவைகளை புவிஇருப்பிடங்களுடன் உருவாக்கலாம், வாடிக்கையாளர் எங்கிருந்து வந்தார் என்பதைத் தீர்மானிக்க அதைப் பயன்படுத்தும்போது அவருக்கு சில பதிவுகளை வழங்கலாம் - அதன் உதவியுடன் நீங்கள் தோல்வியுற்ற கட்டமைப்புகளை உருவாக்கலாம். அதே சுகாதார-சோதனைகள் ரூட் 53 இல் கட்டமைக்கப்பட்டுள்ளன, நீங்கள் கண்காணிக்கப்படும் இறுதிப்புள்ளிகளை அமைக்கிறீர்கள், அளவீடுகளை அமைக்கிறீர்கள், சேவையின் "வாழ்க்கையை" தீர்மானிக்க எந்த நெறிமுறைகளை அமைக்கிறீர்கள் - tcp, http, https; சேவை உயிருடன் உள்ளதா இல்லையா என்பதைத் தீர்மானிக்கும் காசோலைகளின் அதிர்வெண்ணை அமைக்கவும். டிஎன்எஸ்ஸில் எது முதன்மையானது, எது இரண்டாம் நிலை, எந்த இடத்தில் சுகாதாரச் சரிபார்ப்பு பாதை 53 க்குள் தூண்டப்பட்டால் மாற வேண்டும் என்பதைக் குறிப்பிடுகிறீர்கள். இதையெல்லாம் வேறு சில கருவிகள் மூலம் செய்யலாம், ஆனால் அது ஏன் வசதியானது - நாங்கள் அதை அமைக்கிறோம். ஒருமுறை மேலேறி, பிறகு எப்படிச் சரிபார்த்துச் செய்கிறோம், எப்படி மாறுகிறோம் என்பதைப் பற்றி யோசிக்கவேண்டாம்: எல்லாமே தானாகவே செயல்படும்.
முதல் "ஆனால்": எப்படி, எதனுடன் வழி 53ஐ முன்பதிவு செய்வது? யாருக்குத் தெரியும், அவருக்கு ஏதாவது நேர்ந்தால் என்ன செய்வது? அதிர்ஷ்டவசமாக, நாங்கள் ஒருபோதும் இந்த ரேக்கில் அடியெடுத்து வைக்கவில்லை, ஆனால் மீண்டும், நாங்கள் ஏன் முன்பதிவு செய்ய வேண்டும் என்று நினைத்தோம் என்பதற்கான ஒரு கதையை நான் முன்வைக்கிறேன். இங்கே நாங்கள் முன்கூட்டியே எங்களுக்கு வைக்கோல்களை அமைத்தோம். ஒரு நாளைக்கு பல முறை நாங்கள் பாதை 53 இல் உள்ள அனைத்து மண்டலங்களையும் முழுமையாக இறக்குகிறோம். அமேசானின் API ஆனது JSON இல் அவற்றை எளிதாக அனுப்ப உங்களை அனுமதிக்கிறது, மேலும் எங்களிடம் பல காப்புப்பிரதி சேவையகங்கள் உள்ளன, அங்கு நாங்கள் அதை மாற்றுகிறோம், அதை அமைப்புகளின் வடிவத்தில் பதிவேற்றுகிறோம் மற்றும் தோராயமாகச் சொன்னால், காப்புப்பிரதி உள்ளமைவைக் கொண்டுள்ளோம். ஏதாவது நடந்தால், DNS அமைப்புகளின் தரவை இழக்காமல், அதை கைமுறையாக விரைவாக வரிசைப்படுத்தலாம்.
இரண்டாவது "ஆனால்": இந்தப் படத்தில் என்ன இன்னும் முன்பதிவு செய்யப்படவில்லை? சமநிலை தானே! பிராந்திய வாரியாக எங்கள் வாடிக்கையாளர்களின் விநியோகம் மிகவும் எளிமையானது. எங்களிடம் bitrix24.ru, bitrix24.com, .de - டொமைன்கள் உள்ளன - இப்போது 13 வெவ்வேறு டொமைன்கள் உள்ளன, அவை பல்வேறு மண்டலங்களில் செயல்படுகின்றன. நாங்கள் பின்வருவனவற்றிற்கு வந்தோம்: ஒவ்வொரு பிராந்தியத்திற்கும் அதன் சொந்த சமநிலைகள் உள்ளன. நெட்வொர்க்கில் உச்ச சுமை எங்கு உள்ளது என்பதைப் பொறுத்து, பிராந்தியங்களில் விநியோகிக்க இது மிகவும் வசதியாக இருக்கும். ஒற்றை பேலன்சரின் மட்டத்தில் இது தோல்வியடைந்தால், அது வெறுமனே சேவையிலிருந்து அகற்றப்பட்டு dns இலிருந்து அகற்றப்படும். பேலன்சர்களின் குழுவில் ஏதேனும் சிக்கல் ஏற்பட்டால், அவை பிற தளங்களில் காப்புப் பிரதி எடுக்கப்படுகின்றன, மேலும் அவற்றுக்கிடையே மாறுவது அதே பாதையைப் பயன்படுத்தி செய்யப்படுகிறது53, ஏனெனில் குறுகிய TTL காரணமாக, அதிகபட்சம் 2, 3, 5 நிமிடங்களுக்குள் மாறுதல் நிகழ்கிறது.
மூன்றாவது "ஆனால்": எது இன்னும் ஒதுக்கப்படவில்லை? S3, சரி. பயனர்களுக்காக நாங்கள் சேமித்து வைத்திருக்கும் கோப்புகளை s3 இல் வைக்கும்போது, அது கவசம்-துளையிடும் மற்றும் எதையும் முன்பதிவு செய்ய வேண்டிய அவசியமில்லை என்று நாங்கள் உண்மையாக நம்பினோம். ஆனால் விஷயங்கள் வேறுவிதமாக நடப்பதை வரலாறு காட்டுகிறது. பொதுவாக, அமேசான் S3 ஐ ஒரு அடிப்படை சேவையாக விவரிக்கிறது, ஏனெனில் அமேசான் இயந்திரப் படங்கள், configs, AMI படங்கள், ஸ்னாப்ஷாட்களை சேமிக்க S3 ஐப் பயன்படுத்துகிறது... மேலும் s3 செயலிழந்தால், இந்த 7 ஆண்டுகளில் ஒரு முறை நடந்தது போல், நாம் பயன்படுத்தி வரும் வரை. bitrix24, இது ஒரு விசிறியைப் போல பின்தொடர்கிறது - மெய்நிகர் இயந்திரங்களைத் தொடங்க இயலாமை, ஏபிஐ தோல்வி மற்றும் பல விஷயங்கள் உள்ளன.
மற்றும் S3 விழலாம் - அது ஒரு முறை நடந்தது. எனவே, நாங்கள் பின்வரும் திட்டத்திற்கு வந்தோம்: சில ஆண்டுகளுக்கு முன்பு ரஷ்யாவில் தீவிரமான பொதுப் பொருள் சேமிப்பு வசதிகள் இல்லை, மேலும் நாங்கள் சொந்தமாக ஏதாவது செய்வதற்கான விருப்பத்தை நாங்கள் கருதினோம் ... அதிர்ஷ்டவசமாக, நாங்கள் இதைச் செய்யத் தொடங்கவில்லை, ஏனென்றால் நாங்கள் எங்களிடம் இல்லாத நிபுணத்துவத்தை தோண்டி எடுத்துள்ளோம், மேலும் ஒருவேளை குழப்பமடையலாம். இப்போது Mail.ru இல் s3-இணக்கமான சேமிப்பிடம் உள்ளது, யாண்டெக்ஸில் உள்ளது, மேலும் பல வழங்குநர்கள் அதைக் கொண்டுள்ளனர். முதலில், காப்புப்பிரதி மற்றும் இரண்டாவதாக, உள்ளூர் நகல்களுடன் பணிபுரியும் திறனைப் பெற விரும்புகிறோம் என்ற எண்ணத்திற்கு இறுதியில் வந்தோம். ரஷ்ய பிராந்தியத்திற்கு, நாங்கள் Mail.ru ஹாட்பாக்ஸ் சேவையைப் பயன்படுத்துகிறோம், இது s3 உடன் API இணக்கமானது. பயன்பாட்டிற்குள் உள்ள குறியீட்டில் எங்களுக்கு பெரிய மாற்றங்கள் எதுவும் தேவையில்லை, மேலும் பின்வரும் பொறிமுறையை நாங்கள் செய்துள்ளோம்: s3 இல் பொருட்களை உருவாக்க/நீக்குவதைத் தூண்டும் தூண்டுதல்கள் உள்ளன, Amazon இல் Lambda என்ற சேவை உள்ளது - இது குறியீட்டின் சேவையகமற்ற வெளியீடு ஆகும் சில தூண்டுதல்கள் தூண்டப்படும் போது அது செயல்படுத்தப்படும்.
நாங்கள் அதை மிகவும் எளிமையாகச் செய்தோம்: எங்கள் தூண்டுதல் தீ ஏற்பட்டால், பொருளை Mail.ru சேமிப்பகத்திற்கு நகலெடுக்கும் குறியீட்டை இயக்குகிறோம். தரவின் உள்ளூர் நகல்களுடன் வேலையை முழுமையாகத் தொடங்க, எங்களுக்கு தலைகீழ் ஒத்திசைவு தேவைப்படுகிறது, இதனால் ரஷ்ய பிரிவில் உள்ள வாடிக்கையாளர்கள் தங்களுக்கு நெருக்கமான சேமிப்பகத்துடன் வேலை செய்ய முடியும். அஞ்சல் அதன் சேமிப்பகத்தில் தூண்டுதல்களை முடிக்க உள்ளது - உள்கட்டமைப்பு மட்டத்தில் தலைகீழ் ஒத்திசைவைச் செய்ய முடியும், ஆனால் இப்போது நாங்கள் இதை எங்கள் சொந்த குறியீட்டின் மட்டத்தில் செய்கிறோம். ஒரு கிளையன்ட் ஒரு கோப்பை இடுகையிட்டதைக் கண்டால், குறியீட்டு மட்டத்தில் நிகழ்வை ஒரு வரிசையில் வைத்து, அதைச் செயலாக்கி, தலைகீழ் நகலெடுப்பைச் செய்கிறோம். இது ஏன் மோசமானது: எங்கள் தயாரிப்புக்கு வெளியே எங்கள் பொருள்களுடன் சில வகையான வேலைகளைச் செய்தால், அதாவது சில வெளிப்புற வழிமுறைகளால், நாங்கள் அதை கணக்கில் எடுத்துக்கொள்ள மாட்டோம். எனவே, சேமிப்பக மட்டத்தில் தூண்டுதல்கள் தோன்றும் வரை இறுதி வரை காத்திருக்கிறோம், இதனால் குறியீட்டை எங்கிருந்து இயக்கினாலும், நமக்கு வந்த பொருள் மற்ற திசையில் நகலெடுக்கப்படும்.
குறியீடு மட்டத்தில், ஒவ்வொரு கிளையண்டிற்கும் இரண்டு சேமிப்பகங்களையும் நாங்கள் பதிவு செய்கிறோம்: ஒன்று முதன்மையாகக் கருதப்படுகிறது, மற்றொன்று காப்புப்பிரதியாகக் கருதப்படுகிறது. எல்லாம் சரியாக இருந்தால், எங்களுக்கு நெருக்கமான சேமிப்பகத்துடன் நாங்கள் வேலை செய்கிறோம்: அதாவது, அமேசானில் உள்ள எங்கள் வாடிக்கையாளர்கள், அவர்கள் S3 உடன் வேலை செய்கிறார்கள், ரஷ்யாவில் பணிபுரிபவர்கள் ஹாட்பாக்ஸுடன் வேலை செய்கிறார்கள். கொடி தூண்டப்பட்டால், தோல்வி இணைக்கப்பட வேண்டும், மேலும் கிளையண்டுகளை வேறொரு சேமிப்பகத்திற்கு மாற்றுவோம். பிராந்திய வாரியாக இந்தப் பெட்டியைத் தனித்தனியாகச் சரிபார்க்கலாம் மற்றும் அவற்றை முன்னும் பின்னுமாக மாற்றலாம். நாங்கள் இதை இன்னும் நடைமுறையில் பயன்படுத்தவில்லை, ஆனால் இந்த பொறிமுறையை நாங்கள் வழங்கியுள்ளோம், மேலும் ஒரு நாள் நமக்கு இந்த சுவிட்ச் தேவைப்படும் மற்றும் கைக்கு வரும் என்று நாங்கள் நினைக்கிறோம். இது ஏற்கனவே ஒருமுறை நடந்துள்ளது.
ஓ, மற்றும் அமேசான் ஓடி விட்டது ...
இந்த ஏப்ரல் ரஷ்யாவில் டெலிகிராம் தடையின் தொடக்கத்தின் ஆண்டு நிறைவைக் குறிக்கிறது. இதன் கீழ் மிகவும் பாதிக்கப்பட்ட வழங்குநர் அமேசான். மேலும், துரதிர்ஷ்டவசமாக, உலகம் முழுவதும் பணியாற்றிய ரஷ்ய நிறுவனங்கள் அதிகம் பாதிக்கப்பட்டன.
நிறுவனம் உலகளாவியது மற்றும் ரஷ்யா அதற்கு மிகச் சிறிய பிரிவாக இருந்தால், 3-5% - நன்றாக, ஒரு வழி அல்லது வேறு, நீங்கள் அவர்களை தியாகம் செய்யலாம்.
இது முற்றிலும் ரஷ்ய நிறுவனமாக இருந்தால் - இது உள்நாட்டில் அமைந்திருக்க வேண்டும் என்று நான் நம்புகிறேன் - சரி, இது பயனர்களுக்கு வசதியாக இருக்கும், வசதியாக இருக்கும், மேலும் குறைவான அபாயங்கள் இருக்கும்.
இது உலகளவில் செயல்படும் நிறுவனமாக இருந்தால், ரஷ்யா மற்றும் உலகம் முழுவதிலும் இருந்து ஏறக்குறைய சம எண்ணிக்கையிலான வாடிக்கையாளர்களைக் கொண்டிருந்தால் என்ன செய்வது? பிரிவுகளின் இணைப்பு முக்கியமானது, மேலும் அவை ஒருவருக்கொருவர் ஒரு வழி அல்லது வேறு வழியில் செயல்பட வேண்டும்.
மார்ச் 2018 இறுதியில், Roskomnadzor மிகப்பெரிய ஆபரேட்டர்களுக்கு ஒரு கடிதம் அனுப்பியது, அது பல மில்லியன் அமேசான் ஐபிகளைத் தடுக்கும் பொருட்டு... Zello மெசஞ்சரைத் தடுக்கத் திட்டமிட்டுள்ளதாகக் குறிப்பிட்டுள்ளது. இதே வழங்குநர்களுக்கு நன்றி - அவர்கள் அனைவருக்கும் கடிதத்தை வெற்றிகரமாக கசியவிட்டனர், மேலும் அமேசானுடனான தொடர்பு துண்டிக்கப்படலாம் என்ற புரிதல் இருந்தது. அது வெள்ளிக்கிழமை, நாங்கள் servers.ru இலிருந்து எங்கள் சக ஊழியர்களிடம் பீதியுடன் ஓடினோம்: “நண்பர்களே, எங்களுக்கு பல சேவையகங்கள் தேவை, அவை ரஷ்யாவில் அல்ல, அமேசானில் அல்ல, ஆனால், எடுத்துக்காட்டாக, ஆம்ஸ்டர்டாமில் எங்காவது இருக்கும்” குறைந்தபட்சம் எப்படியாவது நமது சொந்த VPN மற்றும் ப்ராக்ஸியை நிறுவுவதற்கு, எந்த வகையிலும் நம்மால் பாதிக்க முடியாத சில இறுதிப்புள்ளிகளுக்கு, எடுத்துக்காட்டாக, அதே s3 இன் எண்ட்பான்ட்கள் - ஒரு புதிய சேவையை உருவாக்கி வேறு ஐபியைப் பெற முயற்சிக்க முடியாது, நாங்கள் இன்னும் நீங்கள் அங்கு செல்ல வேண்டும். ஒரு சில நாட்களில், நாங்கள் இந்த சேவையகங்களை அமைத்து, அவற்றை இயக்கி, பொதுவாக, தடுப்பு தொடங்கும் தருணத்திற்கு தயார் செய்தோம். ஆர்.கே.என், வம்பு மற்றும் பீதியைப் பார்த்து, "இல்லை, நாங்கள் இப்போது எதையும் தடுக்க மாட்டோம்" என்று கூறியது ஆர்வமாக உள்ளது. (ஆனால் இது சரியாக டெலிகிராம் தடுக்கப்படும் தருணம் வரை.) பைபாஸ் திறன்களை அமைத்து, தடுப்பது அறிமுகப்படுத்தப்படவில்லை என்பதை உணர்ந்துகொண்டாலும், நாங்கள் முழு விஷயத்தையும் வரிசைப்படுத்தத் தொடங்கவில்லை. ஆம், ஒரு சந்தர்ப்பத்தில்.
இப்போது 2019 இல் நாங்கள் இன்னும் தடுக்கும் நிலைமைகளில் வாழ்கிறோம். நான் நேற்றிரவு பார்த்தேன்: சுமார் ஒரு மில்லியன் ஐபிகள் தொடர்ந்து தடுக்கப்பட்டுள்ளன. உண்மை, அமேசான் கிட்டத்தட்ட முற்றிலும் தடைநீக்கப்பட்டது, அதன் உச்சத்தில் அது 20 மில்லியன் முகவரிகளை எட்டியது... பொதுவாக, ஒத்திசைவு, நல்ல ஒத்திசைவு இருக்காது என்பதே உண்மை. திடீரென்று. தொழில்நுட்ப காரணங்களுக்காக இது இல்லாமல் இருக்கலாம் - தீ, அகழ்வாராய்ச்சி, அனைத்து. அல்லது, நாம் பார்த்தபடி, முற்றிலும் தொழில்நுட்பம் இல்லை. எனவே, பெரியவர்களும் பெரியவர்களும், தங்கள் சொந்த ASகளுடன், இதை வேறு வழிகளில் நிர்வகிக்கலாம் - நேரடி இணைப்பு மற்றும் பிற விஷயங்கள் ஏற்கனவே l2 நிலையில் உள்ளன. ஆனால் ஒரு எளிய பதிப்பில், நாங்கள் செய்ததைப் போல அல்லது சிறியதாக இருந்தால், வேறு எங்காவது உயர்த்தப்பட்ட சேவையகங்களின் மட்டத்தில் நீங்கள் பணிநீக்கம் செய்யலாம், முன்கூட்டியே vpn, ப்ராக்ஸியில் உள்ளமைக்கப்பட்ட, அவற்றில் உள்ளமைவை விரைவாக மாற்றும் திறன் கொண்டது. உங்கள் இணைப்பிற்கு முக்கியமான பிரிவுகள் . அமேசானின் தடுப்பு தொடங்கியபோது இது ஒன்றுக்கு மேற்பட்ட முறை எங்களுக்கு பயனுள்ளதாக இருந்தது; மோசமான சூழ்நிலையில், நாங்கள் S3 போக்குவரத்தை மட்டுமே அனுமதித்தோம், ஆனால் படிப்படியாக இவை அனைத்தும் தீர்க்கப்பட்டன.
ஒரு முழு வழங்குநரையும் எப்படி முன்பதிவு செய்வது?
முழு அமேசானும் செயலிழந்தால் இப்போது எங்களிடம் ஒரு காட்சி இல்லை. ரஷ்யாவிற்கும் இதேபோன்ற சூழ்நிலை உள்ளது. ரஷ்யாவில், நாங்கள் ஒரு வழங்குநரால் ஹோஸ்ட் செய்யப்பட்டோம், அவரிடமிருந்து பல தளங்களை நாங்கள் தேர்வு செய்தோம். ஒரு வருடத்திற்கு முன்பு நாங்கள் ஒரு சிக்கலை எதிர்கொண்டோம்: இவை இரண்டு தரவு மையங்களாக இருந்தாலும், வழங்குநரின் நெட்வொர்க் உள்ளமைவின் மட்டத்தில் ஏற்கனவே சிக்கல்கள் இருக்கலாம், அது இன்னும் இரண்டு தரவு மையங்களையும் பாதிக்கும். மேலும் இரண்டு தளங்களிலும் நாங்கள் கிடைக்காமல் போகலாம். நிச்சயமாக அதுதான் நடந்தது. உள்ளே உள்ள கட்டிடக்கலையை மறுபரிசீலனை செய்து முடித்தோம். இது பெரிதாக மாறவில்லை, ஆனால் ரஷ்யாவிற்கு இப்போது இரண்டு தளங்கள் உள்ளன, அவை ஒரே வழங்குநரிடமிருந்து அல்ல, ஆனால் இரண்டு வெவ்வேறு தளங்களிலிருந்து. ஒன்று தோல்வியுற்றால், மற்றொன்றுக்கு மாறலாம்.
அனுமானமாக, அமேசானுக்கு மற்றொரு வழங்குநரின் மட்டத்தில் முன்பதிவு செய்வதற்கான சாத்தியத்தை நாங்கள் பரிசீலித்து வருகிறோம்; ஒருவேளை கூகுள், ஒருவேளை வேறு யாரேனும் இருக்கலாம்... ஆனால் இதுவரை நாம் நடைமுறையில் அமேசான் ஒரு கிடைக்கும் மண்டலத்தின் அளவில் விபத்துக்களைக் கொண்டிருந்தாலும், ஒரு முழுப் பகுதியிலும் விபத்துகள் ஏற்படுவது மிகவும் அரிது. எனவே, "அமேசான் அல்ல அமேசான்" முன்பதிவு செய்யலாம் என்று கோட்பாட்டளவில் எங்களுக்கு யோசனை உள்ளது, ஆனால் நடைமுறையில் இது இன்னும் இல்லை.
ஆட்டோமேஷன் பற்றி சில வார்த்தைகள்
ஆட்டோமேஷன் எப்போதும் தேவையா? இங்கே டன்னிங்-க்ரூகர் விளைவை நினைவுபடுத்துவது பொருத்தமானது. "x" அச்சில் நாம் பெறும் நமது அறிவும் அனுபவமும் உள்ளது, மேலும் "y" அச்சில் நமது செயல்களில் நம்பிக்கை உள்ளது. முதலில் எங்களுக்கு எதுவும் தெரியாது, உறுதியாக இல்லை. பின்னர் நாம் கொஞ்சம் தெரிந்துகொண்டு மெகா நம்பிக்கையுடன் இருக்கிறோம் - இது "முட்டாள்தனத்தின் உச்சம்" என்று அழைக்கப்படுகிறது, இது "டிமென்ஷியா மற்றும் தைரியம்" என்ற படத்தால் நன்கு விளக்கப்பட்டுள்ளது. பிறகு கொஞ்சம் கற்றுக்கொண்டு போருக்குத் தயாராகிவிட்டோம். பின்னர் நாம் சில பெரிய-தீவிரமான தவறுகளில் அடியெடுத்து வைப்போம், விரக்தியின் பள்ளத்தாக்கில் நம்மைக் காண்கிறோம், நமக்கு ஏதாவது தெரியும், ஆனால் உண்மையில் நமக்கு அதிகம் தெரியாது. பின்னர், நாம் அனுபவத்தைப் பெறும்போது, நாம் அதிக நம்பிக்கையுடன் இருக்கிறோம்.
சில விபத்துக்களுக்கான பல்வேறு தானியங்கி சுவிட்சுகள் பற்றிய எங்கள் தர்க்கம் இந்த வரைபடத்தால் நன்றாக விவரிக்கப்பட்டுள்ளது. நாங்கள் தொடங்கினோம் - எதையும் எப்படி செய்வது என்று எங்களுக்குத் தெரியவில்லை, கிட்டத்தட்ட எல்லா வேலைகளும் கையால் செய்யப்பட்டன. எல்லாவற்றிற்கும் ஆட்டோமேஷனை இணைக்கலாம், அமைதியாக தூங்கலாம் என்பதை நாங்கள் உணர்ந்தோம். திடீரென்று நாங்கள் ஒரு மெகா-ரேக்கில் அடியெடுத்து வைக்கிறோம்: தவறான நேர்மறை தூண்டப்படுகிறது, மேலும் நல்ல முறையில் இதைச் செய்திருக்கக் கூடாதபோது போக்குவரத்தை முன்னும் பின்னுமாக மாற்றுகிறோம். இதன் விளைவாக, பிரதிபலிப்பு உடைகிறது அல்லது வேறு ஏதாவது - இது விரக்தியின் பள்ளத்தாக்கு. பின்னர் நாம் எல்லாவற்றையும் புத்திசாலித்தனமாக அணுக வேண்டும் என்ற புரிதலுக்கு வருகிறோம். அதாவது, ஆட்டோமேஷனை நம்புவது அர்த்தமுள்ளதாக இருக்கிறது, தவறான அலாரங்களின் சாத்தியத்தை வழங்குகிறது. ஆனாலும்! விளைவுகள் பேரழிவை ஏற்படுத்தும் என்றால், அதை கடமை மாற்றத்திற்கு விட்டுவிடுவது நல்லது, பணியில் இருக்கும் பொறியாளர்களுக்கு, அவர்கள் உண்மையில் விபத்து இருப்பதை உறுதிசெய்து கண்காணிப்பார்கள், மேலும் தேவையான நடவடிக்கைகளை கைமுறையாக மேற்கொள்வார்கள்.
முடிவுக்கு
7 ஆண்டுகளில், ஏதாவது விழுந்தால், பீதி-பீதி ஏற்பட்டது என்ற உண்மையிலிருந்து, பிரச்சினைகள் இல்லை, பணிகள் மட்டுமே உள்ளன, அவை தீர்க்கப்பட வேண்டும் - மற்றும் முடியும் - என்ற புரிதலுக்கு நாங்கள் சென்றோம். நீங்கள் ஒரு சேவையை உருவாக்கும்போது, மேலே இருந்து அதைப் பாருங்கள், நடக்கக்கூடிய அனைத்து அபாயங்களையும் மதிப்பிடுங்கள். நீங்கள் உடனடியாக அவற்றைப் பார்த்தால், பணிநீக்கத்தை முன்கூட்டியே வழங்கவும், தவறு-சகிப்புத்தன்மை கொண்ட உள்கட்டமைப்பை உருவாக்குவதற்கான வாய்ப்பையும் வழங்கவும், ஏனென்றால் எந்தவொரு புள்ளியும் தோல்வியடையும் மற்றும் சேவையின் இயலாமைக்கு வழிவகுக்கும். உள்கட்டமைப்பின் சில கூறுகள் நிச்சயமாக தோல்வியடையாது என்று உங்களுக்குத் தோன்றினாலும் - அதே s3 ஐப் போலவே, அவர்களால் முடியும் என்பதை இன்னும் நினைவில் கொள்ளுங்கள். குறைந்தபட்சம் கோட்பாட்டில், ஏதாவது நடந்தால் நீங்கள் அவர்களை என்ன செய்வீர்கள் என்று ஒரு யோசனை செய்யுங்கள். இடர் மேலாண்மை திட்டத்தை வைத்திருங்கள். எல்லாவற்றையும் தானாகவோ அல்லது கைமுறையாகவோ செய்வதைப் பற்றி நீங்கள் சிந்திக்கும்போது, அபாயங்களை மதிப்பிடுங்கள்: ஆட்டோமேஷன் எல்லாவற்றையும் மாற்றத் தொடங்கினால் என்ன நடக்கும் - இது விபத்துடன் ஒப்பிடும்போது இன்னும் மோசமான சூழ்நிலைக்கு வழிவகுக்காது? ஒருவேளை எங்காவது ஆட்டோமேஷனைப் பயன்படுத்துவதற்கும் பணியில் இருக்கும் பொறியாளரின் எதிர்வினைக்கும் இடையில் நியாயமான சமரசத்தைப் பயன்படுத்துவது அவசியம், அவர் உண்மையான படத்தை மதிப்பீடு செய்து, அந்த இடத்திலேயே ஏதாவது மாற்ற வேண்டுமா அல்லது "ஆம், ஆனால் இப்போது இல்லை" என்பதைப் புரிந்துகொள்வார்.
பரிபூரணவாதம் மற்றும் உண்மையான முயற்சி, நேரம், பணம் ஆகியவற்றுக்கு இடையேயான நியாயமான சமரசம், நீங்கள் இறுதியில் வைத்திருக்கும் திட்டத்தில் நீங்கள் செலவிடலாம்.
இந்த உரை மாநாட்டில் அலெக்சாண்டர் டெமிடோவின் அறிக்கையின் புதுப்பிக்கப்பட்ட மற்றும் விரிவாக்கப்பட்ட பதிப்பாகும் .
ஆதாரம்: www.habr.com