100 കോടിയിലധികം ChatGPT ഉപയോക്താക്കൾക്കായി ഓൺലൈൻ സ്റ്റോറേജ് അതിവേഗം സ്കെയിൽ ചെയ്യുന്നു

ആരെങ്കിലും പ്രവേശിക്കുകയോ Codex ക്രമീകരണങ്ങൾ പരിശോധിക്കുകയോ ChatGPT‑യിൽ പുതിയ സംഭാഷണം തുടങ്ങുകയോ ചെയ്യുമ്പോൾ ഉൾപ്പെടെ, എല്ലാ OpenAI ഉൽപ്പന്നങ്ങളും ഡാറ്റയിലേക്കുള്ള വേഗമേറിയതും വിശ്വസനീയവുമായ പ്രവേശനത്തെ ആശ്രയിക്കുന്നു. ഉൽപ്പന്നത്തിന് പ്രതികരിക്കാനാകുന്നതിനുമുമ്പ് ആ ഓരോ പ്രവൃത്തിക്കും നിരവധി വ്യത്യസ്ത ഡാറ്റാ തിരച്ചിലുകൾ വേണ്ടിവന്നേക്കാം. ആ അഭ്യർത്ഥനകൾ മന്ദഗതിയിലാണെങ്കിൽ ഉൽപ്പന്നവും മന്ദഗതിയിലായി തോന്നും. ആ അഭ്യർത്ഥനകൾ പരാജയപ്പെട്ടാൽ ഉൽപ്പന്നത്തിന്റെ പ്രവർത്തനം പൂർണമായി നിലയ്ക്കും.

OpenAI ഉൽപ്പന്നങ്ങൾക്ക് ആവശ്യമായ വിവരങ്ങൾ വേഗത്തിലും വിശ്വസനീയമായും ലഭ്യമാക്കാൻ ഞങ്ങൾ നിർമ്മിച്ച ഓൺലൈൻ സ്റ്റോറേജ് പ്ലാറ്റ്‌ഫോമാണ് Habitat. ഏകദേശം 40 ഭൂമിശാസ്ത്ര മേഖലകളിലായി, ഓരോ ആഴ്ചയും 100 കോടിയിലധികം ആളുകൾ ഉപയോഗിക്കുന്ന ഉൽപ്പന്നങ്ങളെ പിന്തുണച്ച്, Habitat ഇപ്പോൾ സെക്കൻഡിൽ 7 കോടിയിലധികം അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യുന്നു. DevDay 2023-ൽ GPT‑കളെ പിന്തുണയ്ക്കാനാണ് Habitat ആദ്യം പുറത്തിറക്കിയത്. ഒറ്റ ഡാറ്റാബേസുമായി ബന്ധിപ്പിച്ച ലളിതമായ Python ക്ലയന്റ്-സൈഡ് ലൈബ്രറിയായാണ് അത് തുടങ്ങിയത്. ഇന്ന്, 500 പെറ്റാബൈറ്റിലധികം ഡാറ്റ കൈകാര്യം ചെയ്യുന്ന സങ്കീർണമായ വിതരണ സിസ്റ്റമാണിത്.

ഈ സ്കെയിലിൽ അടിസ്ഥാനസൗകര്യം നിർമ്മിക്കുകയും പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നത് എളുപ്പമല്ലെങ്കിലും അസാധാരണമാംവിധം പ്രയാസകരവുമല്ല. പക്വമായ പ്ലാറ്റ്‌ഫോം ഒരേസമയം നിർമ്മിച്ചുകൊണ്ട്, വിസ്മയകരമായ ഉപയോക്തൃവളർച്ചയും ഉൽപ്പന്ന ആവശ്യവും പിന്തുണയ്ക്കാൻ അഭൂതപൂർവ വേഗത്തിൽ സ്കെയിൽ ചെയ്യേണ്ടിവന്നതാണ് ഞങ്ങളുടെ സാഹചര്യത്തെ വ്യത്യസ്തമാക്കിയത്. സിസ്റ്റം എൻജിനീയർമാർ പലപ്പോഴും 10 മടങ്ങ് സ്കെയിലിനായി നിർമ്മിക്കുകയും അടുത്ത 10 മടങ്ങിനായി തയ്യാറെടുക്കുമ്പോൾ അത് ഏതാനും വർഷം നിലനിൽക്കുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. ഞങ്ങളുടെ കാര്യത്തിൽ, കഴിഞ്ഞ മൂന്ന് വർഷവും ഓരോ വർഷവും 10 മടങ്ങിലധികം വളർന്നു. അതിനാൽ Habitat നിർമ്മിക്കുകയും പ്രവർത്തിപ്പിക്കുകയും ചെയ്തത് തന്ത്രപരമായ തീരുമാനങ്ങളുടെയും അവയുടെ ക്രമീകരണത്തിന്റെയും പരമ്പരയായിരുന്നു. നിലവിലെ സംവിധാനത്തിന്റെ പരമാവധി ശേഷി നേടാൻ ഓരോ ഘടകവും അടിത്തട്ടുവരെ മനസ്സിലാക്കുകയും, അടിസ്ഥാന നിക്ഷേപങ്ങൾക്ക് സമയം നേടാൻ സ്റ്റോറേജ്, കംപ്യൂട്ട് ശേഷിക്കുറവുകൾ നേരിടുകയും ചെയ്തു.

OpenAI വളർന്നപ്പോൾ Habitat-ഉം ഒപ്പം വളരേണ്ടിവന്നു: ആദ്യം നിർണായക ഉൽപ്പന്ന ട്രാഫിക്കിന് വേണ്ടത്ര വിശ്വസനീയമായി, തുടർന്ന് ആഗോള ഉപയോക്താക്കൾക്ക് വേണ്ടത്ര വേഗത്തിൽ, ഒടുവിൽ വൻ സ്കെയിലിൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കാവുന്നവിധം. ഓൺലൈൻ സ്റ്റോറേജ് ഞങ്ങൾ എങ്ങനെ സ്കെയിൽ ചെയ്തുവെന്ന രണ്ട് ഭാഗങ്ങളുള്ള പരമ്പരയിലെ ആദ്യ കുറിപ്പാണിത്. Habitat എങ്ങനെ പരിണമിച്ചു, എന്തുകൊണ്ട് ലൈബ്രറിയിൽനിന്ന് സേവനമാക്കി, സേവനങ്ങൾക്ക് അപൂർവമായി ഉപയോഗിക്കുന്ന Python-ൽ എഴുതിയ സേവനത്തെ എങ്ങനെ വിശ്വസനീയമായ സ്റ്റോറേജ് പ്ലാറ്റ്‌ഫോം പാളിയായി വികസിപ്പിച്ചു എന്നിവ ഈ കുറിപ്പിൽ പങ്കിടുന്നു.

ഭാവിയിലെ കുറിപ്പിൽ, വലിയ സ്കെയിലിൽ മൾട്ടി-ടെനൻസി വിശ്വാസ്യത എങ്ങനെ കൈവരിച്ചു, വായനാ പ്രകടനം മെച്ചപ്പെടുത്താനുള്ള ഞങ്ങളുടെ പാളികളുള്ള തന്ത്രം, അഭൂതപൂർവ ആവശ്യം വിശ്വസനീയമായി കൈകാര്യം ചെയ്യാൻ Azure Cosmos DB-യുമായുള്ള പങ്കാളിത്തം എങ്ങനെ സ്കെയിൽ ചെയ്തു എന്നിവ വിശദീകരിക്കും.

ഉൽപ്പന്ന എൻജിനീയർമാർ ഡാറ്റാബേസ് മാനേജ്മെന്റിനെക്കുറിച്ച് ചിന്തിക്കേണ്ടതില്ല എന്ന ലളിതമായ ആശയത്തിൽനിന്നാണ് Habitat ആരംഭിച്ചത്. ChatGPT‑യുടെ പ്രധാന സെർവറുമായി ഇടപെടുന്ന ചെറിയ Python ലൈബ്രറിയായി, DevDay 2023-ൽ GPT‑കളെ പിന്തുണയ്ക്കാനാണ് Habitat ആദ്യം പുറത്തിറക്കിയത്. അടിയിൽ Azure Cosmos DB എന്ന ഡാറ്റാബേസ് ആപ്ലിക്കേഷനുമായി ബന്ധിപ്പിച്ചിരുന്ന ചെറിയൊരു കൂട്ടം പ്രവർത്തനങ്ങളെ അത് പിന്തുണച്ചു.

അടിസ്ഥാന സാങ്കേതികവിശദാംശങ്ങളിൽ പ്രാവീണ്യം നേടാതെ ഡാറ്റ സംഭരിക്കാനും വീണ്ടെടുക്കാനും ഉൽപ്പന്ന ടീമുകൾക്ക് ലളിതമായ മാർഗം നൽകുകയായിരുന്നു ലൈബ്രറിയുടെ ചുമതല. ഏത് തരത്തിലുള്ള ഡാറ്റയാണ്, അത് എവിടെനിന്ന് വരണം അല്ലെങ്കിൽ എവിടേക്ക് പോകണം, അഭ്യർത്ഥന അനുവദനീയമാണോ തുടങ്ങിയ ആവശ്യമായ കാര്യങ്ങൾ Habitat കൈകാര്യം ചെയ്തു.

സ്കീമ തിരച്ചിൽ, റൂട്ടിങ്, അനുമതി, എൻക്രിപ്ഷൻ, സീരിയലൈസേഷൻ, അഭ്യർത്ഥന രൂപപ്പെടുത്തൽ, കണക്ഷൻ പൂളിങ് എന്നിവയെക്കുറിച്ച് ഉൽപ്പന്ന എൻജിനീയർമാർ ചിന്തിക്കേണ്ടതില്ല. ഡാറ്റ Azure Cosmos DB-യിൽനിന്നോ കാഷുകളിൽനിന്നോ മറ്റ് സ്റ്റോറേജുകളിൽനിന്നോ വരുന്നതാണോ എന്നുപോലും അവർ പരിഗണിക്കേണ്ടതില്ല.

സ്വയം സേവന Postgres, Azure Cosmos DB ഉപയോഗങ്ങളിൽനിന്ന് മാറാൻ കേന്ദ്രീകൃത സമ്മർദമൊന്നും ഇല്ലാതിരുന്നിട്ടും, ഈ Python ലൈബ്രറി നന്നായി പ്രവർത്തിക്കുകയും OpenAI-യിലെ ഉൽപ്പന്ന എൻജിനീയർമാർക്കിടയിൽ Habitat അതിവേഗം പ്രചാരം നേടുകയും ചെയ്തു.

ഉൽപ്പന്ന ആവശ്യങ്ങൾ മാറിയപ്പോൾ, ക്ലയന്റ്-സൈഡ് കാഷിങ്, കംപ്രഷൻ, എൻക്രിപ്ഷൻ തുടങ്ങിയ സവിശേഷതകൾക്കുള്ള പിന്തുണ പങ്കിട്ട ലൈബ്രറിയിൽ ചേർക്കാനും ഉൽപ്പന്ന ഡെവലപ്പർമാർക്ക് എളുപ്പമായിരുന്നു.

2025 മധ്യത്തോടെ, ക്ലയന്റ്-സൈഡ് നടപ്പാക്കൽ എന്ന നിലയിൽ Habitat അതിന്റെ പരിധിയിലെത്തി. Habitat പാളി കൂടുതൽ സങ്കീർണമാവുകയും OpenAI-യുടെ സേവനങ്ങളുടെ എണ്ണം വർധിക്കുകയും ചെയ്തതോടെ, പഴയ പതിപ്പുകളുമായി പൊരുത്തപ്പെടുന്ന പ്രോട്ടോക്കോൾ മാറ്റങ്ങൾ പ്രായോഗികമല്ലാതായി.

ഉദാഹരണത്തിന്, ഏറ്റവും നിർണായകമായ ഡാറ്റാസെറ്റുകൾ മേഖലകളിലായി വിതരണം ചെയ്ത Azure Cosmos DB അക്കൗണ്ടുകളിലേക്ക് മാറ്റി, ഏതെങ്കിലും ഒറ്റ മേഖലയിലെ തടസ്സത്തിന്റെ ആഘാതപരിധി കുറയ്ക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഈ മാറ്റത്തിന് ക്ലയന്റിൽ അധിക റൂട്ടിങ് ലോജിക് ചേർക്കുകയും ഫീച്ചർ ഫ്ലാഗിന് പിന്നിൽ അത് പ്രവർത്തനരഹിതമാക്കുകയും എല്ലാ ക്ലയന്റുകളിലും വിന്യസിച്ചെന്ന് ഉറപ്പാക്കി ഫ്ലാഗ് പ്രവർത്തനക്ഷമമാക്കുകയും വേണമായിരുന്നു.

ഡസൻകണക്കിന് സേവനങ്ങളിലെ വിന്യാസങ്ങൾ ഏകോപിപ്പിച്ച് ഓരോ ടീമുമായും ചേർന്ന് പുറത്തിറക്കാൻ ദിവസങ്ങളെടുത്തു. ഇത് പ്രവർത്തനക്ഷമമാക്കുന്നതിനുമുമ്പ്, ഷാർഡിങ് ലോജിക് ശരിയാണെന്ന് ഉറപ്പാക്കാൻ കുറച്ച് ഷാഡോയിങ് വേണമെന്ന് തിരിച്ചറിഞ്ഞു. അത് വിന്യസിക്കാൻ വീണ്ടും രണ്ട് ദിവസമെടുത്തു. തെറ്റാണെന്ന് തിരിച്ചറിഞ്ഞ കാര്യത്തിനുള്ള പിഴവുപരിഹാരമോ? വീണ്ടും രണ്ട് ദിവസം. ഒടുവിൽ ഫ്ലാഗ് പ്രവർത്തനക്ഷമമാക്കാൻ തയ്യാറായപ്പോൾ, ഒരു ടീം ബന്ധമില്ലാത്ത കാരണങ്ങളാൽ മുമ്പ് പിഴവുണ്ടായിരുന്ന ക്ലയന്റിലേക്ക് സ്വന്തം സേവനം തിരിച്ചുമാറ്റി. ഒഴിവാക്കാൻ ഞങ്ങൾ ഏറെ പരിശ്രമിച്ച തടസ്സം അതോടെ സംഭവിച്ചു.

ക്ലയന്റ് ലൈബ്രറിയിലെ മാറ്റങ്ങൾക്ക് ഡസൻകണക്കിന് സേവനങ്ങളിലുടനീളം സങ്കീർണമായ ഏകോപനം ആവശ്യമായി. ഈ പ്രക്രിയ ക്രമേണ ദുർബലവും കാര്യക്ഷമത കുറഞ്ഞതും പ്രവർത്തനപരമായ പരാജയങ്ങൾക്ക് സാധ്യതയുള്ളതുമായി. ഭാവിയിലെ വിന്യാസങ്ങളുടെ പ്രവർത്തനവ്യാപ്തി കുറയ്ക്കാൻ Habitat-നെ സ്വതന്ത്ര സേവനമാക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു.

സ്റ്റോറേജ് ലോജിക്കിനെ സ്വതന്ത്ര സേവനമാക്കി വേർതിരിച്ചതിലൂടെ വിന്യാസങ്ങൾ, നിരീക്ഷണക്ഷമത, പ്ലാറ്റ്‌ഫോം മെച്ചപ്പെടുത്തലുകൾ എന്നിവയ്ക്കായി ഏക നിയന്ത്രണകേന്ദ്രം സ്ഥാപിച്ചു. ചിതറിക്കിടക്കുന്ന അപ്‌ഡേറ്റുകൾ കൈകാര്യം ചെയ്യുന്നതിന് പകരം, നമുക്ക് മെച്ചപ്പെടുത്തലുകൾ കേന്ദ്രീകൃതമായി നടപ്പിലാക്കാൻ സാധിക്കും; ഇത് എല്ലാ OpenAI ഉൽപ്പന്നങ്ങൾക്കും ഉടനടി പ്രയോജനം നൽകുകയും ചെയ്യും.

ഏറ്റവും ശക്തമായ ഡാറ്റാ സുരക്ഷയും സ്വകാര്യതാ അടിസ്ഥാനസംവിധാനങ്ങളും നൽകാനുള്ള ഏക നിയന്ത്രണകേന്ദ്രവും കേന്ദ്രീകൃത സേവനം ഞങ്ങൾക്ക് നൽകുന്നു. പ്രവേശനനിയന്ത്രണ നയങ്ങൾ കേന്ദ്രീകൃതമായി നടപ്പാക്കാനും ഓഡിറ്റ് രേഖപ്പെടുത്താനും Azure Cosmos DB പോലുള്ള അടിസ്ഥാന സ്റ്റോറേജ് വിഭവങ്ങളിലേക്കുള്ള പ്രവേശനം പരിമിതപ്പെടുത്താനും കഴിയുന്ന ഇടമാണ് Habitat സേവനം. ഉപയോക്തൃ ഡാറ്റ സംരക്ഷിക്കുന്നതിലും ബാഹ്യ, ആന്തരിക, ഏജന്റ് കർത്താക്കളുടെ അനധികൃത പ്രവേശനം തടയുന്നതിലും Habitat നിർണായക പങ്കുവഹിക്കുന്നു.

ഞങ്ങൾക്ക് ഒരു സേവനം വേണമെന്ന് അറിയാമായിരുന്നു. എന്നാൽ സേവനമെന്ന നിലയിൽ Python അധികഭാരം സൃഷ്ടിച്ചിട്ടും, അപ്പോൾത്തന്നെ അതിൽനിന്ന് മാറാൻ ഞങ്ങൾ ആഗ്രഹിച്ചില്ല. ഉയർന്ന ത്രൂപുട്ടുള്ള സേവനത്തിന് Python ഉപയോഗിച്ചത്, പ്രാദേശിക ലൈബ്രറി നിർവഹണത്തെ അപേക്ഷിച്ച് നെറ്റ്‌വർക്ക് കാലതാമസവും CPU, മെമ്മറി സ്കെയിലിങ് ചെലവും ഗണ്യമായി വർധിപ്പിച്ചു. കൂടാതെ, 100 മടങ്ങ് സ്കെയിലിൽ Python-ന്റെ കാര്യക്ഷമതക്കുറവ് അംഗീകരിക്കാനാവില്ലെന്നും ഒടുവിൽ മാറ്റിയെഴുതേണ്ടിവരുമെന്നും ഞങ്ങൾ തിരിച്ചറിഞ്ഞു.

എന്നാൽ, സാങ്കേതിക കടം ബോധപൂർവം ഏറ്റെടുക്കുന്ന തന്ത്രപരമായ തീരുമാനമായാണ് ഞങ്ങൾ ഇതിനെ കണ്ടത്. അന്ന് ഞങ്ങളുടെ പ്രധാന ലക്ഷ്യം ചെലവോ വിഭവങ്ങളോ മെച്ചപ്പെടുത്തുകയായിരുന്നില്ല. ഉൽപ്പന്ന ഡെവലപ്പർമാരുടെ തടസ്സങ്ങൾ നീക്കുകയും പ്ലാറ്റ്‌ഫോം സ്ഥിരത കൈവരിക്കുകയും ചെയ്യുകയായിരുന്നു. ഹ്രസ്വകാലത്തേക്ക് Python സേവനത്തിന്റെ പ്രകടനപരമായ വിട്ടുവീഴ്ചകൾ അംഗീകരിച്ചതിലൂടെ, അടിയന്തര വെല്ലുവിളികൾക്ക് മുൻഗണന നൽകാനും അടിസ്ഥാന API-കൾ സ്ഥാപിക്കാനും ശക്തമായ അടിസ്ഥാനസൗകര്യം പണിയാനും ഞങ്ങൾക്ക് കഴിഞ്ഞു.

ഞങ്ങളുടെ സ്വന്തം കോഡിങ് മോഡലുകളുടെ ദ്രുതഗതിയിലുള്ള പുരോഗതി ഭാവിയിലെ സാങ്കേതികപാത ലളിതമാക്കുമെന്നും ഞങ്ങൾ കണക്കുകൂട്ടി. Python-ൽനിന്ന് പൂർണമായി മാറേണ്ട സമയമാകുമ്പോഴേക്കും Codex-ഉം GPT‑യും ആ മാറ്റം സാധ്യമാക്കുമെന്ന് ഞങ്ങൾ വിശ്വസിച്ചു. ആ വിശ്വാസം ഒടുവിൽ ശരിയാണെന്ന് തെളിഞ്ഞു.

Habitat-നെ Python സേവനമായി പ്രവർത്തിപ്പിക്കുന്നത് പ്രകടനത്തിന്റെ കാര്യത്തിൽ അനുയോജ്യമല്ലെങ്കിലും അനിവാര്യമായ തിരഞ്ഞെടുപ്പായിരുന്നു. വേഗത്തിൽ മുന്നേറാൻ Python സഹായിക്കുന്നു. എന്നാൽ ജാഗ്രത ഉപേക്ഷിച്ച് ഗണ്യമായി മോശമായ കാലതാമസം അംഗീകരിക്കാമെന്ന് അതിനർഥമില്ല. ഒരു ശരാശരി ഉപയോക്തൃ അഭ്യർത്ഥന നൂറുകണക്കിന് ഡാറ്റാബേസ് കോളുകൾ സൃഷ്ടിക്കുമ്പോൾ, ഏറ്റവും മന്ദഗതിയിലുള്ള കോളിന്റെ കാലതാമസമാണ് ഉപയോക്താവ് അനുഭവിക്കുന്നത്. ഈ സ്കെയിലിൽ Python സേവനം പ്രവർത്തിപ്പിക്കുമ്പോഴുള്ള പ്രധാന വെല്ലുവിളി ഈ ടെയിൽ കാലതാമസങ്ങൾ നിയന്ത്രിക്കുകയാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി.

I/O-ബന്ധിത ജോലിഭാരങ്ങൾ ഒരേസമയം നിർവഹിക്കാൻ asyncio Python-നെ സഹായിക്കുന്നു. എന്നാൽ Python GIL മറികടന്ന് CPU സമാന്തരത നൽകുന്നില്ല. I/O കൂടുതലുള്ള അഭ്യർത്ഥന പ്രോക്സിയിങ്ങിനുപുറമേ, റൂട്ടിങ്, കംപ്രഷൻ, എൻക്രിപ്ഷൻ, ചെക്ക്സമ്മിങ്, ഡൗൺസ്ട്രീം ആരോഗ്യപരിശോധന, അഭ്യർത്ഥന ഷാഡോയിങ്, ഹെഡ്ജിങ് തുടങ്ങി CPU കൂടുതലായി ഉപയോഗിക്കുന്ന നിരവധി ചുമതലകളും പശ്ചാത്തല ജോലികളും Habitat കൈകാര്യം ചെയ്യുന്നു.

ഞങ്ങളുടെ സേവനത്തിൽ CPU കൂടുതലായി ഉപയോഗിക്കുന്ന ഇത്രയധികം ജോലിഭാരങ്ങളും പശ്ചാത്തല ജോലികളും ഉള്ളതിനാൽ, asyncio ഷെഡ്യൂളിങ് കാലതാമസം ടെയിൽ അഭ്യർത്ഥനാ കാലതാമസത്തിലെ പ്രധാന ഘടകമാകാം. ആദ്യ സേവനാരംഭത്തിനായി ക്രമീകരിക്കുന്നതിനുമുമ്പ്, p99-ഉം അതിലധികവും കാലതാമസമുള്ള അഭ്യർത്ഥനകളുടെ ട്രേസുകളിൽ ഡൗൺസ്ട്രീം സ്റ്റോറേജ് വേഗത്തിൽ പ്രതികരിച്ചിട്ടും, പ്രതികരണം പാഴ്സ് ചെയ്യേണ്ട കൊറൂട്ടീൻ വീണ്ടും ഷെഡ്യൂൾ ചെയ്യപ്പെടാൻ കാത്ത് അഭ്യർത്ഥനകൾ പതിവായി നിലയ്ക്കുന്നത് കണ്ടു.

OpenAI-യിലെ Python സേവനങ്ങൾക്ക് മെമ്മറി, CPU, നെറ്റ്‌വർക്ക്, ഡിസ്ക് ഉപയോഗത്തിലെ സാധാരണ വിനിയോഗ-സാച്ചുറേഷൻ മെട്രിക്കുകൾ അളക്കുന്നതിനൊപ്പം, asyncio ലൂപ്പും അതിന്റെ തിരക്കും നിരീക്ഷിച്ച് അതനുസരിച്ച് ക്രമീകരിക്കുന്നത് നിർണായകമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി.

പശ്ചാത്തല ജോലികൾ ഇടയ്ക്കിടെ ഷെഡ്യൂൾ ചെയ്ത് പ്രതീക്ഷിച്ച നിർവഹണസമയവും യഥാർഥ സമയവും തമ്മിലുള്ള വ്യത്യാസം രേഖപ്പെടുത്തുന്നതിലൂടെ, ഇവന്റ് ലൂപ്പ് ഷെഡ്യൂളിങ് കാലതാമസം തത്സമയം അനുഭവപരമായി അളക്കുന്നു. ഉയർന്ന വിനിയോഗത്തിൽ ചെലവേറിയ ജോലികൾ ഏറെയുണ്ടെങ്കിൽ, ഓരോ പ്രോസസിലെയും മിതമായ എണ്ണം സമകാലിക അഭ്യർത്ഥനകൾപോലും നൂറുകണക്കിന് മില്ലിസെക്കൻഡും ചില അപൂർവ സാഹചര്യങ്ങളിൽ നിരവധി സെക്കൻഡും നീളുന്ന ഷെഡ്യൂളിങ് വ്യതിയാനം സൃഷ്ടിക്കും.

അതിനാൽ, ഓരോ പ്രോസസും വളരെ കുറച്ച് സമകാലിക അഭ്യർത്ഥനകൾ മാത്രം കൈകാര്യം ചെയ്യാൻ അനുവദിച്ച് Python വർക്കർ പ്രോസസുകളുടെ എണ്ണം വൻതോതിൽ വർധിപ്പിക്കുന്നു.

ആദ്യ സേവനാരംഭത്തിൽ തത്സമയ CPU പ്രൊഫൈലിങ്ങിലൂടെ, ഉയർന്ന asyncio കാലതാമസത്തിന്റെയും തുടർന്നുണ്ടായ ഉയർന്ന ടെയിൽ കാലതാമസത്തിന്റെയും ഒരു മൂലകാരണം കണ്ടെത്തി: Statsig വഴി ഞങ്ങളുടെ ഫീച്ചർ ഫ്ലാഗ് ക്രമീകരണങ്ങൾ ഇടയ്ക്കിടെ JSON പാഴ്സ് ചെയ്യുന്നത്. ഫീച്ചർ ഫ്ലാഗുകൾ കൈകാര്യം ചെയ്യാനും A/B പരിശോധനകൾ നടത്താനും ഉപയോഗിക്കുന്ന ഉപകരണമാണ് Statsig.

സ്ഥിരസ്ഥിതിയിൽ, വ്യതിയാനമില്ലാതെ ഓരോ മിനിറ്റിലും പുതുക്കിയ ക്രമീകരണങ്ങൾ പരിശോധിക്കാനായിരുന്നു 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 പ്രോസസിലും ഫലപ്രാപ്തി കുറവായിരിക്കാവുന്ന നിരക്ക് പരിധികളും സർക്യൂട്ട് ബ്രേക്കറുകളും നടപ്പാക്കാനുള്ള കേന്ദ്രീകൃത ഇടവും Envoy നൽകുന്നു.

Python-നെ ഇത്രയും സ്കെയിൽ ചെയ്യാനായതിന്റെ ഒരു കാരണം അഭ്യർത്ഥനാ ചെലവ് പ്രവചനീയമാക്കുന്ന Habitat-ന്റെ നിയന്ത്രിത API ആണ്. വലിയ പട്ടികാ സ്കാനുകളിലേക്കോ നിരവധി പട്ടികകളിലെ ജോയിനുകളിലേക്കോ നയിക്കാവുന്ന ഏത് SQL അന്വേഷണവും ക്ലയന്റുകൾ നിർമ്മിക്കാൻ അനുവദിക്കുന്നതിനുപകരം, Habitat ലളിതമായ NoSQL API നൽകുന്നു. ശക്തമായ API ഇല്ലാത്തത് Habitat-ന്റെ രൂപകൽപ്പനയിലെ ബോധപൂർവമായ വിട്ടുവീഴ്ചയാണ്.

ലളിതവും പ്രവചനീയവും സ്ഥിരമായ ജോലിഭാരമുള്ളതുമായ അഭ്യർത്ഥനകൾക്ക് അനുകൂലമായി മെച്ചപ്പെടുത്തുകയാണ് ഞങ്ങളുടെ ലക്ഷ്യം. ഞങ്ങളുടെ അനുഭവത്തിൽ, ഇത്തരം സിസ്റ്റങ്ങൾ സ്കെയിൽ ചെയ്യാൻ വളരെ എളുപ്പവും തെറ്റായി ഉപയോഗിക്കാൻ പ്രയാസവുമാണ്. പ്രവചനാതീതമായി വ്യാപിക്കുന്ന അഭ്യർത്ഥനകൾ പ്രവർത്തനപരമായി അപകടകരമാണ്. അവ ഐസൊലേഷനും ലോഡ് ബാലൻസിങ്ങും സങ്കീർണമാക്കുകയും സേവനത്തിനും ക്ലയന്റുകൾക്കും സ്കെയിൽ ചെയ്യാൻ പ്രയാസമുള്ള പെട്ടെന്നുള്ള കാലതാമസ വർധന സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

Habitat-ലേക്കും Azure Cosmos DB-യിലേക്കും മാറുന്നതിനുമുമ്പ്, OpenAI-യുടെ മിക്ക ഓൺലൈൻ ഡാറ്റയും Postgres-ലാണ് സംഭരിച്ചിരുന്നത്. അന്ന്, പ്രൊഡക്ഷനിലേക്ക് അയയ്ക്കുന്നതിനുമുമ്പ് എല്ലാ അന്വേഷണ-സ്കീമ മാറ്റങ്ങളും പരിശോധിച്ച് അവ ശരിയായി പ്രവർത്തിക്കുന്നുവെന്നും ഇൻഡക്സ് ചെയ്ത ഡാറ്റയിലാണ് പ്രവർത്തിക്കുന്നതെന്നും ഉറപ്പാക്കാൻ എളുപ്പമായിരുന്നു. ടീമും ഉൽപ്പന്നങ്ങളും വളർന്നതോടെ ഇത് വേഗത്തിൽ നിയന്ത്രിക്കാനാവാത്തതായി. നിർണായക പാതയിലെ ചെലവേറിയ ഒറ്റ പുതിയ അന്വേഷണം ഡാറ്റാബേസ് നിലയ്ക്കാൻ ഇടയാക്കുന്നത് പതിവായി.

ചെലവിലെ അസന്തുലിതാവസ്ഥയാണ് പ്രശ്നം: പ്രവർത്തിപ്പിക്കാൻ ചെലവേറിയതും പ്രയാസമുള്ളതുമായ SQL അന്വേഷണങ്ങൾ എഴുതുന്നത് വിലകുറഞ്ഞതും എളുപ്പവുമാണ്. Habitat-ൽ ഞങ്ങൾ ഇത് ഒഴിവാക്കുകയും ചെലവേറിയ അന്വേഷണങ്ങൾ ക്ലയന്റ് ഭാഗത്ത് വളരെ വ്യക്തമായി കാണിക്കുകയും ചെയ്യുന്നു. Habitat-നെ അമിതഭാരത്തിലാക്കുന്ന പരിധിയില്ലാത്ത അന്വേഷണങ്ങളില്ല. സങ്കീർണമായ ജോയിനുകൾക്കും ഗ്രാഫ് സഞ്ചാരങ്ങൾക്കും ഉൽപ്പന്ന ടീമുകൾ കഠിനമായ ചില ജോലികൾ ചെയ്യണം. ഇത് കൂടുതൽ കാര്യക്ഷമമായ രൂപകൽപ്പനകൾ തിരഞ്ഞെടുക്കാൻ സഹായിക്കുന്നു.

TAO⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)-യിൽനിന്ന് പ്രചോദനം ഉൾക്കൊണ്ട്, ക്ലയന്റ് നിർവചിക്കുന്ന ഒബ്ജക്റ്റ്, എഡ്ജ് തരങ്ങളെ അടിസ്ഥാനമാക്കിയ NoSQL API ആണ് Habitat നൽകുന്നത്. ക്ലയന്റുകൾ ഒബ്ജക്റ്റുകളും എഡ്ജുകളും അവ തമ്മിലുള്ള ബന്ധവും മുൻകൂട്ടി നിർവചിക്കുന്നു, എന്നാൽ ഓരോ തരത്തിന്റെയും ഉള്ളടക്കം നിർവചിക്കുന്നില്ല. ഫലമായുണ്ടാകുന്ന ബന്ധങ്ങൾ ഒരു ഗ്രാഫിനോട് സാമ്യമുള്ളതാണ്. എന്നാൽ ഒരു പ്രത്യേക ഒബ്ജക്റ്റിന്റെ നേരിട്ടുള്ള എഡ്ജുകൾ അന്വേഷിക്കുന്നതിനു പുറമേ സാധാരണ ഗ്രാഫ് സഞ്ചാര അന്വേഷണങ്ങളെ Habitat പിന്തുണയ്ക്കുന്നില്ല.

ഓരോ ഒബ്ജക്റ്റും അതിന്റെ എഡ്ജുകളും സ്റ്റോറേജ് തലത്തിലെ ഒരേ പാർട്ടീഷനിൽ വരുന്നതുപോലെ ഗ്രാഫ് വിഭജിക്കുന്നു. എന്നാൽ ഒബ്ജക്റ്റുകളെയും അവയുടെ എഡ്ജുകൾ ചൂണ്ടുന്ന വിദൂര ഒബ്ജക്റ്റുകളെയും ഒരുമിച്ച് സ്ഥാപിക്കാൻ ഡാറ്റാബേസ് തലത്തിൽ പ്രത്യേക ശ്രമമില്ല. ഇതിലൂടെ മോഡൽ തിരശ്ചീന സ്കെയിലിങ്ങിനായി എളുപ്പത്തിൽ വിഭജിക്കാം. എന്നാൽ ഒബ്ജക്റ്റുകൾക്കിടയിലെ ഓരോ ഘട്ടത്തിനും വ്യത്യസ്ത മേഖലകളിൽ സൂക്ഷിച്ച രണ്ട് Azure Cosmos DB അക്കൗണ്ടുകളിൽനിന്ന് ഡാറ്റ എടുക്കേണ്ടിവരാം എന്നതിനാൽ ഗ്രാഫ് സഞ്ചാരം കാര്യക്ഷമമല്ല.

കൂടുതൽ സങ്കീർണമായ അന്വേഷണങ്ങൾ ആവശ്യമുള്ള ക്ലയന്റുകൾക്ക് Rockset വഴി ലഭ്യമാകുന്ന Habitat-ന്റെ ഓഫ്‌ലൈൻ ദ്വിതീയ കാഴ്ചയും നൽകുന്നു. ഓൺലൈൻ സ്റ്റോറേജിലെ മാറ്റങ്ങൾ ഏതാണ്ട് തത്സമയം ഒറ്റപ്പെട്ട Rockset ഇൻസ്റ്റൻസുകളിലേക്ക് സ്ട്രീം ചെയ്യാൻ മാറ്റ ഡാറ്റ ക്യാപ്ചർ (CDC) ഉപയോഗിക്കുന്നു. സങ്കീർണമായ അന്വേഷണ ആവശ്യങ്ങൾക്കനുസരിച്ച് സ്വന്തം Rockset ഇൻസ്റ്റൻസ് സ്കെയിൽ ചെയ്യേണ്ടത് ഓരോ ക്ലയന്റ് ടീമിന്റെയും ഉത്തരവാദിത്വമാണ്.

ഈ Rockset സജ്ജീകരണം ക്ലയന്റുകൾക്ക് അധിക ബുദ്ധിമുട്ടുണ്ടാക്കുന്നു. എന്നാൽ ലളിതമായ അന്വേഷണങ്ങളെ സ്ഥിരസ്ഥിതിയാക്കുകയും സങ്കീർണമായവ ആവശ്യമുള്ളവർക്ക് മറ്റൊരു വഴി നൽകുകയും ചെയ്യുന്ന ഈ വിട്ടുവീഴ്ച ഇപ്പോൾ ശരിയാണെന്ന് ഞങ്ങൾ കരുതുന്നു. വായന കൂടുതലുള്ള വിശകലന, തിരയൽ ജോലിഭാരങ്ങളിൽനിന്ന് ഞങ്ങളുടെ ഓൺലൈൻ സ്റ്റോറേജിനെ ഈ രൂപകൽപ്പന വേർതിരിക്കുന്നു.

Python മാറ്റിയെഴുതുന്നത് ഒരു വർഷത്തേക്ക് നീട്ടിവെച്ചതിലൂടെ, അതിവേഗ വളർച്ചയ്ക്കിടെ കൂടുതൽ അടിയന്തരവും ഫലപ്രദവുമായ വെല്ലുവിളികളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിഞ്ഞു. പ്ലാറ്റ്‌ഫോം പക്വമാകുകയും വളർച്ച ത്വരിതപ്പെടുകയും ചെയ്തതോടെ, OpenAI-യിൽ കോർ എണ്ണത്തിൽ രണ്ടാമത്തെ വലിയ സേവനവും Envoy വിന്യാസത്തിൽ നാലാമത്തേതുമായതിനാൽ, ഒടുവിൽ Python-നെ മറികടക്കേണ്ട സമയമായി. പരമാവധി ശേഷിയിൽ, സെക്കൻഡിൽ 2 കോടിയിലധികം അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ Python ഞങ്ങളെ സഹായിച്ചു.

2026-ലെ രണ്ടാം പാദത്തിൽ, വെറും 2 എൻജിനീയർമാരും Codex-ഉം GPT‑5.5‑ഉം ഉപയോഗിച്ച് മുഴുവൻ സേവനവും Rust-ൽ മാറ്റിയെഴുതാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. പുതിയ Rust സേവനം ഇപ്പോൾ പ്രൊഡക്ഷൻ അഭ്യർത്ഥനകളുടെ 95% കൈകാര്യം ചെയ്യുന്നു. വരും ആഴ്ചകളിൽ Python പൂർണമായി ഒഴിവാക്കും. Python പതിപ്പിനെക്കാൾ Rust സേവനം CPU ഉപയോഗത്തിൽ 6 മടങ്ങും മെമ്മറി ഉപയോഗത്തിൽ 15 മടങ്ങും കാര്യക്ഷമമാണെന്നും ശരാശരി, ടെയിൽ കാലതാമസങ്ങൾ ഗണ്യമായി കുറവാണെന്നും ഞങ്ങളുടെ ഡാറ്റ കാണിക്കുന്നു. കൂടുതൽ പഠനങ്ങൾ ഭാവിയിലെ ഒരു ബ്ലോഗിൽ പങ്കിടാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു.

Python സേവനവും ഇപ്പോഴത്തെ Rust സേവനവും Habitat-ന്റെ ഒരു വശം മാത്രമാണ്. 100 കോടിയിലധികം ChatGPT ഉപയോക്താക്കൾക്കായി ഓൺലൈൻ സ്റ്റോറേജ് എങ്ങനെ ദ്രുതഗതിയിൽ സ്കെയിൽ ചെയ്തുവെന്ന് വിശദീകരിക്കുന്ന ഈ പരമ്പരയുടെ രണ്ടാം ഭാഗത്തിൽ, സ്റ്റോറേജ് പാളിയെക്കുറിച്ചും Habitat 500 പെറ്റാബൈറ്റിലധികം ഡാറ്റയും സെക്കൻഡിൽ 7 കോടിയിലധികം അഭ്യർത്ഥനകളും എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്നും ചർച്ച ചെയ്യും.

അത്യാധുനിക സ്കെയിലിലുള്ള OLTP സിസ്റ്റങ്ങളിൽ പ്രവർത്തിക്കാനും ഇത്തരം എൻജിനീയറിങ്ങിൽ താൽപ്പര്യമുണ്ടെങ്കിൽ, ഞങ്ങളുടെ ടീമിലെ ഈ ഒഴിവ് കാണുക⁠.