ഓരോ സെർവറിലും അല്ല, ഒരു തവണ മാത്രം മുഴങ്ങുന്ന അലേർട്ടുകൾ

ഞങ്ങളുടെ പ്രവർത്തന അലേർട്ടുകളിൽ ഒന്ന് — ഒരു ബിൽഡറുടെ പബ്ലിഷ് ചെയ്ത ആപ്പിന്റെ "low credits" — ഒരു ദിവസത്തിൽ പരമാവധി ഒരു തവണ മാത്രം ഞങ്ങളിലെത്താനാണ്. ഒരു ഉച്ചയ്ക്ക് അത് അഞ്ച് തവണ വന്നു. കാരണം: API-യുടെ ഓരോ പകർപ്പും ഇതിനകം അയച്ച അലേർട്ടുകൾ സ്വന്തം മെമ്മറിയിൽ ഓർത്തുവെക്കുന്നു, അതിനാൽ രണ്ട് സെർവറുകൾ അത് രണ്ട് തവണ അയച്ചു, ഓരോ ഡിപ്ലോയും ആ ഓർമ്മ തുടച്ചുനീക്കി അവരെ വീണ്ടും അയയ്ക്കാൻ അനുവദിച്ചു. അതേ പാറ്റേൺ ഒരു പശ്ചാത്തല ജോലിയും അതിന്റെ ജോലി രണ്ട് തവണ ചെയ്യാൻ ഇടയാക്കി. ഇപ്പോൾ രണ്ടും ഒരു പങ്കിട്ട സ്റ്റോർ വഴി ഏകോപിപ്പിക്കുന്നു, ആ സ്റ്റോർ ലഭ്യമല്ലാതായാൽ രണ്ടും സുരക്ഷിതമായ വശത്തേക്ക് തീരുമാനിക്കുന്നു.

ലക്ഷണം

എന്തെങ്കിലും ശ്രദ്ധ ആവശ്യമായപ്പോൾ Mythex ടീം അലേർട്ടുകൾ അയയ്ക്കുന്നു: ഒരു സേവനം ഡൗൺ ആകുമ്പോൾ, ഒരു ജോലി നിലച്ചപ്പോൾ, ഒരു ബിൽഡറുടെ പബ്ലിഷ് ചെയ്ത ആപ്പിന്റെ ക്രെഡിറ്റ് ബാലൻസ് കുറയുമ്പോൾ. ഓരോ അലേർട്ടിനും ഒരു ഡെഡ്യൂപ്പ് വിൻഡോയുണ്ട് — അതേ അലേർട്ട് ഒരു തവണ മാത്രം അയയ്ക്കപ്പെടുന്ന ഒരു കാലയളവ്. ലോ-ക്രെഡിറ്റ്സ് അലേർട്ടിന് ആ വിൻഡോ 24 മണിക്കൂറാണ്.

ഒരു ഉച്ചയ്ക്ക് ഒരേ അലേർട്ടിന്റെ അഞ്ച് പകർപ്പ് എന്നാൽ വിൻഡോ പിടിച്ചുനിന്നില്ല എന്നാണ്. അതിലും മോശം, അവ ഏകദേശം 11 മിനിറ്റ് ഇടവിട്ട് ജോഡികളായി വന്നു.

ഇത് സംഭവിച്ചത് എന്തുകൊണ്ട്

ഞങ്ങളുടെ അലേർട്ട്സ് പാക്കേജ് ഡെഡ്യൂപ്പ് ഇൻ-മെമ്മറിയിൽ സൂക്ഷിച്ചിരുന്നു: "അലേർട്ട് കീ → അവസാനമായി എപ്പോൾ അയച്ചു" എന്ന ഒരു പട്ടിക, പ്രവർത്തിക്കുന്ന പ്രോസസ്സിനുള്ളിൽ. ഒരിക്കലും റീസ്റ്റാർട്ട് ആകാത്ത ഒരൊറ്റ പ്രോസസ്സ് ഉള്ളപ്പോൾ അത് പ്രവർത്തിക്കും. പ്രൊഡക്ഷനിൽ രണ്ടും ഇല്ല:

• രണ്ട് API റെപ്ലിക്കകൾ. പ്രൊഡക്ഷൻ API-യുടെ രണ്ട് പകർപ്പുകൾ ഓടിക്കുന്നു. ഓരോന്നിനും സ്വന്തം പട്ടികയുണ്ടായിരുന്നു, അതിനാൽ ഓരോന്നും അലേർട്ട് ഒരു തവണ അയച്ചു. അതാണ് ജോഡികൾ.
• ഡിപ്ലോയുകൾ. ഓരോ ഡിപ്ലോയും രണ്ട് റെപ്ലിക്കകളെയും പുതിയ പ്രോസസ്സുകളും ശൂന്യമായ പട്ടികകളും കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു. ഡിപ്ലോയ്ക്ക് ശേഷം, അലേർട്ട് ഒരിക്കലും അയച്ചിട്ടില്ലാത്തതുപോലെ വീണ്ടും പുറത്തുപോയി.

ഓരോ ജോഡിയിലെയും രണ്ട് അലേർട്ടുകൾക്കിടയിലെ ~11 മിനിറ്റ് വിടവ് ഈ അലേർട്ട് ഉയർത്തുന്ന ജോലിയിൽ നിന്നായിരുന്നു. അത് രണ്ട് റെപ്ലിക്കകളിലും ഓടുന്നു, ഒരു ലോക്ക് എടുക്കുന്നു, അതിനാൽ റെപ്ലിക്കകൾ ഊഴമനുസരിച്ച് അത് നേടുന്നു, ഓരോന്നും ഊഴമെത്തിയപ്പോൾ അലേർട്ട് ഉയർത്തി.

അതേ കോഡിൽ രണ്ടാമതൊരു, ശാന്തമായ ബഗുമുണ്ടായിരുന്നു. പട്ടിക അനന്തമായി വളരാതിരിക്കാൻ, 500 കീകൾ ആകുമ്പോൾ അത് സ്വയം പ്രൂൺ ചെയ്യുമായിരുന്നു — 15 മിനിറ്റിനേക്കാൾ പഴക്കമുള്ള ഓരോ എൻട്രിയും അതിന്റെ വിൻഡോ എന്തായാലും ഇല്ലാതാക്കി. കനത്ത ലോഡിൽ, 24 മണിക്കൂർ ഡെഡ്യൂപ്പ് കാൽ മണിക്കൂർ മാത്രം നിലനിന്നേക്കാം.

പരിഹാരം

ഓരോ അലേർട്ടിനും ഒരു പങ്കിട്ട റെക്കോർഡ്

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

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

തകരുമ്പോൾ തുറന്ന നിലയിൽ പരാജയപ്പെടുക, അടഞ്ഞ നിലയിലല്ല

ഏറ്റവും പ്രധാനപ്പെട്ട തീരുമാനം Redis എത്താതിരുന്നാൽ എന്ത് ചെയ്യണമെന്നതായിരുന്നു. ഞങ്ങൾ അലേർട്ട് എന്തായാലും അയയ്ക്കാൻ തീരുമാനിച്ചു. Redis ഡൗണാണെങ്കിലോ 1.5 സെക്കൻഡിനുള്ളിൽ മറുപടി നൽകുന്നില്ലെങ്കിലോ, അലേർട്ട് പോകുന്നു. ഡ്യൂപ്ലിക്കേറ്റ് അലേർട്ട് ശബ്ദമാണ്. നഷ്ടപ്പെട്ട അലേർട്ട് എന്നാൽ ആരെയും അറിയിക്കാതിരിക്കലാണ്.

ഏറ്റവും ഗുരുതരമായ അലേർട്ടുകളായ P0 ഒരിക്കലും ഡെഡ്യൂപ്പ് വഴി തടയപ്പെടുന്നില്ല.

ഓരോ എൻട്രിക്കും സ്വന്തം വിൻഡോ

അലേർട്ട്സ് പാക്കേജിന്റെ സ്വന്തം ഇൻ-മെമ്മറി ഡെഡ്യൂപ്പിൽ, ഓരോ എൻട്രിയും ഇപ്പോൾ അതിന്റെ വിൻഡോ എപ്പോൾ അവസാനിക്കുന്നു എന്ന് സൂക്ഷിക്കുന്നു, പ്രൂണിംഗ് വിൻഡോ കഴിഞ്ഞ എൻട്രികൾ മാത്രം നീക്കം ചെയ്യുന്നു. 24 മണിക്കൂർ കീ 24 മണിക്കൂർ നിലനിൽക്കുന്നു, മറ്റ് എത്ര അലേർട്ടുകൾ വന്നാലും.

അതേ ബഗ്, മറ്റൊരിടത്ത്

അതേ പാറ്റേൺ ഒരു പശ്ചാത്തല ജോലിയും ഇരട്ടിയാക്കിയിരുന്നു: ഓരോ ബിൽഡറുടെ വർക്ക്സ്പേസിന്റെയും സ്റ്റാറ്റസിന്റെ ഞങ്ങളുടെ റെക്കോർഡ് ഞങ്ങളുടെ സാൻഡ്‌ബോക്സ് പ്രൊവൈഡറുടേതുമായി ഒത്തുനോക്കി സൂക്ഷിക്കുന്ന ഒരു റീകൺസിലിയേഷൻ ജോലി. ഓരോ പാസ്സും അക്കൗണ്ടിലെ ഓരോ സാൻഡ്‌ബോക്സും പട്ടികപ്പെടുത്തുന്നു — പ്രൊഡക്ഷനിൽ ആയിരക്കണക്കിന്, ഏകദേശം അഞ്ച് സെക്കൻഡ് — കൂടാതെ പ്രവർത്തിക്കുന്നതോ താൽക്കാലികമായി നിർത്തിയതോ ആയ ഓരോ പ്രോജക്റ്റും. രണ്ട് റെപ്ലിക്കകളും ഇത് ഓരോ രണ്ട് മിനിറ്റിലും ഓടിച്ചു.

അതിന്റെ റൈറ്റുകൾ ഐഡെമ്പോടെന്റ് ആണ് — അത് രണ്ട് തവണ ഓടിച്ചാലും ഒരു തവണ ഓടിച്ചതിന്റെ അതേ ഫലമാണ് — അതിനാൽ ഒന്നും തകർന്നില്ല. ജോലി ഇരട്ടിയായതേ ഉണ്ടായിരുന്നുള്ളൂ. ഇപ്പോൾ ഓരോ രണ്ട് മിനിറ്റ് വിൻഡോയും Redis-ൽ ക്ലെയിം ചെയ്യപ്പെടുന്നു, ഞങ്ങളുടെ യൂസേജ് മീറ്ററുകൾ ഇതിനകം ക്ലെയിം ചെയ്തതുപോലെ, ക്ലെയിം ചെയ്യുന്ന റെപ്ലിക്ക മാത്രം പാസ്സ് ഓടിക്കുന്നു. Redis എത്താതിരുന്നാൽ, പാസ്സ് എന്തായാലും ഓടുന്നു: ജോലി രണ്ട് തവണ ചെയ്യുന്നത് ദോഷകരമല്ല, ചെയ്യാതിരിക്കുന്നതാണ് ദോഷം.

ഞങ്ങൾ എങ്ങനെ പരീക്ഷിച്ചു

ടെസ്റ്റുകൾ യഥാർത്ഥ സജ്ജീകരണം മാതൃകയാക്കുന്നു. അവ അലേർട്ട് മൊഡ്യൂൾ രണ്ട് തവണ ലോഡ് ചെയ്യുന്നു, "രണ്ട് വ്യത്യസ്ത റെപ്ലിക്കകളായി", രണ്ടിനെയും ഒരു പങ്കിട്ട സ്റ്റോറിലേക്ക് ചൂണ്ടുന്നു, ഓരോന്നിൽ നിന്നും ഒരേ അലേർട്ട് ഉയർത്തുന്നു, പിന്നെ "ഡിപ്ലോയ്ക്ക് ശേഷം" എന്നതിന് പകരമായി ഒരു മൂന്നാമത്തെ പുതിയ പകർപ്പ് ലോഡ് ചെയ്ത് അത് വീണ്ടും ഉയർത്തുന്നു. കൃത്യം ഒരു അലേർട്ട് അയയ്ക്കപ്പെടുന്നു. മറ്റ് ടെസ്റ്റുകൾ പരിശോധിക്കുന്നത്, വ്യത്യസ്തനായ മറ്റൊരു ബിൽഡറുടെ അലേർട്ട് ഇപ്പോഴും പോകുന്നു, P0 രണ്ട് റെപ്ലിക്കകളിൽ നിന്നും അയയ്ക്കപ്പെടുന്നു, സ്റ്റോർ ഡൗണോ ടൈംഔട്ട് കഴിഞ്ഞ് തൂങ്ങിക്കിടക്കുകയോ ആണെങ്കിലും അലേർട്ട് അയയ്ക്കപ്പെടുന്നു എന്നിവയാണ്. പ്രൂൺ പരിഹാരത്തിന് സ്വന്തം ടെസ്റ്റുണ്ട്: 20 മിനിറ്റിന് ശേഷം എത്തിയ 600 മറ്റ് അലേർട്ടുകൾക്കിടയിലും 24 മണിക്കൂർ കീ നിലനിൽക്കുന്നു.

റീകൺസിലിയേഷൻ ജോലിക്ക്, ഒരേ സമയം ടിക്ക് ചെയ്യുന്ന രണ്ട് റെപ്ലിക്കകളും അതേ വിൻഡോയിലെ മൂന്നാമത്തെ ടിക്കും ഒരു ലിസ്റ്റിംഗ് മാത്രം ഉണ്ടാക്കുന്നു.

ഞങ്ങൾ പഠിച്ചത്

• ഇൻ-മെമ്മറി സ്റ്റേറ്റ് ഓരോ പ്രോസസ്സിനും പ്രത്യേകമാണ്. സെർവറുകളിലുടനീളം സത്യമായിരിക്കേണ്ട എന്തും — "ഒരു തവണ അയച്ചു", "ഒരു തവണ ഓടി" — അവർ പങ്കിടുന്ന ഒരിടത്ത് ജീവിക്കണം.
• ഡിപ്ലോയ്കൾ റീസ്റ്റാർട്ടുകളാണ്. അടുത്ത റീസ്റ്റാർട്ട് വരെ മാത്രം നിലനിൽക്കുന്ന സ്റ്റേറ്റ് ഒരു സാധാരണ പ്രവൃത്തിദിനം അതിജീവിക്കുന്നില്ല.
• ഏത് വഴിയാണ് പരാജയപ്പെടേണ്ടതെന്ന് തീരുമാനിക്കുക. അലേർട്ടുകൾക്ക്, ഒരു പങ്കിട്ട സ്റ്റോർ ഡൗൺ ആകുന്നത് കുറച്ച് അലേർട്ടുകൾ എന്നല്ല, കൂടുതൽ അലേർട്ടുകൾ എന്നാണ് അർത്ഥമാക്കേണ്ടത്.
• ഉദാഹരണം മാത്രമല്ല, പാറ്റേൺ നോക്കുക. ഉച്ചത്തിലുള്ള കേസ് അലേർട്ടായിരുന്നു; ഇരട്ടിച്ച റീകൺസിലിയേഷൻ ജോലി അതേ ബഗ് ആയിരുന്നു, നിശ്ശബ്ദമായി ജോലി നഷ്ടപ്പെടുത്തിക്കൊണ്ടിരുന്നു.

ഇതൊന്നും Mythex-നുള്ളിൽ നിന്ന് കാണാനാവില്ല. പ്ലാറ്റ്‌ഫോം എങ്ങനെ സ്ഥിരമായി നിലനിർത്തുന്നു എന്നതിന്, ഡിപ്ലോയ്കൾ പൂജ്യം 502 പിശകുകളിലേക്ക് എങ്ങനെ എത്തിച്ചു, കാണാതായ സ്വാപ്പ് ഫയൽ എന്നിവ കാണുക. ഒന്നിലധികം സേവനപകർപ്പുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന്റെ ആശയം നിങ്ങൾക്ക് പുതിയതാണെങ്കിൽ, ഞങ്ങളുടെ സെർവർ എന്നാൽ എന്ത് ഗൈഡ് അടിസ്ഥാനകാര്യങ്ങൾ വിശദീകരിക്കുന്നു.