Quay.io-ലെ പോസ്റ്റ് മോർട്ടം ലഭ്യമല്ല

കുറിപ്പ്. വിവർത്തനം.: ആഗസ്റ്റ് ആദ്യം, Red Hat അതിന്റെ സേവനത്തിന്റെ ഉപയോക്താക്കൾ മുൻ മാസങ്ങളിൽ നേരിട്ട പ്രവേശനക്ഷമത പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനെക്കുറിച്ച് പരസ്യമായി സംസാരിച്ചു. Quay.io (ഇത് CoreOS വാങ്ങുന്നതിനൊപ്പം കമ്പനിക്ക് ലഭിച്ച കണ്ടെയ്നർ ഇമേജുകൾക്കായുള്ള ഒരു രജിസ്ട്രിയെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്). ഈ സേവനത്തിലുള്ള നിങ്ങളുടെ താൽപ്പര്യം പരിഗണിക്കാതെ തന്നെ, അപകടത്തിന്റെ കാരണങ്ങൾ കണ്ടുപിടിക്കുന്നതിനും ഇല്ലാതാക്കുന്നതിനും കമ്പനിയുടെ SRE എഞ്ചിനീയർമാർ സ്വീകരിച്ച പാത പ്രബോധനപരമാണ്.

മെയ് 19-ന്, അതിരാവിലെ (ഈസ്റ്റേൺ ഡേലൈറ്റ് സമയം, EDT), quay.io സേവനം തകരാറിലായി. സോഫ്റ്റ്വെയർ നിർമ്മിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനുമുള്ള ഒരു പ്ലാറ്റ്ഫോമായി quay.io ഉപയോഗിക്കുന്ന quay.io ഉപഭോക്താക്കളെയും ഓപ്പൺ സോഴ്സ് പ്രോജക്ടുകളെയും അപകടം ബാധിച്ചു. Red Hat ഇരുവരുടെയും വിശ്വാസത്തെ വിലമതിക്കുന്നു.

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

«എന്താണ് മാറിയിരിക്കുന്നത്?"- ഇത്തരം സന്ദർഭങ്ങളിൽ സാധാരണയായി ചോദിക്കുന്ന ആദ്യത്തെ ചോദ്യമാണിത്. പ്രശ്‌നത്തിന് തൊട്ടുമുമ്പ്, ഓപ്പൺഷിഫ്റ്റ് ഡെഡിക്കേറ്റഡ് ക്ലസ്റ്റർ (ഇത് quay.io പ്രവർത്തിപ്പിക്കുന്നു) പതിപ്പ് 4.3.19-ലേക്ക് അപ്‌ഡേറ്റ് ചെയ്യാൻ തുടങ്ങിയത് ഞങ്ങൾ ശ്രദ്ധിച്ചു. quay.io Red Hat OpenShift Dedicated (OSD)-ൽ പ്രവർത്തിക്കുന്നതിനാൽ, പതിവ് അപ്‌ഡേറ്റുകൾ പതിവായിരുന്നു, ഒരിക്കലും പ്രശ്‌നങ്ങൾ ഉണ്ടാക്കിയില്ല. കൂടാതെ, കഴിഞ്ഞ ആറ് മാസത്തിനിടെ, സേവനത്തിൽ യാതൊരു തടസ്സവുമില്ലാതെ ഞങ്ങൾ നിരവധി തവണ ക്വായ് ക്ലസ്റ്ററുകൾ നവീകരിച്ചു.

ഞങ്ങൾ സേവനം പുനഃസ്ഥാപിക്കാൻ ശ്രമിക്കുന്നതിനിടയിൽ, മറ്റ് എഞ്ചിനീയർമാർ സോഫ്റ്റ്‌വെയറിന്റെ മുൻ പതിപ്പിനൊപ്പം ഒരു പുതിയ OSD ക്ലസ്റ്റർ തയ്യാറാക്കാൻ തുടങ്ങി, അങ്ങനെ എന്തെങ്കിലും സംഭവിച്ചാൽ, അവർക്ക് അതിൽ എല്ലാം വിന്യസിക്കാനാകും.

മൂലകാരണവിശകലനം

പതിനായിരക്കണക്കിന് ഡാറ്റാബേസ് കണക്ഷനുകളുടെ ഹിമപാതമാണ് പരാജയത്തിന്റെ പ്രധാന ലക്ഷണം, ഇത് MySQL ഉദാഹരണത്തെ ഫലപ്രദമായി പ്രവർത്തനരഹിതമാക്കി. ഇത് പ്രശ്നം കണ്ടെത്തുന്നത് ബുദ്ധിമുട്ടാക്കി. പ്രശ്നം വിലയിരുത്താൻ SRE ടീമിനെ സഹായിക്കുന്നതിന് ക്ലയന്റുകളിൽ നിന്നുള്ള പരമാവധി കണക്ഷനുകളുടെ പരിധി ഞങ്ങൾ നിശ്ചയിച്ചിട്ടുണ്ട്. ഡാറ്റാബേസിലേക്കുള്ള അസാധാരണമായ ട്രാഫിക്കൊന്നും ഞങ്ങൾ ശ്രദ്ധിച്ചില്ല: വാസ്തവത്തിൽ, മിക്ക അഭ്യർത്ഥനകളും വായിച്ചു, കുറച്ച് മാത്രമേ എഴുതിയിട്ടുള്ളൂ.

ഈ ഹിമപാതത്തിന് കാരണമായേക്കാവുന്ന ഡാറ്റാബേസ് ട്രാഫിക്കിലെ ഒരു പാറ്റേൺ തിരിച്ചറിയാനും ഞങ്ങൾ ശ്രമിച്ചു. എന്നിരുന്നാലും, ലോഗുകളിൽ ഞങ്ങൾക്ക് പാറ്റേണുകളൊന്നും കണ്ടെത്താൻ കഴിഞ്ഞില്ല. OSD 4.3.18 ഉള്ള പുതിയ ക്ലസ്റ്ററിനായി കാത്തിരിക്കുമ്പോൾ, quay.io പോഡുകൾ സമാരംഭിക്കാനുള്ള ശ്രമം ഞങ്ങൾ തുടർന്നു. ക്ലസ്റ്റർ പൂർണ്ണ ശേഷിയിൽ എത്തുമ്പോഴെല്ലാം, ഡാറ്റാബേസ് മരവിപ്പിക്കും. എല്ലാ quay.io പോഡുകൾക്കും പുറമെ RDS ഇൻസ്റ്റൻസ് പുനരാരംഭിക്കേണ്ടത് ആവശ്യമാണെന്ന് ഇതിനർത്ഥം.

വൈകുന്നേരത്തോടെ, ഡാറ്റാബേസിലെ ലോഡ് കുറയ്ക്കുന്നതിന് ഞങ്ങൾ സേവനം റീഡ്-ഒൺലി മോഡിൽ സ്ഥിരപ്പെടുത്തുകയും സാധ്യമായത്ര അത്യാവശ്യമല്ലാത്ത ഫംഗ്‌ഷനുകൾ (ഉദാഹരണത്തിന്, നെയിംസ്‌പേസ് മാലിന്യ ശേഖരണം) പ്രവർത്തനരഹിതമാക്കുകയും ചെയ്തു. ഫ്രീസുകൾ നിലച്ചു പക്ഷേ കാരണം കണ്ടെത്താനായില്ല. പുതിയ OSD ക്ലസ്റ്റർ തയ്യാറായിക്കഴിഞ്ഞു, ഞങ്ങൾ സേവനം മൈഗ്രേറ്റ് ചെയ്തു, ട്രാഫിക്കിനെ ബന്ധിപ്പിച്ച് നിരീക്ഷണം തുടർന്നു.

Quay.io പുതിയ OSD ക്ലസ്റ്ററിൽ സ്ഥിരമായി പ്രവർത്തിച്ചു, അതിനാൽ ഞങ്ങൾ ഡാറ്റാബേസ് ലോഗുകളിലേക്ക് മടങ്ങി, പക്ഷേ തടസ്സങ്ങൾ വിശദീകരിക്കുന്ന ഒരു പരസ്പരബന്ധം കണ്ടെത്താൻ കഴിഞ്ഞില്ല. Red Hat OpenShift 4.3.19-ലെ മാറ്റങ്ങൾ Quay-ൽ പ്രശ്നങ്ങൾ ഉണ്ടാക്കുമോ എന്ന് മനസ്സിലാക്കാൻ OpenShift എഞ്ചിനീയർമാർ ഞങ്ങളോടൊപ്പം പ്രവർത്തിച്ചു. എന്നിരുന്നാലും, ഒന്നും കണ്ടെത്തിയില്ല, കൂടാതെ ലബോറട്ടറി സാഹചര്യങ്ങളിൽ പ്രശ്നം പുനർനിർമ്മിക്കാൻ സാധ്യമല്ല.

രണ്ടാമത്തെ പരാജയം

മെയ് 28-ന്, ഉച്ചയ്ക്ക് EDT-ന് തൊട്ടുമുമ്പ്, അതേ ലക്ഷണത്തോടെ quay.io വീണ്ടും തകർന്നു: ഡാറ്റാബേസ് തടഞ്ഞു. വീണ്ടും ഞങ്ങൾ ഞങ്ങളുടെ എല്ലാ ശ്രമങ്ങളും അന്വേഷണത്തിലേക്ക് വലിച്ചെറിഞ്ഞു. ഒന്നാമതായി, സേവനം പുനഃസ്ഥാപിക്കേണ്ടത് ആവശ്യമാണ്. എങ്കിലും ഇത്തവണ RDS റീബൂട്ട് ചെയ്യുന്നതും quay.io പോഡുകൾ പുനരാരംഭിക്കുന്നതും ഒന്നും ചെയ്തില്ല: കണക്ഷനുകളുടെ മറ്റൊരു ഹിമപാതം അടിത്തറയെ തകർത്തു. പക്ഷെ എന്തുകൊണ്ട്?

ക്വേ പൈത്തണിൽ എഴുതിയിരിക്കുന്നു, ഓരോ പോഡും ഒറ്റ മോണോലിത്തിക്ക് കണ്ടെയ്‌നറായി പ്രവർത്തിക്കുന്നു. കണ്ടെയ്നർ റൺടൈം ഒരേസമയം നിരവധി സമാന്തര ജോലികൾ പ്രവർത്തിപ്പിക്കുന്നു. ഞങ്ങൾ ലൈബ്രറി ഉപയോഗിക്കുന്നു gevent കീഴെ gunicorn വെബ് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യാൻ. Quay-ലേക്ക് ഒരു അഭ്യർത്ഥന വരുമ്പോൾ (ഞങ്ങളുടെ സ്വന്തം API വഴി അല്ലെങ്കിൽ ഡോക്കറുടെ API വഴി), അതിന് ഒരു ഗെവെന്റ് വർക്കറെ നിയോഗിക്കുന്നു. സാധാരണയായി ഈ തൊഴിലാളി ഡാറ്റാബേസുമായി ബന്ധപ്പെടണം. ആദ്യ പരാജയത്തിന് ശേഷം, സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങൾ ഉപയോഗിച്ച് ഗെവെന്റ് തൊഴിലാളികൾ ഡാറ്റാബേസിലേക്ക് കണക്റ്റുചെയ്യുന്നതായി ഞങ്ങൾ കണ്ടെത്തി.

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

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

ഞങ്ങൾ ഉടൻ തന്നെ ഈ പുതിയ പതിപ്പ് നിർമ്മാണത്തിനായി വിന്യസിക്കുകയും ഡാറ്റാബേസ് കണക്ഷൻ ഷെഡ്യൂൾ നിരീക്ഷിക്കാൻ തുടങ്ങുകയും ചെയ്തു. മുൻകാലങ്ങളിൽ, 20 മിനിറ്റിനുശേഷം അടിത്തറ പൂട്ടിയിരുന്നു. പ്രശ്‌നരഹിതമായ 30 മിനിറ്റുകൾക്ക് ശേഷം ഞങ്ങൾക്ക് പ്രതീക്ഷയുണ്ടായിരുന്നു, ഒരു മണിക്കൂറിന് ശേഷം ഞങ്ങൾക്ക് ആത്മവിശ്വാസമുണ്ടായി. ഞങ്ങൾ സൈറ്റിലേക്കുള്ള ട്രാഫിക് പുനഃസ്ഥാപിക്കുകയും പോസ്റ്റ്‌മോർട്ടം വിശകലനം ആരംഭിക്കുകയും ചെയ്തു.

തടയുന്നതിലേക്ക് നയിക്കുന്ന പ്രശ്നം മറികടക്കാൻ കഴിഞ്ഞു, അതിന്റെ യഥാർത്ഥ കാരണങ്ങൾ ഞങ്ങൾ കണ്ടെത്തിയിട്ടില്ല. ഓപ്പൺഷിഫ്റ്റ് 4.3.19-ലെ മാറ്റങ്ങളുമായി ഇതിന് ബന്ധമില്ലെന്ന് സ്ഥിരീകരിച്ചു, കാരണം 4.3.18 പതിപ്പിലും ഇതുതന്നെ സംഭവിച്ചു, മുമ്പ് ക്വേയിൽ പ്രശ്‌നങ്ങളൊന്നുമില്ലാതെ പ്രവർത്തിച്ചിരുന്നു.

ക്ലസ്റ്ററിൽ മറ്റൊന്ന് ഒളിഞ്ഞിരിക്കുന്നതായി വ്യക്തമായി.

വിശദമായ പഠനം

Quay.io ആറ് വർഷത്തേക്ക് ഒരു പ്രശ്നവുമില്ലാതെ ഡാറ്റാബേസിലേക്ക് കണക്റ്റുചെയ്യുന്നതിന് സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങൾ ഉപയോഗിച്ചു. എന്താണ് മാറിയത്? ഇക്കാലമത്രയും quay.io-ലെ ട്രാഫിക് ക്രമാനുഗതമായി വർദ്ധിച്ചുകൊണ്ടിരിക്കുകയാണെന്ന് വ്യക്തമാണ്. ഞങ്ങളുടെ കാര്യത്തിൽ, ചില ത്രെഷോൾഡ് മൂല്യം എത്തിയതായി തോന്നുന്നു, ഇത് കണക്ഷനുകളുടെ ഹിമപാതത്തിന് ഒരു ട്രിഗറായി വർത്തിച്ചു. രണ്ടാമത്തെ പരാജയത്തിന് ശേഷം ഞങ്ങൾ ഡാറ്റാബേസ് ലോഗുകൾ പഠിക്കുന്നത് തുടർന്നു, പക്ഷേ പാറ്റേണുകളോ വ്യക്തമായ ബന്ധങ്ങളോ കണ്ടെത്തിയില്ല.

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

Quay.io ജൂൺ 9 വരെ നന്നായി പ്രവർത്തിച്ചു. ഇന്ന് രാവിലെ (EDT) ഡാറ്റാബേസ് കണക്ഷനുകളുടെ എണ്ണത്തിൽ ഞങ്ങൾ വീണ്ടും ഗണ്യമായ വർദ്ധനവ് കണ്ടു. ഇത്തവണ പ്രവർത്തനരഹിതമായിരുന്നില്ല, പുതിയ പാരാമീറ്റർ അവയുടെ എണ്ണം പരിമിതപ്പെടുത്തുകയും MySQL ത്രൂപുട്ട് കവിയാൻ അനുവദിക്കാതിരിക്കുകയും ചെയ്തതിനാൽ. എന്നിരുന്നാലും, ഏകദേശം അരമണിക്കൂറോളം, പല ഉപയോക്താക്കളും quay.io-ന്റെ മന്ദഗതിയിലുള്ള പ്രകടനം ശ്രദ്ധിച്ചു. ചേർത്ത മോണിറ്ററിംഗ് ടൂളുകൾ ഉപയോഗിച്ച് സാധ്യമായ എല്ലാ ഡാറ്റയും ഞങ്ങൾ വേഗത്തിൽ ശേഖരിച്ചു. പെട്ടെന്ന് ഒരു മാതൃക പ്രത്യക്ഷപ്പെട്ടു.

കണക്ഷനുകളുടെ കുതിച്ചുചാട്ടത്തിന് തൊട്ടുമുമ്പ്, ആപ്പ് രജിസ്ട്രി API-യിലേക്ക് ധാരാളം അഭ്യർത്ഥനകൾ വന്നിരുന്നു. quay.io-യുടെ അധികം അറിയപ്പെടാത്ത സവിശേഷതയാണ് ആപ്പ് രജിസ്ട്രി. സമ്പന്നമായ മെറ്റാഡാറ്റയുള്ള ഹെൽം ചാർട്ടുകളും കണ്ടെയ്‌നറുകളും പോലുള്ള കാര്യങ്ങൾ സംഭരിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. മിക്ക quay.io ഉപയോക്താക്കളും ഈ സവിശേഷതയിൽ പ്രവർത്തിക്കുന്നില്ല, പക്ഷേ Red Hat OpenShift ഇത് സജീവമായി ഉപയോഗിക്കുന്നു. OpenShift-ന്റെ ഭാഗമായി OperatorHub എല്ലാ ഓപ്പറേറ്റർമാരെയും ആപ്പ് രജിസ്ട്രിയിൽ സംഭരിക്കുന്നു. ഈ ഓപ്പറേറ്റർമാർ ഓപ്പൺഷിഫ്റ്റ് വർക്ക്ലോഡ് ഇക്കോസിസ്റ്റത്തിനും പങ്കാളി കേന്ദ്രീകൃത ഓപ്പറേറ്റിംഗ് മോഡലിനും (ഡേ 2 പ്രവർത്തനങ്ങൾ) അടിസ്ഥാനമാണ്.

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

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

കാരണങ്ങളുടെ ഉന്മൂലനം

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

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

നമ്മൾ എന്താണ് പഠിച്ചത്?

ഏത് സേവനവും പ്രവർത്തനരഹിതമായ സമയം ഒഴിവാക്കാൻ ശ്രമിക്കുന്നുവെന്നത് വ്യക്തമാണ്. ഞങ്ങളുടെ കാര്യത്തിൽ, സമീപകാല തകരാറുകൾ quay.io മികച്ചതാക്കാൻ സഹായിച്ചിട്ടുണ്ടെന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു. ഞങ്ങൾ പങ്കിടാൻ ആഗ്രഹിക്കുന്ന ചില പ്രധാന പാഠങ്ങൾ ഞങ്ങൾ പഠിച്ചു:

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

അടുത്തത് എന്ത്?

സേവനത്തിന്റെ സ്ഥിരത ഉറപ്പാക്കുന്നതിനുള്ള പ്രവർത്തനം ഒരിക്കലും അവസാനിക്കുന്നില്ല, ഞങ്ങൾ അത് നിരന്തരം മെച്ചപ്പെടുത്തിക്കൊണ്ടിരിക്കുകയാണ്. quay.io-ൽ ട്രാഫിക് വോളിയം വർദ്ധിക്കുന്നത് തുടരുമ്പോൾ, ഞങ്ങളുടെ ഉപഭോക്താക്കളുടെ വിശ്വാസത്തിന് അനുസരിച്ച് ജീവിക്കാൻ കഴിയുന്നതെല്ലാം ചെയ്യാൻ ഞങ്ങൾക്ക് ഉത്തരവാദിത്തമുണ്ടെന്ന് ഞങ്ങൾ തിരിച്ചറിയുന്നു. അതിനാൽ, ഞങ്ങൾ ഇപ്പോൾ ഇനിപ്പറയുന്ന ജോലികളിൽ പ്രവർത്തിക്കുന്നു:

1. പ്രൈമറി RDS ഇൻസ്‌റ്റൻസുമായി ബന്ധപ്പെട്ട പ്രശ്‌നങ്ങൾ ഉണ്ടാകുമ്പോൾ ഉചിതമായ ട്രാഫിക് കൈകാര്യം ചെയ്യാൻ സേവനത്തെ സഹായിക്കുന്നതിന് റീഡ്-ഒൺലി ഡാറ്റാബേസ് പകർപ്പുകൾ വിന്യസിക്കുക.
2. ഒരു RDS ഉദാഹരണം അപ്ഡേറ്റ് ചെയ്യുന്നു. നിലവിലെ പതിപ്പ് തന്നെ പ്രശ്നമല്ല. പകരം, തെറ്റായ പാത നീക്കം ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു (പരാജയസമയത്ത് ഞങ്ങൾ അത് പിന്തുടർന്നു); സോഫ്‌റ്റ്‌വെയർ കാലികമായി നിലനിർത്തുന്നത് ഭാവിയിൽ തകരാറുകൾ സംഭവിക്കുന്ന സാഹചര്യത്തിൽ മറ്റൊരു ഘടകം ഇല്ലാതാക്കും.
3. മുഴുവൻ ക്ലസ്റ്ററിലുടനീളം അധിക കാഷിംഗ്. കാഷിംഗ് ഡാറ്റാബേസിലെ ലോഡ് കുറയ്ക്കാൻ കഴിയുന്ന മേഖലകൾക്കായി ഞങ്ങൾ തിരയുന്നത് തുടരുന്നു.
4. ആരാണ് quay.io-ലേക്ക് കണക്‌റ്റ് ചെയ്യുന്നതെന്നും എന്തുകൊണ്ടാണെന്നും കാണാൻ ഒരു വെബ് ആപ്ലിക്കേഷൻ ഫയർവാൾ (WAF) ചേർക്കുന്നു.
5. അടുത്ത റിലീസ് മുതൽ, Red Hat OpenShift ക്ലസ്റ്ററുകൾ quay.io-ൽ ലഭ്യമായ കണ്ടെയ്‌നർ ഇമേജുകളെ അടിസ്ഥാനമാക്കി ഓപ്പറേറ്റർ കാറ്റലോഗുകൾക്ക് അനുകൂലമായി ആപ്പ് രജിസ്ട്രി ഉപേക്ഷിക്കും.
6. ആപ്പ് രജിസ്ട്രിയുടെ ദീർഘകാല മാറ്റിസ്ഥാപിക്കൽ, ഓപ്പൺ കണ്ടെയ്നർ ഇനിഷ്യേറ്റീവ് (ഒസിഐ) ആർട്ടിഫാക്റ്റ് സ്പെസിഫിക്കേഷനുകളുടെ പിന്തുണയായിരിക്കാം. ഇത് നിലവിൽ നേറ്റീവ് ക്വേ ഫംഗ്‌ഷണാലിറ്റിയായി നടപ്പിലാക്കുന്നു, കൂടാതെ സ്പെസിഫിക്കേഷൻ അന്തിമമാകുമ്പോൾ ഉപയോക്താക്കൾക്ക് ലഭ്യമാകും.

ഒരു ചെറിയ "സ്റ്റാർട്ടപ്പ്-സ്റ്റൈൽ" ടീമിൽ നിന്ന് മുതിർന്ന ഒരു SRE-ഡ്രൈവ് പ്ലാറ്റ്‌ഫോമിലേക്ക് മാറുമ്പോൾ മുകളിൽ പറഞ്ഞവയെല്ലാം quay.io-യിൽ Red Hat-ന്റെ നിലവിലുള്ള നിക്ഷേപത്തിന്റെ ഭാഗമാണ്. ഞങ്ങളുടെ ഉപഭോക്താക്കളിൽ പലരും അവരുടെ ദൈനംദിന ജോലികളിൽ (Red Hat ഉൾപ്പെടെ!) quay.io-യെ ആശ്രയിക്കുന്നുണ്ടെന്ന് ഞങ്ങൾക്കറിയാം, കൂടാതെ സമീപകാല തകരാറുകളെക്കുറിച്ചും മെച്ചപ്പെടുത്താനുള്ള നിരന്തരമായ ശ്രമങ്ങളെക്കുറിച്ചും കഴിയുന്നത്ര സുതാര്യത പുലർത്താൻ ഞങ്ങൾ ശ്രമിക്കുന്നു.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «CoreOS കണ്ടെയ്‌നർ ഇമേജുകൾക്കായുള്ള Red Hat ഓപ്പൺ സോഴ്‌സ്ഡ് രജിസ്ട്രി കോഡ് - Quay";
• «ഞങ്ങളുടെ SRE ദൈനംദിന ജീവിതത്തിൽ നിന്നുള്ള പ്രായോഗിക കഥകൾ. ഭാഗം 2";
• «കുബർനെറ്റസിലെ പോഡ് മുൻഗണനകൾ എങ്ങനെയാണ് ഗ്രാഫാന ലാബിൽ പ്രവർത്തനരഹിതമായത്".

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