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

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

OpenAI ઉત્પાદનો જરૂરી માહિતી ઝડપથી અને વિશ્વસનીય રીતે મેળવી શકે તે માટે અમે બનાવેલું ઑનલાઇન સ્ટોરેજ પ્લેટફોર્મ Habitat છે. Habitat હવે લગભગ 40 ભૌગોલિક પ્રદેશોમાં દર અઠવાડિયે 1 અબજથી વધુ લોકો વાપરતાં ઉત્પાદનો માટે પ્રતિ સેકન્ડ 7 કરોડથી વધુ વિનંતીઓ સંભાળે છે. Habitat પ્રથમ વખત DevDay 2023માં GPTsને ટેકો આપવા શરૂ થયું હતું. શરૂઆતમાં તે એક ડેટાબેઝ સાથે જોડાયેલી સરળ Python ગ્રાહક-બાજુની લાઇબ્રેરી હતી. આજે તે 500 પેટાબાઇટથી વધુ ડેટા આપતી જટિલ વિતરિત પ્રણાલી છે.

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

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

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

Habitat એક સરળ વિચારથી શરૂ થયું: ઉત્પાદન ઇજનેરોએ ડેટાબેઝ સંચાલનની ચિંતા ન કરવી જોઈએ. Habitat પ્રથમ DevDay 2023માં GPTsને ટેકો આપવા ChatGPTના મુખ્ય સર્વર સાથે ક્રિયાપ્રતિક્રિયા કરતી નાની Python લાઇબ્રેરી તરીકે શરૂ થયું. તે કેટલીક કામગીરીને ટેકો આપતું હતું, જે આંતરિક રીતે Azure Cosmos DB ડેટાબેઝ ઍપ્લિકેશન સાથે જોડાતી હતી.

લાઇબ્રેરીનું કામ ઉત્પાદન ટીમોને અંતર્ગત વિગતોમાં નિપુણ થયા વિના ડેટા સંગ્રહવા અને મેળવવાની સરળ રીત આપવાનું હતું. Habitat જરૂરી કામ સંભાળતું હતું: કયા પ્રકારનો ડેટા છે, તે ક્યાંથી આવવો કે ક્યાં જવો જોઈએ, વિનંતીની મંજૂરી છે કે નહીં વગેરે નક્કી કરવું.

ઉત્પાદન ઇજનેરોએ સ્કીમા શોધ, રૂટિંગ, અધિકૃતતા, એન્ક્રિપ્શન, શ્રેણીકરણ, વિનંતી આકારણ અને જોડાણ સમૂહીકરણની ચિંતા કરવાની જરૂર નહોતી. ડેટા Azure Cosmos DB, કૅશ કે અન્ય સ્ટોરેજમાંથી ક્યાંથી આવે છે તે પણ વિચારવાની જરૂર નહોતી.

સ્વસેવા Postgres અને Azure Cosmos DB છોડવા કોઈ કેન્દ્રીય પ્રયાસ ન હોવા છતાં આ Python લાઇબ્રેરી સારી ચાલી અને OpenAIના ઉત્પાદન ઇજનેરોએ Habitat ઝડપથી અપનાવ્યું.

ઉત્પાદનની જરૂરિયાતો બદલાતાં વિકાસકર્તાઓ માટે ગ્રાહક-બાજુ કૅશિંગ, સંકોચન કે એન્ક્રિપ્શન જેવી સુવિધાઓનો ટેકો સહિયારી લાઇબ્રેરીમાં ઉમેરવો પણ સરળ હતો.

2025ના મધ્ય સુધીમાં ગ્રાહક-બાજુના અમલ તરીકે Habitat તેની મર્યાદાએ પહોંચી ગયું હતું. Habitat સ્તર વધુ જટિલ બનતાં અને OpenAIની સેવાઓની સંખ્યા વધતાં જૂની આવૃત્તિ સાથે સુસંગત પ્રોટોકૉલ ફેરફારો અવ્યવહારુ બન્યા હતા.

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

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

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

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

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

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

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

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

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

Asyncio Pythonને I/O-આધારિત કામ એકસાથે કરવામાં મદદ કરે છે, પરંતુ Python GILની મર્યાદા ટાળવામાં કે CPU સમાંતરતા આપવામાં મદદ કરતું નથી. I/O-પ્રધાન વિનંતી પ્રોક્સી કરવા ઉપરાંત Habitat અનેક CPU-પ્રધાન જવાબદારીઓ અને પૃષ્ઠભૂમિ કાર્યો સંભાળે છે: રૂટિંગ, સંકોચન, એન્ક્રિપ્શન, ચેકસમ, અનુગામી સેવાઓની સ્થિતિ તપાસ, વિનંતી શેડોઇંગ અને હેજિંગ.

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

OpenAIની Python સેવાઓમાં મેમરી, CPU, નેટવર્ક અને ડિસ્ક વપરાશના પ્રમાણભૂત ઉપયોગ તથા સંતૃપ્તિ માપદંડો ઉપરાંત asyncio લૂપ અને તેની વ્યસ્તતા પર નજર રાખવી અને તે મુજબ સુધારા કરવા અત્યંત જરૂરી છે.

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

પરિણામે, અમે દરેક પ્રક્રિયામાં માત્ર થોડી સમકાલીન વિનંતીઓ જ સંભાળીએ છીએ અને તેના બદલે Python કાર્યકર પ્રક્રિયાઓની સંખ્યા મોટા પાયે વધારીએ છીએ.

પ્રારંભિક સેવા લોન્ચ વખતે જીવંત CPU પ્રોફાઇલિંગથી અમને ઊંચા asyncio વિલંબનું એક મૂળ કારણ મળ્યું (અને તેના પરિણામે વધુ અંતિમ છેડાનો વિલંબ): Statsig દ્વારા અમારી ફીચર ફ્લૅગ ગોઠવણીઓનું સમયાંતરે JSON વિશ્લેષણ. Statsig ફીચર ફ્લૅગ સંચાલિત કરે છે અને A/B પરીક્ષણ વગેરે માટે વાપરી શકાય છે.

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

CPU પ્રોફાઇલિંગથી મૂળ કારણ મળ્યા પછી ઉપાય સરળ હતો: નાની અને લક્ષિત ગોઠવણી તૈનાત કરવી, તાજું કરવાનો સમયગાળો વધારવો અને આવા પૃષ્ઠભૂમિ કાર્યોમાં થોડી અસ્થિરતા ઉમેરવી.

asyncio વિલંબ ઓછો રાખવા સર્વર પ્રક્રિયાઓમાં વિનંતીઓનું સારું ભાર સંતુલન જાળવવું પણ આવશ્યક છે. યોગ્ય સુધારા વિના જોડાણ સમૂહીકરણ તેનો વિરોધી બની શકે છે.

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

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

અમને જોડાણ સમૂહ પર શંકા હતી. જોડાણના પુનઃઉપયોગની મહત્તમ અવધિ મર્યાદિત કરીને તપાસ કરતાં બગાડ મર્યાદિત થયો અને અમારી તપાસની દિશા સાચી હોવાનું સમર્થન મળ્યું. વધુ તપાસમાં જાણવા મળ્યું કે Pythonનું aiohttp TCPConnector મૂળભૂત રીતે LIFO જોડાણ પુનઃઉપયોગ કરે છે: આગામી વિનંતી માટે સૌથી તાજેતરમાં પાછું આવેલું જોડાણ પસંદ થાય છે. સામાન્ય રીતે આ યોગ્ય મૂળભૂત પસંદગી છે: તાજેતરનાં જોડાણો ફરી વાપરવાથી અચાનક ટ્રાફિક માટે બનાવેલાં વધારાનાં જોડાણો નિષ્ક્રિય થઈને સમયસમાપ્તિ પામે છે અને તેમને જાળવવાનો ભાર ઘટે છે. આ કિસ્સામાં તે અમારા માટે મેટાસ્ટેબલ નિષ્ફળતા સર્જતું હતું. વિનંતીઓના ધસારા દરમિયાન ધીમા અતિભારિત સર્વરની વિનંતીઓ જોડાણોને સમૂહમાં મોડાં પાછાં મોકલતી, તેથી અનુગામી વિનંતીઓ તેમને વધુ વાર પસંદ કરતી અને પહેલેથી સંઘર્ષ કરતા પોડ પર ધીમે ધીમે વધુ ટ્રાફિક કેન્દ્રિત થતો. FIFO પુનઃઉપયોગ માટે જોડાણ સમૂહમાં સુધારો કરવાથી આ પ્રતિપોષણ ચક્ર તૂટ્યું અને સ્થિર સ્થિતિમાં વિનંતીઓનો તફાવત પણ ઘટ્યો.

આજે OpenAIના સમગ્ર માળખામાં જોડાણ સમૂહીકરણ અને સર્વર ભારથી વધુ સારી રીતે માહિતગાર સંતુલન વ્યૂહરચનાઓ માટે અમે મુખ્યત્વે Istio અને Envoy પર આધાર રાખીએ છીએ અને આ સમસ્યા સંપૂર્ણપણે ટાળીએ છીએ.

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

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

જોડાણ એકત્રીકરણ મહત્તમ કરવા પણ અમે Envoy પર આધાર રાખીએ છીએ. બહુસંકેતીકરણનો લાભ લેવા અમે Pythonનાં HTTP/1 જોડાણોને HTTP/2માં અદ્યતન કરવા, પછી તેમનું સમૂહીકરણ કરવા અને જોડાણની આયુષ્ય વધારવા તેનો ઉપયોગ કરીએ છીએ. Envoy અમને દર મર્યાદા અને પરિપથ વિચ્છેદક અમલમાં મૂકવા માટે કેન્દ્રીય સ્થાન પણ આપે છે, જે દરેક સ્વતંત્ર Python પ્રક્રિયામાં ઓછાં અસરકારક રહેત.

Pythonને આટલા પાયે વિસ્તારી શકવાનું એક કારણ Habitatનું મર્યાદિત API હતું, જે વિનંતીનો ખર્ચ અનુમાનિત રાખે છે. ગ્રાહકોને વિશાળ કોષ્ટક સ્કૅન કે ઘણાં કોષ્ટકોના જોડાણ સર્જી શકે તેવી મનસ્વી SQL ક્વેરી બનાવવા દેવાને બદલે Habitat સરળ NoSQL API આપે છે. શક્તિશાળી API ન આપવું એ Habitatની રચનામાં ઇરાદાપૂર્વકની સમજૂતી છે.

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

Habitat અને Azure Cosmos DB પર જતા પહેલાં OpenAIનો મોટાભાગનો ઑનલાઇન ડેટા Postgresમાં સંગ્રહાતો હતો. ત્યારે ઉત્પાદન પર મોકલતાં પહેલાં બધી ક્વેરી અને સ્કીમાના ફેરફારો યોગ્ય રીતે વર્તે અને અનુક્રમિત ડેટા પર જ કામ કરે તેની સમીક્ષા કરવી સરળ હતી. ટીમ અને ઉત્પાદનો વધતાં આ ઝડપથી મુશ્કેલ બન્યું અને મહત્ત્વના માર્ગ પરની એક નવી ખર્ચાળ ક્વેરી ડેટાબેઝ બંધ કરી દેતી હોવાથી વારંવાર સેવા ખોરવાતી.

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

Habitat ગ્રાહક દ્વારા નિર્ધારિત ઑબ્જેક્ટ અને એજ પ્રકારો પર આધારિત, TAO⁠(નવી વિન્ડોમાં ખૂલે છે)થી પ્રેરિત NoSQL API આપે છે. ગ્રાહકો ઑબ્જેક્ટ, એજ અને તેમના પરસ્પર સંબંધો અગાઉથી નક્કી કરે છે, પરંતુ દરેક પ્રકારની સામગ્રી નહીં. પરિણામી સંબંધો ગ્રાફ જેવા છે, પરંતુ કોઈ ઑબ્જેક્ટની સીધી એજ પૂછવા સિવાય Habitat પોતે સામાન્ય ગ્રાફ માર્ગક્રમ ક્વેરીને ટેકો આપતું નથી.

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

વધુ જટિલ ક્વેરી જરૂરિયાતવાળા ગ્રાહકોને અમે Rockset દ્વારા ઉપલબ્ધ Habitatનું ઑફલાઇન ગૌણ દૃશ્ય આપીએ છીએ. અમે ફેરફાર ડેટા કૅપ્ચર (CDC)થી ઑનલાઇન સ્ટોરેજના ફેરફારો લગભગ રીઅલ ટાઇમમાં અલગ Rockset ઇન્સ્ટન્સમાં પ્રવાહિત કરીએ છીએ. દરેક ગ્રાહક ટીમ પોતાની જટિલ ક્વેરી જરૂરિયાતો માટે પોતાનું Rockset ઇન્સ્ટન્સ વિસ્તૃત કરવા જવાબદાર છે.

Rocksetની આ જોગવાઈ ગ્રાહકો માટે વધારાનો અવરોધ લાવે છે, પરંતુ અત્યારે આ યોગ્ય સમજૂતી લાગે છે: સરળ ક્વેરીને મૂળભૂત રાખવી અને જટિલ ક્વેરીની જરૂર હોય તેમને વૈકલ્પિક માર્ગ આપવો. આ રચના અમારા ઑનલાઇન સ્ટોરેજને વધુ વાંચનવાળા વિશ્લેષણ અને શોધના કામથી અલગ રાખે છે.

Pythonમાં ફરી લખવાનું એક વર્ષ મુલતવી રાખવાથી અતિવૃદ્ધિ દરમિયાન અમે વધુ તાત્કાલિક અને અસરકારક પડકારો પર ધ્યાન આપી શક્યા. પ્લેટફોર્મ પરિપક્વ થઈ રહ્યું હતું, વૃદ્ધિ વધુ ઝડપી બની રહી હતી અને OpenAIમાં કોરની સંખ્યાની દૃષ્ટિએ આ બીજી સૌથી મોટી સેવા તથા Envoy વ્યાપમાં ચોથી હતી, તેથી આખરે Python છોડવાનો સમય આવ્યો. ચરમ સમયે Pythonએ અમને પ્રતિ સેકન્ડ 2 કરોડથી વધુ વિનંતીઓ સંભાળવામાં મદદ કરી.

2026ના બીજા ત્રિમાસિકમાં માત્ર 2 ઇજનેર, Codex અને GPT‑5.5ની મદદથી અમે આખી સેવા Rustમાં ફરી લખી શક્યા. નવી Rust સેવા હવે અમારી 95% ઉત્પાદન વિનંતીઓ સંભાળે છે. આગામી અઠવાડિયાંમાં અમે Python સંપૂર્ણપણે નિવૃત્ત કરીશું. અમારો ડેટા બતાવે છે કે Rust સેવા Python આવૃત્તિ કરતાં CPUમાં 6 ગણી અને મેમરીમાં 15 ગણી વધુ કાર્યક્ષમ છે તથા તેનો સરેરાશ અને અંતિમ છેડાનો વિલંબ નોંધપાત્ર રીતે ઓછો છે. ભવિષ્યના બ્લૉગમાં અમે વધુ શીખ શેર કરીશું.

Python અને હવે Rust સેવા Habitatનો માત્ર એક પાસો છે. 1 અબજથી વધુ ChatGPT વપરાશકર્તાઓને સેવા આપવા અમે ઑનલાઇન સ્ટોરેજ ઝડપથી કેવી રીતે વિસ્તૃત કર્યું તે સમજાવતી આ શ્રેણીના બીજા ભાગમાં સ્ટોરેજ સ્તર તથા Habitat કેવી રીતે 500 પેટાબાઇટથી વધુ ડેટા અને પ્રતિ સેકન્ડ 7 કરોડથી વધુ વિનંતીઓ સંભાળે છે તેની વાત કરીશું.

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