ከ1 ቢሊዮን በላይ የChatGPT ተጠቃሚዎችን ለማገልገል የመስመር ላይ ማከማቻን በፍጥነት ማሳደግ (ክፍል II)

ሁሉም የOpenAI ምርቶች ውሂብን በፍጥነትና በአስተማማኝ ሁኔታ ማግኘት ይፈልጋሉ፤ ይህንንም የሚያቀርበው Habitat የተባለው የማከማቻ መድረካችን ነው። በ40 ጂኦግራፊያዊ ክልሎች ላሉ ከ1 ቢሊዮን በላይ ተጠቃሚዎች በሚሊሰከንዶች ውስጥ ምላሽ መስጠት አለበት። መሠረተ ልማታችን ያልተለመደ ፈተና ገጥሞት ነበር፦ አስተማማኝነትን፣ አፈጻጸምንና የምርት ገንቢዎችን የሥራ ፍጥነት ማሻሻልን እየቀጠለ፣ ፍንዳታ የመሰለ እድገትንና አዲስ አጠቃቀሞችን ማስተናገድ። ይህን ፈተና ለመፍታት፣ የመስመር ላይ ማከማቻ መድረካችንን የንድፍና የአሠራር መንገድ እንደገና ማጤን አስፈለገ። የአማራጮችን ጥቅምና ጉዳት ያለማቋረጥ እንመዝን ነበር። የተከተልነው ቅደም ተከተልም፦ መጀመሪያ ወሳኝ የምርት ትራፊክን ለማስተናገድ በቂ አስተማማኝነት ማግኘት፣ ከዚያ ለዓለም አቀፍ ተጠቃሚዎች በቂ ፍጥነት ማሳካት፣ በመጨረሻም በእጅግ ሰፊ መጠን በብቃት መሥራት ነበር።

ይህ ባለሁለት ክፍል ተከታታይ ጽሑፍ፣ Habitatን ከቀላል የደንበኛ ላይብረሪና የውሂብ ጎታ ወደ በዓለም ዙሪያ የተሰራጨ፣ ከ500 ፔታባይት በላይ ውሂብ የሚያቀርብ የማከማቻ መድረክ እንዴት እንዳሳደግነው ያብራራል። ክፍል I Habitat ከPython ደንበኛ ፕሮግራም ወደ አገልግሎት ባደረገው ለውጥ ላይ አተኩሯል። እንዲሁም በPython የተገነባ አገልግሎትን ብዙዎች በተግባር ይቻላል ብለው ከሚያስቡት በእጅጉ በላይ እንድናሳድግ ያስቻሉንን ዘዴዎች አብራርቷል።

በዚህ በክፍል II ጽሑፍ፣ የመሠረታዊ ማከማቻውን ክፍል፣ Azure Cosmos DBን፣ እንዴት እንዳሳደግነው እናብራራለን። ከAzure ቡድን ጋር በቅርብ በመሥራት፣ በጋራ በሚተዳደሩ ኮንቴይነሮች ላይ የተመሠረተ ተግባራዊ የብዙ ተከራዮች አጠቃቀም አቀራረብ አገኘን። ይህም በእጅግ ሰፊ ዓለም አቀፍ ደረጃ እጅግ ጥሩ የንባብ አፈጻጸም ይሰጣል።

ኩባንያዎች ሲያድጉ፣ የመሠረተ ልማት ቡድኖች ብዙ ጊዜ የአንድ ተከራይ ስርዓቶችን ከማስኬድ ወደ የብዙ ተከራዮች ስርዓቶች ይሸጋገራሉ። እያንዳንዱ የምርት ክፍል ቡድን የራሱን ስርዓት በሚያስተዳድርበት የአንድ ተከራይ አጠቃቀም፣ የብልሽት ተጽእኖ ወሰን ይቀንሳል፣ የኃላፊነት ወሰኖችን መለየትና የሥራ ጫናዎችን ማግለልም ቀላል ይሆናል። ቡድኖችና የምርት ክፍሎች ሲበዙ ግን፣ ይህን ማስኬድ ውድ ይሆናል። የአንድ ተከራይ አጠቃቀም እያንዳንዱን የምርት ቡድን የአቅም እቅድ ኃላፊ ያደርገዋል፤ ብዙ ጊዜም ከሚያስፈልገው እጅግ የበለጠ አቅም እንዲመደብ ያደርጋል።

በአንጻሩ፣ የብዙ ተከራዮች አጠቃቀም ቁጥጥሩን ለአንድ ማዕከላዊ የውሂብ ጎታ ቡድን ይሰጣል፤ ይህ ቡድንም ሀብት በመመደብ የተሻለ እውቀትና ልምድ አለው። ነገር ግን የብዙ ተከራዮች አጠቃቀም የራሱን ችግሮች ይፈጥራል። አንዱ የጎረቤት ጫና ችግር ሲሆን፣ አንድ ተከራይ ያልተለመደ ከፍተኛ የሀብት ድርሻ በመጠቀም ሌሎችን ይጎዳል።

በHabitat ውስጥ፣ በስፋት የሚሠራ አስተማማኝና ቀልጣፋ የማከማቻ ስርዓት ለመንደፍ የእነዚህን ሁሉ አማራጮች ጥቅምና ጉዳት መመዘን ነበረብን። ዛሬ Habitat ለብዙ የOpenAI ምርቶች የብዙ ተከራዮች የውሂብ ጎታ ንብርብር ነው። ግን ወደዚህ የደረስነው ተመልሶ በሚዞር ጉዞ ነበር፦ መጀመሪያ አንድ የብዙ ተከራዮች የAzure Cosmos DB ኮንቴይነር ተጠቀምን፣ ከዚያ ለእያንዳንዱ ተከራይ የተለዩ መሠረታዊ ኮንቴይነሮችን መደብን፣ በመጨረሻም ወደ የብዙ ተከራዮች ኮንቴይነር እንደ ነባሪ ምርጫ ተመለስን። በHabitat ውስጥ የብዙ ተከራዮች አጠቃቀም ጉዟችን አሁንም ገና በመጀመሪያው ላይ ነው። ብዙ ዓይነት አጠቃቀሞችን ብንደግፍም፣ በተቻለ ቦታ አብረው የተገነቡትን የAzure Cosmos DB መሠረታዊ ተግባራት በመጠቀም በዚህ መስክ የምናደርገውን ኢንቨስትመንት ማዘግየት ችለናል።

የAzure Cosmos DB ጉዟችንን ከማብራራታችን በፊት፣ ጥቂት መሠረታዊ መረጃዎች፦

• አንድ የAzure Cosmos DB መለያ የኮንቴይነሮችን ስብስብና የውሂብ ማባዛት ፖሊሲ ይወስናል

• ለእያንዳንዱ ኮንቴይነር፣ በሰከንድ በጥያቄ አሃዶች (RU/s) የሚለካ የተወሰነ የማስተላለፊያ ዘዴ አቅም ይመደባል

• በእያንዳንዱ ኮንቴይነር ውስጥ ያለ ውሂብ፣ በተወሰነ ሎጂካዊ ክፍል ቁልፍ መሠረት ተከፋፍሎ በተለመደው መንገድ ይከማቻል፤ ለእያንዳንዱ ሎጂካዊ ክፍል ቁልፍም በሰነድ የተገለጹ የማከማቻና የማስተላለፊያ ዘዴ ገደቦች አሉ

• Azure Cosmos DB የሎጂካዊ ክፍል ቁልፎችን ከእነሱ ባነሱ መሠረታዊ አካላዊ ክፍሎች ላይ ይከፋፍላል። የተከማቸው ውሂብ የተወሰነ ወሰን ሲያልፍ፣ ወይም ኮንቴይነሩ የተመደበለትን የማስተላለፊያ ዘዴ አቅም ለማስቀጠል ተጨማሪ አካላዊ ክፍሎች ሲያስፈልጉት፣ እነዚህን ወደ ብዙ አካላዊ ክፍሎች ይከፍላቸዋል

መጀመሪያ ማንኛውንም የደንበኛ ጫና እንዲያልፍ እንፈቅድ ነበር። ጫናውን ወደ ላኪው መልሶ ለመገደብም፣ ለእያንዳንዱ ሎጂካዊ ክፍል ቁልፍ በተገለጸው የ10 ሺህ RU/s ገደብ እንተማመን ነበር። በመጀመሪያ ስንነሳም፣ በእያንዳንዱ መለያ ውስጥ አንድ ነባሪ የAzure Cosmos DB ኮንቴይነር ብቻ እንጠቀም ነበር። ይህ በአጥጋቢ ሁኔታ ቢሠራም፣ በጥቂት ምክንያቶች ችግር እንዳለበት ታየ፦

በመጀመሪያ ባደረግናቸው የAPI ምርጫዎች ምክንያት፣ የሎጂካዊ ክፍል ቁልፍን በቀጥታ ለመምረጥ ለደንበኞች ፈቀድን። በዚህም ምክንያት፣ በተለያዩ የምርት አጠቃቀሞች መካከል እንደ user_id ወይም workspace_id ያሉ በብዛት የሚጠቀሙባቸው የክፍል ቁልፎች ብዙ ጊዜ ይጋጫሉ። እነዚህ አጠቃቀሞች በተመሳሳይ ሎጂካዊ ክፍል ቁልፎች ላይ ያሉትን የAzure Cosmos DB ገደቦች ስለሚጋሩ፣ ንድፉ ለአንድ ተጠቃሚ ያለውን አጠቃላይ የማስተላለፊያ ዘዴ አቅም ገደበ።

ወደ Habitat እና Azure Cosmos DB ከመዛወራችን በፊት Postgresን ስናሳድግ ከገጠሙን የተለመዱ ችግሮች አንዱ፣ ከፍተኛ ጥያቄ ካለበት ድርጅት ወይም ቁልፍ የሚመጡ ብዙ ጥያቄዎች መላውን የውሂብ ጎታ ሊያቋርጡ መቻላቸው ነበር። ይህም አንድ ተከራይ ከሌሎች እጅግ የበለጠ ጫና ሲፈጥር ይከሰታል። እነዚያን ቁልፎች በካሽ ለማስቀመጥና ውሂብ በካሽ ሳይገኝ ሲቀር ጊዜያዊ የመዳረሻ ፈቃዶችን ለመጠቀም ከፍተኛ የጋራ ጥረት ተደርጓል። ዓላማውም ውሂብ በካሽ ባለመገኘቱ የሚመጣው ጫና መሠረታዊውን የውሂብ ጎታ እንዳያጨናንቀው ማድረግ ነበር።

በሰነድ የተገለጹት የውሂብ መጠንና የማስተላለፊያ ዘዴ ገደቦች ለሎጂካዊ ክፍል ቁልፎች ቢሆኑም፣ ገደቦቹ በተግባር የሚተገበሩት በአካላዊ ክፍሉ ላይ ነው። በተግባር ይህ ማለት ሎጂካዊ ክፍሎች 10,000 RU/s መድረስ አይችሉም ማለት ነው። ይልቁንም በዚያው አካላዊ ክፍል ከሚገኙ ሌሎች ሎጂካዊ ክፍል ቁልፎች ሁሉ ጋር የአካላዊ ክፍሉን ገደብ ይጋራሉ።

ይህ ከፍተኛ ጫና የሚፈጥሩ ጎረቤቶች ግንኙነት የሌላቸውን ብዙ ሎጂካዊ ክፍል ቁልፎች እንዲጎዱ አደረገ። ለጥቂት ተጠቃሚዎች የተዘጋጁ የምርት ባህሪያትን ውሂብ የሚያስተናግዱ የሥራ ጫናዎች መሠረታዊ የመግባትና የመመዝገብ ሂደቶችን ያውኩ ነበር።

የአንድ አካላዊ ክፍል የማስተላለፊያ ዘዴ ገደብም ተለዋዋጭ ነው፤ ለAzure Cosmos DB ኮንቴይነሩ በተመደበው ጠቅላላ የማስተላለፊያ ዘዴ አቅም ላይ ይወሰናል። ለኮንቴይነሩ የተመደበው የማስተላለፊያ ዘዴ አቅም በውስጡ ላሉት አካላዊ ክፍሎች በግምት እኩል ይከፋፈላል።

የውሂብ መጠኑ ሲያድግ አካላዊ ክፍሎች ይከፈላሉ። በዚህም ጠቅላላ የክፍሎች ብዛት ይጨምራል፣ የተመደበው ጠቅላላ የማስተላለፊያ ዘዴ አቅም ግን አይለወጥም። ውጤቱም የውሂብ መጠኑ ሲያድግ፣ እያንዳንዱ ክፍል በተግባር የሚያገኘው የማስተላለፊያ ዘዴ ገደብ መቀነሱ ነው።

እንደ blob ላሉትና እጅግ ብዙ ማከማቻ ለሚፈልጉ አጠቃቀሞቻችን፣ ይህ ልዩ የብልሽት ሁኔታ ይፈጥራል፦ የጥያቄ መጠንና አጠቃቀም ሳይለወጡ እንኳ፣ የተከማቸው ውሂብ መጨመር ብቻውን ለንቁ የሥራ ጫናዎች ያለውን የማስተላለፊያ ዘዴ አቅም ይቀንሳል።

የተለያዩ ኮንቴይነሮች እነዚህን የክፍል ቁልፍ ገደቦችና የጎረቤቶች ጫና ችግሮች በከፊል ለመፍታት ይረዳሉ። የተለያዩ ኮንቴይነሮችን በመጠቀም፣ ለእያንዳንዱ የራሱን ገለልተኛ አካላዊ ክፍሎች መመደብ ይቻላል። በጋራ ሀብት ላይ ጫና ሊፈጥሩ ወይም ተመሳሳይ የክፍል ቁልፎችን ሊጋሩ የሚችሉትም በዚያው ኮንቴይነር ውስጥ ያሉ የሥራ ጫናዎች ብቻ ይሆናሉ። በሌላ በኩል፣ አዲስ ኮንቴይነሮችን ማዘጋጀት የራሱ ተጨማሪ ሥራ አለው፤ እያንዳንዱ ኮንቴይነር የተለየ የአቅም እቅድ ይፈልጋል። ስለዚህ ኮንቴይነሮችን መፍጠር የምንፈልገው ተገቢ በሆነ የአገልግሎት ወይም የአጠቃቀም ወሰን ላይ ብቻ ነው።

ጠንካራ መለያየት ለሚፈልጉት በጣም ወሳኝ አዲስ አጠቃቀሞች የተለያዩ የAzure Cosmos DB ኮንቴይነሮችን መጠቀም ጀመርን። ይህን ከደካማ ክፍሎች መቆጣጠሪያ ስክሪፕት ጋር በማጣመር፣ ያጋጠሙንን ችግሮች በአብዛኛው ማስቀረት ቻልን። ስክሪፕቱ ለእያንዳንዱ ኮንቴይነር የተመደበውን ጠቅላላ የማስተላለፊያ ዘዴ አቅም ከአካላዊ ክፍሎቹ ብዛት ጋር ያመጣጥናል።

ሆኖም በነባሪ ኮንቴይነር ስለጀመርን፣ ብዙ ነባር ወሳኝ አጠቃቀሞች ውሂባቸው ሳይዛወር ከዚያ መውጣት አልቻሉም። አሁንም በጋራው ነባሪ ኮንቴይነር ውስጥ ባለ ውሂብ የሚመኩ ወሳኝ አገልግሎቶችን ለመጠበቅ፣ ቡድኖች ለአዲስ አገልግሎቶች ወይም ለዋና የምርት ባህሪያት የተለዩ ኮንቴይነሮችን እንዲፈጥሩ ብዙ ጊዜ እንመክር ነበር። እየሰፋን ስንሄድ፣ በነባሪው ኮንቴይነር ላይ ያለው ጫና ጨመረ፤ በቀጥታ አገልግሎት ላይ የሚከሰቱ ችግሮችም በዙ። ነባሪውን ኮንቴይነር ከተጨማሪ ጫና ለመጠበቅ ብቻ፣ ለማንኛውም አዲስ አገልግሎት ወይም ትልቅ የምርት ባህሪ ኮንቴይነሮችን መመደብ ጀመርን።

ይህ መላውን ጣቢያ ከሚያቋርጡ ብዙ ችግሮች አዳነን፤ የጉዳቱንም ወሰን በአንድ ባህሪ ወይም አገልግሎት መዳከምና መቋረጥ ላይ ገደበው። ሆኖም አዲስ ኮንቴይነሮችን የማዘጋጀት ተጨማሪ ጫና በመጨረሻ ችግር ሆነብን፦

በቀድሞው የጋራ ነባሪ ኮንቴይነር ውስጥ፣ አንድ አዲስ አጠቃቀም ከ0 QPS ወደ 1 ሚሊዮን QPS ቢያድግም፣ ጠቅላላ አጠቃቀሙን በከፍተኛ ሁኔታ የመለወጥ እድሉ አነስተኛ ነበር። በተለየ ኮንቴይነር ውስጥ ግን፣ አንድ አዲስ አጠቃቀም ከ0 ወደ 1 ሚሊዮን QPS ማደጉ፣ በውስጥ ሙከራ አጠቃቀም ብቻ ከነበረው መነሻ ጫና 1,000 እጥፍ የበለጠ ጫና ሊሆን ይችላል።

ኮንቴይነሮች ለየቡድኑ ብቻ ሲመደቡ፣ ቡድኖች ምርቶቻቸውን ሲጀምሩ ለሚጠበቀው የማስተላለፊያ ዘዴ ደረጃ አቅም አስቀድመው መመደብን ማስታወስ ነበረባቸው። የምርት ቡድኖች ብዙ ጊዜ ባህሪያቸውን ለተጠቃሚዎች ይለቁና አቅምን አስቀድሞ ማሳደግን ይረሱ ነበር። እኛም በምረቃ ቀን በከባድ ችግር ምላሽ (SEV) ክፍሎች ተቀምጠን የኮንቴይነሮችን አቅም በመጨረሻው ደቂቃ ለማሳደግ እንሞክር ነበር።

የብዙ ተከራዮች ስርዓቶች የተለያዩ የሥራ ጫናዎችን በማቀላቀል የሚያገኙት ዋና ጥቅም ይህ ነው። በዚህ የኮንቴይነር ስልት የተሻለ መለያየትን ለማግኘት ያንን ጥቅም እናጣለን።

ከጊዜ በኋላ፣ ለብቻቸው የተመደቡ ኮንቴይነሮችን አጠቃቀም መከታተልም ትራፊክ መቼ እንደሚቀየር ወይም እንደሚያድግ ጥልቅ የምርት እውቀት መኖርን ጠየቀ።

በእድገት አዝማሚያዎች መሠረት ለእያንዳንዱ ኮንቴይነር የተመደበውን የማስተላለፊያ ዘዴ አቅም የሚያሳድግ ቀላል የቁጥጥር ንብርብር ስክሪፕት ማቅረብ እንችላለን። ነገር ግን የተረጋጋ አጠቃላይ እድገት በሌለበት፣ አቅሙን በትክክል ማሳደግ በOpenAI ውስጥ ሁሉም ማለት ይቻላል የምርት ቡድኖች በአቅም እቅድ እንዲሳተፉ አደረገ።

ይህ አሠራር ከድርጅቱ እድገት ጋር መስፋት አልቻለም። እያንዳንዱ የአገልግሎት ኃላፊ ቡድን ለAzure Cosmos DB አቅም ምደባው የሚሰጠው ጥንቃቄም በእጅጉ ይለያይ ነበር።

ድርጅቱ እያደገ ሲሄድ፣ እነዚያን የአሠራር ችግሮች በሰፊ መጠን ማስተናገድ አስቸጋሪ ሆነ። እቅድ የሚያወጣ አንድ ማዕከላዊ ቡድን አለመኖሩ፣ ብዙ ቡድኖች ደካማ እቅድ እንዲያወጡ አደረገ። በዚህም ምክንያት፣ ወደ የብዙ ተከራዮች መፍትሔ ተመለስን። በጋራ አጠቃቀም ንድፍ የመጀመሪያዎቹን የብዙ ተከራዮች ችግሮቻችንን ለመፍታትም ከAzure ቡድን ጋር በቅርብ ሠራን፦

ከሁሉ የበለጠ ጥያቄ ያለባቸውን ቁልፎች አስቀድሞ መገደብ፣ ጫና ፈጣሪ ጎረቤቶች ለአንድ አካላዊ ክፍል ያለውን የማስተላለፊያ ዘዴ አቅም በሙሉ እንዳይወስዱ ይከላከላል። ይህም አንድ ከፍተኛ ጥያቄ ያለበት ቁልፍ መላውን ጣቢያ ሊጎዳ የሚችልበትን የጎረቤት ጫና ተጽእኖ ይቀንሳል።

ጥያቄዎችን በደረጃ የሚመድብ QoSም በተመሳሳይ ሁኔታ፣ እንደ በጅምላ ውሂብ ማስገባት ወይም ማውጣት ያሉ ከመስመር ውጭ የሥራ ጫናዎች የአንድን አካላዊ ክፍል የማስተላለፊያ ዘዴ አቅም በሙሉ እንዳይጠቀሙ ይከላከላል። የእነዚህን ሥራዎች ጥያቄዎች በዝቅተኛ ቅድሚያ በመመደብ፣ መጀመሪያ የሚገደቡት እነሱ ይሆናሉ። በዚህም የመጨረሻ ተጠቃሚዎችን የሚያገለግሉ ከፍተኛ ቅድሚያ ያላቸው በይነተገናኝ ጥያቄዎች እንዳይገደቡ ይደረጋል።

Azure Cosmos DB በቅድሚያ አቅም በሚመደብበት ሁነታ ያጋጠመንን የደካማ ክፍሎች ችግር ሊፈታ የሚችል አገልጋይ-አልባ ሁነታ አስቀድሞ ነበረው። ሆኖም አንድ ትልቅ ጉዳት ነበረው፦ አቅሙ የሚያድገው በማከማቻ አጠቃቀም ብቻ ነበር፣ የRU አጠቃቀምንም በእያንዳንዱ አካላዊ ክፍል እስከ 5 ሺህ RU/s ይገድብ ነበር። ይህ የደካማ ክፍሎች ችግራችንን ቢፈታም፣ ብዙ RU የሚፈልጉ አጠቃቀሞችን እንዳናሳድግ ያግደን ነበር።

የAzure Cosmos DB ቡድን ለእኛ የገነባው አዲስና የተሻሻለ አገልጋይ-አልባ ሁነታ፣ እያንዳንዱ አካላዊ ክፍል እስከ 10 ሺህ RU/s እንዲያድግ ፈቀደ። በማከማቻ አጠቃቀም ላይ ከተመሠረተው ክፍፍል በተጨማሪም በRU አጠቃቀም ላይ የተመሠረተ ክፍፍል አስተዋወቀ። ይህም ኮንቴይነሮችን በእጅ መከታተልና አቅማቸውን ማሳደግ እንድናቆም አስቻለን።

በእነዚህ ለውጦች፣ ወደ አንድ የጋራ ኮንቴይነር አጠቃቀም መመለስ ችለናል። ይህም በሥራ ጫናዎች መካከል ያለውን መለያየት እየጠበቀ፣ የምርት ቡድኖች በቅድሚያም ሆነ በቀጣይነት የአቅም እቅድ የማውጣት ፍላጎታቸውን በእጅጉ አቅልሎታል። የምርት ልማት እየተፋጠነ ቢሆንም፣ ከዚያን ጊዜ ወዲህ ባሉት ወራት ከአቅም ምደባ ወይም ከጎረቤት ጫና ጋር የተያያዘ ምንም ችግር አልገጠመንም።

ኩባንያዎች የOpenAIን ያህል ሲያድጉ፣ በአቅራቢ የሚተዳደሩ አገልግሎቶች «ሙሉ በሙሉ የሚተዳደሩ» መሆናቸው ይቀንሳል። ብዙ የሥራ ጫናዎች በክላውድ አቅራቢው መሠረተ ልማት ውስጥ ከተለመደው ክልል ውጭ ይሆናሉ። OpenAI ከትልልቆቹ የAzure Cosmos DB ተጠቃሚዎች አንዱ ሲሆን፣ በተሳካ ሁኔታ ማስኬድ የተለየ አሠራር ጠየቀ፦ የጋራ ሙከራዎች፣ የጋራ ዳሽቦርዶች፣ ቀጥተኛ የምህንድስና ግንኙነት መስመሮች፣ እና እንደኛ ባለ መጠን ብቻ ለሚታዩ የብልሽት ሁኔታዎች የጋራ ኃላፊነት። ዛሬ ትልቁ የAzure Cosmos DB መለያችን በአስር ፔታባይቶች የሚቆጠር ውሂብ ያከማቻል፣ ከ20 ሚሊዮን QPS በላይም ያስተናግዳል። እኛ እስከምናውቀው ድረስ፣ 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 መለያ ላይ ለውጦችን እናስኬዳለን፣ እንፈትሻለን። SDKዎችን በጋራ እንፈትሻለን፣ እናሻሽላለን፤ የAzure Cosmos DB መለያዎቻችንን አቅም ለማሳደግና መጠን ለመወሰንም ምርጥ አሠራሮችን እንወስናለን። በTeams በኩል የእርስ በርሳችንን ምህንድስና ቡድኖች በቀጥታ ማግኘት እንችላለን። በድጋፍ አገልግሎት ደረጃዎች ውስጥ ሳናልፍ እርስ በርሳችን ቀጥተኛ አስቸኳይ ጥሪ የምናደርግባቸውንም መንገዶች አዘጋጅተናል።

ባለፈው ዓመት የAzure Cosmos DB የቁጥጥር ንብርብርና ጌትዌይ የማደግ አቅምን ለማሻሻል ከፍተኛ የጋራ ሥራ ተከናውኗል። የAzure Cosmos DB ሜታዳታ ክፍልን ለመጠበቅ በጌትዌያቸው ውስጥ ከጫና የሚከላከሉ ዘዴዎችንና የተለያዩ የAzure Cosmos DB ሜታዳታዎችን በካሽ ማስቀመጥን ጨምረናል። ግንኙነቶችን በጋራ በማስጠቀምና ደጋግሞ የመጠቀም መጠናቸውን በማሳደግ ከPython habitat-service ሂደቶቻችን የሚመጣውን ጫና ቀንሰናል። በተቻለ ቦታ የሥራ ጫናዎችን በአንድ ስፍራ አስቀምጠናል፤ እንዲሁም ወሳኝ የሥራ ጫናዎችን ከከመስመር ውጭ የሥራ ጫናዎች በተለያዩ VPCዎች ለይተናል።

በዚህ ደረጃ በጋራ መገንባታችን ባለፈው ዓመት ለAzure Cosmos DB መረጋጋታችን ወሳኝ ነበር። በቂ መጠን ወይም ወሳኝነት ያለው ማንኛውም ስርዓት ይህን ዓይነት የቡድን ሥራ ይፈልጋል፤ ይህም የኃላፊነት ወሰኖችን እንደ እንቅፋት ሳይቆጥሩ፣ ከድርጅታዊ ድንበሮች አልፎ መሥራት ነው።

በክፍል I እንደተጠቀሰው፣ መሠረታዊ መርሃችን፦ እንዲሠራ አድርግ፣ ፈጣን አድርገው፣ ወጪውን ቀንስ የሚል ነው። በመጀመሪያ አስተማማኝነት፣ ከዚያ አፈጻጸም፣ በመጨረሻም ቅልጥፍና። Habitat ለOpenAI ወሳኝ መሠረተ ልማት ሆኖ ስለነበር፣ የመጀመሪያ ቅድሚያችን አስተማማኝ ማድረግ ነበር። ስርዓቱ በ2025 እየተረጋጋ ሲሄድና OpenAI በዓለም ዙሪያ ሲስፋፋ፣ የምላሽ መዘግየት ለተጠቃሚዎችና ለምርት ቡድኖች ቀጣዩ እንቅፋት ሆነ።

የማስላትና የማከማቻ አቅም ብዙ ጊዜ በተለያዩ ክልሎች ውስጥ ስለነበረ፣ ክልል አቋራጭ ጥያቄዎችን ማስቀረት አልተቻለም።

የምላሽ መዘግየት መጠኑ ውሂቡ በተከማቸበትና ጥያቄው ምላሽ ባገኘበት ቦታ መሠረት በእጅጉ ይለያይ ነበር። የHabitat ጥያቄዎች ፈጣን ምላሽ እንዲያገኙ፣ የምርት ገንቢዎች በደንበኛው ወገን ተጨማሪ ካሽ ይጠቀሙ፣ ጥያቄዎችን በቡድን ይልኩ፣ የውሂብ ጎታ ንባቦችንና ጽሑፎችን ይቀንሱ፣ እንዲሁም በተቻለ መጠን ሥራዎችን ከምላሽ ጊዜው ወሳኝ መንገድ ውጭ ያከናውኑ ነበር። ይህ የውሂብ ጎታ ችግሮችን በተሻለ የሚቋቋሙ አንዳንድ አስደሳች የምርት ንድፎችን ቢያስገኝም፣ ምርቶችን ይበልጥ ውስብስብ አደረገ፣ የማሻሻያ ዑደታቸውንም አዘገየ። ይህም የውሂብ ጎታውን ዝርዝር መረዳት ሳያስፈልግ ፈጣን የምርት ልማትን ለማበረታታት ያለመውን የHabitat ግብ አላሳካም።

ይህ በ2026 ከፍተኛ ትኩረት የሰጠነው ጉዳይ ሆኗል። ከHabitat ጥያቄዎች ከ90% በላይ የሚሆኑትን የንባብ ጥያቄዎች አፈጻጸም ለማሻሻልም ባለብዙ ደረጃ ስልት አዘጋጅተናል፦

የውሂብ ነዋሪነት መስፈርቶች ላሏቸው ተጠቃሚዎች፣ በዓለም ዙሪያ በተለያዩ የAzure ክልሎች በርካታ የAzure Cosmos DB መለያዎች አሉን። ጥብቅ የውሂብ ነዋሪነት መስፈርቶች ለሌሉባቸው ተጠቃሚዎችም እንኳ፣ ውሂብን በአቅራቢያቸው ማስቀመጥ የምላሽ መዘግየትን በመቀነስ ተሞክሯቸውን ያሻሽላል።

በተግባር ግን፣ አቀማመጡ በክላውድ አካላዊ አቅም ስለሚገደብ፣ ከውሂብ ነዋሪነት አጠቃቀሞች ውጭ ይህን በስፋት ማሳካት አልቻልንም። የውሂብ ስብስቦቻችን ትልቅ ስለሆኑ፣ ብዙ ክልሎች ከሚደርሳቸው የተጠቃሚ ትራፊክ ድርሻ ጋር የሚመጣጠነውን ግዙፍ የማከማቻ ፍላጎት ማስተናገድ አይችሉም።

የውሂብ ማዕከል አቅም፣ ኃይል ወይም ማቀዝቀዣ በተገደበባቸው ክልሎች፣ አንዳንድ ጊዜ ከሁለት አማራጮች አንዱን መምረጥ ይኖርብናል፤ አቅሙን በአቅራቢያ ለሚቀመጥ ማከማቻ መመደብና የHabitat ምላሽ መዘግየትን መቀነስ፣ ወይም ያንን አቅም ለተጨማሪ ማስላት መጠቀምና የማከማቻ ጥያቄዎችን ወደ ሩቅ ቦታ መላክ።

በዚህም ምክንያት የአቀማመጥ ውሳኔዎች ብዙ ጊዜ በሁለት የምርት ፍላጎቶች መካከል ማመጣጠን ይጠይቃሉ፦ ሀ) ለተለያዩ ምርቶችና የተጠቃሚ ቡድኖች የምላሽ መዘግየትን መቀነስ፣ እና ለ) ያለውን መሠረታዊ የማከማቻና የማስላት አቅም መጠቀም።

እንደ በእያንዳንዱ ጥያቄ የሚያስፈልግ የማንነት ማረጋገጫ ሜታዳታ ላሉ፣ የምላሽ ጊዜ እጅግ ወሳኝ ለሆነባቸው የሥራ ጫናዎች፣ ብዙ ሁለተኛ ደረጃ ክልሎች ያሏቸውንና በስፋት የተባዙ የAzure Cosmos DB መለያዎችን በመጠቀም በማስላት አገልግሎቶችና Habitat መካከል ያለውን የደርሶ መልስ ጊዜ (RTT) እንቀንሳለን። አንዳንድ መለያዎች ትራፊክ በምናስተናግድባቸው 40 የAzure ክልሎች ሁሉ ውሂብን ያባዛሉ፤ ሌሎች ደግሞ በእያንዳንዱ አህጉር ቢያንስ በአንድ ክልል ያባዛሉ።

የተለያዩ የማባዛት አወቃቀሮች ባሏቸው መለያዎች መካከል የውሂብ ስብስቦችን ለማዘዋወር፣ ለተጠቃሚው ሳይታይ የሚሠራ የውሂብ ማዘዋወሪያና የጥያቄ መምሪያ ንብርብር ካሰብነው ቀድመን በHabitat ውስጥ መገንባት ነበረብን።

ሆኖም ይህ አቀራረብም በመጨረሻ በአቅም የሚገደብ በመሆኑ፣ በጥንቃቄ ለተመረጡ ጥቂት የውሂብ ስብስቦች ብቻ ተወስኗል።

የHabitat የሥራ ጫናዎች በአብዛኛው የንባብ ናቸው፤ መተግበሪያዎች ቅንብሮችን፣ ሁኔታንና ሌሎች ባህሪያትን ያለማቋረጥ ያመጣሉ። ከፍተኛው የትራፊክ ድርሻም በተደጋጋሚ ከሚጠየቁ በአንጻራዊነት አነስተኛ የውሂብ ዓይነቶች ስብስብ የሚመጣ ነው። ይህ ስርዓቱን በተለይ ለተሰራጨ ካሽ አጠቃቀም አመቺ ያደርገዋል። ካሽ መጠቀም በአንድ ክልል መሠረተ ልማት ውስጥ አፈጻጸምን ቢያሻሽልም፣ በብዙ ክልሎች ሲሠራ ጥቅሙ ይበልጥ ይጨምራል። ምክንያቱም በክልሎች መካከል ያለውን የምላሽ መዘግየት «ለመደበቅ» ሊያገለግል ይችላል።

በHabitat ውስጥ ከዋናው ማከማቻ በፊት የሚፈተሽ የተሰራጨ የካሽ ንብርብር አካተናል። ይህ ንብርብር በቅርቡ የተጠየቁ ኦብጀክቶችንና በመካከላቸው ያሉ ግንኙነቶችን ቅጂ በValkey አገልጋዮች ላይ ያስቀምጣል። አገልጋዮቹም በመሠረተ ልማታችን ውስጥ የተጠቃሚ ጥያቄዎች በሚከናወኑበት ቦታ አቅራቢያ ይገኛሉ። በተለምዶ፣ እነዚህ ዓይነት ካሾች ውሂብ በካሽ የመገኘት መጠንንና የማርጀት እድሉን የሚያመጣጥን የቆይታ ጊዜ (TTL) ይጠቀማሉ። አጫጭር TTLዎች የውሂብ ማርጀትን ይቀንሳሉ፣ ግን የካሽን ጥቅም ያዳክማሉ። ምክንያቱም ንጥሎች ከካሹ በፍጥነት ስለሚወጡ፣ በተደጋጋሚ ከዋናው ማከማቻ መምጣት ይኖርባቸዋል። ረጅም TTLዎች ውሂብ በካሽ የመገኘት መጠንን ያሻሽላሉ፣ ግን ለረጅም ጊዜ ያረጀ ውሂብ ያቀርባሉ። ይህም ደካማ የተጠቃሚ ተሞክሮና ያልተጠበቀ የምርት አሠራር ያስከትላል።

ሌላው አቀራረብ፣ መተግበሪያው በዋናው ማከማቻ ውስጥ ባለው ተመሳሳይ ውሂብ ላይ ሲጽፍ፣ ተዛማጁን የካሽ ቅጂ ከአገልግሎት ውጭ የሚያደርጉ ቀጥተኛ እርምጃዎችን ማከናወን ነው። ይህ በካሽ ያለው ውሂብ ወቅታዊ እንዲሆን በእጅጉ ይረዳል፣ ግን በትክክል መተግበሩ አስቸጋሪ ሊሆን ይችላል። እንዲሁም እንደ ከፊል ብልሽቶች ያሉ፣ በካሽ ውስጥ ያረጀ ውሂብ እንዲቀር የሚያደርጉ በርካታ ልዩ ሁኔታዎች ሊገጥሙት ይችላሉ። በብዙ ክልሎች ሥራ ላይ ማዋል እነዚህን ችግሮች ያባብሳል። በክልሎች መካከል ያሉ አውታረ መረቦች ያነሰ አስተማማኝነት አላቸው፣ የካሽ እርምጃዎችና የመሠረታዊው ማከማቻ ውሂብ ማባዛትም በጊዜ ቅደም ተከተል ሊጋጩ ይችላሉ። ይህን ከTTLዎች ጋር ማጣመር፣ ውሂቡ ያረጀ ሆኖ የሚቆይበትን ከፍተኛ ጊዜ ይገድባል። ሆኖም ከላይ የተገለጸውን ተመሳሳይ የTTL ጥቅምና ጉዳት የማመጣጠን ችግር አያስቀርም።

እንደ Meta TAO ያሉ ስርዓቶችን አርአያ በመከተል፣ ያረጁ የካሽ ቅጂዎችን ከአገልግሎት ውጭ ለማድረግ የበለጠ የላቀ አቀራረብ ወስደናል። የHabitat የተቀናጀ ካሽ፣ በAzure Cosmos DB የለውጥ ፍሰት በኩል በሚሠራ የውሂብ ለውጥ መያዝ (CDC) ይተማመናል። ይህም የካሽ ቅጂዎችን ከአገልግሎት ውጭ የማድረግ መረጃን በሰከንዶች ውስጥ በዓለም ዙሪያ ያሰራጫል፣ ውሂብ በካሽ የመገኘት መጠንን ከፍ እያደረገ ማርጀቱን ይቀንሳል። በመሠረተ ልማታችን ውስጥ ያለ አገልግሎት ይህን የለውጥ ፍሰት ይቀበላል፣ መሠረታዊው ውሂብ ሲዘምንም በአካባቢው ባሉ ካሾች ውስጥ ያሉትን ቅጂዎች ከአገልግሎት ውጭ ያደርጋል። በዚህም ውሂቡ በሚቀጥለው ጊዜ ሲነበብ በካሽ አይገኝም፣ ካሹም በውሂቡ የቅርብ ጊዜ ስሪት ይሞላል።

ኮዱን ከመጀመሪያው Python ይልቅ የተሻለ አፈጻጸም ባለው Rust እንደገና በመጻፍ፣ በHabitat አገልግሎቱ ራሱ ውስጥ ያለውን ተጨማሪ ጫና አስወግደናል። በዚህም የምላሽ መዘግየትን በእጅጉ ቀንሰናል።

እነዚህ ለውጦች በጋራ አጠቃላይ ዓለም አቀፍ የንባብ p50 ጊዜያችንን ከ120 ms ገደማ ወደ 10 ms ገደማ አውርደውታል። ይህም በዚህ ዓመት መጀመሪያ ላይ በአፈጻጸም ላይ ማተኮር ከጀመርን ወዲህ የ12 እጥፍ መሻሻል ነው።

ካሽ መጠቀም መካከለኛውን የምላሽ መዘግየት በእጅጉ ቢቀንስም፣ በጣም የዘገዩ ጥያቄዎች አሁንም በካሽ ያልተቀመጠ ውሂብ ከመሠረታዊው ማከማቻ ማምጣት ይፈልጋሉ። ይህም ብዙ ጊዜ ከሩቅ ክልሎች ይሆናል። ተጨማሪ አቅም ሥራ ላይ ሲውልና የማከማቻ ቅልጥፍናን ስናሻሽል፣ የበለጠ መሠረታዊ ፈተናን ለመፍታት አቅደናል፦ ውሂብን ከመጀመሪያው ጀምሮ ወደሚጠቀምበት ቦታ ቅርብ ማስቀመጥ።

የውሂብ ጎታ ለውጦችን ወደ ተከታይ ስርዓቶች የሚያስተላልፍ፣ አስተማማኝና ሊስፋፋ የሚችል CDC፣ ከHabitat የካሽ ስልት በላይ ለሌሎችም ወሳኝ ክፍል ነው። በሺህዎች ከሚቆጠሩ ኮንቴይነሮችና በሚሊዮኖች ከሚቆጠሩ የኮንቴይነር ክፍሎች፣ በሰከንድ በሚሊዮኖች የሚቆጠሩ ለውጦች ይያዛሉ። እነዚህም ከመቶ በላይ በሆኑ የKafka ርዕሶች ውስጥ በማለፍ፣ ከጊዜ በኋላ ወጥ የሚሆኑ ሁለተኛ ደረጃ መረጃ ጠቋሚዎችን፣ የውሂብ ማዘዋወሪያ ፍሰቶችን፣ ከመስመር ውጭ ትንታኔዎችንና ሌሎች የቅጽበት የምርት ባህሪያትንም ያስኬዳሉ። መሠረታዊ መሠረተ ልማታችን በዓለም ዙሪያ እየሰፋ ሲሄድ፣ የረድፍ ለውጦችን መከታተል እየተወሳሰበ መጥቷል። አንድ ደንበኛ የራሱ ዓይነት ረድፎች በተለወጡ ቁጥር የሚሠራ ተመላሽ ተግባር ለመመዝገብ ቢፈልግ፣ ከሌሎች ጉዳዮች በተጨማሪ መጀመሪያ ውሂቡ በየትኞቹ የCosmos መለያዎችና ኮንቴይነሮች እንዳለ፣ እነዚያን ኮንቴይነሮች የሚከታተለው የCDC አገልግሎት በየክልሉ የትኛው እንደሆነ ማወቅ አለበት። እንዲሁም የCDC ሠራተኛ ፕሮሰሶችን፣ Kafkaን እና መረጃውን የሚቀበለውን ፕሮግራም አቅም በትክክል ማሳደግ ይኖርበታል። የCDC መድረካችን ዓላማ፣ የምርት ገንቢዎች እነዚህን ዝርዝሮች እንዳይከታተሉ ማድረግ ነው። በምትኩ፣ ረድፎቻቸው ሲለወጡ እንዲጠራ የሚፈልጉትን ተግባር የሚመዘግቡበት ቀላል በይነገጽ እናቀርባለን፤ ሁሉንም የውስጥ ግንኙነትና የአቅም ማሳደግ ሥራ እኛ እንወስዳለን።

የውስጥ ቁጥጥር ንብርብር፣ የሚያስፈልጉት ኮንቴይነሮች ሁሉ ለውጦች እየተያዙ መሆናቸውን ያለማቋረጥ ያረጋግጣል፣ ከየትኞቹ የCosmos ክልሎች እንደሚነበብ ይመርጣል፣ እና በብዙ ጂኦግራፊያዊ ክልሎች ባሉ በሺህዎች የሚቆጠሩ ሠራተኛ ፕሮሰሶች መካከል ሥራን በብቃት ያከፋፍላል። የቅጂ ክልሎችንና ዝቅተኛ ቅድሚያ ያላቸውን የፍሰት ንባቦች መጠቀም፣ በምላሽ መዘግየት የሚጎዳውን የHabitat ትራፊክ ከበስተጀርባ የለውጥ መያዝ ሥራ ጫናዎች ይጠብቃል። ይህን ያህል ትልቅ በሆነ የፕሮሰሶች ስብስብ ውስጥ፣ የሠራተኛ ፕሮሰሶች መበላሸት፣ የኮንቴይነር ችግሮች፣ የጊዜያዊ ፈቃድ ማከማቻ ስህተቶች፣ ልክ ያልሆኑ ቅንብሮችና የመድረሻ ብልሽቶች በተደጋጋሚ ይከሰታሉ። የCDC ሠራተኛ ፕሮሰሶችን የሕይወት ዑደትና የጊዜያዊ ፈቃድ አስተዳደር አጠናክረናል፣ ብልሽቶች ከአንዱ ፍሰት ወደ ሌላው እንዳይተላለፉ ለይተናል፣ እና ለቅንብር ለውጦችና ለአዲስ ስሪቶች ስርጭት መከላከያዎችን ገንብተናል። በቋሚነት የማይደርሱ መልዕክቶች የወረፋውን መጀመሪያ ይዘው ሌሎችን እንዳያግዱ፣ ያልተላኩ መልዕክቶች የሚቀመጡባቸውን ልዩ ወረፋዎች እንጠቀማለን። አንባቢ ፕሮሰሶችን ወደ አማራጭ የCosmos ክልሎች በማዛወር ክልላዊ የአገልግሎት መቋረጦችን እንቋቋማለን። ባለን መጠን ምክንያት፣ የAzure CDC SDKን እንኳ ማስተካከል ነበረብን። የሂደት መቀጠያ ነጥቦችን በማህደረ ትውስታ ውስጥ በቡድን በማሰባሰብና በየተወሰነ ጊዜ ብቻ ወደ ቋሚ ማከማቻ በመጻፍ፣ የመቀጠያ ነጥብ አተገባበሩን የበለጠ ቀልጣፋ አድርገነዋል።

Habitat በውስጡ Azure Cosmos DBን የሚጠቀምበት መንገድ ውስብስብ ቢሆንም፣ ዋና እሴቱ ሁልጊዜ የምርት ገንቢዎችን ከመሠረተ ልማት ዝርዝሮች ነፃ በማድረግ የምርት ልማትን ማፋጠን ነው። የCDC መድረካችንም ከዚህ አይለይም።

የማከማቻ APIን ሆን ብሎ በጥቂት ተግባራት በመወሰን፣ የPython አገልግሎቱን ማሳደግ በመቀጠል፣ እና በጣም አስቸኳይ ለሆኑ የምህንድስና ፈተናዎች ቅድሚያ በመስጠት፣ አነስተኛ ቡድን በፍጥነት የሚያድግ የማከማቻ መድረክን ማስተናገድ ችሏል። መጀመሪያ ለወሳኝ የምርት ትራፊክ አስተማማኝነት ላይ፣ ከዚያ ለዓለም አቀፍ ተጠቃሚዎች የንባብ አፈጻጸም ላይ፣ በመጨረሻም በሰፊ መጠን በአሠራር ቅልጥፍና ላይ አተኮርን። ይህ አቀራረብ አስተማማኝነትን፣ አፈጻጸምንና የምርት ልማት ፍጥነትን እያሻሻለ፣ ፈጣን እድገትንና አዲስ አጠቃቀሞችን አስችሏል።

Habitatን እና የውይይት ማከማቻን ለቀጣዮቹ ቢሊዮን ተጠቃሚዎች ለማሳደግ፣ ውሂባችንን በመሠረተ ልማታችን ሁሉ ውስጥ፣ ከዚህም የበለጠ በሆነ መጠን የማባዛት አስቸጋሪነትን መፍታት ያስፈልገናል። ይህን አስቀድመን ለመከላከል፣ ትልቅ መጠን ላላቸው የHabitat ውሂብ ዓይነቶች የተመቻቸ፣ በኤክሳባይት ደረጃ የሚሠራ የራሳችንን ብጁ የመስመር ላይ ማከማቻ ስርዓት በውስጥ እየገነባን ነው። በግንባታ ላይ ያለው ይህ ስርዓት፣ የRocksetን RocksDB Cloud ዋና ክፍል በRaft ላይ ከተመሠረተ የውሂብ ማባዛት ጋር ያጣምራል። ከAzure Cosmos DB ጋር ተመሳሳይ የሰነድ አወቃቀር ይተገብራል። ነገር ግን ከማስላት የተለየ ማከማቻና አካላዊ ማባዛትን በመጠቀም፣ ከፍተኛውን qps ዝቅ በማድረግ ምትክ የሚያስፈልገውን የፍላሽ ማከማቻ አቅም ይቀንሳል።

በግንባር ቀደም ደረጃ በእንደነዚህ ያሉ የውሂብ መሠረተ ልማት ሥራዎች ላይ ለመሳተፍ ፍላጎት ካለዎት፣ ክፍት የሥራ መደቦቻችንን ይመልከቱ⁠።