Kupanua hifadhi mtandaoni kwa kasi kwa watumiaji zaidi ya bilioni 1 wa ChatGPT (Sehemu ya II)

Bidhaa zote za OpenAI zinahitaji ufikiaji wa data wa haraka na unaotegemewa, unaotolewa na jukwaa letu la hifadhi, Habitat. Lazima litoe majibu ndani ya milisekunde kwa zaidi ya watumiaji bilioni 1 katika maeneo 40 ya kijiografia. Miundombinu yetu ilikabiliwa na changamoto isiyo ya kawaida: kuhimili ukuaji mkubwa wa kasi na matumizi mapya huku tukiendelea kuboresha kutegemewa, utendaji na kasi ya watengenezaji wa bidhaa. Kutatua changamoto hiyo kulihitaji kutafakari upya jinsi jukwaa letu la hifadhi ya mtandaoni lilivyoundwa na kuendeshwa. Tulitathmini mara kwa mara faida na hasara za kila chaguo, tukifuata mpangilio huu: kwanza kuwa wa kutegemewa vya kutosha kwa maombi muhimu kabisa ya bidhaa, kisha kuwa na kasi ya kutosha kwa watumiaji duniani kote, na hatimaye kufanya kazi kwa ufanisi katika kiwango kikubwa sana.

Mfululizo huu wa sehemu mbili unaeleza jinsi tulivyoendeleza Habitat kutoka maktaba rahisi ya programu mteja na hifadhidata hadi jukwaa la hifadhi lililosambazwa duniani kote, linalohudumia zaidi ya petabaiti 500 za data. Sehemu ya I iliangazia mageuzi ya Habitat kutoka programu mteja ya Python hadi huduma. Pia ilieleza mbinu zilizotuwezesha kupanua huduma inayotumia Python zaidi ya kiwango ambacho wengi wangeona kinawezekana kiutendaji.

Katika makala hii, Sehemu ya II, tunaeleza jinsi tulivyopanua kipengele cha msingi cha hifadhi: Azure Cosmos DB. Kupitia ushirikiano wa karibu na timu ya Azure, tulipata njia inayofaa ya wapangaji wengi kutumia kontena zinazosimamiwa kwa pamoja, yenye utendaji bora wa usomaji katika kiwango kikubwa duniani kote.

Kampuni zinapopanuka, timu za miundombinu mara nyingi hubadilika kutoka kuendesha mifumo ya mpangaji mmoja hadi ya wapangaji wengi. Katika mfumo wa mpangaji mmoja, kila timu ya sehemu ya bidhaa hudumisha mfumo wake. Hii hupunguza eneo linaloathiriwa na hitilafu, huweka mipaka wazi ya umiliki na hutenganisha kazi. Timu na sehemu za bidhaa zinapoongezeka, njia hii huwa ghali kuendesha. Mfumo wa mpangaji mmoja huipa kila timu ya bidhaa jukumu la kupanga uwezo, na mara nyingi husababisha kutengwa kwa rasilimali nyingi kupita mahitaji.

Kinyume chake, mfumo wa wapangaji wengi huipa timu kuu ya hifadhidata udhibiti, ikiwa na maarifa na uzoefu bora wa kutenga rasilimali. Lakini mfumo wa wapangaji wengi una matatizo yake, kama majirani wanaotumia rasilimali kupita kiasi, ambapo mpangaji mmoja hutumia sehemu kubwa isiyo ya kawaida ya rasilimali na kuwaathiri wengine.

Katika Habitat, tulilazimika kupima faida na hasara zote hizi ili kubuni mfumo mkubwa wa hifadhi unaotegemewa na wenye ufanisi. Leo, Habitat ni safu ya hifadhidata ya wapangaji wengi kwa bidhaa nyingi za OpenAI. Lakini safari yetu ilizunguka kutoka kutumia kontena moja la Azure Cosmos DB la wapangaji wengi, hadi kutenga kontena za msingi za mpangaji mmoja, kisha kurudi kwenye kontena la wapangaji wengi kama chaguomsingi. Bado tuko mwanzoni kabisa mwa safari ya wapangaji wengi kwenye Habitat: tunawezesha matumizi mengi tofauti, lakini tumeweza kuahirisha uwekezaji katika eneo hili kwa kutumia vipengele vya msingi vilivyojengwa ndani ya Azure Cosmos DB inapowezekana.

Kabla ya kueleza safari yetu ya Azure Cosmos DB, haya ndiyo mambo ya msingi:

• Akaunti ya Azure Cosmos DB hufafanua kundi la kontena na sera ya usambazaji wa nakala

• Kila kontena hutengewa kiwango fulani cha utendaji katika vitengo vya maombi kwa sekunde (RU/s)

• Data ndani ya kila kontena huhifadhiwa kwa njia ya kawaida ya kuigawa kulingana na ufunguo maalumu wa kizigeu cha kimantiki, huku kila ufunguo ukiwa na vikomo vya hifadhi na utendaji vilivyoandikwa

• Azure Cosmos DB husambaza funguo za vizigeu vya kimantiki katika vizigeu halisi vichache vya msingi. Hugawanya vizigeu hivyo kuwa vingi zaidi data iliyohifadhiwa inapozidi kiwango fulani, au kontena linapohitaji vizigeu halisi zaidi ili kudumisha utendaji uliotengwa

Mwanzoni tuliruhusu mzigo wowote wa programu mteja upite, tukitegemea kikomo kilichotajwa cha 10K RU/s kwa kila ufunguo wa kizigeu cha kimantiki kudhibiti mtiririko wa maombi. Tulipoanza, pia tulitumia kontena moja tu chaguomsingi la Azure Cosmos DB katika kila akaunti. Hii ilifanya kazi kwa kiasi cha kuridhisha, lakini ilileta matatizo kwa sababu kadhaa:

Kwa sababu ya maamuzi ya mapema ya API, tuliruhusu programu mteja zichague moja kwa moja funguo za vizigeu vya kimantiki. Kwa hiyo, matumizi tofauti ya bidhaa mara nyingi hukutana kwenye funguo zilezile za vizigeu zinazotumiwa sana, kama user_id au workspace_id. Kwa kuwa matumizi haya yalishiriki vikomo vya Azure Cosmos DB kwenye funguo zilezile za vizigeu vya kimantiki, muundo huu uliwekea kikomo utendaji wa jumla kwa mtumiaji husika.

Tatizo moja la kawaida tulilokabili tulipopanua Postgres kabla ya kuhamia Habitat na Azure Cosmos DB lilikuwa kwamba maombi mengi kutoka kwa shirika au ufunguo wenye matumizi makubwa sana—mpangaji mmoja aliyezalisha mzigo mkubwa usio na uwiano—yangeweza kuangusha hifadhidata nzima. Juhudi kubwa za pamoja zilitumika kuweka funguo hizo kwenye kache na kujenga utaratibu wa ruhusa za muda wakati data haipatikani kwenye kache, ili mzigo unaotokana na hali hiyo usilemee hifadhidata ya msingi.

Ingawa vikomo vilivyoandikwa vya ukubwa wa data na utendaji vinahusu funguo za vizigeu vya kimantiki, kwa hakika vikomo hivyo hutekelezwa kwenye kizigeu halisi. Kiutendaji, hii inamaanisha vizigeu vya kimantiki haviwezi kufikia 10,000 RU/s. Badala yake, vinagawana vikomo vya kizigeu halisi na kila ufunguo mwingine wa kizigeu cha kimantiki uliowekwa kwenye kizigeu hicho halisi.

Hili liliwezesha majirani wanaotumia rasilimali kupita kiasi kuathiri funguo nyingi za vizigeu vya kimantiki zisizohusiana. Kazi za data za vipengele vinavyotumiwa na wachache zilivuruga michakato muhimu ya kuingia na kujisajili.

Kikomo cha utendaji cha kizigeu halisi pia hubadilika kulingana na jumla ya utendaji uliotengewa kontena la Azure Cosmos DB. Utendaji uliotengewa kontena hugawanywa kwa takriban usawa kati ya vizigeu vyake halisi.

Kiasi cha data kinapoongezeka, vizigeu halisi hugawanyika na kuongeza jumla ya vizigeu, huku jumla ya utendaji uliotengwa ikibaki ileile. Matokeo yake ni kwamba kikomo halisi cha utendaji kwa kila kizigeu hupungua kadiri ukubwa wa data unavyoongezeka.

Kwa matumizi yetu yanayohitaji hifadhi kubwa zaidi, ya data kama blob, hali hii husababisha tatizo ambapo ongezeko la data iliyohifadhiwa pekee hupunguza uwezo wa utendaji wa kazi zinazoendelea, hata kama kasi ya maombi na matumizi havibadiliki.

Kontena tofauti husaidia kutatua kwa kiasi fulani matatizo haya ya vikomo vya funguo za vizigeu na majirani wanaotumia rasilimali kupita kiasi. Kwa kutumia kontena tofauti, kila kontena linaweza kupewa vizigeu vyake halisi vinavyojitegemea. Ni kazi tofauti ndani ya kontena hilo pekee zinazoweza kuathiriana kwa kutumia rasilimali kupita kiasi au kushiriki funguo zilezile za vizigeu. Kwa upande mwingine, kutenga kontena jipya kuna gharama za ziada: kila kontena linahitaji upangaji wake wa uwezo. Kwa hiyo tunataka kuunda kontena tu katika mipaka inayofaa ya huduma au matumizi.

Tulianza kutumia kontena tofauti za Azure Cosmos DB kwa matumizi mapya muhimu zaidi yaliyohitaji utenganishaji thabiti. Pamoja na hati ya kudhibiti vizigeu dhaifu kwa kulinganisha jumla ya utendaji uliotengewa kila kontena na idadi ya vizigeu vyake halisi, kwa kiasi kikubwa tuliepuka matatizo yote tuliyokuwa tukikabili.

Hata hivyo, kwa kuwa tulianza na kontena chaguomsingi, kwa bahati mbaya matumizi mengi muhimu ya zamani yalibaki humo bila kuhamisha data. Ili kulinda huduma muhimu ambazo bado zilitegemea data katika kontena chaguomsingi la pamoja, mara nyingi tulishauri timu ziunde kontena tofauti kwa huduma mpya au vipengele vikuu vya bidhaa. Tulipopanuka, shinikizo kwenye kontena chaguomsingi liliongezeka, na matukio ya hitilafu katika mazingira ya uzalishaji pia yakaongezeka. Tulianza kutenga kontena kwa kila huduma mpya au kipengele kikubwa cha bidhaa, ili tu kulinda kontena chaguomsingi dhidi ya mzigo zaidi.

Hili lilituepusha na hitilafu nyingi zilizoathiri tovuti nzima, na kufanya athari ziishie kwenye kuzorota kwa kipengele au huduma husika. Hata hivyo, hatimaye gharama za ziada za kutenga kontena mpya zilianza kutulemea:

Katika kontena chaguomsingi la zamani la pamoja, matumizi mapya yoyote yaliyoongezeka kutoka QPS 0 hadi milioni 1 hayakuwa na uwezekano wa kubadilisha sana matumizi ya jumla. Lakini katika kontena lililotengwa, matumizi mapya yanayopanda kutoka QPS 0 hadi milioni 1 yanaweza kuwa mzigo wa mara 1,000 ya kiwango cha awali kilichotokana na majaribio ya matumizi ya ndani pekee.

Kwa kontena za matumizi maalumu, sasa timu zilihitaji kukumbuka kutenga mapema kiwango cha utendaji kilichotarajiwa wakati wa uzinduzi. Mara nyingi timu za bidhaa zilizindua vipengele vyake na kusahau kuongeza uwezo mapema. Siku ya uzinduzi, tungejikuta katika vyumba vya kushughulikia matukio makubwa ya hitilafu (SEV), tukijaribu kuongeza uwezo wa kontena dakika za mwisho.

Hii ni faida kuu ya kuchanganya kazi katika mifumo ya wapangaji wengi, ambayo tunaipoteza ili kupata utenganishaji bora kwa mkakati huu wa kontena.

Baada ya muda, kufuatilia matumizi ya kontena maalumu pia kulihitaji uelewa wa kina wa bidhaa ili kujua wakati maombi yangebadilika au kuongezeka.

Tunaweza kutoa hati rahisi ya safu ya udhibiti ili kuongeza utendaji uliotengewa kila kontena kulingana na mwelekeo wa ukuaji. Lakini bila ukuaji thabiti wa matumizi ya jumla, kuongeza uwezo kwa usahihi kulihusisha karibu kila timu ya bidhaa ya OpenAI katika upangaji wa uwezo.

Njia hii haikuweza kuendana na ukuaji wa shirika, huku kiwango cha umakini ambacho kila timu inayomiliki huduma iliweka katika kutenga rasilimali za Azure Cosmos DB kikitofautiana sana.

Shirika lilipokua, matatizo hayo ya uendeshaji yalikuwa magumu zaidi kushughulikia. Kutokuwa na timu moja kuu ya kupanga kulisababisha timu nyingi kupanga vibaya. Kwa hiyo, hatimaye tulirudi kwenye suluhisho la wapangaji wengi na kushirikiana kwa karibu na timu ya Azure kutatua matatizo yetu ya awali kupitia muundo wa upangaji wa pamoja:

Kudhibiti kwanza kasi ya maombi kwa funguo zenye matumizi makubwa zaidi huzuia majirani wanaotumia rasilimali kupita kiasi kutumia utendaji wote unaopatikana wa kizigeu halisi husika. Hii hupunguza athari za majirani hao, ambapo ufunguo mmoja wenye matumizi makubwa unaweza kuathiri tovuti nzima.

Vilevile, QoS inayogawa maombi katika madaraja huzuia kazi zisizohitaji majibu ya papo hapo, kama kuingiza data nyingi au kutoa data, kutumia utendaji wote wa kizigeu halisi husika. Kwa kuyapa maombi ya kazi hizi kipaumbele cha chini, kasi yake hudhibitiwa kwanza. Hii huepusha kudhibiti kasi ya maombi ya mwingiliano yenye kipaumbele cha juu yanayohudumia watumiaji wa mwisho.

Azure Cosmos DB tayari ilikuwa na hali isiyohitaji usimamizi wa seva ambayo ingetatua tatizo letu la vizigeu dhaifu katika hali ya rasilimali zilizotengwa. Hata hivyo, ilikuwa na dosari kubwa: iliongeza uwezo kulingana na matumizi ya hifadhi pekee na kuweka kikomo cha RU cha 5K RU/s kwa kila kizigeu halisi. Hii ingetatua tatizo letu la vizigeu dhaifu, lakini ingetuzuia kupanua matumizi yanayohitaji RU nyingi.

Timu ya Azure Cosmos DB ilitujengea hali mpya iliyoboreshwa isiyohitaji usimamizi wa seva. Iliruhusu kila kizigeu halisi kufikia 10K RU/s na kuongeza ugawaji unaotegemea matumizi ya RU pamoja na ule unaotegemea hifadhi. Hii ilituwezesha kuacha kufuatilia na kuongeza uwezo wa kontena wenyewe.

Kwa mabadiliko haya, tumeweza kurudi kutumia kontena moja la pamoja. Hili limerahisisha sana upangaji wa awali na endelevu wa uwezo kwa timu za bidhaa, huku likidumisha utenganishaji wa kazi. Katika miezi iliyofuata, hatujapata tukio lolote la hitilafu ya kutenga rasilimali au majirani kutumia rasilimali kupita kiasi, licha ya kuongezeka kwa kasi ya utengenezaji wa bidhaa.

Kampuni zinapokua hadi kiwango cha OpenAI, huduma zinazosimamiwa hazibaki “kusimamiwa” kikamilifu. Kazi nyingi huwa tofauti na zile za kawaida katika miundombinu ya mtoa huduma wa wingu. OpenAI ilipokuwa miongoni mwa watumiaji wakubwa zaidi wa Azure Cosmos DB, kuiendesha vizuri kulihitaji mbinu tofauti: majaribio ya pamoja, dashibodi za pamoja, njia za moja kwa moja za mawasiliano ya kihandisi, na uwajibikaji wa pamoja kwa aina za hitilafu zinazojitokeza tu katika kiwango chetu. Leo, akaunti yetu kubwa zaidi ya Azure Cosmos DB huhifadhi makumi ya petabaiti za data na kuhudumia zaidi ya QPS milioni 20. Kwa ufahamu wetu, sisi ndio kampuni pekee iliyotumia Azure Cosmos DB katika kiwango hiki.

Mwishoni mwa 2024, kukatika kwa huduma katika eneo moja kulidhihirisha kwa nini ushirikiano huu ulikuwa muhimu. Wakati huo, umeme ulikatika katika eneo kuu la Azure la mojawapo ya akaunti zetu kubwa zaidi za Azure Cosmos DB. Katika mchakato uliofuata wa kuhamishia huduma kwenye eneo la akiba, tuligundua kwamba akaunti zetu kubwa zaidi zingechukua saa kadhaa kuhamia eneo la ziada. Hili halikuwa limejaribiwa katika kiwango chetu na timu yetu wala timu ya Azure Cosmos DB.

Takriban mwezi mmoja baadaye, tulipokuwa tukirudisha akaunti hizo katika eneo la awali, tulisababisha hitilafu nyingine kubwa. Wimbi la miunganisho lililofurika katika eneo la awali lililemea lango lake la Azure Cosmos DB. Tabia isiyo ya kawaida ya programu mteja ya Azure Cosmos DB katika hali ya lango wakati wa kuhamisha huduma ilisababisha programu mteja zote kuanzisha miunganisho mara moja na kutuma maombi kwenye eneo la awali, ingawa ni baadhi tu ya vizigeu halisi vilivyokuwa vimerudi huko.

Katika kila tukio la hitilafu, OpenAI na Azure zilifuata taratibu zao za kushughulikia matukio, zikatambua visababishi kadhaa na kutekeleza marekebisho. Lakini hitilafu hizi zilikuwa dalili za tatizo kubwa la kimfumo katika jinsi timu yetu na timu ya Azure Cosmos DB zilivyoendesha huduma na kufanya majaribio. Mwanzoni, kutumia huduma zinazosimamiwa kulitupa uwezo wa kusonga haraka na kuzingatia malengo ya biashara. Katika kiwango kikubwa, huduma hizi hupunguza kiasi cha usimamizi zinachokubebea na huhitaji ushirikiano wa kina na mtoa huduma katika ngazi zote, kuanzia ubunifu hadi uendeshaji.

Leo, timu za uhandisi za Habitat na Azure hufuatilia kwa pamoja kila safu ya Habitat, kuanzia safu zetu za huduma hadi safu za hifadhi halisi za Azure Cosmos DB. Tunaendesha na kujaribu mabadiliko kwenye akaunti ya Azure Cosmos DB yenye ukubwa wa mazingira ya uzalishaji, lakini isiyotumika kwa uzalishaji. Tunajaribu na kuboresha SDK kwa pamoja na kuamua mbinu bora za kuongeza na kupanga ukubwa wa akaunti zetu za Azure Cosmos DB. Tuna mawasiliano ya moja kwa moja kati ya wahandisi kupitia Teams, na hata tumeweka njia za kuitana moja kwa moja kwa tahadhari za dharura bila kupitia ngazi za usaidizi.

Katika mwaka uliopita, tumefanya kazi nyingi kwa pamoja ili kuboresha uwezo wa kupanua safu ya udhibiti na lango la Azure Cosmos DB. Tumeongeza ulinzi dhidi ya mzigo na uhifadhi wa metadata mbalimbali za Azure Cosmos DB kwenye kache ya lango lake ili kulinda kizigeu cha metadata. Pia tumepunguza shinikizo kutoka kwa michakato yetu mingi ya Python ya habitat-service kwa kutumia kundi la miunganisho na kuitumia tena zaidi, kuweka kazi zinazohusiana eneo moja inapowezekana, na kutenganisha kazi muhimu na kazi zisizohitaji majibu ya papo hapo kwa kutumia VPC tofauti.

Ushirikiano huu wa kina wa kihandisi umekuwa muhimu kwa uthabiti wa Azure Cosmos DB yetu katika mwaka uliopita. Mfumo wowote mkubwa au muhimu vya kutosha unahitaji ushirikiano wa aina hii: kuondoa vizuizi vya umiliki na kufanya kazi kwa kuvuka mipaka ya mashirika.

Kama tulivyotaja katika Sehemu ya I, falsafa yetu kuu ni: ufanye ufanye kazi, uharakishe, kisha upunguze gharama. Kwanza kutegemewa, kisha utendaji, halafu ufanisi. Habitat ilikuwa imekuwa miundombinu muhimu kwa OpenAI, hivyo kipaumbele cha kwanza kilikuwa kuifanya itegemewe. Mfumo ulipoimarika mwaka wa 2025 na OpenAI kupanuka duniani kote, muda wa kusubiri ukawa kikwazo kilichofuata kwa watumiaji na timu za bidhaa.

Rasilimali za ukokotoaji na hifadhi mara nyingi zilikuwa katika maeneo tofauti, hivyo maombi kati ya maeneo hayangeepukika.

Muda wa kusubiri ulitofautiana sana kulingana na mahali data ilipohifadhiwa na mahali ombi liliposhughulikiwa. Ili maombi ya Habitat yashughulikiwe haraka, watengenezaji wa bidhaa walitumia kache za ziada upande wa programu mteja, kuunganisha maombi katika makundi, kupunguza usomaji na uandishi kwenye hifadhidata, na kuondoa kazi zisizo za lazima katika mfululizo wa hatua zinazohitajika kutoa jibu inapowezekana. Ingawa hili lilizalisha miundo ya bidhaa ya kuvutia iliyohimili matatizo ya hifadhidata vizuri zaidi, pia liliongeza ugumu wa bidhaa na kupunguza kasi ya kuziboresha. Hivyo hatukufikia lengo la Habitat la kuhimiza utengenezaji wa bidhaa kwa kasi bila kuhitaji kuelewa hifadhidata.

Hili limekuwa lengo letu kuu mwaka wa 2026, na tumebuni mkakati wa ngazi kadhaa wa kuboresha utendaji wa usomaji, ambao unawakilisha zaidi ya 90% ya maombi ya Habitat:

Tuna akaunti kadhaa za Azure Cosmos DB katika maeneo tofauti ya Azure duniani kote kwa watumiaji wenye masharti ya hifadhi ya data. Hata kwa watumiaji wasio na masharti madhubuti ya hifadhi ya data, kuweka data karibu nao huboresha matumizi yao kwa kupunguza muda wa kusubiri.

Kiutendaji, hatuwezi kufanya hivi kwa upana isipokuwa katika hali zinazohitaji hifadhi ya data katika eneo maalumu, kwa sababu mahali pa kuiweka panategemea uwezo halisi wa miundombinu ya wingu. Kwa sababu ya ukubwa wa seti zetu za data, maeneo mengi hayawezi kutoa nafasi kubwa ya hifadhi inayohitajika kwa sehemu yao ya maombi ya watumiaji.

Katika maeneo yenye uwezo mdogo wa vituo vya data, umeme au upoeshaji, wakati mwingine tunalazimika kuchagua: kuhifadhi uwezo kwa ajili ya hifadhi iliyo karibu na kupunguza muda wa kusubiri wa Habitat, au kutumia uwezo huo kwa ukokotoaji wa ziada wa kushughulikia maombi na kuelekeza maombi ya hifadhi mbali zaidi.

Kwa hiyo, maamuzi ya mahali pa kuweka data mara nyingi huhitaji kusawazisha mahitaji ya bidhaa kati ya: A) kupunguza muda wa kusubiri kwa bidhaa na makundi tofauti ya watumiaji, na B) uwezo halisi wa hifadhi na ukokotoaji.

Kwa kazi zinazohitaji majibu ya haraka zaidi, kama metadata ya uthibitishaji inayohitajika kwa kila ombi, tunapunguza muda wa safari ya kwenda na kurudi (RTT) kati ya ukokotoaji na Habitat kwa kutumia akaunti za Azure Cosmos DB zenye nakala katika maeneo mengi ya ziada. Baadhi ya akaunti husambaza nakala katika maeneo yote 40 ya Azure ambako tunashughulikia maombi; nyingine husambaza nakala katika angalau eneo moja kwa kila bara.

Tumelazimika kujenga safu ya kuhamisha data na kuelekeza maombi ndani ya Habitat, inayofanya kazi bila hatua za ziada kwa watumiaji, mapema kuliko tulivyotaka. Hii hutuwezesha kuhamisha seti za data kati ya akaunti zenye mipangilio tofauti ya usambazaji wa nakala.

Hata hivyo, njia hii pia hatimaye huwekewa kikomo na uwezo uliopo, kwa hiyo inatumika kwa seti chache tu za data zilizochaguliwa kwa makini.

Kazi za Habitat kwa kiasi kikubwa ni za kusoma data, huku programu zikichukua mipangilio, hali na sifa nyingine kila wakati. Sehemu kubwa isiyo na uwiano ya maombi hutokana na kundi dogo la aina za data zinazofikiwa mara kwa mara. Hii inafanya mfumo ufaae sana kwa uhifadhi kwenye kache zilizosambazwa. Ingawa kache huboresha utendaji katika miundombinu ya eneo moja, maboresho huwa makubwa zaidi katika maeneo mengi, ambako inaweza “kuficha” muda wa kusubiri unaotokana na mawasiliano kati ya maeneo.

Tumejumuisha ndani ya Habitat safu ya kache iliyosambazwa inayokaguliwa kabla ya kufikia hifadhi kuu. Huhifadhi nakala za vipengee na mahusiano yaliyofikiwa hivi karibuni kwenye seva za Valkey zilizo katika miundombinu yetu karibu na mahali maombi ya watumiaji yanapochakatwa. Kwa kawaida, kache hizi hutumia muda wa kuisha (TTL) unaosawazisha kiwango cha kupata data kwenye kache na uchakavu wa data. TTL fupi hupunguza uchakavu wa data lakini hupunguza faida za kache, kwa sababu vipengee huisha muda wake haraka na lazima vichukuliwe tena mara nyingi zaidi. TTL ndefu huongeza kiwango cha kupata data kwenye kache, lakini hutoa data iliyopitwa na wakati kwa muda mrefu, na kusababisha uzoefu duni kwa watumiaji na tabia ya bidhaa isiyotabirika.

Njia nyingine ni kubatilisha wazi data ya kache wakati programu inaandika kwenye data hiyohiyo ya msingi. Hii hufanya data ya kache iwe ya karibuni zaidi, lakini inaweza kuwa vigumu kuitekeleza ipasavyo. Pia bado huathiriwa na hali nadra, kama hitilafu za sehemu ya mfumo, ambazo huacha kache na data iliyopitwa na wakati. Mifumo iliyosambazwa katika maeneo mengi huongeza matatizo haya: mitandao kati ya maeneo haitegemewi sana, na usasishaji wa kache hushindana kwa muda na usambazaji wa nakala za hifadhi ya msingi. Kuongeza TTL kwenye njia hii huweka kikomo cha muda ambao data inaweza kuwa imepitwa na wakati, lakini bado kunabaki na changamoto zilezile za kusawazisha faida na hasara za TTL zilizotajwa hapo juu.

Tumetumia mbinu ya hali ya juu zaidi ya kubatilisha data, tukifuata mifumo kama TAO ya Meta. Kache iliyojumuishwa ya Habitat hutegemea kunasa mabadiliko ya data (CDC) kupitia mtiririko wa mabadiliko wa Azure Cosmos DB ili kusambaza ubatilishaji duniani kote ndani ya sekunde. Hii huongeza kiwango cha kupata data kwenye kache huku ikipunguza uchakavu wake. Huduma katika miundombinu yetu husoma mtiririko huu wa mabadiliko na kubatilisha data katika kache za eneo data ya msingi inaposasishwa. Hii hufanya data isipatikane kwenye kache inaposomwa tena, kisha kache hujazwa toleo jipya zaidi la data.

Pia tumepunguza sana muda wa kusubiri kwa kuondoa mzigo wa ziada katika huduma ya Habitat yenyewe: tumeandika upya msimbo kwa Rust, ambao una utendaji bora kuliko Python ya awali.

Kwa pamoja, mabadiliko haya yamepunguza p50 yetu ya jumla ya usomaji duniani kutoka takriban ms 120 hadi ms 10, uboreshaji wa mara 12 tangu tulipoanza kuzingatia utendaji mapema mwaka huu.

Ingawa kache imepunguza sana muda wa wastani wa kati wa kusubiri, maombi ya polepole zaidi bado yanahitaji kuchukua data isiyo kwenye kache kutoka hifadhi ya msingi, mara nyingi katika maeneo ya mbali. Uwezo zaidi unapoanza kutumika na tunapoboresha ufanisi wa hifadhi, tunapanga kutatua changamoto ya msingi zaidi: kuweka data karibu na mahali itakapofikiwa tangu mwanzo.

CDC inayotegemewa na inayoweza kupanuliwa—kusambaza mabadiliko ya hifadhidata kwa mifumo inayoyapokea—ni kipengele muhimu zaidi ya mkakati wa kache wa Habitat pekee. Mamilioni ya mabadiliko yanayonaswa kwa sekunde, katika maelfu ya kontena na mamilioni ya vizigeu vyake, hupitia zaidi ya mada mia moja za Kafka. Pia huwezesha faharasa za ziada zinazolingana hatimaye, mifumo ya kuhamisha data, uchanganuzi usio wa papo hapo na vipengele vingine vya bidhaa vya wakati halisi. Miundombinu yetu ya msingi ilipopanuka duniani kote, kufuatilia mabadiliko ya safu mlalo kulizidi kuwa kugumu. Programu mteja ikitaka kusajili kitendakazi kiitwe kila safu mlalo za aina yake zinapobadilika, lazima kwanza ijue, miongoni mwa mambo mengine, akaunti na kontena za Cosmos zenye data yake, na huduma ya CDC inayofuatilia kontena hizo katika kila eneo. Pia lazima ipange ipasavyo uwezo wa kundi la vichakataji vya CDC, Kafka na programu yake inayopokea data. Jukwaa letu la CDC linalenga kuwaondolea watengenezaji wa bidhaa ugumu huu wote. Badala yake, linatoa kiolesura rahisi ambako programu mteja husajili kitendakazi kitakachoitwa safu mlalo zake zinapobadilika, nasi tunashughulikia miunganisho na upanuzi wote.

Safu ya udhibiti ya ndani huhakikisha daima kuwa mabadiliko yananaswa kutoka kontena zote zinazohitajika, huchagua maeneo ya Cosmos ya kusoma, na kugawa kazi kwa ufanisi kati ya maelfu ya vichakataji katika maeneo mengi ya kijiografia. Kutumia maeneo yenye nakala na kusoma mitiririko kwa kipaumbele cha chini hulinda maombi ya Habitat yanayohitaji majibu ya haraka dhidi ya kazi za kunasa mabadiliko chinichini. Katika kundi kubwa hivi, vichakataji huanguka, kontena hupata matatizo, hifadhi za ruhusa za muda hupata hitilafu, mipangilio huwa batili, na mifumo inayopokea data hushindwa mara kwa mara. Tuliimarisha mzunguko wa maisha wa vichakataji vya CDC na ushughulikiaji wa ruhusa za muda, tukatenganisha hitilafu kati ya mitiririko, na kujenga kinga kwa mabadiliko ya mipangilio na utoaji wa matoleo. Tunatumia foleni za ujumbe ulioshindwa kuwasilishwa ili hitilafu za kudumu za uwasilishaji zisizuie ujumbe mwingine kwenye foleni. Tunahimili kukatika kwa huduma katika eneo kwa kuelekeza visomaji kwenye maeneo mengine ya Cosmos. Katika kiwango chetu, tumelazimika hata kubadilisha SDK ya CDC ya Azure ili kuboresha ufanisi wa kuhifadhi alama za maendeleo. Tunazikusanya katika makundi kwenye kumbukumbu na kuziandika kwenye hifadhi kwa vipindi tu.

Ingawa matumizi ya ndani ya Azure Cosmos DB katika Habitat ni changamano, thamani yake daima imekuwa kuwaondolea watengenezaji wa bidhaa haja ya kushughulikia maelezo ya miundombinu ili kuharakisha utengenezaji wa bidhaa. Jukwaa letu la CDC lina lengo hilohilo.

Timu ndogo iliweza kusaidia jukwaa la hifadhi linalokua kwa kasi kwa kuweka kimakusudi API ya hifadhi na wigo mdogo, kuendelea kupanua huduma ya Python, na kutanguliza changamoto za kihandisi zilizohitaji kushughulikiwa haraka zaidi. Tulianza kwa kuzingatia kutegemewa kwa maombi muhimu kabisa ya bidhaa, kisha utendaji wa usomaji kwa watumiaji duniani kote, na hatimaye ufanisi wa uendeshaji katika kiwango kikubwa. Mbinu hii iliwezesha ukuaji wa kasi na matumizi mapya huku ikiboresha kutegemewa, utendaji na kasi ya utengenezaji wa bidhaa.

Ili kupanua Habitat na hifadhi ya mazungumzo kwa watumiaji bilioni moja wanaofuata, tunahitaji kutatua ugumu wa kusambaza nakala za data katika miundombinu yetu kwa kiwango kikubwa zaidi. Ili kujiandaa mapema, tumekuwa tukijenga wenyewe mfumo maalumu wa hifadhi ya mtandaoni wa kiwango cha eksabaiti, ulioboreshwa kwa aina kubwa za data za Habitat. Mfumo huu unaoendelea kutengenezwa unaunganisha kiini cha RocksDB Cloud kutoka Rockset na usambazaji wa nakala unaotumia Raft. Unatumia muundo uleule wa hati wa Azure Cosmos DB, lakini hutumia hifadhi iliyotenganishwa na ukokotoaji pamoja na usambazaji wa nakala katika ngazi halisi ili kupunguza uwezo wa hifadhi ya flash unaohitajika, kwa kukubali kiwango cha juu cha qps kilicho chini zaidi.

Ikiwa ungependa kufanya kazi za aina hii za miundombinu ya data katika kiwango cha mpaka, angalia nafasi zetu za kazi zilizo wazi⁠.