ഡിപ്ലോയ് സമയത്തെ 502 പിശകുകൾ പൂജ്യത്തിലേക്ക് എത്തിച്ചത് എങ്ങനെ

ഓരോ തവണയും Mythex-ന്റെ ബാക്ക്എൻഡ് ഡിപ്ലോയ് ചെയ്യുമ്പോൾ, കുറച്ച് അഭ്യർത്ഥനകൾ 502 Bad Gateway ലഭിച്ചു പരാജയപ്പെട്ടു. എണ്ണം വലുതല്ല — പക്ഷേ ഡിപ്ലോയ് സമയത്തെ 502 എന്നാൽ ആരുടെയെങ്കിലും ക്ലിക്ക് ഒന്നും ചെയ്തില്ല, അല്ലെങ്കിൽ കാത്തിരുന്ന ബിൽഡ് ഒരു നിമിഷം നിന്നുപോയി എന്നാണ്. ഇത് രണ്ട് വേറിട്ട പ്രശ്നങ്ങളിലേക്ക് എത്തി: ഡിപ്ലോയ്കളോട് പോരടിച്ച ഒരു സ്വയം-സുഖപ്പെടുത്തുന്ന വാച്ച്ഡോഗ്; സെർവർ കേൾക്കുന്നത് നിർത്തിയതും ലോഡ് ബാലൻസർ അതിലേക്കുള്ള ട്രാഫിക് നിർത്തിയതും തമ്മിലുള്ള വിടവ്. ശരിയാക്കലുകൾക്ക് ശേഷമുള്ള തുടർച്ചയായ മൂന്ന് പ്രൊഡക്ഷൻ ഡിപ്ലോയ്കളിൽ എണ്ണം 10 → 6 → 0 ആയി കുറഞ്ഞു.

പശ്ചാത്തലം

ഞങ്ങളുടെ API-യും ഓർക്കസ്ട്രേറ്ററും AWS Application Load Balancer (ALB) പിന്നിലുള്ള ഒരു ചെറിയ സെർവർ കൂട്ടത്തിൽ കണ്ടെയ്നറുകളായി ഓടുന്നു. ഒരു ഡിപ്ലോയ് ഒരു സമയം ഒരു സെർവർ മാത്രം അപ്ഡേറ്റ് ചെയ്യുന്നു: പഴയ കണ്ടെയ്നറുകൾ ഒഴിപ്പിക്കുന്നു, പുതിയവ തുടങ്ങുന്നു, പിന്നെ അടുത്ത സെർവറിലേക്ക് പോകുന്നു. ഓരോ സെർവറിലും ഒരു വാച്ച്ഡോഗ് കണ്ടെയ്നറുകൾ ഉയർന്നിട്ടുണ്ടോ എന്ന് പരിശോധിച്ച് പ്രവർത്തിക്കാത്തവയെ റീസ്റ്റാർട്ട് ചെയ്യുന്നു — രാത്രി 3 മണിക്ക് ക്രാഷായ ഒരു പ്രോസസ് ആരെയും ഉണർത്താതെ തിരിച്ചുവരണം എന്നതിനാണ് ഇത്.

രണ്ടും ഒറ്റയ്ക്ക് ന്യായമാണ്. ഒരുമിച്ചാകുമ്പോൾ അവ ചേരുന്നില്ല.

പ്രശ്നം 1: വാച്ച്ഡോഗ് ഡിപ്ലോയുമായി മത്സരിച്ചു

വാച്ച്ഡോഗ് ഓരോ മിനിറ്റിലും ഒരിക്കൽ ഓടി, ഒറ്റ പരാജയപ്പെട്ട ഹെൽത്ത് ചെക്കിൽ 'ചികിത്സിച്ചു'. ഡിപ്ലോയ് മനഃപൂർവം 150 സെക്കൻഡ് വരെ സേവനങ്ങളെ ഒഴിപ്പിക്കുന്നു — ആ സമയത്ത് ഹെൽത്ത് ചെക്ക് പരാജയപ്പെടേണ്ടതാണ്. അതിനാൽ ഓരോ ഡിപ്ലോയിലും വാച്ച്ഡോഗ് പ്രവർത്തിച്ചു.

മിക്കപ്പോഴും മത്സരം ദോഷമില്ലാതെ തോറ്റു. ഒരിക്കൽ അത് ജയിച്ചു: ഡിപ്ലോയുടെ മധ്യത്തിൽ അത് compose ഫയൽ (ഏത് കണ്ടെയ്നറുകൾ ഓടണമെന്ന വിവരണം) വീണ്ടും എഴുതി, ഒരു സെർവറിൽ ഗേറ്റ്‌വേ കണ്ടെയ്നർ ഇല്ലാതെയാക്കി — ഡിപ്ലോയ് ജോബ് വിജയം റിപ്പോർട്ട് ചെയ്തപ്പോഴും.

പരിഹാരങ്ങൾ:

• ഒരൊറ്റ ലോക്ക്. ഡിപ്ലോയ് ഇപ്പോൾ സെർവറിന്റെ bootstrap സ്ക്രിപ്റ്റിന്റെ അതേ ഫയൽ ലോക്ക് എടുക്കുന്നു, അതിനാൽ വാച്ച്ഡോഗും ഡിപ്ലോയും ഒരേ സമയം ഓടില്ല.
• നാല് തവണ, ഒന്നല്ല. തുടർച്ചയായ നാല് പരാജയപ്പെട്ട പരിശോധനകൾക്ക് ശേഷമേ വാച്ച്ഡോഗ് പ്രവർത്തിക്കൂ. ഒഴിപ്പിക്കപ്പെടുന്ന സേവനം ഇനി ചത്തതായി തോന്നില്ല.
• ഒരൊറ്റ നിർവചനം. compose ഫയലിന് ഇപ്പോൾ ഒരേയൊരു ഉറവിടമേയുള്ളൂ, സെർവറുകളിലേക്ക് പ്രസിദ്ധീകരിക്കുന്നത്; പകർപ്പുകൾ വ്യതിചലിക്കില്ല.
• വിശ്വസിക്കരുത്, പരിശോധിക്കുക. ഒരു കമാൻഡ് തിരിച്ചുവന്നു എന്നതുകൊണ്ട് ഡിപ്ലോയ് ജോബ് ഇനി വിജയിക്കില്ല. ഓരോ സെർവറിലെയും API, ഓർക്കസ്ട്രേറ്റർ, ഗേറ്റ്‌വേ, പബ്ലിഷ് വർക്കർ എന്നിവ പരിശോധിച്ചിട്ടേ വിജയിക്കൂ.

പ്രശ്നം 2: ട്രാഫിക് നിർത്തുന്നതിന് മുമ്പ് സെർവർ പോയി

രണ്ടാമത്തേത് കൂടുതൽ നിശ്ശബ്ദമായിരുന്നു. ഡിപ്ലോയ് ഒരു സെർവർ ഒഴിപ്പിക്കുമ്പോൾ, സെർവർ ഹെൽത്ത് എൻഡ്പോയിന്റിൽ 503 നൽകാൻ തുടങ്ങുന്നു, അങ്ങനെ ലോഡ് ബാലൻസർ അതിനെ റൊട്ടേഷനിൽ നിന്ന് മാറ്റുന്നു. ഞങ്ങളുടേത് 5 സെക്കൻഡ് അങ്ങനെ ചെയ്തു, പിന്നെ അടഞ്ഞു.

പക്ഷേ ALB ഇടയ്ക്കിടെ മാത്രമേ ഹെൽത്ത് പരിശോധിക്കൂ, ഒരു ടാർഗെറ്റിലേക്കുള്ള റൂട്ടിങ് നിർത്തുന്നതിന് മുമ്പ് തുടർച്ചയായി നിരവധി പരാജയങ്ങൾ വേണം — ആകെ ഏകദേശം 60 സെക്കൻഡ് വരെ. അതിനാൽ ഏകദേശം 55 സെക്കൻഡ് നേരത്തേക്ക്, കേൾക്കുന്നത് നിർത്തിയ സെർവറിലേക്ക് ലോഡ് ബാലൻസർ യഥാർത്ഥ അഭ്യർത്ഥനകൾ അയച്ചുകൊണ്ടിരുന്നു. അവയായിരുന്നു ഞങ്ങളുടെ 502-കൾ.

പരിഹാരം രണ്ട് ടൈംലൈനുകളെ യോജിപ്പിക്കുകയായിരുന്നു:

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

സംഖ്യകൾ പരസ്പരം പിടിച്ചുനിർത്തുന്നത്

ഇങ്ങനെയുള്ള ടൈംഔട്ടുകൾ പരസ്പരം ആശ്രയിക്കുന്നു. ഒഴിപ്പിക്കൽ ലോഡ് ബാലൻസർ ശ്രദ്ധിക്കാൻ വേണ്ട സമയത്തേക്കാൾ നീളണം; ഒഴിപ്പിക്കലും ഷട്ട്ഡൗണും ചേർന്ന് കണ്ടെയ്നർ നിർബന്ധമായി കൊല്ലുന്നതിന് മുമ്പ് തീരണം. ആറ് മാസം കഴിഞ്ഞ് ആരെങ്കിലും ഒരു സംഖ്യ മാറ്റി ബഗ് വീണ്ടും കൊണ്ടുവരുന്നത് എളുപ്പമാണ്.

അതിനാൽ ഈ ബന്ധങ്ങൾ ടെസ്റ്റുകളായി എഴുതി വച്ചു: ഒഴിപ്പിക്കൽ ഹെൽത്ത്-ചെക്ക് ഇടവേള × പരാജയ പരിധിയേക്കാൾ നീളണം; വീണ്ടും ആരോഗ്യകരമായി അടയാളപ്പെടാൻ എടുക്കുന്ന സമയം ചെറുതായിരിക്കണം; മുഴുവൻ ഒഴിപ്പിക്കലും കണ്ടെയ്നറിന്റെ stop grace period-ൽ ഒതുങ്ങണം. ഒരു സംഖ്യ മാത്രം മാറ്റിയാൽ മറ്റുള്ളവ ഇല്ലാതെ CI പരാജയപ്പെടും. ടെസ്റ്റുകളെ തന്നെ mutation-test ചെയ്തു — ഓരോ സംഖ്യയും തെറ്റായ മൂല്യത്തിലേക്ക് മാറ്റി ഒരു ടെസ്റ്റ് അത് പിടിച്ചോ എന്ന് പരിശോധിച്ചു.

ഡിപ്ലോയ് അളക്കുന്നത് തെറ്റാൻ എളുപ്പമാണ്

ആദ്യത്തെ അളവ് പറഞ്ഞത്, ശുദ്ധമായ ഒരു ഡിപ്ലോയ് ഏകദേശം 3% തകർന്നു എന്നാണ്. അങ്ങനെ ആയിരുന്നില്ല. ഞങ്ങൾ 200 അല്ലാത്ത ഓരോ പ്രതികരണവും എണ്ണിയിരുന്നു, പക്ഷേ ഒഴിപ്പിക്കൽ സമയത്ത് ഹെൽത്ത് എൻഡ്പോയിന്റിൽ നിന്നുള്ള 503 ഒരു പരാജയമല്ല — അത് ഒഴിപ്പിക്കൽ അതിന്റെ ജോലി ചെയ്യുന്നതാണ്: യഥാർത്ഥ അഭ്യർത്ഥനകൾ സേവിക്കുന്നത് തുടരുമ്പോൾ ആ സെർവർ തിരഞ്ഞെടുക്കരുതെന്ന് ലോഡ് ബാലൻസറിനോട് പറയുന്നു.

ഉപയോക്താക്കൾക്ക് അനുഭവപ്പെടുന്നത് 502 ആണ്: അഭ്യർത്ഥന ഒന്നിലും എത്തിയില്ല. അവ മാത്രം എണ്ണിയപ്പോൾ യഥാർത്ഥ ചിത്രം കിട്ടി — മൂന്ന് പ്രൊഡക്ഷൻ ഡിപ്ലോയ്കളിൽ 10, പിന്നെ 6, പിന്നെ 0.

ഇതിൽ നിന്ന് ഞങ്ങൾ പഠിച്ചത്

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

Mythex-ൽ ഒരു ആപ്പ് പ്രസിദ്ധീകരിക്കുകയാണെങ്കിൽ, ഇതൊന്നും നിങ്ങൾക്ക് കാണാനാകില്ല — അതാണ് ലക്ഷ്യം. ബന്ധപ്പെട്ടത്: നിങ്ങളുടെ പ്രസിദ്ധീകരിച്ച ആപ്പ് പുതുക്കുമ്പോഴും എങ്ങനെ പ്രവർത്തനക്ഷമമായി തുടരുന്നു.