100 கோடிக்கும் மேற்பட்ட ChatGPT பயனர்களுக்காகச் சேமிப்பகத்தை விரிவாக்குதல் (பகுதி 2)
முன்னெப்போதுமில்லாத வளர்ச்சியைச் சமாளிக்க, எங்கள் செயலிச் சேமிப்பகத் தளமான Habitat-இல் Azure Cosmos DB-ஐ மேம்படுத்திய விதம்.
அனைத்து OpenAI தயாரிப்புகளுக்கும் தரவை வேகமாகவும் நம்பகமாகவும் அணுக வேண்டியுள்ளது. இதை எங்கள் சேமிப்பகத் தளமான Habitat வழங்குகிறது. 40 புவியியல் வட்டாரங்களில் உள்ள 100 கோடிக்கும் மேற்பட்ட பயனர்களுக்கு அது மில்லிவினாடிகளில் பதிலளிக்க வேண்டும். எங்கள் உள்கட்டமைப்பு அசாதாரணமான சவாலை எதிர்கொண்டது: நம்பகத்தன்மை, செயல்திறன் மற்றும் தயாரிப்பு உருவாக்க வேகத்தைத் தொடர்ந்து மேம்படுத்தியபடியே, அதிவேக வளர்ச்சியையும் புதிய பயன்பாடுகளையும் ஆதரிக்க வேண்டியிருந்தது. அந்தச் சவாலைத் தீர்க்க, எங்கள் இணையச் சேமிப்பகத் தளத்தின் வடிவமைப்பையும் இயக்கத்தையும் மறுபரிசீலனை செய்ய வேண்டியிருந்தது. முதலில் மிக முக்கியமான தயாரிப்புப் போக்குவரத்துக்குத் தேவையான நம்பகத்தன்மை, அடுத்து உலகளாவிய பயனர்களுக்குத் தேவையான வேகம், இறுதியாக மிகப்பெரிய அளவில் திறம்பட இயங்குதல் என்ற வரிசையில், நன்மை தீமைகளைத் தொடர்ந்து மதிப்பிட்டோம்.
எளிய கிளையன்ட் நிரலகம் மற்றும் தரவுத்தளமாக இருந்த Habitat-ஐ, 500 பெட்டாபைட்டுக்கும் மேற்பட்ட தரவை வழங்கும் உலகளாவிய பரவலான சேமிப்பகத் தளமாக எப்படி உருவாக்கினோம் என்பதை இந்த இருபகுதித் தொடர் விளக்குகிறது. பகுதி 1, Python கிளையன்ட்டிலிருந்து சேவையாக Habitat வளர்ந்த விதத்தில் கவனம் செலுத்தியது. Python அடிப்படையிலான சேவையைப் பலரும் நடைமுறையில் சாத்தியமென்று கருதும் அளவைத் தாண்டி இயக்க உதவிய நுட்பங்களையும் அது விவரித்தது.
பகுதி 2-ஆன இந்தப் பதிவில், அடிப்படைச் சேமிப்பகக் கூறான Azure Cosmos DB-ஐ எவ்வாறு விரிவாக்கினோம் என்பதை விளக்குகிறோம். Azure குழுவுடன் நெருக்கமாக இணைந்து பணியாற்றியதன் மூலம், கூட்டாக நிர்வகிக்கப்படும் கொள்கலன்களைக் கொண்ட நடைமுறைக்கு ஏற்ற பல டெனன்ட் அணுகுமுறையை உருவாக்கினோம். இது மிகப்பெரிய உலகளாவிய அளவிலும் சிறந்த வாசிப்புச் செயல்திறனை வழங்குகிறது.
படம் 01 · Habitat என்றால் என்ன?
இணையவழிச் சேமிப்பகத் தளம்
OpenAI தயாரிப்புகளுக்குத் தேவையான தகவலை விரைவாகவும் நம்பகமாகவும் அணுகுவதற்காக நாங்கள் உருவாக்கிய இணையவழிச் சேமிப்பகத் தளமே Habitat ஆகும்.
- கோரிக்கை
- பதில்
- மாற்றங்கள் (CDC)
நிறுவனங்கள் விரிவடையும்போது, உள்கட்டமைப்புக் குழுக்கள் பெரும்பாலும் ஒற்றை டெனன்ட் முறைமைகளிலிருந்து பல டெனன்ட் முறைமைகளுக்கு மாறுகின்றன. ஒவ்வொரு தயாரிப்புப் பகுதிக்கான குழுவும் தனி முறைமையைப் பராமரிக்கும் ஒற்றை டெனன்ட் முறை, பாதிப்பின் பரப்பைக் குறைக்கிறது. பொறுப்பு எல்லைகளையும் பணிச்சுமைத் தனிமைப்படுத்தலையும் எளிதாக்குகிறது. குழுக்களும் தயாரிப்புப் பகுதிகளும் வளரும்போது, இதை இயக்கும் செலவு அதிகரிக்கிறது. ஒற்றை டெனன்ட் முறை, ஒவ்வொரு தயாரிப்புக் குழுவையும் வளத் திட்டமிடலுக்குப் பொறுப்பாக்குகிறது. பெரும்பாலும் தேவையைவிட அதிக வள ஒதுக்கீட்டுக்கும் வழிவகுக்கிறது.
மாறாக, வளங்களை ஒதுக்குவதில் கூடுதல் அறிவும் அனுபவமும் கொண்ட மையத் தரவுத்தளக் குழுவிடம் பல டெனன்ட் முறையானது கட்டுப்பாட்டை ஒப்படைக்கிறது. ஆனால் பல டெனன்ட் முறையிலும் தனிப்பட்ட சிக்கல்கள் உள்ளன. உதாரணமாக, ஒரு டெனன்ட் வழக்கத்துக்கு மாறாக அதிக வளங்களைப் பயன்படுத்தி மற்ற டெனன்ட்களைப் பாதிக்கும் அண்டைப் பணிச்சுமை இடையூறு ஏற்படலாம்.
Habitat-இல், பெரிய அளவில் நம்பகமாகவும் வளச் சிக்கனமாகவும் இயங்கும் சேமிப்பக முறைமையை வடிவமைக்க இந்த நன்மை தீமைகள் அனைத்தையும் சீர்தூக்க வேண்டியிருந்தது. இன்று Habitat பல OpenAI தயாரிப்புகளுக்கான பல டெனன்ட் தரவுத்தள அடுக்காக உள்ளது. ஆனால் முதலில் ஒரே பல டெனன்ட் Azure Cosmos DB கொள்கலனைப் பயன்படுத்தி, பிறகு ஒற்றை டெனன்ட் அடிப்படைக் கொள்கலன்களை ஒதுக்கி, மீண்டும் பல டெனன்ட் கொள்கலனை இயல்புநிலையாக்கிய ஒரு சுற்றுப்பயணத்தைக் கடந்துள்ளோம். Habitat-இன் பல டெனன்ட் பயணத்தில் இன்னும் தொடக்க நிலையில்தான் இருக்கிறோம். ஏராளமான பயன்பாடுகளை ஆதரித்தாலும், இயன்ற இடங்களில் Azure Cosmos DB-இன் உள்ளமைந்த அடிப்படை வசதிகளைப் பயன்படுத்தி, இத்துறைக்கான முதலீட்டை ஒத்திவைக்க முடிந்துள்ளது.
எங்கள் Azure Cosmos DB பயணத்தை விவரிக்கும் முன், சில அடிப்படைத் தகவல்கள்:
ஓர் Azure Cosmos DB கணக்கு, கொள்கலன்களின் தொகுப்பையும் பிரதியெடுப்புக் கொள்கையையும் வரையறுக்கிறது
ஒவ்வொரு கொள்கலனுக்கும் வினாடிக்கான கோரிக்கை அலகுகளில் (RU/s) குறிப்பிட்ட அளவு த்ரூபுட் ஒதுக்கப்படுகிறது
ஒவ்வொரு கொள்கலனிலும், குறிப்பிட்ட தருக்கப் பகுதிப்பிரிப்பு விசையின்படி தரவைப் பிரித்துச் சேமிக்கும் வழக்கமான முறை பயன்படுத்தப்படுகிறது. ஒவ்வொரு விசைக்குமான சேமிப்பகம் மற்றும் த்ரூபுட் வரம்புகள் ஆவணப்படுத்தப்பட்டுள்ளன
Azure Cosmos DB, தருக்கப் பகுதிப்பிரிப்பு விசைகளைக் குறைவான அடிப்படை வன்பொருள் பகுதிப்பிரிப்புகளில் பிரித்து வைக்கிறது. சேமிப்பகம் ஒரு வரம்பை மீறும்போதோ, ஒதுக்கப்பட்ட த்ரூபுட்டை வழங்கக் கொள்கலனுக்குக் கூடுதல் வன்பொருள் பகுதிப்பிரிப்புகள் தேவைப்படும்போதோ, அவற்றைப் பல வன்பொருள் பகுதிப்பிரிப்புகளாகப் பிரிக்கிறது
தொடக்கத்தில் எந்தக் கிளையன்ட் சுமையையும் அனுமதித்தோம். ஒவ்வொரு தருக்கப் பகுதிப்பிரிப்பு விசைக்கும் கூறப்பட்ட 10,000 RU/s வரம்பு, அதிகப்படியான கோரிக்கைகளைத் தடுக்கும் என நம்பினோம். தொடக்கத்தில் ஒவ்வொரு கணக்கிலும் ஒரே இயல்புநிலை Azure Cosmos DB கொள்கலனை மட்டுமே பயன்படுத்தினோம். இது ஓரளவு நன்றாக இயங்கினாலும், சில காரணங்களால் சிக்கலானது:
ஆரம்பகால API தேர்வுகளால், தருக்கப் பகுதிப்பிரிப்பு விசையைத் தேர்ந்தெடுக்கும் வசதியை நேரடியாகக் கிளையன்ட்களுக்கு வழங்கினோம். இதனால் வெவ்வேறு தயாரிப்புப் பயன்பாடுகளில், பொதுவாகப் பயன்படுத்தப்படும் user_id அல்லது workspace_id போன்ற பகுதிப்பிரிப்பு விசைகள் அடிக்கடி ஒன்றுடன் ஒன்று மோதுகின்றன. ஒரே தருக்கப் பகுதிப்பிரிப்பு விசைகளுக்கான Azure Cosmos DB வரம்புகளை இந்தப் பயன்பாடுகள் பகிர்ந்ததால், ஒரு பயனருக்கான ஒட்டுமொத்த த்ரூபுட்டை இந்த வடிவமைப்பு கட்டுப்படுத்தியது.
Habitat மற்றும் Azure Cosmos DB-க்கு மாறுவதற்கு முன், Postgres-ஐ விரிவாக்கும்போது அடிக்கடி ஒரு சிக்கலை எதிர்கொண்டோம்: மிக அதிகச் சுமையை உருவாக்கும் ஒரு நிறுவனம் அல்லது விசையிலிருந்து வரும் ஏராளமான கோரிக்கைகள், அதாவது ஒரே டெனன்ட்டின் அளவுக்கு மீறிய சுமை, முழுத் தரவுத்தளத்தையும் முடக்கிவிடக்கூடும். அந்த விசைகளைத் தற்காலிகச் சேமிப்பில் வைக்கவும், அதில் தரவு கிடைக்காதபோது தற்காலிகப் பூட்டுகளைப் பயன்படுத்தவும் கணிசமான கூட்டுமுயற்சி எடுத்தோம். இதனால் தற்காலிகச் சேமிப்பில் தரவு இல்லாததால் ஏற்படும் சுமை, அடிப்படைத் தரவுத்தளத்தை முடக்காமல் தடுத்தோம்.
Figure 02a · Logical partition key limits
Different clients, the same partition key
ஆவணங்களில் தரவு அளவு மற்றும் த்ரூபுட் வரம்புகளானவை தருக்கப் பகுதிப்பிரிப்பு விசைகளுக்குப் பொருந்தினாலும், உண்மையில் வன்பொருள் பகுதிப்பிரிப்பில்தான் அவை அமல்படுத்தப்படுகின்றன. நடைமுறையில், தருக்கப் பகுதிப்பிரிப்புகளால் 10,000 RU/s-ஐ எட்ட முடியாது என்பதே இதன் பொருள் ஆகும். மாறாக, அதே வன்பொருள் பகுதிப்பிரிப்பில் உள்ள மற்ற எல்லாத் தருக்கப் பகுதிப்பிரிப்பு விசைகளுடனும் அதன் வரம்புகளைப் பகிர்ந்துகொள்கின்றன.
இதனால் வளங்களை அதிகம் பயன்படுத்தும் அண்டைப் பணிச்சுமைகள், தொடர்பற்ற பல தருக்கப் பகுதிப்பிரிப்பு விசைகளைப் பாதித்தன. குறுகிய பயன்பாடுள்ள தயாரிப்பு அம்சங்களின் தரவைச் செயலாக்கும் பணிச்சுமைகள், அடிப்படை உள்நுழைவு மற்றும் பதிவுசெய்தல் செயல்பாடுகளையே சீர்குலைத்தன.
Figure 02b · Noisy neighbors
Different users, the same physical partition
ஒரு வன்பொருள் பகுதிப்பிரிப்பின் த்ரூபுட் வரம்பும் மாறக்கூடியது. அது Azure Cosmos DB கொள்கலனுக்கு ஒதுக்கப்பட்ட மொத்த த்ரூபுட்டைப் பொறுத்தது. கொள்கலனுக்கு ஒதுக்கப்பட்ட த்ரூபுட், அதன் வன்பொருள் பகுதிப்பிரிப்புகளிடையே ஏறத்தாழச் சமமாகப் பகிரப்படுகிறது.
தரவு அளவு அதிகரிக்கும்போது வன்பொருள் பகுதிப்பிரிப்புகள் பிரிந்து, மொத்தப் பகுதிப்பிரிப்பு எண்ணிக்கை அதிகரிக்கிறது. ஆனால் ஒதுக்கப்பட்ட மொத்த த்ரூபுட் மாறுவதில்லை. இதனால் தரவு அளவு வளர வளர, ஒவ்வொரு பகுதிப்பிரிப்புக்கும் கிடைக்கும் நடைமுறை த்ரூபுட் வரம்பு சுருங்குகிறது.
பெரும் தரவுப் பொருட்களைச் சேமிக்கும் எங்கள் பயன்பாடுகளில் இது ஒரு செயலிழப்புச் சூழலை உருவாக்குகிறது: கோரிக்கை வீதமும் பயன்பாடும் நிலையாக இருந்தாலும், சேமிப்பக வளர்ச்சி மட்டுமே செயலில் உள்ள பணிச்சுமைகளுக்கான த்ரூபுட் திறனைக் குறைத்துவிடுகிறது.
Figure 02C · Weak partitions
The limit falls below demand
A partition splits when it reaches its storage limit. Each child receives half the throughput capacity.
தனித்தனி கொள்கலன்கள், இந்தப் பகுதிப்பிரிப்பு விசை வரம்புகளையும் அண்டைப் பணிச்சுமைகளின் இடையூறுகளையும் ஓரளவு தீர்க்க உதவுகின்றன. தனித்தனி கொள்கலன்களைப் பயன்படுத்தும்போது, ஒவ்வொன்றுக்கும் தனித்த வன்பொருள் பகுதிப்பிரிப்புகளை ஒதுக்கலாம். அந்தக் கொள்கலனுக்குள் உள்ள பணிச்சுமைகள் மட்டுமே ஒன்றுக்கொன்று இடையூறு செய்யவோ ஒரே பகுதிப்பிரிப்பு விசையைப் பயன்படுத்தவோ முடியும். ஆனால் புதிய கொள்கலன்களை அமைப்பதில் கூடுதல் பணி உள்ளது. ஒவ்வொன்றுக்கும் தனித்த வளத் திட்டமிடல் தேவை. எனவே பொருத்தமான சேவை அல்லது பயன்பாட்டு எல்லைகளில் மட்டுமே கொள்கலன்களை உருவாக்க விரும்புகிறோம்.
வலுவான தனிமைப்படுத்தல் தேவைப்பட்ட மிக முக்கியமான புதிய பயன்பாடுகளுக்குத் தனித்தனி Azure Cosmos DB கொள்கலன்களைப் பயன்படுத்தத் தொடங்கினோம். ஒவ்வொரு கொள்கலனின் மொத்த த்ரூபுட் ஒதுக்கீட்டையும் அதன் வன்பொருள் பகுதிப்பிரிப்பு எண்ணிக்கைக்கு ஏற்பச் சரிசெய்யும் நிரலையும் சேர்த்தோம். இதன்மூலம் திறன் குறைந்த பகுதிப்பிரிப்புகளை நிர்வகித்து, நாங்கள் எதிர்கொண்ட பெரும்பாலான சிக்கல்களைத் தவிர்த்தோம்.
எனினும், தொடக்கத்தில் இயல்புநிலைக் கொள்கலனைப் பயன்படுத்தியதால், பழைய முக்கியப் பயன்பாடுகள் பல, தரவு இடமாற்றமின்றி அங்கேயே சிக்கியிருந்தன. பகிரப்பட்ட இயல்புநிலைக் கொள்கலனின் தரவை இன்னும் சார்ந்திருந்த முக்கியச் சேவைகளைப் பாதுகாக்க, புதிய சேவைகள் அல்லது பெரிய தயாரிப்பு அம்சங்களுக்குத் தனிக் கொள்கலன்களை உருவாக்குமாறு குழுக்களுக்கு அடிக்கடி அறிவுறுத்தினோம். நாங்கள் விரிவடைந்தபோது, இயல்புநிலைக் கொள்கலனின் அழுத்தமும் நேரடிச் சேவைச் சிக்கல்களும் அதிகரித்தன. இயல்புநிலைக் கொள்கலனில் கூடுதல் சுமையைத் தவிர்ப்பதற்காகவே, எந்தப் புதிய சேவைக்கும் பெரிய தயாரிப்பு அம்சத்துக்கும் தனிக் கொள்கலன்களை ஒதுக்கத் தொடங்கினோம்.
இது பல தளம் முழுவதுமான முடக்கங்களிலிருந்து எங்களைப் பாதுகாத்தது. பாதிப்பை ஓர் அம்சம் அல்லது சேவையின் செயல்திறன் குறைவாக மட்டுப்படுத்தியது. எனினும், புதிய கொள்கலன்களை அமைப்பதற்கான கூடுதல் பணி இறுதியில் சிக்கலாக மாறியது:
பழைய பகிரப்பட்ட இயல்புநிலைக் கொள்கலனில், ஒரு புதிய பயன்பாடு வினாடிக்கு 0 வினவலிலிருந்து 10 லட்சம் வினவல்களாக உயர்ந்தாலும், மொத்தப் பயன்பாடு பெரிதும் மாற வாய்ப்பில்லை. ஆனால் தனிமைப்படுத்தப்பட்ட கொள்கலனில், புதிய பயன்பாடு வினாடிக்கு 0-இலிருந்து 10 லட்சம் வினவல்களாக உயர்வது, உள்நிறுவனச் சோதனைப் பயன்பாட்டால் மட்டுமே இருந்த அடிப்படைச் சுமையைவிட 1,000 மடங்கு அதிகமாக இருக்கலாம்.
பிரத்யேகக் கொள்கலன்கள் வந்ததால், அறிமுகத்தின்போது எதிர்பார்க்கும் த்ரூபுட் அளவுக்கேற்ப முன்கூட்டியே வளங்களை ஒதுக்க, குழுக்கள் நினைவில் கொள்ள வேண்டியிருந்தது. தயாரிப்புக் குழுக்கள் பெரும்பாலும் அம்சங்களை வெளியிட்டுவிட்டு, முன்கூட்டியே வளங்களை அதிகரிக்க மறந்துவிடும். அறிமுக நாளில் அவசரச் சம்பவ அறைகளில் அமர்ந்து, கடைசி நேரத்தில் கொள்கலன்களின் திறனை அதிகரிக்க முயல்வோம்.
பல டெனன்ட் முறைமைகளில் பணிச்சுமைகளைக் கலப்பதால் கிடைக்கும் முக்கிய நன்மை இதுவாகும். சிறந்த தனிமைப்படுத்தலுக்காக இந்தக் கொள்கலன் உத்தியில் அதை இழக்கிறோம்.
Figure 03 · Lack of stable aggregate growth
The same workload, different headroom
1K RU/s during load testing → 1M RU/s at launch
காலப்போக்கில், பிரத்யேகக் கொள்கலன்களின் பயன்பாட்டைக் கண்காணிக்கவும், போக்குவரத்து எப்போது மாறும் அல்லது வளரும் என்ற ஆழமான தயாரிப்பு அறிவு தேவைப்பட்டது.
வளர்ச்சிப் போக்குகளின் அடிப்படையில் ஒவ்வொரு கொள்கலனுக்கும் ஒதுக்கப்பட்ட த்ரூபுட்டை அதிகரிக்க ஓர் அடிப்படைக் கட்டுப்பாட்டுத் தள நிரலை வழங்கலாம். ஆனால் நிலையான ஒட்டுமொத்த வளர்ச்சி இல்லாததால், சரியாக விரிவாக்குவதற்கு OpenAI-இன் கிட்டத்தட்ட ஒவ்வொரு தயாரிப்புக் குழுவும் வளத் திட்டமிடலில் ஈடுபட வேண்டியிருந்தது.
ஒவ்வொரு சேவைக் குழுவும் Azure Cosmos DB வள ஒதுக்கீட்டில் செலுத்திய கவனம் பெரிதும் மாறுபட்டதால், நிறுவன வளர்ச்சிக்கு ஏற்ப இந்த முறை செயல்படவில்லை.
நிறுவனம் வளர்ந்தபோது, அந்த இயக்கச் சிக்கல்களைச் சமாளிப்பது கடினமானது. திட்டமிடுவதற்கு ஒரே மையக் குழு இல்லாததால், பல குழுக்களின் திட்டமிடல் மோசமாக இருந்தது. எனவே மீண்டும் பல டெனன்ட் தீர்வை நோக்கி மாறினோம். Azure குழுவுடன் நெருக்கமாகப் பணியாற்றி, பகிரப்பட்ட டெனன்ட் வடிவமைப்பில் எங்கள் ஆரம்பகாலச் சிக்கல்களுக்குத் தீர்வுகளை உருவாக்கினோம்:
அதிகச் சுமையுள்ள விசைகளை முதலில் கட்டுப்படுத்துவதால், ஒரு வன்பொருள் பகுதிப்பிரிப்பின் முழு த்ரூபுட்டையும் அண்டைப் பணிச்சுமைகள் பயன்படுத்திவிடாமல் தடுக்கலாம். இதனால் ஒரே விசையின் அதிகச் சுமை தளம் முழுவதையும் பாதிக்கும் அபாயம் குறைகிறது.
இதேபோல், கோரிக்கைகளைத் தரப்படுத்தும் QoS முறை, மொத்தத் தரவுச் சேர்ப்பு அல்லது பிரித்தெடுத்தல் போன்ற பின்னணிப் பணிச்சுமைகள் ஒரு வன்பொருள் பகுதிப்பிரிப்பின் முழு த்ரூபுட்டையும் பயன்படுத்துவதைத் தடுக்கிறது. இந்தப் பணிச்சுமைகளின் கோரிக்கைகளுக்குக் குறைந்த முன்னுரிமை கொடுப்பதால், அவை முதலில் கட்டுப்படுத்தப்படுகின்றன. இதனால் இறுதிப் பயனர்களுக்குச் சேவையளிக்கும் அதிக முன்னுரிமையுள்ள ஊடாடும் கோரிக்கைகள் கட்டுப்படுத்தப்படுவது தவிர்க்கப்படுகிறது.
முன் ஒதுக்கீட்டு முறையில் எங்களுக்கு ஏற்பட்ட திறன் குறைந்த பகுதிப்பிரிப்புச் சிக்கலைத் தீர்க்கக்கூடிய சேவையகமற்ற முறை Azure Cosmos DB-இல் ஏற்கெனவே இருந்தது. ஆனால் அதில் ஒரு பெரிய குறை இருந்தது: சேமிப்பகப் பயன்பாட்டின் அடிப்படையில் மட்டுமே விரிவடைந்தது. ஒவ்வொரு வன்பொருள் பகுதிப்பிரிப்பிலும் RU பயன்பாட்டை 5,000 RU/s-ஆகக் கட்டுப்படுத்தியது. இது திறன் குறைந்த பகுதிப்பிரிப்புச் சிக்கலைத் தீர்த்தாலும், அதிக RU தேவைப்படும் பயன்பாடுகளை விரிவாக்குவதைத் தடுக்கும்.
Azure Cosmos DB குழு எங்களுக்காக உருவாக்கிய மேம்பட்ட சேவையகமற்ற முறை, ஒவ்வொரு வன்பொருள் பகுதிப்பிரிப்பையும் 10,000 RU/s வரை விரிவாக்க அனுமதித்தது. சேமிப்பகப் பயன்பாட்டுடன், RU பயன்பாட்டின் அடிப்படையிலும் பகுதிப்பிரிப்புகளைப் பிரித்தது. இதனால் கொள்கலன்களைக் கைமுறையாகக் கண்காணித்து விரிவாக்க வேண்டிய அவசியம் நீங்கியது.
இந்த மாற்றங்களால், மீண்டும் ஒரே பகிரப்பட்ட கொள்கலனுக்குத் திரும்ப முடிந்தது. பணிச்சுமைகளுக்கிடையிலான தனிமைப்படுத்தலைப் பேணியபடியே, தயாரிப்புக் குழுக்களின் முன்கூட்டிய அல்லது தொடர்ச்சியான வளத் திட்டமிடல் தேவையை இது பெரிதும் எளிதாக்கியுள்ளது. அதன்பிறகு கடந்த மாதங்களில், தயாரிப்பு உருவாக்கம் வேகமடைந்தபோதும், வள ஒதுக்கீடு அல்லது அண்டைப் பணிச்சுமை இடையூறு சார்ந்த எந்தச் சம்பவமும் ஏற்படவில்லை.
நிறுவனங்கள் OpenAI அளவுக்கு வளரும்போது, நிர்வகிக்கப்பட்ட சேவைகளில் வழங்குநரின் “நிர்வாகம்” மட்டும் போதாமல் போகிறது. பல பணிச்சுமைகள் கிளவுட் வழங்குநரின் உள்கட்டமைப்பில் வழக்கத்துக்கு மாறானவையாகிவிடுகின்றன. Azure Cosmos DB-இன் மிகப்பெரிய பயனர்களில் ஒன்றாக OpenAI மாறியபோது, அதை வெற்றிகரமாக இயக்க வேறு அணுகுமுறை தேவைப்பட்டது: பகிரப்பட்ட சோதனைகள், பகிரப்பட்ட கண்காணிப்புப் பலகைகள், நேரடிப் பொறியியல் தொடர்புகள், எங்கள் அளவில் மட்டுமே தோன்றும் செயலிழப்புகளுக்குக் கூட்டுப் பொறுப்பு. இன்று எங்கள் மிகப்பெரிய Azure Cosmos DB கணக்கு பல பத்து பெட்டாபைட் தரவைச் சேமித்து, வினாடிக்கு 2 கோடிக்கும் மேற்பட்ட வினவல்களுக்குச் சேவையளிக்கிறது. எங்களுக்குத் தெரிந்தவரை, இந்த அளவில் Azure Cosmos DB-ஐச் செயல்படுத்திய ஒரே நிறுவனம் நாங்கள்தான்.
2024 இறுதியில் ஏற்பட்ட ஒரு வட்டாரச் செயலிழப்பு, இந்த ஒத்துழைப்பு ஏன் தேவை என்பதைத் தெளிவாக்கியது. அப்போது, எங்கள் மிகப்பெரிய Azure Cosmos DB கணக்குகளில் ஒன்றின் முதன்மை Azure வட்டாரத்தில் மின்தடை ஏற்பட்டது. அதையடுத்து மாற்று வட்டாரத்துக்கு மாற்றியபோது, எங்கள் மிகப்பெரிய கணக்குகளை இரண்டாம் நிலை வட்டாரத்துக்கு மாற்றப் பல மணிநேரம் ஆகும் என்பதை உணர்ந்தோம். எங்கள் குழுவோ Azure Cosmos DB குழுவோ எங்கள் அளவில் இதைச் சோதித்திருக்கவில்லை.
சுமார் ஒரு மாதத்துக்குப் பிறகு, அந்தக் கணக்குகளை மீண்டும் அசல் வட்டாரத்துக்கு மாற்றியபோது, மற்றொரு கடுமையான செயலிழப்பை ஏற்படுத்தினோம். அசல் வட்டாரத்தை நோக்கித் திடீரெனக் குவிந்த இணைப்புகள், அங்குள்ள Azure Cosmos DB நுழைவாயிலைத் திணறடித்தன. நுழைவாயில் முறையிலான Azure Cosmos DB கிளையன்ட், மாற்று இயக்கத்தைக் கையாளும் விதத்தில் ஒரு தனித்தன்மை இருந்தது. சில வன்பொருள் பகுதிப்பிரிப்புகள் மட்டுமே அசல் வட்டாரத்துக்குத் திரும்பியிருந்தாலும், எல்லாக் கிளையன்ட்களும் உடனே அங்கு இணைப்புகளை உருவாக்கிக் கோரிக்கைகளை அனுப்பின.
ஒவ்வொரு செயலிழப்பிலும் OpenAI மற்றும் Azure தங்களின் சம்பவ மேலாண்மை நடைமுறைகளைப் பின்பற்றி, பல மூலக் காரணங்களைக் கண்டறிந்து திருத்தங்களைச் செயல்படுத்தின. ஆனால் இந்தச் செயலிழப்புகள், எங்கள் குழுவும் Azure Cosmos DB குழுவும் இயங்கி, சோதிக்கும் விதத்தில் இருந்த ஒரு பெரிய முறைமைசார் சிக்கலின் அறிகுறிகளாக இருந்தன. தொடக்கத்தில், நிர்வகிக்கப்பட்ட சேவைகள் வேகமாகச் செயல்படவும் வணிக இலக்குகளில் கவனம் செலுத்தவும் உதவின. அளவு பெருகும்போது, வழங்குநரின் நிர்வாகம் மட்டும் போதாது. வடிவமைப்பு முதல் இயக்கம் வரை அனைத்து நிலைகளிலும் சேவை வழங்குநருடன் ஆழமான ஒருங்கிணைப்பு தேவைப்படுகிறது.
இன்று Habitat மற்றும் Azure பொறியியல் குழுக்கள், எங்கள் சேவை அடுக்குகள் முதல் Azure Cosmos DB-இன் வன்பொருள் சேமிப்பக அடுக்குகள் வரை Habitat-இன் ஒவ்வொரு அடுக்கையும் கூட்டாகக் கண்காணிக்கின்றன. நேரடிச் சேவைக்குப் பயன்படாத, ஆனால் அதே அளவுள்ள Azure Cosmos DB கணக்கில் மாற்றங்களை இயக்கிச் சோதிக்கிறோம். மென்பொருள் உருவாக்கக் கருவித்தொகுப்புகளை இணைந்து சோதித்து மேம்படுத்துகிறோம். எங்கள் Azure Cosmos DB கணக்குகளின் அளவை நிர்ணயிக்கவும் விரிவாக்கவும் சிறந்த நடைமுறைகளைத் தீர்மானிக்கிறோம். Teams மூலம் இருதரப்புப் பொறியாளர்களும் நேரடியாகத் தொடர்புகொள்கிறோம். ஆதரவு நிலைகளைக் கடக்காமல் ஒருவருக்கொருவர் நேரடியாக அவசர அழைப்பு விடுக்கும் வசதிகளையும் அமைத்துள்ளோம்.
கடந்த ஆண்டில் Azure Cosmos DB-இன் கட்டுப்பாட்டுத் தளம் மற்றும் நுழைவாயிலின் விரிவாக்கத் திறனை மேம்படுத்த, கணிசமான கூட்டுப்பணி நடந்துள்ளது. அதன் மீத்தரவுப் பகுதிப்பிரிப்பைப் பாதுகாக்க, நுழைவாயிலில் சுமைப் பாதுகாப்பையும் பல்வேறு மீத்தரவுகளுக்கான தற்காலிகச் சேமிப்பையும் சேர்த்தோம். இணைப்புத் தொகுப்புகள் மற்றும் அதிக இணைப்பு மறுபயன்பாட்டால் எங்கள் Python habitat-service செயல்முறைகள் ஏற்படுத்தும் அழுத்தத்தைக் குறைத்தோம். இயன்ற இடங்களில் பணிச்சுமைகளை ஒரே இடத்தில் வைத்தோம். தனிப்பட்ட மெய்நிகர் தனியார் கிளவுட்கள் மூலம் முக்கியப் பணிச்சுமைகளைப் பின்னணிப் பணிச்சுமைகளிலிருந்து தனிமைப்படுத்தினோம்.
கடந்த ஆண்டில் எங்கள் Azure Cosmos DB நிலையாக இயங்க இந்த அளவிலான கூட்டுப் பொறியியல் பணி இன்றியமையாததாக இருந்தது. போதுமான அளவு பெரிய அல்லது முக்கியமான எந்த முறைமைக்கும் இத்தகைய குழுப்பணி தேவை: பொறுப்பு எல்லைகளைத் தகர்த்து, நிறுவன எல்லைகளைக் கடந்து செயல்பட வேண்டும்.
பகுதி 1-இல் குறிப்பிட்டபடி, எங்கள் அடிப்படை அணுகுமுறை: முதலில் இயங்கச் செய், பிறகு வேகப்படுத்து, அடுத்து செலவைக் குறை. முதலில் நம்பகத்தன்மை, அடுத்து செயல்திறன், பிறகு வளச் சிக்கனம். Habitat, OpenAI-க்கு இன்றியமையாத உள்கட்டமைப்பாகிவிட்டதால், அதை நம்பகமாக்குவதே முதல் முன்னுரிமையாக இருந்தது. 2025-இல் முறைமை நிலைபெற்று, OpenAI உலகளவில் விரிவடைந்தபோது, தாமதமே பயனர்களுக்கும் தயாரிப்புக் குழுக்களுக்கும் அடுத்த தடையாக மாறியது.
கணக்கீடு மற்றும் சேமிப்பக வளங்கள் பெரும்பாலும் வெவ்வேறு வட்டாரங்களில் இருந்ததால், வட்டாரங்களுக்கு இடையிலான கோரிக்கைகளைத் தவிர்க்க முடியவில்லை.
Figure 04 · Improving performance at a global scale
Global traffic
Compute and storage capacity were often located in different regions, making cross-region requests unavoidable.
கணக்கீடு மற்றும் சேமிப்பகத்தின் புவியியல் இடங்கள், விளக்கத்துக்காக மட்டுமே காட்டப்பட்டுள்ளன.
தரவு சேமிக்கப்பட்ட இடத்தையும் கோரிக்கை செயலாக்கப்பட்ட இடத்தையும் பொறுத்துத் தாமதம் பெரிதும் மாறுபட்டது. Habitat கோரிக்கைகளை வேகப்படுத்த, தயாரிப்பு உருவாக்குநர்கள் கூடுதல் கிளையன்ட் பக்கத் தற்காலிகச் சேமிப்பு, கோரிக்கைத் தொகுப்பாக்கம், தரவுத்தள வாசிப்பு மற்றும் எழுத்துகளைக் குறைத்தல், இயன்றவரை உடனடியாக முடிக்க வேண்டிய பணிப்பாதையிலிருந்து வேலைகளை விலக்குதல் ஆகியவற்றைச் சார்ந்திருந்தனர். இதனால் தரவுத்தளச் சிக்கல்களைச் சிறப்பாகத் தாங்கும் சில சுவாரசியமான தயாரிப்பு வடிவமைப்புகள் உருவாயின. ஆனால் தயாரிப்புகள் சிக்கலாகி, அவற்றைத் தொடர்ந்து மேம்படுத்தும் வேகம் குறைந்தது. தரவுத்தளத்தைப் புரிந்துகொள்ள வேண்டிய அவசியமின்றி விரைவாகத் தயாரிப்புகளை உருவாக்க உதவும் Habitat-இன் இலக்கை இது எட்டவில்லை.
2026-இல் இதில் பெரிதும் கவனம் செலுத்திவருகிறோம். Habitat கோரிக்கைகளில் 90%-க்கும் மேல் உள்ள வாசிப்புகளின் செயல்திறனை மேம்படுத்த, படிநிலை உத்தியை உருவாக்கியுள்ளோம்:
டேட்டா ரெசிடென்சி தேவைகள் உள்ள பயனர்களுக்காக, உலகெங்கிலும் வெவ்வேறு Azure வட்டாரங்களில் பல Azure Cosmos DB கணக்குகளை வைத்துள்ளோம். கட்டாய டேட்டா ரெசிடென்சி தேவைகள் இல்லாத பயனர்களுக்கும்கூட, அருகில் தரவை வைப்பது தாமதத்தைக் குறைத்து அவர்களின் அனுபவத்தை மேம்படுத்துகிறது.
நடைமுறையில், டேட்டா ரெசிடென்சி பயன்பாடுகளைத் தாண்டி இதைப் பரவலாகச் செயல்படுத்த முடியவில்லை. ஏனெனில், தரவை வைக்கும் இடத்தை கிளவுடின் வன்பொருள் வளங்களே கட்டுப்படுத்துகின்றன. எங்கள் தரவுத்தொகுப்புகள் மிகப் பெரியவை என்பதால், பல வட்டாரங்களால் தங்களுக்குரிய பயனர் போக்குவரத்துக்கு ஏற்பத் தேவைப்படும் மிகப்பெரிய சேமிப்பிடத்தை வழங்க முடியவில்லை.
தரவுமைய வளங்கள், மின்சாரம் அல்லது குளிரூட்டல் குறைவாக உள்ள வட்டாரங்களில், சில நேரங்களில் நேரடியாக ஒன்றைத் தேர்ந்தெடுக்க வேண்டியுள்ளது. அதாவது அருகிலேயே சேமிப்பகத்தை அமைத்து Habitat தாமதத்தைக் குறைக்க வளங்களை ஒதுக்குவதா அல்லது அவற்றைக் கூடுதல் கணக்கீட்டுக்குப் பயன்படுத்திச் சேமிப்பகக் கோரிக்கைகளைத் தொலைவில் அனுப்புவதா என்பதைத் தீர்மானிப்பதாகும்.
எனவே, தரவை வைக்கும் இடம் குறித்த முடிவுகள் பெரும்பாலும் இரண்டைச் சமநிலைப்படுத்துகின்றன: அ) பல்வேறு தயாரிப்புகள் மற்றும் பயனர் பிரிவுகளுக்கான தாமதத்தைக் குறைத்தல், ஆ) கிடைக்கும் சேமிப்பு மற்றும் கணக்கீட்டு வளங்கள்.
ஒவ்வொரு கோரிக்கைக்கும் தேவைப்படும் அடையாளச் சரிபார்ப்பு மீத்தரவு போன்ற, மிகக் குறைந்த தாமதம் தேவைப்படும் பணிச்சுமைகளுக்குப் பல இரண்டாம் நிலை வட்டாரங்களில் பிரதிகள் கொண்ட Azure Cosmos DB கணக்குகளைப் பயன்படுத்துகிறோம். இதனால் கணக்கீட்டுக்கும் Habitat-க்கும் இடையிலான சுற்றுப்பயண நேரத்தைக் குறைக்கிறோம். சில கணக்குகள், நாங்கள் சேவையளிக்கும் 40 Azure வட்டாரங்களிலும் பிரதியெடுக்கின்றன. மற்றவை ஒவ்வொரு கண்டத்திலும் குறைந்தது ஒரு வட்டாரத்தில் பிரதியெடுக்கின்றன.
வெவ்வேறு பிரதியெடுப்பு அமைப்புகள் கொண்ட கணக்குகளுக்கு இடையே தரவுத்தொகுப்புகளை நகர்த்த, பயனர்களுக்குத் தெரியாமல் இயங்கும் தரவு நகர்த்தல் மற்றும் வழிப்படுத்தல் அடுக்கை Habitat-இல் திட்டமிட்டதைவிட முன்னதாகவே உருவாக்க வேண்டியிருந்தது.
எனினும், இந்த அணுகுமுறையும் இறுதியில் வளங்களால் கட்டுப்படுத்தப்படுவதால், கவனமாகத் தேர்ந்தெடுத்த சில தரவுத்தொகுப்புகளுக்கு மட்டுமே பயன்படுத்தப்படுகிறது.
Habitat பணிச்சுமைகளில் பெரும்பாலானவை வாசிப்புகளே. செயலிகள் தொடர்ந்து அமைப்புகள், நிலை மற்றும் பிற பண்புகளைப் பெறுகின்றன. அடிக்கடி அணுகப்படும் ஒரு சிறிய தரவுத் தொகுப்பே போக்குவரத்தின் பெரும்பகுதிக்குக் காரணமாகிறது. இதனால் பரவலான தற்காலிகச் சேமிப்புக்கு இந்த முறைமை மிகவும் ஏற்றதாகிறது. ஒற்றை வட்டார உள்கட்டமைப்பில் செயல்திறனைத் தற்காலிகச் சேமிப்பு மேம்படுத்துகிறது. பல வட்டாரங்களில் இயங்கும்போது, அவற்றுக்கு இடையிலான தாமதத்தை “மறைக்க” உதவுவதால் பலன் மேலும் அதிகரிக்கிறது.
Habitat-இல் பரவலான, தேவைக்கேற்ப நிரப்பப்படும் தற்காலிகச் சேமிப்பு அடுக்கை ஒருங்கிணைத்துள்ளோம். பயனர் கோரிக்கைகள் செயலாக்கப்படும் இடத்துக்கு அருகிலுள்ள எங்கள் Valkey சேவையகங்களில், அண்மையில் அணுகப்பட்ட பொருட்கள் மற்றும் உறவுகளின் பிரதியை அது சேமிக்கிறது. பொதுவாக இத்தகைய சேமிப்புகள், தரவு கிடைக்கும் விகிதத்தையும் அதன் பழைமையையும் சமநிலைப்படுத்த ஒரு காலாவதி நேரத்தைப் பயன்படுத்துகின்றன. தரவின் பழைமையைக் குறுகிய காலாவதி நேரம் குறைக்கிறது. ஆனால் உருப்படிகள் விரைவில் காலாவதியாகி அடிக்கடி மீட்டெடுக்கப்படுவதால், தற்காலிகச் சேமிப்பின் நன்மையும் குறைகிறது. தரவு கிடைக்கும் விகிதத்தை நீண்ட காலாவதி நேரம் உயர்த்துகிறது. ஆனால் பழைய தரவை நீண்ட நேரம் வழங்குவதால், பயனர் அனுபவம் மோசமாகி, தயாரிப்பின் நடத்தை கணிக்க முடியாததாகிறது.
அதே அடிப்படைத் தரவில் செயலி எழுதும்போது, தற்காலிகச் சேமிப்பிலுள்ள தரவை வெளிப்படையாகச் செல்லாததாக்குவது மற்றொரு அணுகுமுறை ஆகும். இது தற்காலிகச் சேமிப்புத் தரவின் புதுமையைப் பெரிதும் மேம்படுத்துகிறது. ஆனால் சரியாகச் செயல்படுத்துவது கடினம். பகுதி செயலிழப்புகள் போன்ற விதிவிலக்கான சூழல்களில், தற்காலிகச் சேமிப்பில் பழைய தரவு நீடிக்கலாம். பல வட்டார அமைப்புகளில் நம்பகத்தன்மை குறைந்த இடைவட்டார வலையமைப்புகளும், அடிப்படைச் சேமிப்பகத்தின் பிரதியெடுப்புடன் தற்காலிகச் சேமிப்பு போட்டியிட்டு இயங்குவதும் இச்சிக்கல்களை அதிகரிக்கின்றன. இதனுடன் காலாவதி நேரத்தைச் சேர்ப்பது அதிகபட்சப் பழைமைக்கு வரம்பிடுகிறது. இருந்தாலும் மேலே கூறிய காலாவதி நேரத்தின் அதே நன்மை தீமைகள் நீடிக்கின்றன.
Meta-இன் TAO போன்ற முறைமைகளைப் பின்பற்றி, தரவைச் செல்லாததாக்குவதற்கு இன்னும் மேம்பட்ட அணுகுமுறையை எடுத்துள்ளோம். Habitat-இன் ஒருங்கிணைந்த தற்காலிகச் சேமிப்பு, Azure Cosmos DB மாற்ற ஃபீடு வழியான மாற்றத் தரவுப் பிடிப்பை (CDC) பயன்படுத்துகிறது. செல்லாததாக்கும் தகவலை உலகளவில் சில வினாடிகளில் பரப்பி, பழைமையைக் குறைத்தபடியே தரவு கிடைக்கும் விகிதத்தை உயர்வாக வைத்திருக்கிறது. எங்கள் உள்கட்டமைப்பிலுள்ள ஒரு சேவை இந்த மாற்ற ஃபீடைப் பெற்று, அடிப்படைத் தரவு புதுப்பிக்கப்படும்போது உள்துறைத் தற்காலிகச் சேமிப்புகளில் அதைச் செல்லாததாக்குகிறது. அடுத்த வாசிப்பில் தரவு தற்காலிகச் சேமிப்பில் கிடைக்காது. எனவே அதன் சமீபத்திய பதிப்பு பெறப்பட்டு அங்கு நிரப்பப்படுகிறது.
அசல் Python-ஐவிட வேகமாக இயங்கும் Rust-இல் நிரலை மறுஎழுதி, Habitat சேவையிலேயே இருந்த கூடுதல் செயலாக்கத்தைக் குறைத்தோம். இதுவும் தாமதத்தைக் கணிசமாகக் குறைத்தது.
இந்த மாற்றங்கள் இணைந்து, உலகளாவிய வாசிப்பு p50 நேரத்தைச் சுமார் 120 மில்லிவினாடியிலிருந்து 10 மில்லிவினாடியாகக் குறைத்துள்ளன. இந்த ஆண்டின் தொடக்கத்தில் செயல்திறனில் கவனம் செலுத்தியதிலிருந்து இது 12 மடங்கு முன்னேற்றம் ஆகும்.
Figure 05 · Improving performance at a global scale
p50 latency for reads
Three major design changes improved read latency
தற்காலிகச் சேமிப்பு நடுநிலைத் தாமதத்தைப் பெரிதும் குறைத்தாலும், மிக மெதுவான கோரிக்கைகளுக்குத் தற்காலிகச் சேமிப்பில் இல்லாத தரவை அடிப்படைச் சேமிப்பிலிருந்து பெரும்பாலும் தொலைதூர வட்டாரங்களிலிருந்து பெற வேண்டியுள்ளது. கூடுதல் வளங்கள் கிடைத்து, சேமிப்புத் திறன் மேம்படும்போது, அடிப்படையான சவாலைத் தீர்க்கத் திட்டமிட்டுள்ளோம்: தரவு அணுகப்படும் இடத்துக்கு அருகிலேயே அதைத் தொடக்கத்திலிருந்து வைத்திருப்பதாகும்.
தரவுத்தள மாற்றங்களைச் சார்பு முறைமைகளுக்குப் பரப்பும் நம்பகமான, விரிவாக்கக்கூடிய CDC, Habitat தற்காலிகச் சேமிப்பு உத்தியைத் தாண்டியும் முக்கியப் பங்காற்றுகிறது. ஆயிரக்கணக்கான கொள்கலன்கள், லட்சக்கணக்கான பகுதிப்பிரிப்புகளில் வினாடிக்கு லட்சக்கணக்கான மாற்றங்கள் பிடிக்கப்பட்டு, நூற்றுக்கும் மேற்பட்ட Kafka தலைப்புகள் வழியே செல்கின்றன. அவை காலப்போக்கில் ஒத்திசையும் இரண்டாம் நிலைக் குறியீடுகள், தரவு நகர்த்தும் தொடர்கள், பின்னணிப் பகுப்பாய்வு மற்றும் பிற நிகழ்நேர அம்சங்களையும் இயக்குகின்றன. எங்கள் அடிப்படை உள்கட்டமைப்பு உலகளவில் வளர்ந்ததால், தரவு வரிசை மாற்றங்களைக் கண்காணிப்பது மேலும் சிக்கலாகியுள்ளது. தங்கள் வகையைச் சேர்ந்த வரிசைகள் மாறும்போதெல்லாம் இயங்கும் மீளழைப்பைப் பதிவுசெய்ய, கிளையன்ட்கள் முதலில் தங்கள் தரவு எந்த Cosmos கணக்குகளிலும் கொள்கலன்களிலும் உள்ளது, அந்த வட்டாரங்களில் அவற்றைக் கண்காணிக்கும் CDC சேவை எது என்பதைக் கண்டறிய வேண்டும். மேலும் CDC பணிச் செயலிகள், Kafka மற்றும் தரவைப் பெறும் செயலியின் வளங்களையும் சரியாக விரிவாக்க வேண்டும். இந்தச் சிக்கல்களைத் தயாரிப்பு உருவாக்குநர்களிடமிருந்து மறைப்பதே எங்கள் CDC தளத்தின் நோக்கம் ஆகும். மாறிய வரிசைகளில் அழைக்க வேண்டிய செயல்கூறைப் பதிவுசெய்ய எளிய இடைமுகத்தை வழங்குகிறோம். உள் இணைப்புகளையும் விரிவாக்கத்தையும் நாங்களே கையாளுகிறோம்.
தேவையான எல்லாக் கொள்கலன்களிலும் மாற்றங்கள் பிடிக்கப்படுவதை உள் கட்டுப்பாட்டுத் தளம் தொடர்ந்து உறுதிசெய்கிறது. எந்த Cosmos வட்டாரங்களில் வாசிக்க வேண்டும் என்பதைத் தேர்ந்தெடுத்து, பல வட்டாரங்களில் ஆயிரக்கணக்கான பணிச் செயலிகளுக்குத் திறம்பட வேலை பகிர்கிறது. பிரதி வட்டாரங்களையும் குறைந்த முன்னுரிமையுள்ள ஃபீடு வாசிப்புகளையும் பயன்படுத்துவது, குறைந்த தாமதம் தேவைப்படும் Habitat போக்குவரத்தைப் பின்னணிப் பிடிப்புப் பணிகளிலிருந்து பாதுகாக்கிறது. இவ்வளவு பெரிய தொகுப்பில் பணிச் செயலி முடக்கங்கள், கொள்கலன் சிக்கல்கள், தற்காலிகப் பூட்டுச் சேமிப்புப் பிழைகள், தவறான உள்ளமைவு மற்றும் இலக்குச் செயலிழப்புகள் தொடர்ந்து நிகழ்கின்றன. CDC பணிச் செயலிகளின் வாழ்க்கைச் சுழற்சியையும் தற்காலிகப் பூட்டுகளைக் கையாள்வதையும் வலுப்படுத்தினோம். ஃபீடுகளுக்கிடையே செயலிழப்புகள் பரவாமல் தனிமைப்படுத்தி, உள்ளமைவு மாற்றங்களுக்கும் வெளியீடுகளுக்கும் பாதுகாப்புகளை அமைத்தோம். நிரந்தர வழங்கல் தோல்விகள் வரிசையின் தொடக்கத்திலேயே பிற பணிகளைத் தடுக்காமல் இருக்க, தோல்வியுற்ற செய்திகளுக்குத் தனி வரிசைகளைப் பயன்படுத்துகிறோம். வாசிப்புச் செயலிகளை மாற்று Cosmos வட்டாரங்களுக்கு மாற்றி, வட்டாரச் செயலிழப்புகளைச் சமாளிக்கிறோம். எங்கள் அளவில், Azure-இன் CDC SDK-இலும் மாற்றங்கள் தேவைப்பட்டன. முன்னேற்றப் பதிவுகளை நினைவகத்தில் தொகுத்து, குறிப்பிட்ட இடைவெளிகளில் மட்டும் சேமிப்புக்கு எழுதுவதன் மூலம் அதன் செயல்திறனை மேம்படுத்தினோம்.
Habitat-இன் உள் Azure Cosmos DB பயன்பாடு சிக்கலானது. ஆனால் உள்கட்டமைப்பு விவரங்களை உருவாக்குநர்களிடமிருந்து மறைத்து, தயாரிப்பு உருவாக்கத்தை வேகப்படுத்துவதே அதன் நோக்கம் ஆகும். எங்கள் CDC தளமும் அதையே செய்கிறது.
சேமிப்பக API-இன் செயல்பரப்பை வேண்டுமென்றே குறுகலாக வைத்து, Python சேவையைத் தொடர்ந்து விரிவாக்கி, அவசரப் பொறியியல் சவால்களுக்கு முன்னுரிமை அளித்ததால், சிறிய குழுவாலேயே வேகமாக வளரும் சேமிப்பகத் தளத்தை ஆதரிக்க முடிந்தது. முதலில் முக்கியமான தயாரிப்புப் போக்குவரத்தின் நம்பகத்தன்மை, அடுத்து உலகளாவிய பயனர்களுக்கான வாசிப்புச் செயல்திறன், இறுதியில் பெரிய அளவிலான இயக்கத் திறன் ஆகியவற்றில் கவனம் செலுத்தினோம். நம்பகத்தன்மை, செயல்திறன் மற்றும் தயாரிப்பு உருவாக்க வேகத்தை மேம்படுத்தியபடியே, விரைவான வளர்ச்சியையும் புதிய பயன்பாடுகளையும் இந்த அணுகுமுறை சாத்தியமாக்கியது.
அடுத்த 100 கோடி பயனர்களுக்காக Habitat மற்றும் உரையாடல் சேமிப்பகத்தை விரிவாக்க, இன்னும் பெரிய அளவில் எங்கள் உள்கட்டமைப்பு முழுவதும் தரவைப் பிரதியெடுக்கும் சிக்கலைத் தீர்க்க வேண்டும். இதை முன்கூட்டியே சமாளிக்க, பெரிய Habitat தரவு வகைகளுக்கு ஏற்ற, எக்சாபைட் அளவிலான தனிப்பயன் இணையச் சேமிப்பக முறைமையை நிறுவனத்துக்குள்ளேயே உருவாக்கிவருகிறோம். உருவாக்கத்தில் உள்ள இந்த முறைமை, Rockset-இன் RocksDB Cloud மையத்தை Raft அடிப்படையிலான பிரதியெடுப்புடன் இணைக்கிறது. இது Azure Cosmos DB-இன் அதே ஆவண மாதிரியைச் செயல்படுத்துகிறது. ஆனால் தனித்த சேமிப்பகத்தையும் வன்பொருள் நிலைப் பிரதியெடுப்பையும் பயன்படுத்தித் தேவையான பிளாஷ் சேமிப்பைக் குறைக்கிறது. அதற்குப் பதிலாக உச்ச வினவல் வீதம் குறைகிறது.
அதிநவீன அளவில் இத்தகைய தரவு உள்கட்டமைப்புப் பணிகளில் ஈடுபட ஆர்வமிருந்தால், எங்கள் வேலைவாய்ப்புகளைப் பாருங்கள்.
