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

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

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

આ લેખમાં, એટલે કે ભાગ 2માં, અમે મૂળ સંગ્રહ ઘટક એઝ્યોર કોસ્મોસ ડીબીને કેવી રીતે વિસ્તાર્યો તે સમજાવીએ છીએ. એઝ્યોર ટીમ સાથે ગાઢ સહયોગથી અમે સંયુક્ત રીતે સંચાલિત કન્ટેનરવાળો વ્યવહારુ બહુ-ટેનન્ટ અભિગમ વિકસાવ્યો, જે વિશાળ વૈશ્વિક પાયે ઉત્તમ વાંચન કામગીરી આપે છે.

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

તેનાથી વિપરીત, બહુ-ટેનન્ટ વ્યવસ્થા સંસાધન ફાળવણીનું વધુ સારું જ્ઞાન અને અનુભવ ધરાવતી કેન્દ્રીય ડેટાબેઝ ટીમને નિયંત્રણ સોંપે છે. પરંતુ બહુ-ટેનન્ટ વ્યવસ્થાની પોતાની સમસ્યાઓ છે. જેમ કે, એક ટેનન્ટ અસામાન્ય રીતે વધુ સંસાધનો વાપરે અને અન્ય ટેનન્ટને નુકસાન થાય એવો પડોશી કાર્યભારનો ઉપદ્રવ.

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

એઝ્યોર કોસ્મોસ ડીબી સાથેની અમારી યાત્રા સમજતાં પહેલાં થોડી મૂળભૂત માહિતી:

• એઝ્યોર કોસ્મોસ ડીબી ખાતું કન્ટેનરનો સમૂહ અને પ્રતિકૃતિ નીતિ નિર્ધારિત કરે છે

• દરેક કન્ટેનર માટે પ્રતિ સેકન્ડ વિનંતી એકમો (RU/s)માં ચોક્કસ થ્રૂપુટ ફાળવાય છે

• દરેક કન્ટેનરમાં ડેટા સામાન્ય રીતે નિર્દિષ્ટ તાર્કિક પાર્ટિશન કી પ્રમાણે શાર્ડમાં વહેંચીને સંગ્રહાય છે. દરેક તાર્કિક પાર્ટિશન કી માટે સંગ્રહ અને થ્રૂપુટની મર્યાદાઓ દસ્તાવેજોમાં આપેલી હોય છે

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

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

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

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

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

છેલ્લા વર્ષમાં એઝ્યોર કોસ્મોસ ડીબીના નિયંત્રણ સ્તર અને ગેટવેની વિસ્તરણક્ષમતા સુધારવા ઘણું સંયુક્ત કામ થયું છે. મેટાડેટા પાર્ટિશનને સુરક્ષિત રાખવા ગેટવેમાં ભાર સામે રક્ષણ અને વિવિધ મેટાડેટાનું કૅશિંગ ઉમેર્યું; જોડાણોના પૂલ અને વધુ પુનઃઉપયોગથી અમારી પાયથન habitat-service પ્રક્રિયાઓના સમૂહનું દબાણ ઘટાડ્યું; શક્ય હોય ત્યાં કાર્યભારો એક જ સ્થાને રાખ્યા; અને અલગ VPC વડે નિર્ણાયક કાર્યભારોને ઑફલાઇન કાર્યભારોથી અલગ કર્યા.

છેલ્લા વર્ષમાં એઝ્યોર કોસ્મોસ ડીબીની સ્થિરતા માટે આટલો ગાઢ ઇજનેરી સહયોગ નિર્ણાયક રહ્યો છે. પૂરતી મોટી કે નિર્ણાયક કોઈ પણ સિસ્ટમ માટે આવું ટીમવર્ક જરૂરી છે: જવાબદારીની દીવાલો તોડીને સંસ્થાકીય સીમાઓ પાર કામ કરવું.

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

ગણનક્ષમતા અને સંગ્રહક્ષમતા ઘણી વાર અલગ પ્રદેશોમાં હોવાથી આંતરપ્રદેશીય વિનંતીઓ અનિવાર્ય હતી.

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

2026માં આ અમારા ધ્યાનનું મુખ્ય કેન્દ્ર રહ્યું છે. હેબિટેટની 90%થી વધુ વિનંતીઓ વાંચન માટેની હોવાથી, તેની કામગીરી સુધારવા અમે બહુસ્તરીય વ્યૂહરચના વિકસાવી છે:

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

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

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

તેથી ડેટાનું સ્થાન નક્કી કરતી વખતે ઘણી વાર ઉત્પાદનના બે હિતો વચ્ચે સંતુલન સાધવું પડે છે: અ) જુદાં ઉત્પાદનો અને વપરાશકર્તા જૂથો માટે વિલંબ ઘટાડવો, અને બ) ઉપલબ્ધ સંગ્રહ તથા ગણનક્ષમતા.

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

અલગ પ્રતિકૃતિ ગોઠવણી ધરાવતાં ખાતાં વચ્ચે ડેટાસેટ ખસેડી શકીએ તે માટે હેબિટેટમાં વપરાશકર્તાને દેખાયા વિના ડેટા ખસેડતું અને વિનંતીઓ મોકલતું સ્તર ધાર્યા કરતાં વહેલું બનાવવું પડ્યું.

જોકે, અંતે આ અભિગમ પણ ક્ષમતાથી મર્યાદિત છે, તેથી તેનો ઉપયોગ થોડા પસંદ કરેલા ડેટાસેટ પૂરતો જ છે.

હેબિટેટના કાર્યભારોમાં વાંચનનું પ્રમાણ ઘણું ઊંચું છે. ઍપ્લિકેશનો સતત સેટિંગ, સ્થિતિ અને અન્ય ગુણધર્મો મેળવે છે. વારંવાર વપરાતા પ્રકારોના પ્રમાણમાં નાના સક્રિય સમૂહને કારણે ટ્રાફિકનો મોટો હિસ્સો સર્જાય છે. તેથી આ સિસ્ટમ વિતરિત કૅશિંગ માટે ખાસ અનુકૂળ છે. કૅશિંગ એક પ્રદેશના માળખામાં કામગીરી સુધારે છે. અનેક પ્રદેશોમાં કામ કરતી વખતે તેનો લાભ ઘણો વધે છે, કારણ કે તે આંતરપ્રદેશીય વિલંબને “છુપાવી” શકે છે.

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

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

અમે મેટાની TAO જેવી સિસ્ટમોના પગલે કૅશને અમાન્ય કરવા વધુ અદ્યતન અભિગમ અપનાવ્યો છે. હેબિટેટનો સંકલિત કૅશ એઝ્યોર કોસ્મોસ ડીબીના ફેરફાર પ્રવાહ દ્વારા ફેરફારિત ડેટાની નોંધ (CDC) પર આધાર રાખે છે. તે કૅશ અમાન્ય કરવાની સૂચનાઓ સેકન્ડોમાં વિશ્વભરમાં પહોંચાડે છે, જેથી ડેટા ઓછો જૂનો રહે અને કૅશમાં મળવાનો દર ઊંચો રહે. અમારા માળખાની એક સેવા આ ફેરફાર પ્રવાહ વાંચે છે અને મૂળ ડેટા બદલાય ત્યારે સ્થાનિક કૅશની નકલ અમાન્ય કરે છે. આથી આગલી વાર વાંચતી વખતે ડેટા કૅશમાં મળતો નથી અને કૅશમાં તેની નવીનતમ આવૃત્તિ ભરાય છે.

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

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

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

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

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

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

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

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

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