100 കോടിയിലധികം ChatGPT ഉപയോക്താക്കൾക്കായി ഓൺലൈൻ സ്റ്റോറേജ് അതിവേഗം വിപുലീകരിച്ച വിധം (ഭാഗം 2)

എല്ലാ OpenAI ഉൽപ്പന്നങ്ങൾക്കും ഡാറ്റയിലേക്ക് വേഗത്തിലും വിശ്വസനീയമായും പ്രവേശനം വേണം. ഞങ്ങളുടെ സംഭരണ പ്ലാറ്റ്‌ഫോമായ Habitat ആണ് അത് നൽകുന്നത്. 40 ഭൂമിശാസ്ത്ര മേഖലകളിലെ 100 കോടിയിലേറെ ഉപയോക്താക്കൾക്ക് മില്ലിസെക്കൻഡുകൾക്കുള്ളിൽ അത് പ്രതികരിക്കണം. ഞങ്ങളുടെ അടിസ്ഥാനസൗകര്യം അസാധാരണമായൊരു വെല്ലുവിളി നേരിട്ടു: വിശ്വാസ്യതയും പ്രകടനവും ഉൽപ്പന്ന വികസനവേഗവും മെച്ചപ്പെടുത്തിക്കൊണ്ടുതന്നെ അതിവേഗ വളർച്ചയെയും പുതിയ ഉപയോഗങ്ങളെയും പിന്തുണയ്ക്കുക. ഇത് പരിഹരിക്കാൻ ഞങ്ങളുടെ ഓൺലൈൻ സംഭരണ പ്ലാറ്റ്‌ഫോമിന്റെ രൂപകൽപ്പനയും നടത്തിപ്പും പുനഃപരിശോധിക്കേണ്ടിവന്നു. നേട്ടങ്ങളും വിട്ടുവീഴ്ചകളും ഞങ്ങൾ നിരന്തരം വിലയിരുത്തി. ആദ്യം നിർണായക ഉൽപ്പന്ന ട്രാഫിക്കിന് മതിയായ വിശ്വാസ്യത, പിന്നെ ആഗോള ഉപയോക്താക്കൾക്ക് വേണ്ട വേഗം, ഒടുവിൽ ഭീമമായ തോതിൽ കാര്യക്ഷമമായ നടത്തിപ്പ്—ഇതായിരുന്നു ക്രമം.

ലളിതമായ ഒരു ക്ലയന്റ് ലൈബ്രറിയും ഡാറ്റാബേസുമായിരുന്ന Habitat-നെ, 500 പെറ്റാബൈറ്റിലേറെ ഡാറ്റ നൽകുന്ന ആഗോള വിതരണ സംഭരണ പ്ലാറ്റ്‌ഫോമാക്കി വികസിപ്പിച്ചതെങ്ങനെയെന്ന് ഈ രണ്ടു ഭാഗങ്ങളുള്ള പരമ്പര വിശദീകരിക്കുന്നു. Python ക്ലയന്റിൽനിന്ന് സേവനത്തിലേക്കുള്ള Habitat-ന്റെ വളർച്ചയായിരുന്നു ഭാഗം I-ന്റെ വിഷയം. പലരും പ്രായോഗികമെന്ന് കരുതുന്ന പരിധികൾക്കപ്പുറം Python അധിഷ്ഠിത സേവനത്തെ വളർത്താൻ സഹായിച്ച സങ്കേതങ്ങളും അതിൽ വിശദീകരിച്ചു.

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

കമ്പനികൾ വളരുമ്പോൾ അടിസ്ഥാനസൗകര്യ ടീമുകൾ പലപ്പോഴും ഏക-ടെനന്റ് സംവിധാനങ്ങളിൽനിന്ന് ബഹു-ടെനന്റ് സംവിധാനങ്ങളിലേക്ക് മാറുന്നു. ഓരോ ഉൽപ്പന്നഭാഗത്തിന്റെയും ടീം സ്വന്തം സംവിധാനം പരിപാലിക്കുന്ന ഏക-ടെനന്റ് രീതി തകരാറിന്റെ വ്യാപ്തി കുറയ്ക്കുന്നു. ചുമതലകളുടെ വ്യക്തമായ വിഭജനവും ജോലിഭാരങ്ങളുടെ വേർതിരിക്കലും ഇതിലൂടെ എളുപ്പമാകുന്നു. ടീമുകളും ഉൽപ്പന്നഭാഗങ്ങളും വർധിക്കുമ്പോൾ ഈ രീതി ചെലവേറിയതാകുന്നു. ഏക-ടെനന്റ് രീതി ഓരോ ഉൽപ്പന്ന ടീമിനെയും ശേഷി ആസൂത്രണത്തിന് ഉത്തരവാദികളാക്കുന്നു. പലപ്പോഴും ആവശ്യത്തിലേറെ വിഭവങ്ങൾ അനുവദിക്കപ്പെടാനും ഇത് കാരണമാകുന്നു.

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

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

ഞങ്ങളുടെ Azure Cosmos DB യാത്ര വിശദീകരിക്കുംമുമ്പ് ചില അടിസ്ഥാന കാര്യങ്ങൾ:

• ഒരു Azure Cosmos DB അക്കൗണ്ട് ഒരു കൂട്ടം കണ്ടെയ്‌നറുകളും പകർപ്പെടുക്കൽ നയവും നിർവചിക്കുന്നു

• ഓരോ കണ്ടെയ്‌നറിനും സെക്കൻഡിലെ അഭ്യർത്ഥനാ യൂണിറ്റുകളിൽ (RU/s) നിശ്ചിത ത്രൂപുട്ട് അനുവദിക്കുന്നു

• നിർദിഷ്ട ലോജിക്കൽ പാർട്ടീഷൻ കീ അടിസ്ഥാനമാക്കിയുള്ള സാധാരണ ഷാർഡിങ് രീതിയിലാണ് ഓരോ കണ്ടെയ്‌നറിലും ഡാറ്റ സൂക്ഷിക്കുന്നത്. ഓരോ കീക്കും രേഖപ്പെടുത്തിയ സംഭരണ-ത്രൂപുട്ട് പരിധികളുണ്ട്

• Azure Cosmos DB ലോജിക്കൽ പാർട്ടീഷൻ കീകളെ കുറച്ച് ഭൗതിക പാർട്ടീഷനുകളിലായി ഷാർഡ് ചെയ്യുന്നു. സംഭരണം പരിധി കടക്കുമ്പോഴോ അനുവദിച്ച ത്രൂപുട്ട് നിലനിർത്താൻ കൂടുതൽ പാർട്ടീഷനുകൾ വേണ്ടിവരുമ്പോഴോ അവയെ ഒന്നിലധികം ഭൗതിക പാർട്ടീഷനുകളായി വിഭജിക്കുന്നു

ആദ്യം ഏതു ക്ലയന്റ് ലോഡും ഞങ്ങൾ അനുവദിച്ചിരുന്നു. ഓരോ ലോജിക്കൽ പാർട്ടീഷൻ കീക്കുമുള്ള പ്രഖ്യാപിത 10,000 RU/s പരിധി അധിക ലോഡ് നിയന്ത്രിക്കുമെന്ന് ആശ്രയിച്ചു. തുടക്കത്തിൽ ഓരോ അക്കൗണ്ടിലും ഒരു ഡിഫോൾട്ട് Azure Cosmos DB കണ്ടെയ്‌നർ മാത്രമാണ് ഉപയോഗിച്ചിരുന്നത്. ഇത് സാമാന്യം നന്നായി പ്രവർത്തിച്ചെങ്കിലും ചില കാരണങ്ങളാൽ പ്രശ്നങ്ങൾ ഉണ്ടായി:

ആദ്യകാല API തീരുമാനങ്ങൾ കാരണം ലോജിക്കൽ പാർട്ടീഷൻ കീ തിരഞ്ഞെടുക്കാനുള്ള സൗകര്യം ക്ലയന്റുകൾക്ക് നേരിട്ട് നൽകിയിരുന്നു. ഫലമായി, വ്യത്യസ്ത ഉൽപ്പന്ന ഉപയോഗങ്ങളിൽ user_id, workspace_id പോലുള്ള സാധാരണ പാർട്ടീഷൻ കീകൾ പതിവായി ഒത്തുവരുന്നു. ഈ ഉപയോഗങ്ങൾ ഒരേ ലോജിക്കൽ പാർട്ടീഷൻ കീകളിലെ Azure Cosmos DB പരിധികൾ പങ്കിട്ടതിനാൽ, ഒരു ഉപയോക്താവിന് ലഭിക്കുന്ന മൊത്തം ത്രൂപുട്ട് ഈ രൂപകൽപ്പന നിയന്ത്രിച്ചു.

Habitat-ലേക്കും Azure Cosmos DB-യിലേക്കും മാറുംമുമ്പ് Postgres വിപുലീകരിക്കുമ്പോൾ ഒരു പതിവ് പ്രശ്നമുണ്ടായിരുന്നു: അമിത ലോഡ് സൃഷ്ടിക്കുന്ന ഒരു ടെനന്റിന്റെ സ്ഥാപനത്തിൽനിന്നോ കീയിലേക്കോ വരുന്ന അനവധി അഭ്യർത്ഥനകൾക്ക് ഡാറ്റാബേസ് മുഴുവൻ തകരാറിലാക്കാൻ കഴിയുമായിരുന്നു. ആ കീകൾ കാഷ് ചെയ്യാനും കാഷിൽ ഡാറ്റ ഇല്ലാത്ത സാഹചര്യങ്ങളിൽ ലീസ് സംവിധാനം ചേർക്കാനും വലിയ കൂട്ടായ പരിശ്രമം നടത്തി. അത്തരം അഭ്യർത്ഥനകളുടെ ലോഡ് അടിസ്ഥാന ഡാറ്റാബേസിനെ തളർത്താതിരിക്കുകയായിരുന്നു ലക്ഷ്യം.

രേഖപ്പെടുത്തിയ ഡാറ്റാ വലുപ്പ-ത്രൂപുട്ട് പരിധികൾ ലോജിക്കൽ പാർട്ടീഷൻ കീകൾക്ക് ബാധകമാണെങ്കിലും, യഥാർഥത്തിൽ പരിധികൾ നടപ്പാക്കുന്നത് ഭൗതിക പാർട്ടീഷനിലാണ്. പ്രായോഗികമായി, ലോജിക്കൽ പാർട്ടീഷനുകൾക്ക് 10,000 RU/s-ൽ എത്താനാകില്ലെന്നാണ് ഇതിന്റെ അർഥം. പകരം, അതേ ഭൗതിക പാർട്ടീഷനിലുള്ള മറ്റെല്ലാ ലോജിക്കൽ പാർട്ടീഷൻ കീകളുമായും അവ അതിന്റെ പരിധികൾ പങ്കിടുന്നു.

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

ഒരു ഭൗതിക പാർട്ടീഷന്റെ ത്രൂപുട്ട് പരിധിയും മാറിക്കൊണ്ടിരിക്കും; അത് Azure Cosmos DB കണ്ടെയ്‌നറിന് അനുവദിച്ച മൊത്തം ത്രൂപുട്ടിനെ ആശ്രയിക്കുന്നു. കണ്ടെയ്‌നറിന് അനുവദിച്ച ത്രൂപുട്ട് അതിലെ ഭൗതിക പാർട്ടീഷനുകൾക്കിടയിൽ ഏകദേശം തുല്യമായി വിഭജിക്കപ്പെടുന്നു.

ഡാറ്റ കൂടുമ്പോൾ ഭൗതിക പാർട്ടീഷനുകൾ വിഭജിക്കപ്പെടുകയും അവയുടെ ആകെ എണ്ണം വർധിക്കുകയും ചെയ്യുന്നു. എന്നാൽ അനുവദിച്ച മൊത്തം ത്രൂപുട്ട് മാറുന്നില്ല. തൽഫലമായി, ഡാറ്റ കൂടുന്നതിനനുസരിച്ച് ഓരോ പാർട്ടീഷനും ലഭിക്കുന്ന ത്രൂപുട്ട് പരിധി ചുരുങ്ങുന്നു.

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

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

കർശനമായ വേർതിരിക്കൽ വേണ്ട ഏറ്റവും നിർണായകമായ പുതിയ ഉപയോഗങ്ങൾക്ക് ഞങ്ങൾ വേറിട്ട Azure Cosmos DB കണ്ടെയ്‌നറുകൾ ഉപയോഗിച്ചുതുടങ്ങി. ഓരോ കണ്ടെയ്‌നറിന്റെയും ഭൗതിക പാർട്ടീഷനുകളുടെ എണ്ണത്തിനനുസരിച്ച് മൊത്തം ത്രൂപുട്ട് ക്രമീകരിക്കുന്ന സ്ക്രിപ്റ്റും ഇതോടൊപ്പം ഉപയോഗിച്ചു. ദുർബല പാർട്ടീഷനുകൾ കൈകാര്യം ചെയ്ത ഈ രീതി ഞങ്ങൾ നേരിട്ടിരുന്ന മിക്ക പ്രശ്നങ്ങളും ഒഴിവാക്കി.

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

ഇത് സൈറ്റിനെ മുഴുവനായി ബാധിക്കുമായിരുന്ന നിരവധി തടസ്സങ്ങളിൽനിന്ന് ഞങ്ങളെ രക്ഷിക്കുകയും പ്രശ്നങ്ങളുടെ ആഘാതം ഏതെങ്കിലും ഒരു ഫീച്ചറിലോ സർവീസിലോ മാത്രമായി പരിമിതപ്പെടുത്തുകയും ചെയ്തു. എങ്കിലും, പുതിയ കണ്ടെയ്‌നറുകൾ ഒരുക്കുന്നതിലെ അധികഭാരം ഒടുവിൽ ഞങ്ങൾക്ക് തിരിച്ചടിയായി:

പഴയ പങ്കിട്ട ഡിഫോൾട്ട് കണ്ടെയ്‌നറിൽ ഒരു പുതിയ ഉപയോഗം 0 QPS-ൽനിന്ന് 10 ലക്ഷം QPS-ലേക്ക് വളർന്നാലും മൊത്തം ഉപയോഗത്തിൽ വലിയ മാറ്റമുണ്ടാകാൻ സാധ്യത കുറവായിരുന്നു. എന്നാൽ വേർതിരിച്ച കണ്ടെയ്‌നറിൽ ഇതേ വളർച്ച, ആഭ്യന്തര പരീക്ഷണത്തിൽ മാത്രമുണ്ടായിരുന്ന അടിസ്ഥാന ലോഡിന്റെ 1,000 മടങ്ങായേക്കാം.

സമർപ്പിത കണ്ടെയ്‌നറുകൾ വന്നതോടെ, പുറത്തിറക്കുമ്പോൾ പ്രതീക്ഷിക്കുന്ന ത്രൂപുട്ടിനനുസരിച്ച് അവ മുൻകൂട്ടി ഒരുക്കാൻ ടീമുകൾ ഓർക്കേണ്ടിവന്നു. ഉൽപ്പന്ന ടീമുകൾ പലപ്പോഴും ശേഷി മുൻകൂട്ടി കൂട്ടാൻ മറന്ന് സവിശേഷതകൾ പുറത്തിറക്കും. അപ്പോൾ പുറത്തിറക്കുന്ന ദിവസം അടിയന്തര തകരാർപരിഹാര മുറികളിലിരുന്ന് അവസാന നിമിഷം കണ്ടെയ്‌നറുകൾ വികസിപ്പിക്കാൻ ഞങ്ങൾ ശ്രമിക്കേണ്ടിവരും.

വ്യത്യസ്ത ജോലിഭാരങ്ങൾ കൂട്ടിച്ചേർക്കുന്നതിലൂടെ ബഹു-ടെനന്റ് സംവിധാനങ്ങൾ നൽകുന്ന പ്രധാന നേട്ടമാണിത്. ഈ കണ്ടെയ്‌നർ തന്ത്രത്തിൽ മെച്ചപ്പെട്ട വേർതിരിക്കലിനായി ആ നേട്ടം നഷ്ടപ്പെടുന്നു.

കാലക്രമേണ, സമർപ്പിത കണ്ടെയ്‌നറുകളുടെ ഉപയോഗം നിരീക്ഷിക്കാൻ ട്രാഫിക് എപ്പോൾ മാറുമെന്നോ വർധിക്കുമെന്നോ ഉള്ള ആഴത്തിലുള്ള ഉൽപ്പന്ന അറിവും ആവശ്യമായി.

വളർച്ചാപ്രവണതകൾക്കനുസരിച്ച് ഓരോ കണ്ടെയ്‌നറിന്റെയും ത്രൂപുട്ട് കൂട്ടാൻ അടിസ്ഥാന കൺട്രോൾ പ്ലെയിൻ സ്ക്രിപ്റ്റ് നൽകാം. എന്നാൽ സ്ഥിരമായ മൊത്ത വളർച്ചയില്ലാത്തതിനാൽ, ശരിയായ ശേഷിവർധനയ്ക്കായി OpenAI-യിലെ മിക്കവാറും എല്ലാ ഉൽപ്പന്ന ടീമുകളും ശേഷി ആസൂത്രണത്തിൽ ഇടപെടേണ്ടിവന്നു.

ഓരോ സേവനത്തിന്റെയും ഉത്തരവാദിത്തമുള്ള ടീം Azure Cosmos DB വിഭവവിന്യാസത്തിൽ കാണിച്ച ശ്രദ്ധ വളരെ വ്യത്യസ്തമായിരുന്നു. അതിനാൽ സ്ഥാപനത്തിന്റെ വളർച്ചയ്ക്കൊപ്പം ഈ സമീപനം നിലനിർത്താനായില്ല.

സ്ഥാപനം വളർന്നതോടെ ഈ പ്രവർത്തനപ്രശ്നങ്ങൾ കൈകാര്യം ചെയ്യുക കൂടുതൽ ദുഷ്കരമായി. ആസൂത്രണം നടത്തുന്ന ഏക കേന്ദ്ര ടീം ഇല്ലാതിരുന്നത് പല ടീമുകളുടെയും മോശം ആസൂത്രണത്തിന് കാരണമായി. അതോടെ ഞങ്ങൾ വീണ്ടും ബഹു-ടെനന്റ് പരിഹാരത്തിലേക്ക് നീങ്ങി. പങ്കിട്ട ടെനൻസി രൂപകൽപ്പനയിലൂടെ ആദ്യകാല പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ Azure ടീമുമായി ചേർന്ന് പ്രവർത്തിച്ചു:

ഏറ്റവും കൂടുതൽ ഉപയോഗിക്കുന്ന കീകളെ ആദ്യം നിയന്ത്രിക്കുന്നത്, ഒരു ഭൗതിക പാർട്ടീഷന്റെ മുഴുവൻ ത്രൂപുട്ടും അയൽ ജോലിഭാരങ്ങൾ കൈവശപ്പെടുത്തുന്നത് തടയുന്നു. ഒരൊറ്റ കീ സൈറ്റ് മുഴുവൻ ബാധിക്കുന്ന തരത്തിലുള്ള അയൽ ജോലിഭാര ശല്യം ഇതിലൂടെ കുറയുന്നു.

അഭ്യർത്ഥനകളെ തട്ടുകളാക്കുന്ന QoS, കൂട്ടമായി ഡാറ്റ ചേർക്കുകയോ പുറത്തെടുക്കുകയോ ചെയ്യുന്ന ഓഫ്‌ലൈൻ ജോലിഭാരങ്ങൾ ഒരു ഭൗതിക പാർട്ടീഷന്റെ മുഴുവൻ ത്രൂപുട്ടും ഉപയോഗിക്കുന്നത് തടയുന്നു. ഈ ജോലികളുടെ അഭ്യർത്ഥനകൾക്ക് കുറഞ്ഞ മുൻഗണന നൽകുന്നതിനാൽ അവയാണ് ആദ്യം നിയന്ത്രിക്കപ്പെടുന്നത്. ഉപയോക്താക്കളെ നേരിട്ട് സേവിക്കുന്ന, ഉയർന്ന മുൻഗണനയുള്ള സംവേദനാത്മക അഭ്യർത്ഥനകൾക്ക് ഇതുമൂലം നിയന്ത്രണം ഒഴിവാകുന്നു.

മുൻകൂട്ടി ശേഷി അനുവദിക്കുന്ന രീതിയിലെ ദുർബല പാർട്ടീഷൻ പ്രശ്നം പരിഹരിക്കാവുന്ന സെർവർലെസ് രീതി Azure Cosmos DB-യിൽ നേരത്തേ ഉണ്ടായിരുന്നു. എന്നാൽ വലിയൊരു പോരായ്മയുണ്ടായിരുന്നു: സംഭരണ ഉപയോഗത്തിനനുസരിച്ച് മാത്രമേ അത് വളർന്നിരുന്നുള്ളൂ. ഓരോ ഭൗതിക പാർട്ടീഷന്റെയും RU ഉപയോഗം 5,000 RU/s ആയി പരിമിതപ്പെടുത്തിയിരുന്നു. ദുർബല പാർട്ടീഷൻ പ്രശ്നം ഇത് പരിഹരിക്കുമെങ്കിലും, RU കൂടുതലായി വേണ്ട ഉപയോഗങ്ങൾ വിപുലീകരിക്കാൻ തടസ്സമാകും.

Azure Cosmos DB ടീം ഞങ്ങൾക്കായി മെച്ചപ്പെടുത്തിയ പുതിയ സെർവർലെസ് രീതി നിർമിച്ചു. അതിൽ ഓരോ ഭൗതിക പാർട്ടീഷനും 10,000 RU/s വരെ വളരാം. സംഭരണ ഉപയോഗത്തിനു പുറമേ RU ഉപയോഗത്തെ അടിസ്ഥാനമാക്കിയും വിഭജനം നടത്താം. ഇതോടെ കണ്ടെയ്‌നറുകൾ നേരിട്ട് നിരീക്ഷിച്ച് ശേഷി കൂട്ടേണ്ടതില്ലാതായി.

ഈ മാറ്റങ്ങളിലൂടെ വീണ്ടും ഒരു പങ്കിട്ട കണ്ടെയ്‌നർ ഉപയോഗിക്കാനായി. ജോലിഭാരങ്ങൾ തമ്മിലുള്ള വേർതിരിക്കൽ നിലനിർത്തിക്കൊണ്ട്, ഉൽപ്പന്ന ടീമുകളുടെ പ്രാരംഭവും തുടർച്ചയായതുമായ ശേഷി ആസൂത്രണത്തിന്റെ ആവശ്യകത വളരെ ലളിതമാക്കി. ഉൽപ്പന്ന വികസനം വേഗത്തിലായിട്ടും, തുടർന്നുള്ള മാസങ്ങളിൽ വിഭവവിന്യാസമോ അയൽ ജോലിഭാരമോ സംബന്ധിച്ച ഒരു തകരാറും ഉണ്ടായിട്ടില്ല.

കമ്പനികൾ OpenAI-യുടെ വലുപ്പത്തിലെത്തുമ്പോൾ, നിയന്ത്രിത സേവനങ്ങളുടെ നടത്തിപ്പ് അത്രത്തോളം “മറ്റുള്ളവർ നോക്കിക്കൊള്ളുന്ന” ഒന്നല്ലാതാകുന്നു. ക്ലൗഡ് ദാതാവിന്റെ അടിസ്ഥാനസൗകര്യത്തിൽ പല ജോലിഭാരങ്ങളും അസാധാരണ വലുപ്പമുള്ളവയായി മാറുന്നു. Azure Cosmos DB-യുടെ ഏറ്റവും വലിയ ഉപയോക്താക്കളിലൊന്നായി OpenAI മാറിയപ്പോൾ, വിജയകരമായ നടത്തിപ്പിന് വേറൊരു സമീപനം വേണ്ടിവന്നു: പങ്കിട്ട പരിശോധനകൾ, പങ്കിട്ട ഡാഷ്‌ബോർഡുകൾ, നേരിട്ടുള്ള എൻജിനീയറിങ് ആശയവിനിമയം, ഞങ്ങളുടെ തോതിൽ മാത്രം പ്രത്യക്ഷപ്പെടുന്ന തകരാറുകളിൽ സംയുക്ത ഉത്തരവാദിത്തം. ഇന്ന് ഞങ്ങളുടെ ഏറ്റവും വലിയ Azure Cosmos DB അക്കൗണ്ട് പതിനായിരക്കണക്കിനല്ല, പതിനുകളുടെ ഗുണിതങ്ങളായ പെറ്റാബൈറ്റുകൾ ഡാറ്റ സൂക്ഷിക്കുകയും 2 കോടിയിലേറെ QPS കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു. ഞങ്ങൾക്കറിയാവുന്നിടത്തോളം, Azure Cosmos DB ഇത്ര വലിയ തോതിൽ വിന്യസിച്ച ഏക കമ്പനി ഞങ്ങളാണ്.

2024 അവസാനത്തെ ഒരു മേഖലാതല സേവനതടസ്സം ഈ സഹകരണം എന്തുകൊണ്ട് ആവശ്യമായിരുന്നെന്ന് വ്യക്തമാക്കി. ഞങ്ങളുടെ ഏറ്റവും വലിയ Azure Cosmos DB അക്കൗണ്ടുകളിലൊന്നിന്റെ പ്രാഥമിക Azure മേഖലയിൽ അന്ന് വൈദ്യുതി മുടങ്ങി. തുടർന്നുള്ള പകരം മേഖലയിലേക്കുള്ള മാറ്റത്തിൽ, ഏറ്റവും വലിയ അക്കൗണ്ടുകൾ ദ്വിതീയ മേഖലയിലേക്ക് മാറ്റാൻ മണിക്കൂറുകൾ വേണ്ടിവരുമെന്ന് മനസ്സിലായി. ഞങ്ങളുടെ തോതിൽ ഈ മാറ്റം ഞങ്ങളുടെ ടീമോ Azure Cosmos DB ടീമോ പരിശോധിച്ചിരുന്നില്ല.

ഏകദേശം ഒരു മാസത്തിനുശേഷം ആ അക്കൗണ്ടുകൾ പഴയ മേഖലയിലേക്ക് തിരിച്ചുമാറ്റുമ്പോൾ മറ്റൊരു ഗുരുതര തടസ്സത്തിന് ഞങ്ങൾ കാരണമായി. പഴയ മേഖലയിലേക്കുള്ള കണക്ഷനുകളുടെ കുത്തൊഴുക്ക് അവിടത്തെ Azure Cosmos DB ഗേറ്റ്‌വേയെ തളർത്തി. ഗേറ്റ്‌വേ രീതിയിലുള്ള Azure Cosmos DB ക്ലയന്റ് മേഖലാമാറ്റം കൈകാര്യം ചെയ്ത രീതിയിലെ ഒരു പ്രത്യേകതയായിരുന്നു കാരണം. ചില ഭൗതിക പാർട്ടീഷനുകൾ മാത്രം തിരിച്ചെത്തിയിട്ടും എല്ലാ ക്ലയന്റുകളും ഉടൻ പഴയ മേഖലയിലേക്ക് കണക്ഷനുകൾ സ്ഥാപിച്ച് അഭ്യർത്ഥനകൾ അയച്ചു.

ഓരോ തടസ്സത്തിലും OpenAI-യും Azure-ഉം തങ്ങളുടെ തകരാർ കൈകാര്യം ചെയ്യൽ നടപടികൾ പിന്തുടർന്നു. നിരവധി മൂലകാരണങ്ങൾ കണ്ടെത്തി പരിഹാരങ്ങൾ നടപ്പാക്കി. എന്നാൽ ഈ തടസ്സങ്ങൾ, ഞങ്ങളുടെ ടീമും Azure Cosmos DB ടീമും പ്രവർത്തിക്കുകയും പരിശോധിക്കുകയും ചെയ്ത രീതികളിലെ കൂടുതൽ വലിയ വ്യവസ്ഥാപരമായ പ്രശ്നത്തിന്റെ ലക്ഷണങ്ങളായിരുന്നു. തുടക്കത്തിൽ നിയന്ത്രിത സേവനങ്ങൾ ഉപയോഗിച്ചത് വേഗത്തിൽ മുന്നേറാനും ബിസിനസ് ലക്ഷ്യങ്ങളിൽ ശ്രദ്ധിക്കാനും സഹായിച്ചു. വലിയ തോതിലെത്തുമ്പോൾ ഇത്തരം സേവനങ്ങളുടെ നടത്തിപ്പ് പൂർണമായി ദാതാവിനെ ഏൽപ്പിക്കാനാവില്ല. രൂപകൽപ്പന മുതൽ നടത്തിപ്പ് വരെ എല്ലാ തലങ്ങളിലും ദാതാവുമായി ആഴത്തിലുള്ള സംയോജനം ആവശ്യമാണ്.

ഇന്ന് Habitat, Azure എൻജിനീയറിങ് ടീമുകൾ ഞങ്ങളുടെ സേവന പാളികൾ മുതൽ Azure Cosmos DB-യുടെ ഭൗതിക സംഭരണ പാളികൾ വരെ Habitat-ന്റെ എല്ലാ തലങ്ങളും സംയുക്തമായി നിരീക്ഷിക്കുന്നു. തത്സമയ സേവനത്തിനുള്ളതിനു തുല്യമായ വലുപ്പമുള്ള, എന്നാൽ അതിനായി ഉപയോഗിക്കാത്ത Azure Cosmos DB അക്കൗണ്ടിൽ ഞങ്ങൾ മാറ്റങ്ങൾ പ്രവർത്തിപ്പിക്കുകയും പരിശോധിക്കുകയും ചെയ്യുന്നു. SDK-കൾ ഒരുമിച്ച് പരിശോധിച്ച് പരിഷ്കരിക്കുകയും Azure Cosmos DB അക്കൗണ്ടുകളുടെ വലുപ്പവും ശേഷിവർധനയും സംബന്ധിച്ച മികച്ച രീതികൾ നിർണയിക്കുകയും ചെയ്യുന്നു. Teams വഴി എൻജിനീയറിങ് സംഘങ്ങൾക്ക് പരസ്പരം നേരിട്ട് ബന്ധപ്പെടാം. പിന്തുണയുടെ വിവിധ തട്ടുകളിലൂടെ പോകാതെ അടിയന്തര അറിയിപ്പുകൾ നേരിട്ട് അയയ്ക്കാനുള്ള മാർഗങ്ങളും ഒരുക്കിയിട്ടുണ്ട്.

Azure Cosmos DB കൺട്രോൾ പ്ലെയിനും ഗേറ്റ്‌വേയും കൂടുതൽ വിപുലീകരിക്കാനായി കഴിഞ്ഞ വർഷം ഗണ്യമായ സംയുക്ത പ്രവർത്തനം നടന്നു. മെറ്റാഡാറ്റ പാർട്ടീഷനെ സംരക്ഷിക്കാൻ ഗേറ്റ്‌വേയിൽ ലോഡ് സംരക്ഷണവും വിവിധ Azure Cosmos DB മെറ്റാഡാറ്റയുടെ കാഷിങ്ങും ചേർത്തു. കണക്ഷൻ പൂളിങ്ങും കൂടുതൽ കണക്ഷൻ പുനരുപയോഗവും വഴി ഞങ്ങളുടെ Python habitat-service പ്രോസസുകളുടെ സമ്മർദം കുറച്ചു. സാധ്യമായിടത്ത് ജോലിഭാരങ്ങൾ ഒരേ ഇടത്ത് വിന്യസിക്കുകയും വ്യത്യസ്ത VPC-കൾ വഴി നിർണായക ജോലിഭാരങ്ങളെ ഓഫ്‌ലൈൻ ജോലിഭാരങ്ങളിൽനിന്ന് വേർതിരിക്കുകയും ചെയ്തു.

കഴിഞ്ഞ വർഷം ഞങ്ങളുടെ Azure Cosmos DB-യുടെ സ്ഥിരത ഉറപ്പാക്കാൻ ഈ തോതിലുള്ള സംയുക്ത എൻജിനീയറിങ് നിർണായകമായിരുന്നു. വലുപ്പമോ നിർണായകതയോ ഒരു പരിധിയിലെത്തുന്ന ഏതൊരു സംവിധാനത്തിനും ഇത്തരം കൂട്ടായ പ്രവർത്തനം ആവശ്യമാണ്: ചുമതലകളുടെ വേലിക്കെട്ടുകൾ നീക്കി സ്ഥാപനാതിർത്തികൾക്കപ്പുറം സഹകരിക്കുക.

ഭാഗം I-ൽ പറഞ്ഞതുപോലെ, ഞങ്ങളുടെ അടിസ്ഥാന സമീപനം ഇതാണ്: ആദ്യം പ്രവർത്തനക്ഷമമാക്കുക, പിന്നെ വേഗത്തിലാക്കുക, തുടർന്ന് ചെലവ് കുറയ്ക്കുക. ആദ്യം വിശ്വാസ്യത, പിന്നെ പ്രകടനം, തുടർന്ന് കാര്യക്ഷമത. 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 പോലുള്ള സംവിധാനങ്ങളെ പിന്തുടർന്ന്, കാഷ് അസാധുവാക്കാൻ ഞങ്ങൾ കൂടുതൽ വികസിതമായ രീതി സ്വീകരിച്ചു. Azure Cosmos DB-യുടെ മാറ്റ ഫീഡിലൂടെയുള്ള മാറ്റ ഡാറ്റാ ശേഖരണം (CDC) ഉപയോഗിച്ച് Habitat കാഷ് അസാധുവാക്കലുകൾ സെക്കൻഡുകൾക്കുള്ളിൽ ആഗോളമായി പ്രചരിപ്പിക്കുന്നു. ഇതിലൂടെ കാഷിൽ ഡാറ്റ ലഭിക്കുന്ന നിരക്ക് ഉയരുകയും പഴക്കം കുറയുകയും ചെയ്യുന്നു. ഞങ്ങളുടെ ഒരു സേവനം ഈ മാറ്റ ഫീഡ് വായിച്ച്, അടിസ്ഥാന ഡാറ്റ പുതുക്കുമ്പോൾ പ്രാദേശിക കാഷുകളിലെ പകർപ്പുകൾ അസാധുവാക്കുന്നു. അടുത്ത വായനയിൽ കാഷിൽ ഡാറ്റ ലഭിക്കാതിരിക്കുകയും ഏറ്റവും പുതിയ പതിപ്പ് കാഷിൽ നിറയ്ക്കപ്പെടുകയും ചെയ്യുന്നു.

ആദ്യത്തെ Python കോഡ് കൂടുതൽ വേഗമുള്ള Rust-ൽ മാറ്റിയെഴുതി Habitat സേവനത്തിന്റെതന്നെ അധികഭാരം നീക്കിയതിലൂടെയും വിലംബം (ലേറ്റൻസി) ഗണ്യമായി കുറച്ചു.

ഈ മാറ്റങ്ങൾ ചേർന്ന് ആഗോള വായനകളുടെ മൊത്തം p50 ഏകദേശം 120-ൽനിന്ന് 10 മില്ലിസെക്കൻഡായി കുറച്ചു. ഈ വർഷമാദ്യം പ്രകടനത്തിൽ ശ്രദ്ധിക്കാൻ തുടങ്ങിയശേഷം 12 മടങ്ങ് മെച്ചം.

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

ഡാറ്റാബേസ് മാറ്റങ്ങൾ തുടർ സംവിധാനങ്ങളിലെത്തിക്കുന്ന വിശ്വസനീയവും വിപുലീകരിക്കാവുന്നതുമായ CDC, Habitat കാഷിങ്ങിനപ്പുറവും നിർണായകമാണ്. ആയിരക്കണക്കിന് കണ്ടെയ്‌നറുകളിലും ദശലക്ഷക്കണക്കിന് പാർട്ടീഷനുകളിലുംനിന്ന് സെക്കൻഡിൽ ദശലക്ഷക്കണക്കിന് മാറ്റങ്ങൾ നൂറിലേറെ Kafka ടോപ്പിക്കുകളിലൂടെ ഒഴുകുന്നു. ക്രമേണ സ്ഥിരത കൈവരിക്കുന്ന ദ്വിതീയ സൂചികകൾ, ഡാറ്റാ കൈമാറ്റ പൈപ്പ്‌ലൈനുകൾ, ഓഫ്‌ലൈൻ വിശകലനം, തത്സമയ ഉൽപ്പന്ന സവിശേഷതകൾ എന്നിവയ്ക്കും ഇവ കരുത്തേകുന്നു. അടിസ്ഥാനസൗകര്യം ആഗോളമായി വളർന്നതോടെ വരികളിലെ മാറ്റങ്ങൾ നിരീക്ഷിക്കുക കൂടുതൽ സങ്കീർണമായി. സ്വന്തം തരത്തിലെ വരികൾ മാറുമ്പോഴെല്ലാം പ്രവർത്തിക്കുന്ന കോൾബാക്ക് രജിസ്റ്റർ ചെയ്യാൻ ക്ലയന്റ് പല കാര്യങ്ങളും ചെയ്യണം: ഡാറ്റയുള്ള Cosmos അക്കൗണ്ടുകളും കണ്ടെയ്‌നറുകളും കണ്ടെത്തുക, അതത് മേഖലകളിൽ അവ നിരീക്ഷിക്കുന്ന CDC വിന്യാസം തിരിച്ചറിയുക, CDC വർക്കറുകൾക്കും Kafka-യ്ക്കും സ്വന്തം കൺസ്യൂമറിനും വേണ്ട ശേഷി ഒരുക്കുക. ഇതെല്ലാം ഉൽപ്പന്ന ഡെവലപ്പർമാരിൽനിന്ന് മറച്ചുവയ്ക്കുകയാണ് ഞങ്ങളുടെ CDC പ്ലാറ്റ്‌ഫോമിന്റെ ലക്ഷ്യം. വരികൾ മാറുമ്പോൾ വിളിക്കേണ്ട ഫങ്ഷൻ ക്ലയന്റുകൾ ലളിതമായി രജിസ്റ്റർ ചെയ്യുന്നു; പിന്നിലെ ക്രമീകരണവും ശേഷിവർധനയും ഞങ്ങൾ നോക്കുന്നു.

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

Habitat-ന്റെ ആഭ്യന്തര Azure Cosmos DB ഉപയോഗം സങ്കീർണമാണെങ്കിലും, അടിസ്ഥാനസൗകര്യ വിശദാംശങ്ങൾ മറച്ച് ഉൽപ്പന്ന വികസനം വേഗത്തിലാക്കുക എന്നതാണ് അതിന്റെ പ്രധാന മൂല്യം. CDC പ്ലാറ്റ്‌ഫോമും അതുതന്നെ ചെയ്യുന്നു.

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

അടുത്ത 100 കോടി ഉപയോക്താക്കൾക്കായി Habitat-ഉം സംഭാഷണ സംഭരണവും വളർത്താൻ, അടിസ്ഥാനസൗകര്യത്തിലുടനീളം ഇതിലും വലിയ തോതിൽ ഡാറ്റ പകർത്താനുള്ള ബുദ്ധിമുട്ട് പരിഹരിക്കണം. ഇത് മുൻകൂട്ടിക്കണ്ട്, വലുപ്പമേറിയ Habitat ഡാറ്റാ തരങ്ങൾക്ക് അനുയോജ്യമായ എക്സാബൈറ്റ് തോതിലുള്ള സ്വന്തം ഓൺലൈൻ സംഭരണ സംവിധാനം ഞങ്ങൾ നിർമിച്ചുവരുന്നു. വികസനത്തിലുള്ള ഈ സംവിധാനം Rockset-ന്റെ RocksDB Cloud കോറും Raft അധിഷ്ഠിത പകർപ്പെടുക്കലും സംയോജിപ്പിക്കുന്നു. Azure Cosmos DB-യുടെ അതേ ഡോക്യുമെന്റ് മാതൃകയാണിത് ഉപയോഗിക്കുന്നത്. എന്നാൽ വേർതിരിച്ച സംഭരണവും ഭൗതിക പകർപ്പെടുക്കലും വഴി ആവശ്യമായ ഫ്ലാഷ് ശേഷി കുറയ്ക്കുന്നു; പകരം പരമാവധി qps കുറവായിരിക്കും.

അത്യാധുനിക തോതിലുള്ള ഇത്തരം ഡാറ്റാ അടിസ്ഥാനസൗകര്യ പ്രവർത്തനങ്ങളിൽ താൽപ്പര്യമുണ്ടെങ്കിൽ, ഞങ്ങളുടെ തൊഴിൽ അവസരങ്ങൾ നോക്കൂ⁠.