ከ1 ቢሊዮን በላይ የChatGPT ተጠቃሚዎችን ለማገልገል የመስመር ላይ ማከማቻን በፍጥነት ማስፋፋት

አንድ ሰው ሲገባ፣ የCodex ቅንብሮቹን ሲፈትሽ ወይም በChatGPT አዲስ ውይይት ሲጀምር፣ እያንዳንዱ የOpenAI ምርት ፈጣንና አስተማማኝ የውሂብ መዳረሻ ይፈልጋል። ምርቱ ምላሽ ከመስጠቱ በፊት እያንዳንዱ ድርጊት ብዙ የተለያዩ የውሂብ ፍለጋዎችን ሊጠይቅ ይችላል። እነዚያ ጥያቄዎች ከዘገዩ፣ ምርቱ የዘገየ ይመስላል። እነዚያ ጥያቄዎች ካልተሳኩ፣ ምርቱ ሙሉ በሙሉ መሥራት ያቆማል።

Habitat የOpenAI ምርቶች የሚያስፈልጋቸውን መረጃ በፍጥነትና በአስተማማኝነት እንዲያገኙ የገነባነው የመስመር ላይ ማከማቻ መድረክ ነው። Habitat አሁን በየሰከንዱ ከ70 ሚሊዮን በላይ ጥያቄዎችን ያስተናግዳል፤ በ40 የሚጠጉ ጂኦግራፊያዊ ክልሎችም በየሳምንቱ ከ1 ቢሊዮን በላይ ሰዎች የሚጠቀሙባቸውን ምርቶች ይደግፋል። Habitat በDevDay 2023 GPTዎችን ለመደገፍ መጀመሪያ ሲጀመር፣ ከአንድ የውሂብ ጎታ ጋር የተገናኘ ቀላል የPython የደንበኛ-ወገን ቤተ-መጻሕፍት ነበር። ዛሬ ከ500 ፔታባይት በላይ ውሂብን የሚያገለግል ውስብስብ የተሰራጨ ስርዓት ነው።

በዚህ ስፋት መሠረተ ልማትን መገንባትና ማስኬድ ቀላል ባይሆንም፣ በተለይ አስቸጋሪም አይደለም። ሁኔታችንን ልዩ ያደረገው፣ በጣም ፈጣን የተጠቃሚ እድገትንና የምርት ፍላጎትን እየደገፍን በተመሳሳይ ጊዜ የበሰለ መድረክ ስንገነባ፣ ከዚህ በፊት ባልታየ ፍጥነት ማስፋፋት መገደዳችን ነው። ብዙውን ጊዜ የስርዓት መሐንዲሶች ለ10 እጥፍ ስፋት ይገነባሉ፤ ለቀጣዩ 10 እጥፍ እየተዘጋጁም ለጥቂት ዓመታት እንዲቆይ ተስፋ ያደርጋሉ። በእኛ ሁኔታ ግን ባለፉት ሦስት ዓመታት በየዓመቱ ከ10 እጥፍ በላይ አድገናል። በዚህም ምክንያት Habitatን መገንባትና ማስኬድ ተከታታይ ስልታዊ ውሳኔዎችንና ቅደም ተከተልን ጠይቋል፦ ከነባሩ ቴክኖሎጂያችን ከፍተኛውን ጥቅም ለማግኘት እያንዳንዱን አካል በዝቅተኛው ደረጃ መረዳት፣ እንዲሁም ለመሠረታዊ ኢንቨስትመንቶች ጊዜ ለመግዛት የማከማቻና የስሌት አቅም እጥረቶችን መቋቋም።

OpenAI ሲያድግ Habitatም አብሮ ማደግ ነበረበት፦ መጀመሪያ ለወሳኝ የምርት ትራፊክ በቂ አስተማማኝ፣ ከዚያም ለዓለም አቀፍ ተጠቃሚዎች በቂ ፈጣን፣ በመጨረሻም በግዙፍ ስፋት በብቃት የሚሠራ መሆን። ይህ ጽሑፍ የመስመር ላይ ማከማቻን እንዴት እንዳስፋፋን ከሚያብራራው ባለሁለት ክፍል ተከታታይ የመጀመሪያው ነው። በዚህ ጽሑፍ Habitat እንዴት እንደተሻሻለ፣ ለምን ከቤተ-መጻሕፍት ወደ አገልግሎት እንደቀየርነውና ለአገልግሎት ብዙም ባልተለመደው Python የተጻፈ አገልግሎትን ወደ አስተማማኝ የማከማቻ መድረክ ንብርብር እንዴት እንዳሳደግነው እናጋራለን።

ወደፊት በሚወጣ ጽሑፍ፣ በሰፊ ደረጃ የብዙ ተከራይነትን አስተማማኝ እንዴት እንዳደረግን፣ የንባብ አፈጻጸምን ለማመቻቸት ያለንን ባለንብርብር ስልት እና ከዚህ በፊት ያልታየ ፍላጎትን በአስተማማኝነት ለማስተናገድ ከAzure Cosmos DB ጋር ያለንን አጋርነት እንዴት እንዳስፋፋን በዝርዝር እንገልጻለን።

Habitat የጀመረው ከቀላል ሐሳብ ነው፦ የምርት መሐንዲሶች ስለ ውሂብ ጎታ አስተዳደር ማሰብ የለባቸውም። Habitat በDevDay 2023 GPTዎችን ለመደገፍ ከChatGPT ዋና አገልጋይ ጋር የሚገናኝ አነስተኛ የPython ቤተ-መጻሕፍት ሆኖ ተጀመረ። በውስጡ ወደ Azure Cosmos DB የውሂብ ጎታ መተግበሪያ የሚዛመዱ ጥቂት ክወናዎችን ይደግፍ ነበር።

የቤተ-መጻሕፍቱ ተግባር፣ የምርት ቡድኖች መሠረታዊ ዝርዝሮቹን ማወቅ ሳያስፈልጋቸው ውሂብን የሚያከማቹበትና መልሰው የሚያገኙበት ቀላል መንገድ መስጠት ነበር። Habitat አስፈላጊውን ሥራ ይሠራ ነበር፦ የውሂቡን ዓይነት፣ ከየት መምጣት ወይም ወዴት መሄድ እንዳለበት፣ ጥያቄው የተፈቀደ መሆኑንና ሌሎችንም ይወስን ነበር።

የምርት መሐንዲሶች ስለ እቅድ ማውጣት ፍለጋ፣ ማዞሪያ፣ ፈቃድ ማረጋገጥ፣ ምስጠራ፣ ተከታታይ ቅርጸት ማዘጋጀት፣ የጥያቄ ቅርጽና የግንኙነት ስብስብ መጨነቅ አያስፈልጋቸውም። ውሂቡ ከAzure Cosmos DB፣ ከመሸጎጫዎች ወይም ከሌሎች የማከማቻ ዓይነቶች ከየት እንደሚመጣ እንኳ ማሰብ አያስፈልጋቸውም።

ይህ የPython ቤተ-መጻሕፍት በጥሩ ሁኔታ ሠርቷል፤ በራስ አገልግሎት Postgres እና Azure Cosmos DBን ከመጠቀም ለማራቅ የተቀናጀ ማዕከላዊ ግፊት ባይኖርም፣ Habitat በOpenAI የምርት መሐንዲሶች ዘንድ በፍጥነት ተቀባይነት አገኘ።

የምርት ፍላጎቶች ሲለወጡ፣ የምርት ገንቢዎች እንደ ደንበኛ-ወገን መሸጎጥ፣ መጭመቅ ወይም ምስጠራ ያሉ ባህሪያትን ድጋፍ ወደ የጋራ ቤተ-መጻሕፍቱ ማከልም ቀላል ነበር።

በ2025 አጋማሽ Habitat እንደ ደንበኛ-ወገን ትግበራ የአቅሙ ገደብ ላይ ደርሶ ነበር። የHabitat ንብርብር ይበልጥ ውስብስብ ሲሆንና የOpenAI አገልግሎቶች ቁጥር ሲጨምር፣ ከቀድሞ ስሪቶች ጋር የሚጣጣሙ የፕሮቶኮል ለውጦች ማድረግ የማይቻል ሆነ።

በአንድ ወቅት፣ በጣም ወሳኝ የሆኑ የውሂብ ስብስቦቻችንን በክልል ወደተሰራጩ የAzure Cosmos DB መለያዎች በማዛወር፣ በአንድ ክልል የሚከሰት መቋረጥ የሚያደርሰውን ጉዳት መጠን መቀነስ ፈልገን ነበር። ይህን ለውጥ ለማድረግ፣ በባህሪ ጠቋሚ ጀርባ የተሰናከለ ተጨማሪ የማዞሪያ አመክንዮ በደንበኛው ውስጥ ማከል፣ ለሁሉም ደንበኞች መሰራጨቱን ማረጋገጥና ከዚያ ባህሪውን ማንቃት አስፈለገ።

በደርዘን የሚቆጠሩ አገልግሎቶች ላይ ስምሪቶችን ማስተባበርና ከእያንዳንዱ ቡድን ጋር ለማሰራጨት መሥራት ቀናትን ወሰደ። ይህን ከማንቃታችን በፊት፣ የsharding አመክንዮው ትክክል መሆኑን ለማረጋገጥ የጥላ ቅጂ ማከል እንደምንፈልግ ተገነዘብን። ያንን ለማሰራጨትም ሌላ ሁለት ቀናት ያህል ፈጀ። ስህተት መሆኑን ላወቅነው ነገር የሳንካ ማስተካከያስ? ሌላ ሁለት ቀናት ያህል። በመጨረሻ ጠቋሚውን ለማንቃት ተዘጋጀን፤ ሆኖም ከቡድኖቹ አንዱ ባልተያያዘ ምክንያት አገልግሎቱን ወደ ቀድሞው ሳንካ ያለበት ደንበኛ መለሰ፣ ይህም ለማስቀረት ጠንክረን የሠራንበትን መቋረጥ አስከተለ።

በደንበኛ ቤተ-መጻሕፍቱ ላይ የሚደረጉ ለውጦች በደርዘን የሚቆጠሩ አገልግሎቶች መካከል ውስብስብ ቅንጅት ይጠይቁ ነበር፤ ይህ ሂደትም እየተበላሸ፣ ብቃት እያጣና ለአሠራር ውድቀቶች እየተጋለጠ መጣ። በወደፊት ስምሪቶቻችን ይህን የአሠራር መስፋፋት ለመቀነስ Habitatን ራሱን የቻለ አገልግሎት ለማድረግ ወሰንን።

የማከማቻ አመክንዮውን ወደ ራሱን የቻለ አገልግሎት በመለየት፣ ለስምሪት፣ ለታዛቢነትና ለመድረክ ማሻሻያዎች አንድ የቁጥጥር ነጥብ አቋቋምን። የተበታተኑ ዝማኔዎችን ከማስተዳደር ይልቅ፣ ማሻሻያዎችን በማዕከል ተግባራዊ በማድረግ ለእያንዳንዱ የOpenAI ምርት ፈጣን ጥቅም መስጠት ቻልን።

ማዕከላዊ አገልግሎት እጅግ ጠንካራ የውሂብ ደህንነትና ግላዊነት መሠረቶችን የምናቀርብበት አንድ የቁጥጥር ነጥብም ይሰጠናል። የHabitat አገልግሎት የመዳረሻ ቁጥጥር ፖሊሲዎችን በማዕከል የምናስፈጽምበት፣ የኦዲት ምዝገባ የምናደርግበትና እንደ Azure Cosmos DB ያሉ መሠረታዊ የማከማቻ ሀብቶችን መዳረሻ የምንገድብበት ነው። Habitat የተጠቃሚ ውሂብን በመጠበቅና ከውጭ፣ ከውስጥና ከወኪል አካላት ያልተፈቀደ መዳረሻን በመከላከል ወሳኝ ሚና ይጫወታል።

አገልግሎት እንደሚያስፈልገን እናውቅ ነበር፤ ሆኖም Python እንደ አገልግሎት ተጨማሪ ወጪ ቢኖረውም ገና ከPython መውጣት አልፈለግንም። Pythonን ለከፍተኛ የማስተላለፊያ ዘዴ አገልግሎት መጠቀም፣ ከአካባቢያዊ የቤተ-መጻሕፍት አፈጻጸም ጋር ሲነጻጸር የአውታረ መረብ መዘግየትንና የCPU እና የማህደረ ትውስታ ማስፋፊያ ወጪን በእጅጉ ጨመረ። በተጨማሪም የPython ብቃት ማነስ በ100 እጥፍ ስፋት ተቀባይነት እንደማይኖረው ተገንዝበን ነበር፤ ስለዚህ ወደፊት እንደገና መጻፍ የማይቀር ነበር።

ሆኖም ይህንን ሆን ተብሎ እንደተወሰደ የቴክኒክ ዕዳ ተመለከትነው። በዚያን ጊዜ ዋና ዓላማችን ወጪን ወይም ሀብትን ማመቻቸት ሳይሆን፣ የምርት ገንቢዎችን እንቅፋት ማስወገድና የመድረኩን መረጋጋት ማሳካት ነበር። የPython አገልግሎትን የአጭር ጊዜ የአፈጻጸም መስዋዕትነት በመቀበል፣ ይበልጥ አስቸኳይ ለሆኑ ፈተናዎች ቅድሚያ መስጠት፣ ዋና APIዎቻችንን ማቋቋምና ጠንካራ መሠረተ ልማት መገንባት ቻልን።

የራሳችን የኮድ ሞዴሎች ፈጣን እድገት የወደፊቱን ቴክኒካዊ መንገድ እንደሚያቀልልም በስሌት የተደገፈ ውርርድ አደረግን። ከPython ሙሉ በሙሉ መሰደድ በሚያስፈልግበት ጊዜ Codex እና GPT ፍልሰቱን እንዲቻል ያደርጉታል ብለን ተወራረድን። ውርርዱም በመጨረሻ ትክክል ሆነ።

Habitatን እንደ Python አገልግሎት ማስኬድ ከአፈጻጸም አንጻር ምርጥ ባይሆንም አስፈላጊ ምርጫ ነበር። Python በፍጥነት እንድንንቀሳቀስ ያስችለናል፤ ይህ ግን ጥንቃቄን ትተን በእጅጉ የከፋ መዘግየትን እንድንቀበል አይፈቅድልንም። አንድ አማካይ የተጠቃሚ ጥያቄ በመቶዎች የውሂብ ጎታ ጥሪዎችን ሲያስከትል፣ ተጠቃሚው የሚሰማው ከሁሉ የዘገየውን ጥሪ ነው። በዚህ ስፋት የPython አገልግሎትን ለማስኬድ ዋናው ፈተና እነዚህን የጭራ መዘግየቶች መቆጣጠር መሆኑን አግኝተናል።

Asyncio Python በI/O ላይ የተመሠረቱ የሥራ ጫናዎችን በአንድ ጊዜ እንዲያከናውን ይረዳዋል፤ ነገር ግን የPython GILን በማለፍ የCPU ትይዩነትን አያቀርብም። Habitat ብዙ I/O የሚጠቀም የጥያቄ ውክልናን ጨምሮ፣ ብዙ CPU የሚጠቀሙ ኃላፊነቶችንና የጀርባ ተግባራትን ያስተናግዳል፦ ማዞሪያ፣ መጭመቅ፣ ምስጠራ፣ የማረጋገጫ ድምር፣ የታችኛው ስርዓት ጤና ፍተሻ፣ የጥያቄ ጥላ ቅጂ እና የተጠባባቂ ጥያቄ።

በአገልግሎታችን ውስጥ ብዙ CPU የሚጠቀሙ የሥራ ጫናዎችና የጀርባ ተግባራት ስላሉ፣ የasyncio መርሐግብር መዘግየት የጭራ ጥያቄ መዘግየትን በቀላሉ ሊቆጣጠር ይችላል። የመጀመሪያውን አገልግሎት ከማስጀመራችን በፊት ስናስተካክል፣ p99 እና ከዚያ በላይ መዘግየት ባላቸው ጥያቄዎች ዱካ ላይ የታችኛው ማከማቻ በፍጥነት ቢመልስም፣ ምላሹን ለመተንተን ኃላፊው coroutine እንደገና መርሐግብር እስኪያዝለት ጥያቄዎች ብዙ ጊዜ ቆመው እንደሚጠብቁ አየን።

በOpenAI የPython አገልግሎቶች ላይ፣ የማህደረ ትውስታ፣ CPU፣ አውታረ መረብና ዲስክ አጠቃቀምን የተለመዱ የአጠቃቀምና ሙሌት መለኪያዎች ከመለካት በተጨማሪ፣ የasyncio loopንና ምን ያህል ሥራ እንዳለበት መከታተል እና በዚያው መሠረት ማስተካከል ወሳኝ ነው።

የጀርባ ተግባራትን በየጊዜው መርሐግብር በመያዝና በታሰበውና በትክክለኛው የአፈጻጸም ጊዜ መካከል ያለውን ልዩነት በመመዝገብ፣ የevent loop መርሐግብር መዘግየትን በቅጽበት በተግባር መለካት እንችላለን። አጠቃቀሙ ከፍተኛ ሲሆንና ብዙ ውድ ተግባራት ሲኖሩ፣ በእያንዳንዱ ሂደት መጠነኛ ቁጥር ያላቸው ተጓዳኝ ጥያቄዎች እንኳ እስከ መቶዎች ሚሊሰከንድ፣ በአንዳንድ ልዩ ሁኔታዎችም በርካታ ሰከንዶች የሚደርስ ከፍተኛ የመርሐግብር መዋዠቅ ይፈጥራሉ።

በዚህም ምክንያት እያንዳንዱ ሂደት ጥቂት ተጓዳኝ ጥያቄዎችን ብቻ እንዲያገለግል እናደርጋለን፤ በምትኩም የPython worker ሂደቶችን በእጅጉ እናሰፋለን።

የመጀመሪያውን አገልግሎት ስናስጀምር፣ ቀጥታ የCPU መገለጫ ትንተና በማድረግ የከፍተኛ asyncio መዘግየትና የጭራ መዘግየት አንዱን ዋና መንስኤ አገኘን፦ በStatsig—የባህሪ ጠቋሚዎችን የሚያስተዳድርና ለA/B ሙከራዎች የሚያገለግል መሣሪያ—በኩል የባህሪ ጠቋሚ ውቅሮቻችንን JSON በየጊዜው መተንተን።

በነባሪነት Statsig ምንም መዋዠቅ ሳይኖረው በየደቂቃው የታደሱ ውቅሮችን እንዲፈትሽ ተዋቅሮ ነበር፤ ውቅሩም በሁሉም አገልግሎቶች ያሉ ሁሉንም የምርት ደንቦች ይዟል። በሌላ ቦታ፣ የCPU አጠቃቀምን ለመጨመርና መዘግየትን ለመቀነስ በእያንዳንዱ pod እስከ 8 የPython ሂደቶችን ለማስኬድ የሕንጻ ንድፍ ውሳኔ ተወስኖ ነበር። እነዚህ ሁለቱ ሲጣመሩ፣ በየደቂቃው በእያንዳንዱ pod ውስጥ ሁሉም workers በሂደት ላይ ያሉ ጥያቄዎችን ማስኬድ አቁመው የCPU ዑደታቸውን ግዙፉን የውቅር ፋይል በመተንተን ላይ የሚያሳልፉበት ጊዜ ነበር።

የCPU መገለጫ ትንተናው ዋናውን መንስኤ ካሳየን በኋላ መፍትሔው ቀላል ነበር፦ አነስ ያለና የታለመ ውቅር ማሰማራት፣ የማደሻ ክፍተቱን ማራዘም እና እንደነዚህ ባሉ የጀርባ ተግባራት ላይ መዋዠቅ መጨመር።

ዝቅተኛ የasyncio መዘግየትን ለመጠበቅ፣ ጥያቄዎችን በአገልጋይ ሂደቶች መካከል በጥሩ ሁኔታ ማመጣጠንም ወሳኝ ነው፤ የግንኙነት ስብስብ ካልተስተካከለ ይህን ዓላማ ሊቃረን ይችላል።

በደንበኛ-ወገን የግንኙነት ስብስብ፣ ብዙ ተጓዳኝ ጥያቄዎችን የሚያቀርብ አንድ የደንበኛ ሂደት ጥቂት የአገልጋይ ግንኙነቶችን ብቻ ሊመሠርትና በውጤቱም ሁሉንም ጫናውን ወደ ጥቂት ሂደቶች ብቻ ሊልክ ይችላል። የጫና ማመጣጠኛ ዘዴያችንን ከማስተካከላችን በፊት፣ የአገልግሎታችን አጠቃቀም በእጅጉ ይለያይ ነበር፤ አንዳንድ የጭራ ሂደቶች ከአማካዩ 5–10 እጥፍ ተጨማሪ ተጓዳኝ ጥያቄዎችን ያገለግሉ ነበር።

ይህን ያገኘነው የአገልግሎታችንን አንድ ክፍል ከመጠን በላይ የጫነውን ደንበኛ ብናቆምም፣ ከድንገተኛው ትራፊክ በኋላ አንዳንድ ሂደቶች ለረጅም ጊዜ ተጎድተው በቆዩበት ድንገተኛ ክስተት ነበር። እንዲያውም እነዚያ ሂደቶች እንደገና እስክናስጀምራቸው ድረስ እየጨመሩ የሚሄዱ ጥያቄዎችን በመቀበል ከቁጥጥር ውጭ እየተበላሹ መሆናቸውን አየን። አንድ pod ከመጠን በላይ ከተጫነ በኋላ፣ አንድ ባህሪ ተጨማሪ ትራፊክን በዚያው pod ላይ እንዲቆይ ያደርግ ነበር። ይህ አንዳንድ ባልደረቦቻችን ከቀድሞ ሥራቸው በደንብ የሚያውቁት የውድቀት ዓይነት ነበር፦ metastable ውድቀት⁠(በአዲስ መስኮት ውስጥ ይክፈታል)።

ተጠያቂው የግንኙነት ስብስቡ እንደሆነ ጠረጠርን፤ ከፍተኛውን የግንኙነት ዳግም አጠቃቀም ጊዜ በመገደብም ፈተንነው። ይህም መበላሸቱን በእርግጥ ገድቦ የምርመራችንን አቅጣጫ አረጋገጠ። ተጨማሪ ምርመራ የPython aiohttp TCPConnector በነባሪነት የLIFO ግንኙነት ዳግም አጠቃቀምን እንደሚጠቀም አሳየ፦ በቅርብ ጊዜ የተመለሰው ግንኙነት ለቀጣዩ ጥያቄ ይመረጣል። ይህ በተለምዶ ምክንያታዊ ነባሪ ነው፦ የቅርብ ጊዜ ግንኙነቶችን እንደገና መጠቀም፣ ድንገተኛ ትራፊክን ለመቆጣጠር የተፈጠሩት ተጨማሪ ግንኙነቶች ሥራ ፈት ሆነው ጊዜያቸው እንዲያልቅ ያስችላል፤ በዚህም ተጨማሪ ግንኙነቶችን የመጠበቅ ወጪ ይቀንሳል። በዚህ ሁኔታ ግን metastable ውድቀት ፈጠረብን። በድንገተኛ የጥያቄ ጫና ወቅት፣ ወደ ዘገዩና ከመጠን በላይ ወደተጫኑ አገልጋዮች የተላኩ ጥያቄዎች ግንኙነቶቹን ወደ ስብስቡ ዘግይተው ይመልሱ ነበር፤ በመሆኑም ተከታይ ጥያቄዎች በብዛት ይመርጧቸውና ተጨማሪ ትራፊክን አስቀድመው በተቸገሩት pods ላይ ቀስ በቀስ ያከማቹ ነበር። የግንኙነት ስብስቡ FIFO ዳግም አጠቃቀምን እንዲጠቀም ማስተካከላችን ይህን የግብረመልስ ዑደት አቋርጦ፣ በተረጋጋ ሁኔታ ያለውን የጥያቄ ልዩነትም ቀንሷል።

ዛሬ በአብዛኛው Istio እና Envoy በመላው የOpenAI መሠረተ ልማት የግንኙነት ስብስብንና የአገልጋይን ጫና ይበልጥ ያገናዘቡ የማመጣጠኛ ስልቶችን እንዲያቀርቡልን እንመካባቸዋለን፤ በዚህም ችግሩን ሙሉ በሙሉ እናስወግዳለን።

ለዝቅተኛ asyncio መዘግየት ማስተካከልና ብዙ የPython ሂደቶች መኖራቸው ከሚያስከትሉት ጎንዮሽ ውጤቶች አንዱ፣ በግዙፉ የግንኙነት ብዛት—«thundering herd» በመባል የሚታወቀው—የታችኛውን ጥገኞች በቀላሉ ማጨናነቅ ነው።

የተለመደ ዕለታዊ ስምሪት በዝግታ እንዲካሄድ ካልተስተካከለ፣ ግንኙነቶችን በተደጋጋሚ በመቀየር ከፍተኛ የCPU መዋዠቅ ሊያስከትል ይችላል። ወይም የግንኙነት ፍሳሽ NAT gatewayን በማጨናነቅ አውታረ መረቡን ሊያቋርጥ ይችላል። እነዚህ ለሌሎች አገልግሎቶችም ያልተለመዱ ችግሮች አይደሉም፤ ነገር ግን በደረጃ ብዙ ሂደቶች መኖራቸው ችግሩን የሚቀሰቅሰውን ገደብ በእጅጉ ያወርደዋል። ይህም ደንበኞች በየማስተላለፊያ ዘዴው ብቻ በመመርኮዝ በተረጋጋ ሁኔታ ለመቆጣጠር የማይጠብቋቸውን ከአውታረ መረብ ጋር የተያያዙ ሀብቶች ብዙ ጊዜ ያጨናንቃል።

ግንኙነቶችን ማሰባሰብን ከፍተኛ ለማድረግም Envoy ላይ እንመካለን። multiplexingን ለመጠቀም የPython HTTP/1 ግንኙነቶችን ወደ HTTP/2 ለማሻሻል፣ ከዚያም ግንኙነቶቹን ለመሰብሰብና የሕይወት ጊዜያቸውን ለማራዘም Envoyን እንጠቀማለን። Envoy በእያንዳንዱ ራሱን የቻለ የPython ሂደት ውስጥ ብዙም ውጤታማ የማይሆኑ የፍጥነት ገደቦችንና circuit breakersን የምንተገብርበት ማዕከላዊ ቦታም ይሰጠናል።

Pythonን እስከዚህ ድረስ ማስፋፋት የቻልንበት አንዱ ምክንያት የጥያቄ ወጪን ሊገመት የሚችል ያደረገው የHabitat የተገደበ API ነው። ደንበኞች ሰፊ የሰንጠረዥ ቅኝትን ወይም ብዙ ሰንጠረዦችን ማገናኘትን ሊያስከትሉ የሚችሉ ማናቸውንም የSQL ጥያቄዎች እንዲገነቡ ከመፍቀድ ይልቅ፣ Habitat ቀላል NoSQL API ያቀርባል። ኃይለኛ API አለመኖሩ በHabitat ንድፍ ውስጥ በግልጽ የተመረጠ መስዋዕትነት ነው።

ቀላል፣ ሊገመቱ የሚችሉና ቋሚ ሥራ የሚጠይቁ ጥያቄዎችን ለማመቻቸት እንጥራለን። ከልምዳችን አንጻር እነዚህ ስርዓቶች ለማስፋፋት እጅግ ቀላል ሲሆኑ፣ በስህተት ለመጠቀምም አስቸጋሪ ናቸው። ሊገመት የማይችል fanout ያላቸው ጥያቄዎች በሥራ አፈጻጸም አደገኛ ናቸው፦ መነጠልንና የጫና ሚዛንን ያወሳስባሉ፤ ለአገልግሎቱም ሆነ ለደንበኞቹ ለማስፋፋት አስቸጋሪ የሆኑ ድንገተኛ የመዘግየት ጭማሪዎችንም ያመጣሉ።

ወደ Habitat እና Azure Cosmos DB ከመሸጋገራችን በፊት፣ አብዛኛው የOpenAI የመስመር ላይ ውሂብ በPostgres ላይ ይከማች ነበር። በዚያን ጊዜ ሁሉም የጥያቄና የእቅድ ማውጣት ለውጦች በትክክል እንደሚሠሩና ወደ ምርት ከመላካቸው በፊት በመረጃ ጠቋሚ በተደራጀ ውሂብ ላይ እንደሚሠሩ መገምገም ቀላል ነበር። ቡድኑና ምርቶቹ ሲያድጉ ይህ በፍጥነት ሊተዳደር የማይችል ሆነ፤ በወሳኝ መንገድ ላይ ያለ አንድ አዲስ ውድ ጥያቄ የውሂብ ጎታውን በማቋረጡም ተደጋጋሚ የአገልግሎት መቋረጥ ምክንያት ሆነ።

ችግሩ የወጪ አለመመጣጠን ነው፦ ለማስኬድ ውድና አስቸጋሪ የሆኑ SQL ጥያቄዎችን መጻፍ ርካሽና ቀላል ነው። በHabitat ውስጥ ይህን እናስወግዳለን፤ ውድ ጥያቄዎችም በደንበኛው በኩል እጅግ ግልጽ እንዲሆኑ እናደርጋለን። Habitatን ሊያጨናንቁ የሚችሉ ወሰን የሌላቸው ጥያቄዎች የሉም፤ ውስብስብ joins እና የግራፍ አሰሳዎችም የምርት ቡድኖች ከባዱን ሥራ እንዲሠሩ ይጠይቃሉ፣ ይህም በአጠቃላይ ይበልጥ ቀልጣፋ ንድፎችን ለማመቻቸት ይረዳል።

Habitat በደንበኛ በሚወሰኑ የነገርና የጠርዝ ዓይነቶች ዙሪያ የተቀረጸ፣ በTAO⁠(በአዲስ መስኮት ውስጥ ይክፈታል) የተነሳሳ NoSQL API ያቀርባል። ደንበኞች ነገሮችን፣ ጠርዞችንና እርስ በርሳቸው ያላቸውን ግንኙነት አስቀድመው ይወስናሉ፤ የእያንዳንዱን ዓይነት ይዘት ግን አይወስኑም። የሚፈጠሩት ግንኙነቶች ግራፍን ይመስላሉ፤ ነገር ግን Habitat የአንድን የተወሰነ ነገር ቀጥተኛ ጠርዞች ከመጠየቅ ውጭ የተለመዱ የግራፍ አሰሳ ጥያቄዎችን አይደግፍም።

እያንዳንዱ ነገርና ተዛማጅ ጠርዞቹ በማከማቻ ደረጃ ክፍል ውስጥ አብረው እንዲቀመጡ ይህን ግራፍ እንከፋፍለዋለን፤ ነገር ግን ነገሮችንና ጠርዞቻቸው የሚያመለክቷቸውን ሩቅ ነገሮች አብረው ለማስቀመጥ በውሂብ ጎታ ደረጃ የተቀናጀ ጥረት አናደርግም። በዚህም ምክንያት ሞዴሉ ለአግድም ማስፋፋት በቀላሉ ይከፋፈላል፤ ሆኖም በነገሮች መካከል ያለ ማንኛውም ዝላይ በተለያዩ ክልሎች ከተቀመጡ ሁለት ፈጽሞ የተለያዩ Azure Cosmos DB መለያዎች ማምጣትን ሊጠይቅ ስለሚችል የግራፍ አሰሳዎች ቀልጣፋ አይደሉም።

ይበልጥ ውስብስብ የጥያቄ ፍላጎት ላላቸው ደንበኞች፣ በRockset በኩል የሚቀርብ ከመስመር ውጭ ሁለተኛ የHabitat እይታ እናቀርባለን። ለውጦችን ከመስመር ላይ ማከማቻ ወደ ተነጠሉ የRockset አጋጣሚዎች በቅጽበት በሚቀርብ ፍጥነት ለመልቀቅ የለውጥ ውሂብ ቀረጻን (CDC) እንጠቀማለን። እያንዳንዱ የደንበኛ ቡድን ለውስብስብ የጥያቄ ፍላጎቱ የራሱን Rockset አጋጣሚ የማስፋፋት ኃላፊነት አለበት።

ይህ የRockset አቅርቦት ለደንበኞቻችን ተጨማሪ ውስብስብነት ይፈጥራል፤ ሆኖም በዚህ ጊዜ ትክክለኛው መስዋዕትነት ነው ብለን እናምናለን፦ ቀላል ጥያቄዎችን ነባሪ ማድረግ፣ ውስብስብ ጥያቄዎች ለሚያስፈልጓቸውም አማራጭ መውጫ መስጠት። ይህ ንድፍ የመስመር ላይ ማከማቻችንን ከንባብ ከበዳቸው የትንታኔና የፍለጋ የሥራ ጫናዎች ይነጥለዋል።

Pythonን እንደገና መጻፍን ለአንድ ዓመት ማዘግየታችን፣ በከፍተኛ እድገታችን ወቅት ይበልጥ አስቸኳይና ተጽዕኖ ባላቸው ፈተናዎች ላይ እንድናተኩር አስችሎናል። መድረኩ እየበሰለና እድገታችን ይበልጥ እየተፋጠነ ሲሄድ፣ በOpenAI በCPU core ብዛት ሁለተኛው ትልቁ አገልግሎት ከሆንን በኋላ—በEnvoy አሻራችን ደግሞ አራተኛ—በመጨረሻ ከPython የምንሻገርበት ጊዜ ደረሰ። Python በከፍተኛው ወቅት በየሰከንዱ ከ20 ሚሊዮን በላይ ጥያቄዎችን እንድናገለግል ረድቶናል።

በ2026 ሁለተኛ ሩብ፣ በ2 መሐንዲሶች፣ Codex እና GPT‑5.5 ብቻ አጠቃላይ አገልግሎቱን በRust እንደገና መጻፍ ቻልን። አዲሱ የRust አገልግሎት አሁን 95% የምርት ጥያቄዎቻችንን እያስተናገደ ነው፤ በሚቀጥሉት ሳምንታት Pythonን ሙሉ በሙሉ ከአገልግሎት እናስወግዳለን። ውሂባችን የRust አገልግሎቱ ከPython ስሪት በCPU 6 እጥፍ፣ በማህደረ ትውስታ 15 እጥፍ ይበልጥ ቀልጣፋ መሆኑንና አማካይና የጭራ መዘግየቱም በእጅጉ ዝቅተኛ መሆኑን ያሳያል። ወደፊት በሚወጣ የጦማር ጽሑፍ ተጨማሪ ትምህርቶችን ለማጋራት አቅደናል።

የPython—እና አሁን የRust—አገልግሎት የHabitat አንድ ገጽታ ብቻ ነው። ከ1 ቢሊዮን በላይ የChatGPT ተጠቃሚዎችን ለማገልገል የመስመር ላይ ማከማቻችንን እንዴት በፍጥነት እንዳስፋፋን በሚያብራራው የዚህ ተከታታይ ክፍል II፣ ስለ ማከማቻ ንብርብሩና Habitat ከ500 ፔታባይት በላይ ውሂብንና በየሰከንዱ ከ70 ሚሊዮን በላይ ጥያቄዎችን እንዴት እንደሚያገለግል እንነጋገራለን።

በግንባር ቀደም ስፋት ባሉ OLTP ስርዓቶች ላይ መሥራት ከፈለጉና የዚህ ዓይነት ምሕንድስና ፍላጎት ካለዎት፣ በቡድናችን ያለውን ክፍት የሥራ ቦታ ይመልከቱ⁠።