ഡാറ്റാബേസുകൾ കുബർനെറ്റസിൽ താമസിക്കുന്നുണ്ടോ?

എങ്ങനെയെങ്കിലും, ചരിത്രപരമായി, ഐടി വ്യവസായം ഏതെങ്കിലും കാരണത്താൽ രണ്ട് സോപാധിക ക്യാമ്പുകളായി തിരിച്ചിരിക്കുന്നു: "വേണ്ടി" ഉള്ളവരും "എതിരായി" ഉള്ളവരും. മാത്രമല്ല, തർക്ക വിഷയം പൂർണ്ണമായും ഏകപക്ഷീയമായിരിക്കും. ഏത് OS ആണ് നല്ലത്: Win അല്ലെങ്കിൽ Linux? ഒരു Android അല്ലെങ്കിൽ iOS സ്മാർട്ട്ഫോണിൽ? നിങ്ങൾ എല്ലാം മേഘങ്ങളിൽ സൂക്ഷിക്കണോ അതോ കോൾഡ് റെയിഡ് സ്റ്റോറേജിൽ ഇടുകയും സ്ക്രൂകൾ സുരക്ഷിതമായി ഇടുകയും ചെയ്യണോ? PHP ആളുകൾക്ക് പ്രോഗ്രാമർമാർ എന്ന് വിളിക്കാൻ അവകാശമുണ്ടോ? ഈ തർക്കങ്ങൾ ചിലപ്പോൾ അസ്തിത്വപരമായ സ്വഭാവമുള്ളവയാണ്, കായിക താൽപ്പര്യമല്ലാതെ മറ്റൊരു അടിസ്ഥാനവുമില്ല.

കണ്ടെയ്‌നറുകളുടെയും ഡോക്കറും സോപാധികമായ കെ 8 കളും ഉള്ള ഈ പ്രിയപ്പെട്ട പാചകരീതികളുടെ വരവോടെ, ബാക്കെൻഡിന്റെ വിവിധ മേഖലകളിൽ പുതിയ കഴിവുകൾ ഉപയോഗിക്കുന്നതിന് “അതിനായി”, “എതിരായ” ചർച്ചകൾ ആരംഭിച്ചു. (ഈ ചർച്ചയിൽ കുബെർനെറ്റസ് ഒരു ഓർക്കസ്ട്രേറ്ററായി നിർദ്ദേശിക്കപ്പെടുമെങ്കിലും, ഈ പ്രത്യേക ഉപകരണത്തിന്റെ തിരഞ്ഞെടുപ്പിന് അടിസ്ഥാന പ്രാധാന്യമില്ല. പകരം, നിങ്ങൾക്ക് ഏറ്റവും സൗകര്യപ്രദവും പരിചിതവുമാണെന്ന് തോന്നുന്ന മറ്റേതെങ്കിലും ഒന്ന് മാറ്റിസ്ഥാപിക്കാം. .)

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

ബ്രൈറ്റ് സൈഡ്

ലൈറ്റ് സൈഡിന്റെ വാദം ഒരു വാചകത്തിൽ സംക്ഷിപ്തമായി വിവരിക്കാം: "ഹലോ, 2k19 വിൻഡോയ്ക്ക് പുറത്താണ്!" തീർച്ചയായും ഇത് പോപ്പുലിസം പോലെ തോന്നുന്നു, പക്ഷേ നിങ്ങൾ സാഹചര്യം വിശദമായി പരിശോധിക്കുകയാണെങ്കിൽ, അതിന് അതിന്റെ ഗുണങ്ങളുണ്ട്. നമുക്ക് ഇപ്പോൾ അവ ക്രമീകരിക്കാം.

നിങ്ങൾക്ക് ഒരു വലിയ വെബ് പ്രോജക്റ്റ് ഉണ്ടെന്ന് പറയാം. ഇത് തുടക്കത്തിൽ ഒരു മൈക്രോസർവീസ് സമീപനത്തിന്റെ അടിസ്ഥാനത്തിൽ നിർമ്മിക്കാമായിരുന്നു, അല്ലെങ്കിൽ ഒരു ഘട്ടത്തിൽ അത് ഒരു പരിണാമ പാതയിലൂടെയാണ് അതിലേക്ക് വന്നത് - ഇത് വളരെ പ്രധാനമല്ല, വാസ്തവത്തിൽ. നിങ്ങൾ ഞങ്ങളുടെ പ്രോജക്‌റ്റ് പ്രത്യേക മൈക്രോസർവീസുകളായി വിതറി, ഓർക്കസ്ട്രേഷൻ സജ്ജീകരിക്കുക, ലോഡ് ബാലൻസിങ്, സ്‌കെയിലിംഗ്. ഇപ്പോൾ, വ്യക്തമായ മനസ്സാക്ഷിയോടെ, വീണുപോയ സെർവറുകൾ ഉയർത്തുന്നതിനുപകരം ഹബ്ര ഇഫക്റ്റുകൾക്കിടയിൽ നിങ്ങൾ ഒരു ഊഞ്ഞാലിൽ ഒരു മോജിറ്റോ കുടിക്കുന്നു. എന്നാൽ എല്ലാ പ്രവർത്തനങ്ങളിലും നിങ്ങൾ സ്ഥിരത പുലർത്തണം. മിക്കപ്പോഴും, ആപ്ലിക്കേഷൻ തന്നെ - കോഡ് - കണ്ടെയ്നറൈസ് ചെയ്യപ്പെടുന്നു. കോഡ് കൂടാതെ നമുക്ക് മറ്റെന്താണ് ഉള്ളത്?

അത് ശരിയാണ്, ഡാറ്റ. ഏതൊരു പ്രോജക്റ്റിന്റെയും ഹൃദയം അതിന്റെ ഡാറ്റയാണ്: ഇത് ഒന്നുകിൽ ഒരു സാധാരണ DBMS ആകാം - MySQL, Postgre, MongoDB, അല്ലെങ്കിൽ തിരയലിനായി ഉപയോഗിക്കുന്ന സംഭരണം (ElasticSearch), കാഷിംഗിനുള്ള കീ-മൂല്യം സംഭരണം - ഉദാഹരണത്തിന്, redis മുതലായവ. നിലവിൽ ഞങ്ങൾ അങ്ങനെയല്ല. മോശമായി എഴുതിയ ചോദ്യങ്ങൾ കാരണം ഡാറ്റാബേസ് ക്രാഷാകുമ്പോൾ വളഞ്ഞ ബാക്കെൻഡ് നടപ്പിലാക്കൽ ഓപ്ഷനുകളെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും, പകരം ക്ലയന്റ് ലോഡിന് കീഴിലുള്ള ഈ ഡാറ്റാബേസിന്റെ തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും. എല്ലാത്തിനുമുപരി, ഞങ്ങൾ ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ കണ്ടെയ്‌നറൈസ് ചെയ്യുകയും ഇൻകമിംഗ് അഭ്യർത്ഥനകൾ എത്ര വേണമെങ്കിലും പ്രോസസ്സ് ചെയ്യുന്നതിന് സ്വതന്ത്രമായി സ്കെയിൽ ചെയ്യാൻ അനുവദിക്കുകയും ചെയ്യുമ്പോൾ, ഇത് സ്വാഭാവികമായും ഡാറ്റാബേസിലെ ലോഡ് വർദ്ധിപ്പിക്കുന്നു.

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

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

നിങ്ങൾക്ക് ഒരു ക്യാച്ച് അനുഭവപ്പെടുന്നുണ്ടോ? ലോഡ് വിതരണം ചെയ്യുന്നതിനും പ്രധാന വെബ് സെർവർ ക്രാഷ് ചെയ്യാതിരിക്കുന്നതിനും ഞങ്ങൾ k8s അല്ലെങ്കിൽ Swarm ഉപയോഗിക്കുന്നു, പക്ഷേ ഡാറ്റാബേസിനായി ഞങ്ങൾ ഇത് ചെയ്യുന്നില്ല. എന്നാൽ ഡാറ്റാബേസ് ക്രാഷായാൽ, ഞങ്ങളുടെ മുഴുവൻ ക്ലസ്റ്റേർഡ് ഇൻഫ്രാസ്ട്രക്ചറിനും അർത്ഥമില്ല - ഡാറ്റാബേസ് ആക്സസ് പിശക് നൽകുന്ന ശൂന്യമായ വെബ് പേജുകൾക്ക് എന്ത് പ്രയോജനം?

അതുകൊണ്ടാണ് സാധാരണയായി ചെയ്യുന്നത് പോലെ വെബ് സെർവറുകൾ മാത്രമല്ല, ഡാറ്റാബേസ് ഇൻഫ്രാസ്ട്രക്ചറും ക്ലസ്റ്റർ ചെയ്യേണ്ടത്. ഈ രീതിയിൽ മാത്രമേ നമുക്ക് ഒരു ടീമിൽ പൂർണ്ണമായി പ്രവർത്തിക്കുന്ന ഒരു ഘടന ഉറപ്പാക്കാൻ കഴിയൂ, എന്നാൽ അതേ സമയം പരസ്പരം സ്വതന്ത്രവും. മാത്രമല്ല, ഞങ്ങളുടെ ബാക്കെൻഡിന്റെ പകുതിയും ലോഡിന് കീഴിൽ "തകർച്ച" ഉണ്ടായാലും, ബാക്കിയുള്ളവ നിലനിൽക്കും, കൂടാതെ ക്ലസ്റ്ററിനുള്ളിൽ ഡാറ്റാബേസുകൾ പരസ്പരം സമന്വയിപ്പിക്കുന്ന സംവിധാനവും പുതിയ ക്ലസ്റ്ററുകൾ അനന്തമായി സ്കെയിൽ ചെയ്യാനും വിന്യസിക്കാനും ഉള്ള കഴിവ് ആവശ്യമായ ശേഷി വേഗത്തിൽ എത്താൻ സഹായിക്കും - ഡാറ്റാ സെന്ററിൽ റാക്കുകൾ ഉണ്ടായിരുന്നെങ്കിൽ മാത്രം.

കൂടാതെ, ക്ലസ്റ്ററുകളിൽ വിതരണം ചെയ്യുന്ന ഡാറ്റാബേസ് മോഡൽ ഈ ഡാറ്റാബേസ് ആവശ്യമുള്ളിടത്തേക്ക് കൊണ്ടുപോകാൻ നിങ്ങളെ അനുവദിക്കുന്നു; ഞങ്ങൾ ഒരു ആഗോള സേവനത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, സാൻ ഫ്രാൻസിസ്കോ ഏരിയയിൽ എവിടെയെങ്കിലും ഒരു വെബ് ക്ലസ്റ്റർ സ്പിന്നപ്പ് ചെയ്യുന്നത് തികച്ചും യുക്തിരഹിതമാണ്, അതേ സമയം മോസ്കോ മേഖലയിലും തിരിച്ചും ഒരു ഡാറ്റാബേസ് ആക്സസ് ചെയ്യുമ്പോൾ പാക്കറ്റുകൾ അയയ്ക്കുക.

കൂടാതെ, ഡാറ്റാബേസിന്റെ കണ്ടെയ്നറൈസേഷൻ, സിസ്റ്റത്തിന്റെ എല്ലാ ഘടകങ്ങളും ഒരേ തലത്തിലുള്ള അമൂർത്തീകരണത്തിൽ നിർമ്മിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. അഡ്‌മിനിസ്‌ട്രേറ്റർമാരുടെ സജീവ പങ്കാളിത്തമില്ലാതെ ഡെവലപ്പർമാർ വഴി കോഡിൽ നിന്ന് നേരിട്ട് ഈ സിസ്റ്റം തന്നെ കൈകാര്യം ചെയ്യുന്നത് സാധ്യമാക്കുന്നു. പുതിയ ഉപപദ്ധതിക്ക് ഒരു പ്രത്യേക DBMS ആവശ്യമാണെന്ന് ഡെവലപ്പർമാർ കരുതി - എളുപ്പമാണ്! ഒരു yaml ഫയൽ എഴുതി, അത് ക്ലസ്റ്ററിലേക്ക് അപ്‌ലോഡ് ചെയ്‌തു, നിങ്ങൾ പൂർത്തിയാക്കി.

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

കണ്ടെയ്നറൈസേഷനും, വാസ്തവത്തിൽ, നിങ്ങളുടെ പ്രോജക്റ്റിന്റെ ഡാറ്റാബേസിന്റെ വിതരണം ചെയ്ത ഫിസിക്കൽ ടോപ്പോളജിയും അത്തരം സാധൂകരണ നിമിഷങ്ങൾ ഒഴിവാക്കാൻ സഹായിക്കുന്നു. ഒരു പുതുമുഖത്തെ വിശ്വസിക്കുന്നില്ലേ? ശരി! മറ്റ് ക്ലസ്റ്ററുകളിൽ നിന്ന് ഡാറ്റാബേസ് വിച്ഛേദിക്കുന്നതിനും പ്രവർത്തിക്കുന്നതിനും അദ്ദേഹത്തിന് സ്വന്തം ക്ലസ്റ്റർ നൽകാം - മാനുവൽ പുഷ് വഴിയും രണ്ട് കീകളുടെ സിൻക്രണസ് റൊട്ടേഷനിലൂടെയും മാത്രം സിൻക്രൊണൈസേഷൻ (ഒന്ന് ടീം ലീഡിന്, മറ്റൊന്ന് അഡ്മിന്). പിന്നെ എല്ലാവരും സന്തോഷത്തിലാണ്.

ഡാറ്റാബേസ് ക്ലസ്റ്ററിംഗിന്റെ എതിരാളികളായി മാറാനുള്ള സമയമാണിത്.

ഇരുണ്ട വശം

ഡാറ്റാബേസ് കണ്ടെയ്‌നറൈസ് ചെയ്യുന്നതും ഒരു സെൻട്രൽ സെർവറിൽ അത് പ്രവർത്തിപ്പിക്കുന്നത് തുടരുന്നതും മൂല്യവത്തല്ലെന്ന് വാദിച്ചുകൊണ്ട്, യാഥാസ്ഥിതികരുടെ വാചാടോപത്തിലേക്കും “മുത്തച്ഛന്മാർ ഹാർഡ്‌വെയറിൽ ഡാറ്റാബേസുകൾ നടത്തിയിരുന്നു, ഞങ്ങളും അങ്ങനെ ചെയ്യും!” എന്ന വാചാടോപത്തിലേക്ക് വഴുതിപ്പോകില്ല. പകരം, കണ്ടെയ്‌നറൈസേഷൻ യഥാർത്ഥത്തിൽ വ്യക്തമായ ലാഭവിഹിതം നൽകുന്ന ഒരു സാഹചര്യം കൊണ്ടുവരാൻ ശ്രമിക്കാം.

സമ്മതിക്കുക, ഒരു കണ്ടെയ്‌നറിൽ ശരിക്കും അടിസ്ഥാനം ആവശ്യമുള്ള പ്രോജക്റ്റുകൾ മികച്ച മില്ലിംഗ് മെഷീൻ ഓപ്പറേറ്ററല്ല ഒരു കൈവിരലിൽ കണക്കാക്കാം. മിക്കവാറും, k8s അല്ലെങ്കിൽ ഡോക്കർ സ്വാം ഉപയോഗിക്കുന്നത് പോലും അനാവശ്യമാണ് - മിക്കപ്പോഴും ഈ ഉപകരണങ്ങൾ അവലംബിക്കുന്നത് സാങ്കേതികവിദ്യകളുടെ പൊതുവായ ഹൈപ്പും ലിംഗഭേദത്തിന്റെ വ്യക്തിയിലെ “സർവ്വശക്തന്റെ” മനോഭാവവും കാരണമാണ്. മേഘങ്ങളും പാത്രങ്ങളും. ശരി, കാരണം ഇപ്പോൾ ഇത് ഫാഷനാണ്, എല്ലാവരും അത് ചെയ്യുന്നു.

കുറഞ്ഞത് പകുതി കേസുകളിലെങ്കിലും, ഒരു പ്രോജക്റ്റിൽ കുബർനെറ്റിസ് അല്ലെങ്കിൽ ഡോക്കർ ഉപയോഗിക്കുന്നത് അനാവശ്യമാണ്. ക്ലയന്റിന്റെ അടിസ്ഥാന സൗകര്യങ്ങൾ പരിപാലിക്കാൻ നിയമിച്ച എല്ലാ ടീമുകൾക്കോ ​​ഔട്ട്സോഴ്സിംഗ് കമ്പനികൾക്കോ ​​ഇതിനെക്കുറിച്ച് അറിയില്ല എന്നതാണ് പ്രശ്നം. കണ്ടെയ്നറുകൾ അടിച്ചേൽപ്പിക്കുമ്പോൾ ഇത് മോശമാണ്, കാരണം ഇത് ക്ലയന്റിന് ഒരു നിശ്ചിത തുക നാണയങ്ങൾ ചിലവാക്കുന്നു.

പൊതുവേ, ഈ അടിസ്ഥാന സൗകര്യ പ്രശ്‌നങ്ങൾ ഔട്ട്‌സോഴ്‌സ് ചെയ്യുന്ന ക്ലയന്റുകളെ ഡോക്കർ/ക്യൂബ് മാഫിയ മണ്ടത്തരമായി തകർക്കുകയാണെന്ന് അഭിപ്രായമുണ്ട്. എല്ലാത്തിനുമുപരി, ക്ലസ്റ്ററുകളുമായി പ്രവർത്തിക്കുന്നതിന്, ഇതിന് കഴിവുള്ളതും നടപ്പിലാക്കിയ പരിഹാരത്തിന്റെ വാസ്തുവിദ്യ പൊതുവെ മനസ്സിലാക്കുന്നതുമായ എഞ്ചിനീയർമാരെ ഞങ്ങൾക്ക് ആവശ്യമാണ്. റിപ്പബ്ലിക് പ്രസിദ്ധീകരണത്തിൽ ഞങ്ങളുടെ കേസ് ഞങ്ങൾ ഇതിനകം വിവരിച്ചിട്ടുണ്ട് - അവിടെ ഞങ്ങൾ ക്ലയന്റ് ടീമിനെ കുബർനെറ്റിസിന്റെ യാഥാർത്ഥ്യങ്ങളിൽ പ്രവർത്തിക്കാൻ പരിശീലിപ്പിച്ചു, എല്ലാവരും സംതൃപ്തരായി. അത് മാന്യമായിരുന്നു. പലപ്പോഴും, k8s “ഇനിപ്ലിമെന്റർമാർ” ക്ലയന്റിന്റെ ഇൻഫ്രാസ്ട്രക്ചർ ബന്ദികളാക്കുന്നു - കാരണം അവിടെ എല്ലാം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഇപ്പോൾ അവർക്ക് മാത്രമേ മനസ്സിലാകൂ; ക്ലയന്റിന്റെ ഭാഗത്ത് സ്പെഷ്യലിസ്റ്റുകളൊന്നുമില്ല.

ഈ രീതിയിൽ ഞങ്ങൾ വെബ് സെർവർ ഭാഗം മാത്രമല്ല, ഡാറ്റാബേസ് മെയിന്റനൻസും ഔട്ട്സോഴ്സ് ചെയ്യുന്നുവെന്ന് ഇപ്പോൾ സങ്കൽപ്പിക്കുക. BD ഹൃദയമാണെന്നും ഹൃദയത്തിന്റെ നഷ്ടം ഏതൊരു ജീവജാലത്തിനും മാരകമാണെന്നും ഞങ്ങൾ പറഞ്ഞു. ചുരുക്കത്തിൽ, സാധ്യതകൾ മികച്ചതല്ല. അതിനാൽ, കുബർനെറ്റിസിന്റെ ഹൈപ്പിനുപകരം, പല പ്രോജക്റ്റുകളും AWS-നുള്ള സാധാരണ താരിഫിനെ വെറുതെ ബുദ്ധിമുട്ടിക്കരുത്, അത് അവരുടെ സൈറ്റിലെ/പ്രോജക്റ്റിലെ ലോഡിലെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കും. എന്നാൽ AWS ഇപ്പോൾ ഫാഷനല്ല, ഷോ-ഓഫുകൾക്ക് പണത്തേക്കാൾ വിലയുണ്ട് - നിർഭാഗ്യവശാൽ, ഐടി പരിതസ്ഥിതിയിലും.

ശരി. ഒരുപക്ഷേ പ്രോജക്‌റ്റിന് ശരിക്കും ക്ലസ്റ്ററിംഗ് ആവശ്യമാണ്, എന്നാൽ സ്‌റ്റേറ്റ്‌ലെസ് ആപ്ലിക്കേഷനുകൾ ഉപയോഗിച്ച് എല്ലാം വ്യക്തമാണെങ്കിൽ, ഒരു ക്ലസ്റ്റേർഡ് ഡാറ്റാബേസിനായി നമുക്ക് എങ്ങനെ മാന്യമായ നെറ്റ്‌വർക്ക് കണക്റ്റിവിറ്റി സംഘടിപ്പിക്കാനാകും?

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

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

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

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

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

ഔട്ട്പുട്ട് പകരം

"ഡാറ്റാബേസ് വെർച്വലൈസ് ചെയ്യണോ വേണ്ടയോ" എന്ന വ്യക്തമായ നിഗമനത്തിനായി നിങ്ങൾ കാത്തിരിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ നിങ്ങളെ നിരാശരാക്കും: അത് ഇവിടെ ഉണ്ടാകില്ല. കാരണം, ഏതെങ്കിലും അടിസ്ഥാന സൗകര്യ പരിഹാരം സൃഷ്ടിക്കുമ്പോൾ, ഒരാളെ നയിക്കേണ്ടത് ഫാഷനും പുരോഗതിയുമല്ല, മറിച്ച്, ഒന്നാമതായി, സാമാന്യബുദ്ധിയാണ്.

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

അവലംബം: www.habr.com