1 અબજથી વધુ ChatGPT વપરાશકર્તાઓ માટે ઑનલાઇન સંગ્રહનું ઝડપી વિસ્તરણ (ભાગ 2)

OpenAI ની તમામ પ્રોડક્ટ્સને ડેટા સુધી ઝડપી અને વિશ્વસનીય ઍક્સેસની જરૂર હોય છે, જે અમારું સ્ટોરેજ પ્લેટફોર્મ Habitat પૂરું પાડે છે. આ પ્લેટફોર્મે 40 ભૌગોલિક વિસ્તારોમાં એક અબજથી વધુ વપરાશકર્તાઓને મિલિસેકન્ડ્સમાં પ્રતિસાદ આપવો પડે છે.અમારા ઇન્ફ્રાસ્ટ્રક્ચર સામે એક અસાધારણ પડકાર હતો: ઝડપથી વધી રહેલા વપરાશ અને નવા ઉપયોગના કિસ્સાઓને ટેકો આપવાની સાથે વિશ્વસનીયતા, કાર્યક્ષમતા અને પ્રોડક્ટ ડેવલપર્સની કામ કરવાની ઝડપમાં સતત સુધારો કરવો. આ પડકારનો ઉકેલ લાવવા માટે અમારા ઑનલાઇન સ્ટોરેજ પ્લેટફોર્મની ડિઝાઇન અને કામગીરીની પદ્ધતિ પર નવેસરથી વિચારવું જરૂરી હતું.અમે સતત વિવિધ વિકલ્પો વચ્ચેના ફાયદા-ગેરફાયદાનું મૂલ્યાંકન કરતા રહ્યા. આ માટે અમે એક નિશ્ચિત ક્રમ અનુસર્યો: સૌપ્રથમ, મિશન-ક્રિટિકલ પ્રોડક્ટ ટ્રાફિકને સંભાળી શકે એટલી વિશ્વસનીયતા હાંસલ કરવી; ત્યારબાદ, વૈશ્વિક વપરાશકર્તાઓની જરૂરિયાત મુજબ પૂરતી ઝડપ હાંસલ કરવી; અને અંતે, અત્યંત મોટા પાયે કામગીરીને કુશળતાપૂર્વક સંચાલિત કરવી.

આ બે ભાગની શ્રેણી સમજાવે છે કે અમે Habitat ને સરળ ક્લાયન્ટ લાઇબ્રેરી અને ડેટાબેઝમાંથી 500 પેટાબાઇટથી વધુ ડેટા પૂરો પાડતા, વિશ્વભરમાં વિતરિત સંગ્રહ પ્લેટફોર્મમાં કેવી રીતે વિકસાવ્યું. ભાગ 1 માં Habitatના પાયથન ક્લાયન્ટમાંથી સેવામાં થયેલા વિકાસ પર ધ્યાન આપ્યું હતું. તેમાં એવી તકનીકો પણ આવરી લીધી હતી, જેનાથી પાયથન-આધારિત સેવાને ઘણા લોકો વ્યવહારુ માને તેનાથી ઘણી આગળ લઈ જઈ શક્યા.

આ લેખમાં, એટલે કે ભાગ 2 માં, અમે મૂળ સંગ્રહ ઘટક 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 સુધી પહોંચી શકતાં નથી. તેના બદલે, એ જ ભૌતિક પાર્ટિશન પર રહેલી અન્ય દરેક તાર્કિક પાર્ટિશન કી સાથે તેમને ભૌતિક પાર્ટિશનની મર્યાદાઓ વહેંચવી પડે છે.

આથી વધુ સંસાધનો વાપરતા પડોશી કાર્યભારો ઘણી અસંબંધિત તાર્કિક પાર્ટિશન કીને અસર કરી શકતા. મર્યાદિત ઉપયોગવાળી ઉત્પાદન સુવિધાઓના ડેટા પર ચાલતા કાર્યભારો મુખ્ય પ્રવેશ અને નોંધણી પ્રક્રિયાઓમાં વિક્ષેપ પાડતા.

કોઈ ભૌતિક પાર્ટિશનની થ્રૂપુટ મર્યાદા પણ બદલાતી રહે છે; તે એઝ્યોર કોસ્મોસ ડીબી કન્ટેનરને ફાળવેલા કુલ થ્રૂપુટ પર આધારિત છે. કન્ટેનર માટે ફાળવેલો થ્રૂપુટ તેના ભૌતિક પાર્ટિશનો વચ્ચે લગભગ સરખે ભાગે વહેંચાય છે.

ડેટા વધતાં ભૌતિક પાર્ટિશન વિભાજિત થાય છે. તેથી પાર્ટિશનની કુલ સંખ્યા વધે છે, પરંતુ કુલ ફાળવેલો થ્રૂપુટ બદલાતો નથી. પરિણામે ડેટાનું કદ વધે તેમ દરેક પાર્ટિશનની અસરકારક થ્રૂપુટ મર્યાદા ઘટે છે.

અમારા સૌથી વધુ સંગ્રહ માગતા, બ્લોબ જેવા ઉપયોગોમાં આનાથી એવી નિષ્ફળતા સર્જાય છે કે વિનંતીનો દર અને ઉપયોગ સ્થિર હોવા છતાં માત્ર સંગ્રહ વધવાથી સક્રિય કાર્યભારોની થ્રૂપુટ ક્ષમતા ઘટે છે.

અલગ કન્ટેનર આ પાર્ટિશન કી મર્યાદાઓ અને પડોશી કાર્યભારોના ઉપદ્રવને આંશિક રીતે ઉકેલવામાં મદદ કરે છે. અલગ કન્ટેનર વાપરવાથી દરેકને સ્વતંત્ર ભૌતિક પાર્ટિશન ફાળવી શકાય છે. પછી માત્ર એ કન્ટેનરના પોતાના કાર્યભારો જ એકબીજાને નડી શકે અથવા તેમની પાર્ટિશન કી પરસ્પર અથડાઈ શકે. પરંતુ નવા કન્ટેનર ગોઠવવામાં વધારાનું કામ થાય છે—દરેક માટે અલગ ક્ષમતા આયોજન જરૂરી છે. તેથી અમે ફક્ત યોગ્ય સેવા કે ઉપયોગના આધારે જ અલગ કન્ટેનર બનાવવા માગીએ છીએ.

મજબૂત અલગાવની જરૂર ધરાવતા સૌથી નિર્ણાયક નવા ઉપયોગો માટે અમે અલગ એઝ્યોર કોસ્મોસ ડીબી કન્ટેનર વાપરવા લાગ્યા. સાથે, નબળાં પાર્ટિશન સંભાળવા દરેક કન્ટેનરના કુલ ફાળવેલા થ્રૂપુટને તેના ભૌતિક પાર્ટિશનની સંખ્યા સાથે સુસંગત કરતી સ્ક્રિપ્ટ વાપરી. આથી અમને નડતી લગભગ બધી સમસ્યાઓ ટાળી શક્યા.

જોકે, શરૂઆત મૂળભૂત કન્ટેનરથી કરી હોવાથી ઘણા જૂના નિર્ણાયક ઉપયોગો કમનસીબે ડેટા સ્થળાંતર વિના તેમાં જ અટવાઈ ગયા હતા. હજી પણ સહિયારા મૂળભૂત કન્ટેનરના ડેટા પર નિર્ભર નિર્ણાયક સેવાઓને સુરક્ષિત રાખવા અમે ટીમોને નવી સેવાઓ કે મોટી ઉત્પાદન સુવિધાઓ માટે અલગ કન્ટેનર બનાવવાની સલાહ આપતા. અમે વિસ્તર્યા તેમ મૂળભૂત કન્ટેનર પર દબાણ અને કાર્યરત સિસ્ટમમાં સમસ્યાઓ બંને વધ્યાં. મૂળભૂત કન્ટેનર પર વધુ ભાર ન પડે તે માટે જ અમે દરેક નવી સેવા કે મોટી ઉત્પાદન સુવિધા માટે કન્ટેનર ફાળવવા લાગ્યા.

આનાથી સમગ્ર સાઇટ ઠપ થવાના ઘણા કિસ્સા ટળ્યા અને અસર માત્ર સંબંધિત સુવિધા કે સેવાની કામગીરી બગડવા સુધી મર્યાદિત રહી. પરંતુ આખરે નવા કન્ટેનર ગોઠવવાનું વધારાનું કામ અમને નડવા લાગ્યું:

જૂના સહિયારા મૂળભૂત કન્ટેનરમાં કોઈ નવો ઉપયોગ 0થી 10 લાખ QPS થાય તો પણ કુલ વપરાશમાં મોટો ફેરફાર થવાની શક્યતા ઓછી હતી. પરંતુ અલગ કન્ટેનરમાં નવો ઉપયોગ 0થી 10 લાખ QPS થાય તો તે માત્ર આંતરિક પરીક્ષણ વખતે રહેતા મૂળ ભાર કરતાં 1,000 ગણો વધુ ભાર બની શકે.

સમર્પિત કન્ટેનર હોવાથી ટીમોએ હવે ઉત્પાદન રજૂ કરતાં પહેલાં અપેક્ષિત થ્રૂપુટ જેટલી ક્ષમતા ફાળવવાનું યાદ રાખવું પડતું. ઉત્પાદન ટીમો ઘણી વાર આગોતરી ક્ષમતા વધારવાનું ભૂલીને સુવિધાઓ જાહેર કરી દેતી. પછી રજૂઆતના દિવસે અમે ગંભીર ઘટનાના સંકલન કક્ષમાં બેસીને છેલ્લી ઘડીએ કન્ટેનરની ક્ષમતા વધારવા મથતા.

જુદા કાર્યભારો ભેળવવાનો આ બહુ-ટેનન્ટ સિસ્ટમોનો મુખ્ય લાભ છે. આ કન્ટેનર વ્યૂહરચનામાં વધુ સારા અલગાવ માટે અમે એ લાભ ગુમાવીએ છીએ.

સમય જતાં, સમર્પિત કન્ટેનરના ઉપયોગ પર નજર રાખવા પણ ટ્રાફિક ક્યારે બદલાશે કે વધશે તે અંગે ઉત્પાદનનું ઊંડું જ્ઞાન જરૂરી બન્યું.

વૃદ્ધિના વલણ પ્રમાણે દરેક કન્ટેનરનો ફાળવેલો થ્રૂપુટ વધારવા અમે નિયંત્રણ સ્તરની સરળ સ્ક્રિપ્ટ આપી શકીએ. પરંતુ એકંદર વૃદ્ધિ સ્થિર ન હોવાથી યોગ્ય વિસ્તરણ માટે OpenAIની લગભગ દરેક ઉત્પાદન ટીમે ક્ષમતા આયોજનમાં ભાગ લેવો પડ્યો.

સંસ્થા વિસ્તરતાં આ પદ્ધતિ ટકી નહીં, કારણ કે દરેક સેવાની જવાબદાર ટીમ પોતાની એઝ્યોર કોસ્મોસ ડીબી ક્ષમતા ફાળવણીમાં કેટલી કાળજી રાખતી તેમાં મોટો તફાવત હતો.

સંસ્થા વધતાં આ સંચાલકીય સમસ્યાઓ સંભાળવી મુશ્કેલ બની. આયોજન માટે એક કેન્દ્રીય ટીમ ન હોવાથી ઘણી ટીમોનું આયોજન નબળું રહ્યું. પરિણામે, અમે ફરી બહુ-ટેનન્ટ ઉકેલ તરફ વળ્યા. સહિયારી ટેનન્સીની રચના દ્વારા મૂળ બહુ-ટેનન્ટ સમસ્યાઓ ઉકેલવા એઝ્યોર ટીમ સાથે ગાઢ સહયોગ કર્યો:

સૌથી સક્રિય કીની વિનંતીઓ પહેલાં મર્યાદિત કરવાથી વધુ ભારવાળા પડોશી કાર્યભારો કોઈ ભૌતિક પાર્ટિશનનો આખો ઉપલબ્ધ થ્રૂપુટ વાપરી શકતા નથી. આથી એક અતિસક્રિય કીની અસર આખી સાઇટ પર પડવાનો ઉપદ્રવ ઘટે છે.

એ જ રીતે, વિનંતીઓને સ્તરોમાં વહેંચતી QoS વ્યવસ્થા મોટા પાયે ડેટા દાખલ કે બહાર કાઢતા ઑફલાઇન કાર્યભારોને ભૌતિક પાર્ટિશનનો આખો થ્રૂપુટ વાપરતા રોકે છે. આ કાર્યભારોની વિનંતીઓને ઓછી પ્રાથમિકતા આપવાથી તે પહેલાં મર્યાદિત થાય છે. તેથી અંતિમ વપરાશકર્તાઓને સેવા આપતી વધુ પ્રાથમિકતાવાળી સંવાદાત્મક વિનંતીઓ મર્યાદિત થતી નથી.

એઝ્યોર કોસ્મોસ ડીબીમાં પહેલેથી સર્વરરહિત મોડ હતો, જે પૂર્વફાળવેલી ક્ષમતાવાળા મોડમાં થતી નબળાં પાર્ટિશનની અમારી સમસ્યા ઉકેલી શક્યો હોત. પરંતુ તેની મોટી ખામી હતી: તે માત્ર સંગ્રહના ઉપયોગ પ્રમાણે વિસ્તરતો અને દરેક ભૌતિક પાર્ટિશનનો RU ઉપયોગ 5 હજાર RU/s સુધી મર્યાદિત રાખતો. આનાથી નબળાં પાર્ટિશનની સમસ્યા ઉકેલાત, પરંતુ વધુ RU વાપરતા ઉપયોગોને વિસ્તારી શકાત નહીં.

એઝ્યોર કોસ્મોસ ડીબી ટીમે અમારા માટે સુધારેલો સર્વરરહિત મોડ બનાવ્યો. તેમાં દરેક ભૌતિક પાર્ટિશન 10 હજાર RU/s સુધી વિસ્તરી શકતું અને સંગ્રહ ઉપરાંત RU ઉપયોગના આધારે પણ વિભાજન થતું. આથી કન્ટેનર પર જાતે નજર રાખીને ક્ષમતા વધારવાની જરૂર રહી નહીં.

આ ફેરફારોથી અમે ફરી એક સહિયારું કન્ટેનર વાપરી શક્યા. કાર્યભારો વચ્ચે અલગાવ જાળવીને ઉત્પાદન ટીમો માટે આગોતરું કે સતત ક્ષમતા આયોજન ઘણું સરળ બન્યું. ત્યાર પછીના મહિનાઓમાં ઉત્પાદન વિકાસ ઝડપી બન્યો હોવા છતાં ક્ષમતા ફાળવણી કે પડોશી કાર્યભારના ઉપદ્રવની એક પણ ઘટના બની નથી.

કંપનીઓ OpenAI જેટલી મોટી થાય ત્યારે સંચાલિત સેવાઓ ઓછી “સંચાલિત” રહે છે. ઘણા કાર્યભારો ક્લાઉડ પ્રદાતાના માળખામાં અસામાન્ય કિસ્સા બની જાય છે. OpenAI એઝ્યોર કોસ્મોસ ડીબીના સૌથી મોટા વપરાશકર્તાઓમાંનું એક બન્યું, ત્યારે તેને સફળતાથી ચલાવવા અલગ અભિગમ જરૂરી બન્યો: સહિયારાં પરીક્ષણો, સહિયારાં ડેશબોર્ડ, સીધા ઇજનેરી સંચારમાર્ગો અને માત્ર અમારા પાયે દેખાતી નિષ્ફળતાઓની સંયુક્ત જવાબદારી. આજે અમારું સૌથી મોટું એઝ્યોર કોસ્મોસ ડીબી ખાતું દસીઓ પેટાબાઇટ ડેટા સંગ્રહે છે અને 2 કરોડથી વધુ QPS સંભાળે છે. અમારી જાણ મુજબ, આટલા મોટા પાયે એઝ્યોર કોસ્મોસ ડીબી વાપરતી અમે એકમાત્ર કંપની છીએ.

2024ના અંતમાં એક પ્રાદેશિક સેવા અવરોધે સ્પષ્ટ કર્યું કે આ સહયોગ શા માટે જરૂરી હતો. એ વખતે અમારા સૌથી મોટા એઝ્યોર કોસ્મોસ ડીબી ખાતાંમાંથી એકના મુખ્ય એઝ્યોર પ્રદેશમાં વીજળી જતી રહી. ત્યાર પછી સેવા ગૌણ પ્રદેશમાં ખસેડતાં સમજાયું કે અમારાં સૌથી મોટાં ખાતાંને આમ ખસેડવામાં ઘણા કલાકો લાગશે. અમારી કે એઝ્યોર કોસ્મોસ ડીબી ટીમે અમારા પાયે આનું પરીક્ષણ કર્યું નહોતું.

લગભગ એક મહિના પછી એ ખાતાંને મૂળ પ્રદેશમાં પાછાં ખસેડતાં અમારી કામગીરીથી ફરી ગંભીર સેવા અવરોધ સર્જાયો. મૂળ પ્રદેશમાં એકસાથે જોડાણોનો ધસારો થતાં ત્યાંનું એઝ્યોર કોસ્મોસ ડીબી ગેટવે ભાર સહન ન કરી શક્યું. ગેટવે-મોડના એઝ્યોર કોસ્મોસ ડીબી ક્લાયન્ટની પ્રદેશ બદલવાની રીતમાં એક વિચિત્રતા હતી. માત્ર અમુક ભૌતિક પાર્ટિશન મૂળ પ્રદેશમાં પાછાં આવ્યાં હોવા છતાં બધા ક્લાયન્ટ તરત ત્યાં જોડાણ બનાવીને વિનંતીઓ મોકલવા લાગ્યા.

દરેક અવરોધ વખતે OpenAI અને એઝ્યોરે પોતાની ઘટના વ્યવસ્થાપન પ્રક્રિયાઓ અનુસરી, અનેક મૂળ કારણો શોધ્યાં અને સુધારા લાગુ કર્યા. પરંતુ આ અવરોધો અમારી અને એઝ્યોર કોસ્મોસ ડીબી ટીમની સંચાલન તથા પરીક્ષણ પદ્ધતિઓ વચ્ચેની વધુ મોટી પ્રણાલીગત સમસ્યાનાં લક્ષણો હતા. શરૂઆતમાં સંચાલિત સેવાઓના ઉપયોગથી અમે ઝડપથી આગળ વધી શક્યા અને વ્યવસાયિક લક્ષ્યો પર ધ્યાન આપી શક્યા. મોટા પાયે સંચાલિત સેવાઓ ઓછી સંચાલિત રહે છે અને રચનાથી સંચાલન સુધીના દરેક સ્તરે સેવા પ્રદાતા સાથે ઊંડું સંકલન જરૂરી બને છે.

આજે હેબિટેટ અને એઝ્યોરની ઇજનેરી ટીમો અમારા સેવા સ્તરથી એઝ્યોર કોસ્મોસ ડીબીના ભૌતિક સંગ્રહ સ્તર સુધી હેબિટેટના દરેક સ્તરનું સંયુક્ત નિરીક્ષણ કરે છે. અમે વાસ્તવિક કાર્યરત સિસ્ટમ જેટલા કદના, પરંતુ વપરાશકર્તાઓને સેવા ન આપતા એઝ્યોર કોસ્મોસ ડીબી ખાતામાં ફેરફારો ચલાવીએ અને ચકાસીએ છીએ. અમે સાથે મળીને SDKનું પરીક્ષણ અને સુધારણા કરીએ છીએ તથા એઝ્યોર કોસ્મોસ ડીબી ખાતાંના કદ અને વિસ્તરણ માટે શ્રેષ્ઠ પદ્ધતિઓ નક્કી કરીએ છીએ. ટીમ્સ દ્વારા અમે સીધો ઇજનેરી સંપર્ક કરી શકીએ છીએ. સહાયનાં વિવિધ સ્તરોમાંથી પસાર થયા વિના એકબીજાને સીધી તાત્કાલિક ચેતવણી મોકલવાની વ્યવસ્થા પણ કરી છે.

Azure Cosmos DB ના કંટ્રોલ પ્લેન અને ગેટવેની સ્કેલેબિલિટી વધારવા માટે છેલ્લા એક વર્ષમાં વ્યાપક સહયોગથી કામ કરવામાં આવ્યું છે. આ અંતર્ગત, Azure Cosmos DB ના મેટાડેટા પાર્ટિશન પરનો ભાર ઘટાડવા માટે લોડ પ્રોટેક્શનની સુવિધા ઉમેરવામાં આવી છે અને ગેટવેમાં Azure Cosmos DB ના વિવિધ મેટાડેટાને કૅશ કરવામાં આવ્યા છે. કનેક્શન પૂલિંગ અને કનેક્શનનો હાઇ પુનઃઉપયોગ કરીને Python હૅબિટેટ-સર્વિસ પ્રોસેસિસના સમગ્ર સમૂહ પરનું દબાણ ઘટાડવામાં આવ્યું છે. શક્ય હોય ત્યાં વર્કલોડ્સને એક જ જગ્યાએ રાખવામાં આવ્યા છે અને અલગ-અલગ VPCs નો ઉપયોગ કરીને મહત્ત્વપૂર્ણ વર્કલોડ્સને ઑફલાઇન વર્કલોડ્સથી અલગ રાખવામાં આવ્યા છે.

છેલ્લા એક વર્ષમાં Azure Cosmos DB ની સ્થિરતા જાળવવામાં સહ-એન્જિનિયરિંગના આ સ્તરની મહત્ત્વપૂર્ણ ભૂમિકા રહી છે. કોઈપણ સિસ્ટમનું કદ અથવા તેનું મહત્ત્વ એટલું વધારે હોય કે આવી ટીમવર્કની જરૂર પડે, ત્યારે વિવિધ ટીમો વચ્ચેની માલિકીની દીવાલો દૂર કરીને અને સંગઠનાત્મક સીમાઓથી પર રહીને સાથે મળીને કામ કરવું અનિવાર્ય બને છે.

ભાગ 1 માં જણાવ્યા મુજબ, અમારો મૂળ સિદ્ધાંત છે: પહેલાં કાર્યરત બનાવો, પછી ઝડપી, પછી સસ્તું. પહેલાં વિશ્વસનીયતા, પછી કામગીરી, પછી સંસાધનોની કાર્યક્ષમતા. 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) પર આધારિત છે. આના દ્વારા સમગ્ર વિશ્વમાં માત્ર થોડી જ સેકન્ડોમાં કૅશ ઇનવેલિડેશનની પ્રક્રિયા પહોંચાડવામાં આવે છે. પરિણામે, કૅશ હિટ રેટ ઊંચો રહે છે અને ડેટા જૂનો થઈ જવાની શક્યતા ઓછી રહે છે.અમારા ઇન્ફ્રાસ્ટ્રક્ચરમાં આવેલી એક સર્વિસ આ ચેન્જ ફીડમાંથી ડેટા મેળવે છે અને જ્યારે અંતર્ગત ડેટા અપડેટ થાય છે, ત્યારે સ્થાનિક કૅશમાં ઇનવેલિડેશન પ્રક્રિયા ચલાવે છે. આથી, આગલી વખતે એ ડેટા વાંચવાની વિનંતી આવે ત્યારે કૅશ મિસ થાય છે અને કૅશમાં ડેટાનું સૌથી નવું વર્ઝન ભરવામાં આવે છે.

અમે Habitat સેવાનો કોડ રસ્ટમાં ફરી લખીને તેની પોતાની વધારાની પ્રક્રિયાઓનો ભાર દૂર કર્યો અને વિલંબ ઘણો ઘટાડ્યો. રસ્ટ મૂળ પાયથન કરતાં વધુ ઝડપી છે.

આ ફેરફારોએ મળીને અમારો એકંદર વૈશ્વિક વાંચન p50 આશરે 120થી ઘટાડીને 10 મિલિસેકન્ડ કર્યો છે. આ વર્ષની શરૂઆતમાં કામગીરી પર ધ્યાન આપવાનું શરૂ કર્યું ત્યારથી આ 12 ગણો સુધારો છે.

કૅશિંગથી મધ્યક વિલંબ ઘણો ઘટ્યો છે, છતાં સૌથી ધીમી વિનંતીઓ માટે કૅશમાં ન હોય એવો ડેટા મૂળ સંગ્રહમાંથી, ઘણી વાર દૂરના પ્રદેશોમાંથી, મેળવવો પડે છે. વધુ ક્ષમતા ઉપલબ્ધ થાય અને અમે સંગ્રહ કાર્યક્ષમતા સુધારીએ તેમ વધુ મૂળભૂત પડકાર ઉકેલવાની યોજના છે: ડેટા જ્યાંથી વપરાશે તેની નજીક શરૂઆતથી જ રાખવો.

વિશ્વસનીય અને મોટા પાયે કાર્ય કરી શકે તેવું CDC —એટલે કે ડેટાબેઝમાં થતા ફેરફારોને તેના પર આધારિત અન્ય સિસ્ટમ્સ સુધી પહોંચાડવાની પ્રક્રિયા—માત્ર Habitatની કૅશિંગ વ્યૂહરચના માટે જ નહીં, પરંતુ અન્ય અનેક હેતુઓ માટે પણ એક મહત્ત્વપૂર્ણ ઘટક છે.દર સેકન્ડે કૅપ્ચર થતા લાખો ફેરફારો, હજારો કન્ટેનર્સ અને લાખો કન્ટેનર પાર્ટિશન્સમાંથી પસાર થઈને, સોથી વધુ Kafka ટૉપિક્સ દ્વારા આગળ પહોંચે છે. આ ફેરફારોનો ઉપયોગ આખરે સુસંગતતા જાળવતા સેકન્ડરી ઇન્ડેક્સિસ, ડેટા-મૂવમેન્ટ પાઇપલાઇન્સ, ઑફલાઇન ઍનાલિટિક્સ અને અન્ય રિયલ-ટાઇમ પ્રોડક્ટ ફીચર્સને કાર્યરત રાખવા માટે પણ થાય છે.જેમ જેમ આપણું બેકિંગ ઇન્ફ્રાસ્ટ્રક્ચર વૈશ્વિક સ્તરે વિસ્તર્યું છે, તેમ તેમ રો (Row)માં થતા ફેરફારોને સાંભળવાની પ્રક્રિયા વધુ ને વધુ જટિલ બની છે. જો કોઈ ક્લાયન્ટ ઇચ્છે કે તેના પ્રકારના રોમાં ફેરફાર થાય ત્યારે દર વખતે એક કૉલબૅક ફંક્શન ચાલે, તો તેણે અન્ય બાબતોની સાથે પહેલાં એ નક્કી કરવું પડે છે કે તેનો ડેટા કયા Cosmos એકાઉન્ટ્સ અને કન્ટેનર્સમાં છે, સંબંધિત રિજનમાં કયું CDC સર્વિસ ડિપ્લોયમેન્ટ તે કન્ટેનર્સના ફેરફારો સાંભળી રહ્યું છે અને CDC સર્વિસના વર્કર ફ્લીટ, Kafka તથા તેના કન્ઝ્યુમરને યોગ્ય રીતે કેવી રીતે સ્કેલ કરવા.અમારા CDC પ્લૅટફૉર્મનો હેતુ આ બધી જટિલતાઓ પ્રોડક્ટ ડેવલપર્સથી દૂર રાખવાનો છે. તેના બદલે, અમે એક સરળ વ્યવસ્થા પૂરી પાડીએ છીએ, જેમાં ક્લાયન્ટ્સ તેમના બદલાયેલા રો પર કયું ફંક્શન ચલાવવું છે તે રજિસ્ટર કરી શકે છે અને બાકીની તમામ આંતરિક પ્રક્રિયાઓ તથા સ્કેલિંગની જવાબદારી અમે સંભાળીએ છીએ.

આંતરિક નિયંત્રણ સ્તર સતત ખાતરી કરે છે કે બધાં જરૂરી કન્ટેનરના ફેરફારો નોંધાય છે. તે વાંચવા માટે કોસ્મોસ પ્રદેશો પસંદ કરે છે અને અનેક ભૌગોલિક પ્રદેશોના હજારો વર્કરમાં કામ કાર્યક્ષમ રીતે વહેંચે છે. પ્રતિકૃતિવાળા પ્રદેશો અને ઓછી પ્રાથમિકતાવાળા પ્રવાહ વાંચનનો ઉપયોગ વિલંબ પ્રત્યે સંવેદનશીલ Habitat ટ્રાફિકને પૃષ્ઠભૂમિમાં ફેરફારો નોંધતા કાર્યભારોથી સુરક્ષિત રાખે છે. આટલા મોટા સમૂહમાં વર્કર બંધ પડવા, કન્ટેનરની સમસ્યાઓ, લીઝ સંગ્રહની ભૂલો, અયોગ્ય ગોઠવણી અને ગંતવ્યની નિષ્ફળતાઓ સતત થતી રહે છે. અમે CDC વર્કરના જીવનચક્ર અને લીઝ સંચાલનને વધુ મજબૂત બનાવ્યાં, પ્રવાહોની નિષ્ફળતાને એકબીજાથી અલગ રાખી અને ગોઠવણી ફેરફારો તથા નવી આવૃત્તિઓ લાગુ કરવા સુરક્ષા વ્યવસ્થા બનાવી. કાયમી વિતરણ નિષ્ફળતાઓને કારણે કતારનું આગળનું કામ અટકે નહીં તે માટે અમે નિષ્ફળ સંદેશાઓની અલગ કતારો વાપરીએ છીએ. વાંચન પ્રક્રિયાઓને વૈકલ્પિક કોસ્મોસ પ્રદેશોમાં ફેરવીને અમે પ્રાદેશિક સેવા અવરોધો સહન કરીએ છીએ. અમારા પાયે એઝ્યોરના CDC SDKમાં પણ ફેરફાર કરવો પડ્યો. ચેકપૉઇન્ટ મેમરીમાં જૂથબદ્ધ કરીને માત્ર સમયાંતરે સંગ્રહમાં લખવાથી તેની ચેકપૉઇન્ટ પ્રક્રિયા વધુ કાર્યક્ષમ બનાવી.

Habitat માં Azure Cosmos DBનો આંતરિક ઉપયોગ જટિલ છે. છતાં તેનું મુખ્ય મૂલ્ય હંમેશાં ઉત્પાદન વિકાસકર્તાઓથી માળખાની વિગતો છુપાવી વિકાસની ગતિ વધારવાનું રહ્યું છે. અમારું CDC પ્લેટફોર્મ પણ એ જ કરે છે.

સ્ટોરેજ APIને જાણીજોઈને મર્યાદિત અને સરળ રાખીને, Python સર્વિસને સતત સ્કેલ કરીને અને એન્જિનિયરિંગના સૌથી તાત્કાલિક પડકારોને પ્રાથમિકતા આપીને, એક નાની ટીમ ઝડપથી વિકસતા સ્ટોરેજ પ્લૅટફૉર્મને સપોર્ટ કરી શકી.અમે સૌપ્રથમ મિશન-ક્રિટિકલ પ્રોડક્ટ ટ્રાફિકની વિશ્વસનીયતા સુધારવા પર ધ્યાન કેન્દ્રિત કર્યું, ત્યારબાદ વૈશ્વિક સ્તરે યુઝર્સ માટે રીડ પર્ફોર્મન્સ સુધાર્યું અને અંતે મોટા પાયે કામગીરીની કાર્યક્ષમતા વધારવા પર ધ્યાન આપ્યું.આ અભિગમથી વિશ્વસનીયતા, પર્ફોર્મન્સ અને પ્રોડક્ટ ડેવલપમેન્ટની ગતિમાં સુધારો કરવાની સાથે ઝડપથી વિકાસ કરવો અને નવા ઉપયોગો શક્ય બનાવવાનું પણ શક્ય બન્યું.

આગામી એક અબજ યુઝર્સ માટે Habitat અને કન્વર્સેશન સ્ટોરેજને મોટા પાયે વિસ્તૃત કરવા માટે, આપણા ઇન્ફ્રાસ્ટ્રક્ચરમાં વધુ વિશાળ પાયે ડેટાનું રિપ્લિકેશન કરવાની મુશ્કેલીનો ઉકેલ લાવવો જરૂરી છે.આ પડકારનો અગાઉથી સામનો કરવા માટે, અમે મોટા કદના Habitat ડેટા પ્રકારો માટે ખાસ ઑપ્ટિમાઇઝ કરેલી, એક્સાબાઇટ-સ્કેલની કસ્ટમ ઇન-હાઉસ ઑનલાઇન સ્ટોરેજ સિસ્ટમ વિકસાવી રહ્યા છીએ. વિકાસ હેઠળની આ સિસ્ટમમાં Rocksetનું RocksDB Cloud કોર અને Raft-આધારિત રિપ્લિકેશનનો સમન્વય કરવામાં આવ્યો છે.આ સિસ્ટમ Azure Cosmos DB જેવું જ ડૉક્યુમેન્ટ મોડલ અમલમાં મૂકે છે, પરંતુ તેમાં ડિ-એગ્રીગેટેડ સ્ટોરેજ અને ફિઝિકલ રિપ્લિકેશનનો ઉપયોગ થાય છે. તેના કારણે જરૂરી ફ્લૅશ સ્ટોરેજ ક્ષમતામાં ઘટાડો થાય છે, જોકે તેના બદલામાં મહત્તમ QPS ઓછો રહે છે.

જો તમને અત્યાધુનિક પાયે આવા ડેટા માળખાના પ્રયાસોમાં કામ કરવામાં રસ હોય, તો અમારા ખાલી હોદ્દાઓ જુઓ⁠.