100 கோடிக்கும் மேற்பட்ட ChatGPT பயனர்களுக்காக இணையவழிச் சேமிப்பகத்தை விரைவாக விரிவாக்குதல்

ஒருவர் உள்நுழைந்தாலும், Codex அமைப்புகளைச் சரிபார்த்தாலும், ChatGPT‑இல் புதிய உரையாடலைத் தொடங்கினாலும், ஒவ்வொரு OpenAI தயாரிப்பும் தரவை விரைவாகவும் நம்பகமாகவும் அணுகுவதைச் சார்ந்துள்ளது. தயாரிப்பு பதிலளிக்கும் முன், அந்தச் செயல்கள் ஒவ்வொன்றுக்கும் பல தனித்தனித் தரவுத் தேடல்கள் தேவைப்படலாம். அந்தக் கோரிக்கைகள் மெதுவாக இருந்தால், தயாரிப்பும் மெதுவாகத் தோன்றும். அந்தக் கோரிக்கைகள் தோல்வியடைந்தால், தயாரிப்பு முற்றிலும் செயல்படுவதை நிறுத்தும்.

OpenAI தயாரிப்புகளுக்குத் தேவையான தகவலை விரைவாகவும் நம்பகமாகவும் அணுகுவதற்காக நாங்கள் உருவாக்கிய இணையவழிச் சேமிப்பகத் தளமே Habitat ஆகும். Habitat இப்போது ஒவ்வொரு விநாடியும் 7 கோடிக்கும் அதிகமான கோரிக்கைகளைக் கையாள்கிறது; ஏறக்குறைய 40 புவியியல் பிராந்தியங்களில் வாரந்தோறும் 100 கோடிக்கும் மேற்பட்டோர் பயன்படுத்தும் தயாரிப்புகளை ஆதரிக்கிறது. DevDay 2023-இல் GPTகளை ஆதரிக்க Habitat முதலில் வெளியிடப்பட்டது. அது ஒற்றைத் தரவுத்தளத்துடன் இணைக்கப்பட்ட எளிய Python வாடிக்கையாளர் நூலகமாகத் தொடங்கியது. இன்று அது 500 பெட்டாபைட்டுக்கும் அதிகமான தரவுக்கு சேவை செய்யும் சிக்கலான பகிர்ந்தமைப்பாக உள்ளது.

இந்த அளவில் உள்கட்டமைப்பை உருவாக்கி இயக்குவது எளிய சாதனையல்ல; அதேசமயம் தனிப்பட்ட வகையில் கடினமானதும் அல்ல. வியக்கத்தக்க பயனர் வளர்ச்சியையும் தயாரிப்புத் தேவையையும் ஆதரிக்கும் அதேவேளையில் முதிர்ந்த தளத்தையும் உருவாக்க, முன்னெப்போதும் இல்லாத வேகத்தில் விரிவாக்க வேண்டியிருந்ததே எங்கள் சூழலைத் தனித்துவமாக்கியது. பொதுவாக முறைமைப் பொறியாளர்கள் 10 மடங்கு அளவுக்கு உருவாக்கி, அடுத்த 10 மடங்குக்குத் தயாராகும் சில ஆண்டுகள் வரை அது தாங்கும் என நம்புவார்கள். ஆனால் கடந்த மூன்று ஆண்டுகளிலும் நாங்கள் ஆண்டுதோறும் 10 மடங்குக்கும் அதிகமாக வளர்ந்துள்ளோம். இதனால் Habitat-ஐ உருவாக்கி இயக்குவது தந்திரோபாய முடிவுகள் மற்றும் வரிசைப்படுத்தல்களின் தொடராக அமைந்தது: அடித்தள முதலீடுகளுக்கான நேரத்தைப் பெற சேமிப்பு மற்றும் கணிப்பொறித் திறன் நெருக்கடிகளைச் சமாளித்தபடி, தற்போதைய தொழில்நுட்ப அடுக்கிலிருந்து அதிகபட்சப் பயனைப் பெற ஒவ்வொரு கூறையும் அடிமட்டம் வரை புரிந்துகொண்டோம்.

OpenAI வளர்ந்தபோது Habitat-உம் அதனுடன் வளர வேண்டியிருந்தது: முதலில் முக்கியத் தயாரிப்புப் போக்குவரத்திற்குப் போதுமான நம்பகத்தன்மை, பின்னர் உலகளாவிய பயனர்களுக்குப் போதுமான வேகம், இறுதியாகப் பெரும் அளவில் திறம்பட இயங்கும் திறன் ஆகியவற்றைப் பெற்றது. இணையவழிச் சேமிப்பகத்தை எவ்வாறு விரிவாக்கினோம் என்பது குறித்த இரு பகுதித் தொடரின் முதல் பதிவு இதுவாகும். Habitat எவ்வாறு வளர்ந்தது, அதை ஏன் நூலகத்திலிருந்து சேவையாக மாற்றினோம், சேவைத் தொழில்நுட்ப அடுக்குகளில் அரிதாகப் பயன்படுத்தப்படும் Python மொழியில் எழுதப்பட்ட சேவையை எவ்வாறு நம்பகமான சேமிப்பகத் தள அடுக்காக விரிவாக்கினோம் என்பவற்றை இப்பதிவில் பகிர்கிறோம்.

எதிர்காலப் பதிவில், பெருமளவில் பலகுத்தகை நம்பகத்தன்மையை எவ்வாறு உருவாக்கினோம், வாசிப்புச் செயல்திறனை மேம்படுத்திய பல அடுக்கு உத்தி, முன்னெப்போதும் இல்லாத தேவையை நம்பகமாகக் கையாள Azure Cosmos DB உடனான கூட்டாண்மையை எவ்வாறு விரிவாக்கினோம் ஆகியவற்றை விரிவாகப் பார்ப்போம்.

தரவுத்தள நிர்வாகத்தைப் பற்றித் தயாரிப்புப் பொறியாளர்கள் யோசிக்க வேண்டியிருக்கக் கூடாது என்ற எளிய எண்ணத்திலிருந்து Habitat தொடங்கியது. ChatGPT‑இன் முதன்மை சேவையகத்துடன் தொடர்புகொண்ட சிறிய Python நூலகமாக, DevDay 2023-இல் GPTகளை ஆதரிக்க Habitat முதலில் வெளியிடப்பட்டது. அது பின்னணியில் Azure Cosmos DB தரவுத்தளப் பயன்பாட்டுடன் பொருந்திய சில செயல்பாடுகளை ஆதரித்தது.

அடிப்படை விவரங்களில் நிபுணத்துவம் பெற வேண்டிய அவசியமின்றி தரவைச் சேமிக்கவும் மீட்டெடுக்கவும் தயாரிப்புக் குழுக்களுக்கு எளிய வழியை வழங்குவதே நூலகத்தின் பணி ஆகும். எந்த வகைத் தரவு சம்பந்தப்பட்டது, அது எங்கிருந்து வர வேண்டும் அல்லது எங்கு செல்ல வேண்டும், கோரிக்கை அனுமதிக்கப்பட்டதா போன்ற தேவையான பணிகளை Habitat கவனித்துக்கொண்டது.

ஸ்கீமா தேடல், வழிப்படுத்தல், அங்கீகாரம், மறையாக்கம், தொடராக்கம், கோரிக்கை வடிவமைப்பு, இணைப்புத் தொகுப்பாக்கம் ஆகியவற்றைப் பற்றித் தயாரிப்புப் பொறியாளர்கள் கவலைப்படத் தேவையில்லை. Azure Cosmos DB, இடைநினைவகம் அல்லது வேறு சேமிப்பகத்திலிருந்து தரவு வருகிறதா என்பதைக்கூட அவர்கள் கருத்தில் கொள்ளத் தேவையில்லை.

சுயசேவை Postgres மற்றும் Azure Cosmos DB பயன்பாட்டிலிருந்து விலக மையப்படுத்தப்பட்ட முயற்சி இல்லாதபோதும், இந்த Python நூலகம் சிறப்பாகச் செயல்பட்டு OpenAI தயாரிப்புப் பொறியாளர்களிடையே Habitat விரைவாக ஏற்கப்பட்டது.

தயாரிப்புத் தேவைகள் வளர்ந்தபோது, வாடிக்கையாளர் தரப்பு இடைநினைவாக்கம், சுருக்கம், மறையாக்கம் போன்ற அம்சங்களுக்கான ஆதரவைப் பகிரப்பட்ட நூலகத்தில் தயாரிப்பு உருவாக்குநர்கள் எளிதாகச் சேர்க்க முடிந்தது.

2025 நடுப்பகுதியில், வாடிக்கையாளர் தரப்புச் செயலாக்கமாக இருந்த Habitat தனது வரம்பை எட்டியது. Habitat அடுக்கு சிக்கலானதாகி OpenAI சேவைகளின் எண்ணிக்கை அதிகரித்ததால், முந்தைய பதிப்புகளுடன் இணக்கமான நெறிமுறை மாற்றங்கள் சாத்தியமற்றன.

ஒரு சூழலில், மிக முக்கியமான தரவுத் தொகுப்புகளைப் பிராந்திய அளவில் பகிர்ந்த Azure Cosmos DB கணக்குகளுக்கு மாற்றி, ஏதேனும் ஒரு பிராந்தியச் செயலிழப்பின் தாக்கப் பரப்பைக் குறைக்க விரும்பினோம். இந்த மாற்றத்திற்கு, அம்சக் கொடியின் பின்னால் முடக்கப்பட்ட கூடுதல் வழிப்படுத்தல் தர்க்கத்தை வாடிக்கையாளரில் சேர்த்து, அது அனைத்து வாடிக்கையாளர்களுக்கும் வெளியிடப்பட்டதை உறுதிப்படுத்தி, பின்னர் அம்சக் கொடியை இயக்க வேண்டியிருந்தது.

பல சேவைகளின் வெளியீடுகளை ஒருங்கிணைத்து, ஒவ்வொரு குழுவுடனும் பணியாற்றி அதை வெளியிட பல நாட்கள் ஆனது. இதை இயக்குவதற்கு முன், பிரிப்புத் தர்க்கம் சரியாக இருப்பதை உறுதிப்படுத்த சில நிழலாக்கங்களை அறிமுகப்படுத்த விரும்பினோம். அதை வெளியிட மேலும் இரண்டு நாட்கள் ஆனது. தவறாக இருப்பதை உணர்ந்த ஒன்றுக்கான பிழைத் திருத்தமா? அதற்கு மேலும் இரண்டு நாட்கள். இறுதியாகக் கொடியை இயக்கத் தயாரானோம். ஆனால் ஒரு குழு தொடர்பற்ற காரணங்களால் தனது சேவையை முந்தைய பிழையுள்ள வாடிக்கையாளருக்குத் திரும்பச் செய்தது; தவிர்க்க நாங்கள் கடுமையாக உழைத்த செயலிழப்பே இதனால் ஏற்பட்டது.

வாடிக்கையாளர் நூலக மாற்றங்களுக்கு பல சேவைகளிடையே சிக்கலான ஒருங்கிணைப்பு தேவைப்பட்டது. இந்தச் செயல்முறை நாளடைவில் எளிதில் உடையக்கூடியதாகவும் திறனற்றதாகவும் இயக்கத் தோல்விகளுக்கு ஆளாகக்கூடியதாகவும் மாறியது. எதிர்கால வெளியீடுகளில் இந்த இயக்கப் பரவலைக் குறைக்க, Habitat-ஐத் தனிச் சேவையாக மாற்ற முடிவு செய்தோம்.

சேமிப்பகத் தர்க்கத்தைத் தனிச் சேவையாகப் பிரித்ததன் மூலம், வெளியீடுகள், கண்காணிப்புத் தெளிவு, தள மேம்பாடுகள் ஆகியவற்றுக்கு ஒற்றைக் கட்டுப்பாட்டு மையத்தை நிறுவினோம். சிதறிய புதுப்பிப்புகளை நிர்வகிப்பதற்குப் பதிலாக, மேம்பாடுகளை மையத்திலேயே செயல்படுத்தி ஒவ்வொரு OpenAI தயாரிப்புக்கும் உடனடிப் பலன்களை வழங்க முடிந்தது.

மிக வலுவான தரவுப் பாதுகாப்பு மற்றும் தனியுரிமை அடிப்படைகளை வழங்க, மையப்படுத்தப்பட்ட சேவையானது ஒற்றைக் கட்டுப்பாட்டுப் புள்ளியையும் அளிக்கிறது. அணுகல் கட்டுப்பாட்டுக் கொள்கைகளை மையப்படுத்திச் செயல்படுத்தவும், தணிக்கைப் பதிவுகளை உருவாக்கவும், Azure Cosmos DB போன்ற அடிப்படைச் சேமிப்பக வளங்களுக்கான அணுகலைக் கட்டுப்படுத்தவும் உதவும் இடம் Habitat சேவை ஆகும். பயனர் தரவைப் பாதுகாப்பதிலும் வெளிப்புற, உள்புற மற்றும் ஏஜென்ட் தரப்பினரின் அங்கீகரிக்கப்படாத அணுகலைத் தடுப்பதிலும் Habitat முக்கியப் பங்கு வகிக்கிறது.

எங்களுக்கு ஒரு சேவை தேவை என்பது தெரிந்திருந்தது. ஆனால் சேவையாக Python கூடுதல் சுமையை ஏற்படுத்தினாலும், அப்போதே அதிலிருந்து மாற விரும்பவில்லை. அதிக த்ரூபுட் கொண்ட சேவைக்கு Python-ஐப் பயன்படுத்துவது, உள்ளூர் நூலக இயக்கத்துடன் ஒப்பிடும்போது பிணையத் தாமதத்தையும் CPU மற்றும் நினைவக அளவீட்டுச் செலவையும் கணிசமாக அதிகரித்தது. மேலும், 100 மடங்கு அளவில் Python-இன் திறனின்மை ஏற்கத்தக்கதாக இருக்காது என்பதால், இறுதியில் மீண்டும் எழுதுவது ஏறக்குறைய உறுதி என்பதை உணர்ந்தோம்.

எனினும், இதைத் தொழில்நுட்பக் கடனை உத்திசார்ந்து ஏற்றுக்கொள்வதாகக் கருதினோம். அப்போது செலவு அல்லது வள மேம்பாடு எங்கள் முதன்மை நோக்கமல்ல. தயாரிப்பு உருவாக்குநர்களின் தடைகளை நீக்குவதும் தளத்தின் நிலைத்தன்மையை அடைவதுமே நோக்கம் ஆகும். குறுகிய காலத்தில் Python சேவையின் செயல்திறன் சமரசங்களை ஏற்றதால், உடனடிச் சவால்களுக்கு முன்னுரிமை அளித்து, மைய APIகளை நிறுவி, வலுவான உள்கட்டமைப்பை உருவாக்க முடிந்தது.

எதிர்காலத் தொழில்நுட்பப் பாதையை எங்கள் நிரலாக்க மாடல்களின் விரைவான முன்னேற்றம் எளிதாக்கும் என்றும் கணக்கிட்டுப் பந்தயம் வைத்தோம். Python-இலிருந்து முழுமையாக மாற வேண்டிய நேரத்தில், Codex மற்றும் GPT அந்த மாற்றத்தைச் சாத்தியமாக்கும் என்று நம்பினோம். இறுதியில் அந்த நம்பிக்கை சரியானதென நிரூபிக்கப்பட்டது.

Habitat-ஐ Python சேவையாக இயக்குவது செயல்திறனுக்கு உகந்ததல்ல; ஆனால் அவசியமான தேர்வாக இருந்தது. Python விரைவாக முன்னேற உதவுகிறது. அதற்காக எச்சரிக்கையைக் கைவிட்டு, கணிசமாக மோசமான தாமதங்களை ஏற்க முடியாது. ஒரு சராசரிப் பயனர் கோரிக்கை நூற்றுக்கணக்கான தரவுத்தள அழைப்புகளை ஏற்படுத்தும்போது, அவற்றில் மிக மெதுவான அழைப்பின் தாமதத்தையே பயனர் உணர்கிறார். இந்த அளவில் Python சேவையை இயக்குவதில், இத்தகைய இறுதிப்பகுதி தாமதங்களை நிர்வகிப்பதே முக்கியச் சவால் என்பதைக் கண்டோம்.

I/O சார்ந்த பணிச்சுமைகளை Python ஒரே நேரத்தில் இயக்க asyncio உதவுகிறது. ஆனால் Python GIL கட்டுப்பாட்டைத் தவிர்த்து CPU இணைச்செயலாக்கத்தை வழங்காது. I/O அதிகமுள்ள கோரிக்கை பதிலாள் பணியுடன், வழிப்படுத்தல், சுருக்கம், மறையாக்கம், சரிபார்ப்புத் தொகை கணக்கிடல், கீழ்நிலை ஆரோக்கியச் சோதனை, கோரிக்கை நிழலாக்கம், மாற்றுக் கோரிக்கைகள் அனுப்புதல் போன்ற பல CPU-அதிகப் பொறுப்புகளையும் பின்னணிப் பணிகளையும் Habitat கையாள்கிறது.

இத்தனை CPU-அதிகப் பணிச்சுமைகளும் பின்னணிப் பணிகளும் இருப்பதால், asyncio அட்டவணையிடல் தாமதமே இறுதிப்பகுதிக் கோரிக்கைத் தாமதத்தில் ஆதிக்கம் செலுத்தக்கூடும். முதல் சேவை வெளியீட்டுக்கான சீரமைப்புக்கு முன், p99 மற்றும் அதற்கு மேற்பட்ட தாமதமுள்ள கோரிக்கைகளின் தடங்களில், கீழ்நிலைச் சேமிப்பகம் விரைவாகப் பதிலளித்தாலும், பதிலைப் பகுப்பாய்வு செய்ய வேண்டிய இணைநிரல் மீண்டும் அட்டவணையிடப்படும் வரை கோரிக்கைகள் அடிக்கடி நின்றதைக் கண்டோம்.

OpenAI-இன் Python சேவைகளில் நினைவகம், CPU, பிணையம், வட்டு ஆகியவற்றின் வழக்கமான பயன்பாடு மற்றும் நிரம்பல் அளவீடுகளோடு, asyncio சுழற்சியையும் அதன் பணிச்சுமையையும் கண்காணித்து அதற்கேற்ப சீரமைப்பது இன்றியமையாதது.

பின்னணிப் பணிகளை அவ்வப்போது அட்டவணையிட்டு, எதிர்பார்த்த மற்றும் உண்மையான இயக்க நேரங்களின் வேறுபாட்டைப் பதிவு செய்வதன் மூலம், நிகழ்வுச் சுழற்சி அட்டவணையிடல் தாமதத்தை நிகழ்நேரத்தில் அனுபவத் தரவால் அளவிடுகிறோம். அதிகப் பயன்பாட்டில் செலவுமிக்க பல பணிகள் இருக்கும்போது, ஒவ்வொரு செயல்முறையிலும் மிதமான எண்ணிக்கையிலான ஒரேநேரக் கோரிக்கைகளே நூற்றுக்கணக்கான மில்லிவிநாடிகள் வரையிலும், சில அரிய சூழல்களில் பல விநாடிகள் வரையிலும் குறிப்பிடத்தக்க அட்டவணையிடல் தடுமாற்றத்தை ஏற்படுத்தும்.

எனவே ஒவ்வொரு செயல்முறையும் சில ஒரேநேரக் கோரிக்கைகளுக்கு மட்டுமே சேவை செய்யும்படி வைத்து, அதற்குப் பதிலாக Python பணியாளர் செயல்முறைகளின் எண்ணிக்கையைப் பெருமளவில் விரிவாக்குகிறோம்.

முதல் சேவை வெளியீட்டில், நேரடிச் சேவையின் CPU சுயவிவர ஆய்வு மூலம் அதிக asyncio தாமதத்திற்கும் அதனால் ஏற்பட்ட அதிக இறுதிப்பகுதி தாமதங்களுக்கும் ஒரு மூல காரணத்தைக் கண்டோம்: அம்சக் கொடிகளை நிர்வகிக்கவும் A/B சோதனைகள் உள்ளிட்டவற்றை நடத்தவும் உதவும் Statsig வழியாக எங்கள் அம்சக் கொடி உள்ளமைவுகளின் JSON-ஐ அவ்வப்போது பகுப்பாய்வு செய்தது.

இயல்பாக, எந்தத் தடுமாற்றமும் இல்லாமல் ஒவ்வொரு நிமிடமும் புதுப்பிக்கப்பட்ட உள்ளமைவுகளைப் பெற Statsig அமைக்கப்பட்டிருந்தது. மேலும் அனைத்து சேவைகளின் ஒவ்வொரு உற்பத்தி விதியும் அந்த உள்ளமைவில் இருந்தது. மற்றொரு இடத்தில், CPU பயன்பாட்டை உயர்த்தவும் தாமதங்களைக் குறைக்கவும் ஒவ்வொரு பாடிலும் அதிகபட்சம் 8 Python செயல்முறைகளை இயக்கும் கட்டமைப்பு முடிவு எடுக்கப்பட்டிருந்தது. இதனால் ஒவ்வொரு நிமிடமும் ஒரு கட்டத்தில் ஒவ்வொரு பாடிலுள்ள அனைத்து பணியாளர்களும் நடந்துகொண்டிருக்கும் கோரிக்கைகளைச் செயலாக்குவதை நிறுத்தி, மிகப்பெரிய உள்ளமைவுக் கோப்பைப் பகுப்பாய்வு செய்ய CPU சுழற்சிகளைச் செலவிட்டனர்.

CPU சுயவிவர ஆய்வு மூல காரணத்தைக் கண்டறிய உதவியதும் தீர்வு எளிதாக இருந்தது: சிறிய இலக்கு உள்ளமைவைப் பயன்படுத்துதல், புதுப்பிப்பு இடைவெளியை நீட்டித்தல், இதுபோன்ற பின்னணிப் பணிகளில் சிறிது தடுமாற்றத்தைச் சேர்த்தல்.

asyncio தாமதத்தைக் குறைவாக வைத்திருக்க, சேவையகச் செயல்முறைகளிடையே கோரிக்கைகளை நன்றாகச் சமப்படுத்துவதும் முக்கியம். சீரமைக்காவிட்டால் இணைப்புத் தொகுப்பாக்கம் இதற்கு எதிராகவே அமையலாம்.

வாடிக்கையாளர் தரப்பு இணைப்புத் தொகுப்பாக்கத்தில், பல ஒரேநேரக் கோரிக்கைகளை அனுப்பும் ஒற்றை வாடிக்கையாளர் செயல்முறை சில வழங்கி இணைப்புகளை மட்டுமே ஏற்படுத்தி, அதன் முழுச் சுமையையும் சில செயல்முறைகளுக்கே அனுப்பக்கூடும். சுமைச் சமநிலையை மாற்றுவதற்கு முன், எங்கள் சேவையின் பயன்பாட்டில் பெரிய வேறுபாடு இருந்தது. சில இறுதிப்பகுதிச் செயல்முறைகள் சராசரியைவிட 5 முதல் 10 மடங்கு ஒரேநேரக் கோரிக்கைகளுக்குச் சேவை செய்தன.

எங்கள் சேவையின் ஒரு பகுதியை அதிகச் சுமைக்கு உள்ளாக்கிய வாடிக்கையாளரை நிறுத்திய பிறகும், திடீர்ப் போக்குவரத்து முடிந்து நீண்ட நேரம் சில செயல்முறைகள் பாதிக்கப்பட்டிருந்த ஒரு தற்செயல் நிகழ்வில் இதைக் கண்டறிந்தோம். அந்தச் செயல்முறைகளை மீண்டும் தொடங்கும் வரை அவை கட்டுப்பாடின்றி மோசமடைந்து, தொடர்ந்து அதிகரிக்கும் கோரிக்கைகளைப் பெற்றதைக் கண்டோம். ஒரு பாடு அதிகச் சுமைக்கு உள்ளானதும், ஏதோ ஓர் நடத்தை மேலும் அதிகப் போக்குவரத்தை அதே பாடில் நிலைநிறுத்தியது. முந்தைய பணியிலிருந்து எங்கள் குழுவினர் சிலருக்கு நன்கு பரிச்சயமான ஒரு தோல்வி வகை இது: மெட்டாஸ்டேபிள் தோல்வி⁠(புதிய சாளரத்தில் திறக்கும்).

இணைப்புத் தொகுப்பே காரணம் எனச் சந்தேகித்து, இணைப்பின் அதிகபட்ச மறுபயன்பாட்டுக் காலத்தை வரம்பிட்டு சோதித்தோம். அது உண்மையிலேயே சீர்கேட்டைக் கட்டுப்படுத்தி, எங்கள் விசாரணைத் திசை சரியென்பதை உறுதிப்படுத்தியது. Python-இன் aiohttp TCPConnector இயல்பாக LIFO இணைப்பு மறுபயன்பாட்டைப் பயன்படுத்துவதை மேலதிக விசாரணை கண்டறிந்தது: மிக அண்மையில் திரும்பிய இணைப்பே அடுத்த கோரிக்கைக்குத் தேர்ந்தெடுக்கப்படுகிறது. பொதுவாக இது நியாயமான இயல்புநிலை. அண்மை இணைப்புகளை மறுபயன்படுத்துவதால் திடீர்ப் போக்குவரத்தைக் கையாள உருவாக்கப்பட்ட கூடுதல் இணைப்புகள் செயலற்ற காலாவதியை அடைகின்றன; இதனால் அவற்றைப் பராமரிக்கும் கூடுதல் சுமை குறைகிறது. ஆனால் இச்சூழலில் அது மெட்டாஸ்டேபிள் தோல்வியை உருவாக்கியது. திடீர் கோரிக்கை வரவின்போது, மெதுவான அதிகச் சுமை வழங்கிகளுக்கான கோரிக்கைகள் இணைப்புகளைத் தொகுப்புக்குத் தாமதமாகத் திருப்பின. எனவே அடுத்தடுத்த கோரிக்கைகள் அவற்றை அதிகம் தேர்ந்தெடுத்து, ஏற்கெனவே சிரமப்பட்ட பாடுகளில் படிப்படியாக அதிகப் போக்குவரத்தைக் குவித்தன. FIFO மறுபயன்பாட்டைப் பயன்படுத்த இணைப்புத் தொகுப்பைத் திருத்தியது இந்தப் பின்னூட்டச் சுழற்சியை முறித்து, நிலையான நிலையிலான கோரிக்கை வேறுபாட்டையும் குறைத்தது.

இன்று OpenAI உள்கட்டமைப்பு முழுவதும் இணைப்புத் தொகுப்பாக்கத்தையும் சேவையகச் சுமையை நன்கு அறிந்த சமநிலை உத்திகளையும் வழங்க Istio மற்றும் Envoy-ஐப் பெரிதும் சார்ந்து, இச்சிக்கலை முற்றிலும் தவிர்க்கிறோம்.

குறைந்த asyncio தாமதத்திற்காகச் சீரமைத்து இத்தனை Python செயல்முறைகளை வைத்திருப்பதன் ஒரு பக்கவிளைவு, மிகப்பெரிய எண்ணிக்கையிலான இணைப்புகள் கீழ்நிலைச் சார்புகளை எளிதில் மூழ்கடிப்பதாகும். இது “இடிமுழக்கக் கூட்டம்” எனப்படுகிறது.

மெதுவாக நடைபெறுமாறு சீரமைக்கப்படாவிட்டால், வழக்கமான தினசரி வெளியீடுகூட இணைப்புச் சுழற்சியால் கணிசமான CPU அலைச்சலை ஏற்படுத்தலாம் அல்லது ஓர் இணைப்புக் கசிவு, NAT நுழைவாயிலை நிரப்பிப் பிணையத்தை முடக்கலாம். பிற சேவைகளிலும் இச்சிக்கல்கள் அசாதாரணமானவை அல்ல. ஆனால் பல மடங்கு அதிகமான செயல்முறைகள் இருப்பதால் அவற்றைத் தூண்டும் வரம்பு கணிசமாகக் குறைகிறது. த்ரூபுட்டை மட்டும் அடிப்படையாகக் கொண்டு நிலையான நிலையில் கையாள வேண்டியிருக்கும் என வாடிக்கையாளர்கள் எதிர்பார்க்காத பிணைய வளங்களைக்கூட இது அடிக்கடி நிரப்புகிறது.

இணைப்புக் குவிப்பை அதிகரிக்கவும் Envoy-ஐச் சார்ந்திருக்கிறோம். பல்வழிப்படுத்தலைப் பயன்படுத்த Python-இன் HTTP/1 இணைப்புகளை HTTP/2-க்கு மேம்படுத்தவும், பின்னர் அவற்றைத் தொகுத்து இணைப்புகளின் ஆயுளை நீட்டிக்கவும் அதைப் பயன்படுத்துகிறோம். ஒவ்வொரு தனித்தனி Python செயல்முறையிலும் செயல்திறன் குறைவாக இருக்கும் விகித வரம்புகளையும் மின்சுற்றுத் துண்டிப்பான்களையும் செயல்படுத்துவதற்கான மைய இடத்தையும் Envoy வழங்குகிறது.

Python-ஐ இவ்வளவு விரிவாக்க முடிந்ததற்கு ஒரு காரணம் Habitat-இன் கட்டுப்படுத்தப்பட்ட API ஆகும். அது கோரிக்கைச் செலவை முன்கணிக்கக்கூடியதாக வைத்திருக்கிறது. பெரிய அட்டவணை வருடல்கள் அல்லது பல அட்டவணைகளிடையிலான இணைப்புகளை ஏற்படுத்தக்கூடிய தன்னிச்சையான SQL வினவல்களை வாடிக்கையாளர்கள் உருவாக்க அனுமதிப்பதற்குப் பதிலாக, எளிய NoSQL API-ஐ Habitat வழங்குகிறது. சக்திவாய்ந்த API இல்லாதது Habitat வடிவமைப்பில் வேண்டுமென்றே செய்யப்பட்ட சமரசம் ஆகும்.

எளிய, முன்கணிக்கக்கூடிய, நிலையான வேலை கொண்ட கோரிக்கைகளுக்கு உகந்ததாக்குவதே எங்கள் நோக்கம் ஆகும். எங்கள் அனுபவத்தில், இந்த முறைமைகளை விரிவாக்குவது மிகவும் எளிது; தவறாக அமைப்பதும் தவறாகப் பயன்படுத்துவதும் கடினம் ஆகும். முன்கணிக்க முடியாத கிளைபரவல் கொண்ட கோரிக்கைகள் இயக்கரீதியாக ஆபத்தானவை. அவை தனிமைப்படுத்தலையும் சுமைச் சமநிலையையும் சிக்கலாக்கி, சேவைக்கும் வாடிக்கையாளர்களுக்கும் விரிவாக்கக் கடினமான திடீர் தாமத உயர்வுகளை உருவாக்குகின்றன.

Habitat மற்றும் Azure Cosmos DB-க்கு மாறுவதற்கு முன், Postgres-இல் OpenAI-இன் பெரும்பாலான இணையவழித் தரவு சேமிக்கப்பட்டிருந்தது. அப்போது அனைத்து வினவல் மற்றும் ஸ்கீமா மாற்றங்களையும் ஆய்வு செய்து, உற்பத்திக்கு அனுப்பும் முன் அவை முறையாகச் செயல்பட்டு அட்டவணைப்படுத்தப்பட்ட தரவில் இயங்குவதை உறுதிப்படுத்துவது எளிதாக இருந்தது. குழுவும் தயாரிப்புகளும் வளர்ந்தபோது இது விரைவில் நிர்வகிக்க முடியாததாகி, அதிகம் பயன்படுத்தப்படும் பாதையில் ஒரு புதிய செலவுமிக்க வினவல், தரவுத்தளத்தையே முடக்குவதால் அடிக்கடி செயலிழப்புகள் ஏற்பட்டன.

இங்குள்ள சிக்கல், செலவுச் சமநிலையின்மை ஆகும். இயக்குவதற்கு அதிகச் செலவும் கடினமும் உள்ள SQL வினவல்களை எழுதுவது மலிவும் எளிதும். Habitat-இல் இதைத் தவிர்த்து, செலவுமிக்க வினவல்களை வாடிக்கையாளர் தரப்பிலேயே மிகவும் தெளிவாகத் தெரியச் செய்கிறோம். Habitat-க்கு அதிகச் சுமை தரக்கூடிய வரம்பற்ற வினவல்கள் இல்லை. சிக்கலான இணைப்புகளுக்கும் வரைபடப் பயணங்களுக்கும் கடினப் பணியின் ஒரு பகுதியைத் தயாரிப்புக் குழுக்களே செய்ய வேண்டும்; இது ஒட்டுமொத்தமாகச் செயல்திறனுள்ள வடிவமைப்புகளை ஊக்குவிக்கிறது.

TAO⁠(புதிய சாளரத்தில் திறக்கும்)-ஆல் ஈர்க்கப்பட்டு, வாடிக்கையாளர் வரையறுக்கும் பொருள் மற்றும் விளிம்பு வகைகளை அடிப்படையாகக் கொண்ட NoSQL API-ஐ Habitat வழங்குகிறது. பொருட்கள், விளிம்புகள் மற்றும் அவற்றின் உறவுகளை வாடிக்கையாளர்கள் முன்கூட்டியே வரையறுக்கிறார்கள்; ஆனால் ஒவ்வொரு வகையின் உள்ளடக்கத்தை அல்ல. இதனால் உருவாகும் உறவுகள் ஒரு வரைபடத்தை ஒத்திருக்கும். ஆனால் குறிப்பிட்ட பொருளின் நேரடி விளிம்புகளை வினவுவதற்கு அப்பால், வழக்கமான வரைபடப் பயண வினவல்களை Habitat ஆதரிப்பதில்லை.

ஒவ்வொரு பொருளும் அதனுடன் தொடர்புடைய விளிம்புகளும் சேமிப்பகநிலைப் பிரிவில் ஒன்றாக இருக்கும்படி இந்த வரைபடத்தைப் பிரிக்கிறோம். ஆனால் பொருட்களையும் அவற்றின் விளிம்புகள் சுட்டும் தொலைப் பொருட்களையும் ஒன்றாக வைக்க தரவுத்தள நிலையில் ஒருங்கிணைந்த முயற்சி செய்வதில்லை. இதனால் மாடலைக் கிடைமட்ட விரிவாக்கத்திற்காக எளிதில் பிரிக்க முடிகிறது. ஆனால் பொருட்களுக்கிடையிலான ஒவ்வொரு தாவலுக்கும் வெவ்வேறு பிராந்தியங்களில் உள்ள முற்றிலும் வேறுபட்ட Azure Cosmos DB கணக்குகளிலிருந்து தரவு பெற வேண்டியிருக்கலாம் என்பதால் வரைபடப் பயணம் திறனற்றது.

சிக்கலான வினவல் தேவைகளுள்ள வாடிக்கையாளர்களுக்கு, Rockset வழியாகக் கிடைக்கும் Habitat-இன் இணையமற்ற இரண்டாம் நிலைக் காட்சியை வழங்குகிறோம். மாற்றத் தரவுப் பிடிப்பைப் பயன்படுத்தி, இணையவழிச் சேமிப்பக மாற்றங்களை ஏறக்குறைய நிகழ்நேரத்தில் தனிமைப்படுத்தப்பட்ட Rockset நிகழ்வுகளுக்கு அனுப்புகிறோம். சிக்கலான வினவல் தேவைகளுக்கேற்ப தங்களின் Rockset நிகழ்வை விரிவாக்குவது ஒவ்வொரு வாடிக்கையாளர் குழுவின் பொறுப்பு.

இந்த Rockset வழங்கல் எங்கள் வாடிக்கையாளர்களுக்குக் கூடுதல் இடையூறை ஏற்படுத்துகிறது. ஆனால் எளிய வினவல்களை இயல்புநிலையாக்கி, சிக்கலான வினவல்கள் தேவைப்படுவோருக்கு மாற்றுவழி வழங்குவது தற்போதைக்கு சரியான சமரசம் எனக் கருதுகிறோம். இந்த வடிவமைப்பு, வாசிப்பு அதிகமுள்ள பகுப்பாய்வு மற்றும் தேடல் பணிச்சுமைகளிலிருந்து இணையவழிச் சேமிப்பகத்தைத் தனிமைப்படுத்துகிறது.

Python மறுஎழுத்தை ஓராண்டு தள்ளிப்போட்டதால், அதிவேக வளர்ச்சிக் காலத்தில் அதிக அவசரமும் தாக்கமும் கொண்ட சவால்களில் கவனம் செலுத்த முடிந்தது. தளம் முதிர்ந்து வளர்ச்சி தொடர்ந்து வேகமெடுத்த நிலையில், OpenAI-இல் மைய எண்ணிக்கைப்படி இரண்டாவது பெரிய சேவையாகவும் Envoy தடத்தின்படி நான்காவதாகவும் இருந்ததால், இறுதியாக Python-ஐக் கடந்து செல்ல வேண்டிய நேரம் வந்தது. உச்சத்தில், ஒவ்வொரு விநாடியும் 2 கோடிக்கும் அதிகமான கோரிக்கைகளுக்கு சேவை செய்ய Python உதவியது.

2026-இன் இரண்டாம் காலாண்டில், 2 பொறியாளர்கள், Codex மற்றும் GPT‑5.5 உதவியுடன் முழுச் சேவையையும் Rust-இல் மீண்டும் எழுத முடிந்தது. இந்தப் புதிய Rust சேவை இப்போது எங்கள் உற்பத்திக் கோரிக்கைகளில் 95%-ஐக் கையாள்கிறது. வரும் வாரங்களில் Python-ஐ முழுமையாக நிறுத்துவோம். Python பதிப்பைவிட Rust சேவை CPU பயன்பாட்டில் 6 மடங்கும் நினைவகப் பயன்பாட்டில் 15 மடங்கும் திறனுள்ளதாகவும், சராசரி மற்றும் இறுதிப்பகுதி தாமதங்கள் கணிசமாகக் குறைவாகவும் இருப்பதை எங்கள் தரவு காட்டுகிறது. எதிர்கால வலைப்பதிவில் மேலும் பல கற்றல்களைப் பகிரத் திட்டமிட்டுள்ளோம்.

Python சேவையும் இப்போதைய Rust சேவையும் Habitat-இன் ஒரு பகுதி மட்டுமே ஆகும். 100 கோடிக்கும் மேற்பட்ட ChatGPT பயனர்களுக்குச் சேவை செய்ய இணையவழிச் சேமிப்பகத்தை எவ்வாறு விரைவாக விரிவாக்கினோம் என்பதை விளக்கும் இத்தொடரின் இரண்டாம் பகுதியில், சேமிப்பக அடுக்கைப் பற்றியும் 500 பெட்டாபைட்டுக்கும் அதிகமான தரவையும் விநாடிக்கு 7 கோடிக்கும் அதிகமான கோரிக்கைகளையும் Habitat எவ்வாறு கையாள்கிறது என்பதையும் பார்ப்போம்.

அதிநவீன அளவில் OLTP முறைமைகளில் பணியாற்றவும் இத்தகைய பொறியியலில் ஈடுபடவும் விரும்பினால், எங்கள் குழுவிலுள்ள இந்தக் காலிப் பணியிடத்தைப் பாருங்கள்⁠.