Mythex-ന്റെ സെർവറുകൾ ARM-ലേക്ക് മാറ്റിയത് എന്തുകൊണ്ട്

സെപ്റ്റംബർ 19-ന് Mythex-ന്റെ പ്രൊഡക്ഷൻ ബാക്കെൻഡ് x86 സെർവറുകളിൽ നിന്ന് ചെറിയ ARM-അധിഷ്ഠിത AWS Graviton സെർവറുകളിലേക്ക് മാറ്റി, പ്ലാറ്റ്‌ഫോം ഡാറ്റാബേസും ഒരു Graviton ഇൻസ്റ്റൻസിലേക്ക് മാറ്റി. പ്രേരണ ലളിതമായിരുന്നു: ഓരോ ഉപയോക്താവിന്റെയും ആപ്പ് പ്രവർത്തിപ്പിക്കുന്നതും ബിൽഡ് ചെയ്യുന്നതുമായ ഭാരമുള്ള ജോലി ഒറ്റപ്പെട്ട ഓരോ-പ്രോജക്റ്റ് സാൻഡ്‌ബോക്സുകളിലേക്ക് മാറ്റിയ ശേഷം, ഞങ്ങളുടെ പ്രധാന സെർവറുകൾ മെമ്മറിയുടെ ഏകദേശം ഒരു മൂന്നിലൊന്ന് ഉപയോഗിക്കുകയായിരുന്നു. ചെറിയ ARM മെഷീനുകൾ യഥാർത്ഥ ലോഡിന് യോജിക്കുന്നു, പ്രതിമാസ സെർവർ ബില്ലിൽ ഏകദേശം 30% കുറയ്ക്കുന്നു.

ഞങ്ങളുടെ സെർവറുകൾ ഇപ്പോൾ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

നേരത്തെ, ബാക്കെൻഡ് സെർവറുകൾ ധാരാളം ജോലി നേരിട്ട് ചെയ്തിരുന്നു. സെപ്റ്റംബർ മധ്യത്തോടെ ചെലവേറിയ ഭാഗങ്ങൾ — ഓരോ പ്രോജക്റ്റിന്റെയും കോഡ് പ്രവർത്തിപ്പിക്കൽ, പാക്കേജുകൾ ഇൻസ്റ്റാൾ ചെയ്യൽ, ആപ്പുകൾ ബിൽഡ് ചെയ്യൽ — സ്വകാര്യ ക്ലൗഡ് സാൻഡ്‌ബോക്സുകളിലേക്ക്, ഒന്ന് വീതം ഒരു പ്രോജക്റ്റിന്, മാറ്റി പൂർത്തിയാക്കി. ഓരോ പ്രോജക്റ്റിനും സ്വന്തമായി ഒറ്റപ്പെട്ട എൻവയോൺമെന്റും ലൈവ് പ്രിവ്യൂവും നൽകുന്നത് അതാണ്.

ഞങ്ങളുടെ സ്വന്തം സെർവറുകളിൽ അവശേഷിക്കുന്നത് ഏകോപനമാണ്: API, സാൻഡ്‌ബോക്സുകളും പ്രസിദ്ധീകരണവും നിയന്ത്രിക്കുന്ന ഓർക്കസ്ട്രേറ്റർ, ഓതന്റിക്കേഷൻ, ബില്ലിംഗ്, ഗേറ്റ്‌വേ. ആ ജോലി സ്ഥിരവും ഭാരം കുറഞ്ഞതുമാണ്. മാറ്റത്തിന് ശേഷം, മൂന്ന് മടങ്ങ് വലിപ്പമുള്ള മെഷീനുകളിൽ സെർവറുകൾ ഏകദേശം 1.3 GB മെമ്മറിയിൽ എത്തിയിരുന്നു.

എന്തുകൊണ്ട് ARM

AWS-ന്റെ Graviton പ്രോസസ്സറുകൾ AWS രൂപകൽപ്പന ചെയ്ത ARM ചിപ്പുകളാണ്. ഒരേ പണത്തിന് സാധാരണയായി താരതമ്യപ്പെടുത്താവുന്ന x86 ഇൻസ്റ്റൻസിനെക്കാൾ കൂടുതൽ ശേഷി ലഭിക്കും, അല്ലെങ്കിൽ കുറഞ്ഞ ചെലവിൽ അതേ ശേഷി — ഞങ്ങളുടേത് പോലുള്ള ഒരു ജോലിക്ക് (Node.js സേവനങ്ങൾ, Docker, Postgres) x86-ൽ തളച്ചിടപ്പെടാൻ ഒരു കാരണവുമില്ല.

ഞങ്ങൾ മാറ്റിയത്:

• രണ്ട് ആപ്പ് സെർവറുകൾ ഇടത്തരം x86 ഇൻസ്റ്റൻസുകളിൽ നിന്ന് ഓരോന്നിനും 2 GB RAM ഉള്ള ചെറിയ Graviton ഇൻസ്റ്റൻസുകളിലേക്ക്.
• പ്ലാറ്റ്‌ഫോം ഡാറ്റാബേസ് ചെറിയ x86 ഡാറ്റാബേസ് ഇൻസ്റ്റൻസിൽ നിന്ന് അതിന്റെ Graviton തത്തുല്യത്തിലേക്ക്.

ഒരേയൊരു യഥാർത്ഥ സങ്കീർണ്ണത: രണ്ട് ആർക്കിടെക്ചറുകൾക്കുള്ള ഇമേജുകൾ

ഞങ്ങളുടെ സ്റ്റേജിംഗ് എൻവയോൺമെന്റ് ഇപ്പോഴും ഒരു ചെറിയ x86 സെർവറിലാണ് പ്രവർത്തിക്കുന്നത്. പ്രൊഡക്ഷൻ ഇപ്പോൾ ARM-ൽ പ്രവർത്തിക്കുന്നു. ഒന്നിനായി ബിൽഡ് ചെയ്ത കണ്ടെയ്‌നർ ഇമേജ് മറ്റൊന്നിൽ പ്രവർത്തിക്കില്ല.

അതിനാൽ ഓരോ ഇമേജും ഇപ്പോൾ ഒരൊറ്റ ടാഗിന് കീഴിൽ രണ്ട് ആർക്കിടെക്ചറുകൾക്കുമായി ബിൽഡ് ചെയ്യുന്നു — ഒരു മൾട്ടി-ആർച്ച് ഇമേജ്. ഓരോ മെഷീനിലും ശരിയായ വേരിയന്റ് Docker സ്വയമേവ തിരഞ്ഞെടുക്കുന്നു, ഡിപ്ലോയ് പൈപ്പ്‌ലൈൻ ഏത് എൻവയോൺമെന്റിലേക്കാണ് പുഷ് ചെയ്യുന്നതെന്ന് അറിയേണ്ടതില്ല. ചെലവ് ദൈർഘ്യമേറിയ CI ബിൽഡാണ്; നേട്ടം സ്റ്റേജിംഗും പ്രൊഡക്ഷനും ഒരേ ടാഗിൽ നിന്ന് കൃത്യമായി ഒരേ കോഡ് പ്രവർത്തിപ്പിക്കുന്നു എന്നതാണ്.

മാറ്റത്തിന് മുമ്പ് റോൾബാക്ക് ആസൂത്രണം ചെയ്യൽ

തത്സമയ സേവനത്തിന് കീഴിൽ CPU ആർക്കിടെക്ചർ മാറ്റുന്നത് മിനിറ്റുകൾക്കുള്ളിൽ പഴയപടിയാക്കാൻ കഴിയേണ്ട ഒരു മാറ്റമാണ്. മാറുന്നതിന് മുമ്പ് ഞങ്ങൾ:

• മുമ്പത്തെ സെർവർ ടെംപ്ലേറ്റ് പതിപ്പ് ഒരു പേരുള്ള റോൾബാക്ക് ലക്ഷ്യമായി സൂക്ഷിച്ചു,
• ഡാറ്റാബേസ് റീസൈസ് ചെയ്യുന്നതിന് തൊട്ടുമുമ്പ് ഒരു ഡാറ്റാബേസ് സ്നാപ്‌ഷോട്ട് എടുത്തു, കൂടാതെ
• മാറ്റവും തിരികെ പോകുന്ന വഴിയും ഉൾക്കൊള്ളുന്ന ഒരു റൺബുക്ക് എഴുതി.

ഞങ്ങൾക്ക് റോൾബാക്ക് ആവശ്യമായി വന്നില്ല. ഇപ്പോഴും അതേ രീതിയിൽ തന്നെ ചെയ്യും.

ഞങ്ങൾ എന്തിനെ ശ്രദ്ധിക്കും

ചെറിയ സെർവറുകൾക്ക് കുറഞ്ഞ ഹെഡ്‌റൂം ഉണ്ട്. അതിൽ നിന്ന് രണ്ട് കാര്യങ്ങൾ വരുന്നു:

1. ഭാരമുള്ള ജോലി ഒരിക്കൽ ഈ സെർവറുകളിലേക്ക് തിരിച്ചുവന്നാൽ, 2 GB മതിയാകില്ല. അപ്പോഴത്തെ പരിഹാരം x86-ലേക്ക് തിരികെ പോകുകയല്ല, വലിയ Graviton വലിപ്പം ഉപയോഗിക്കുകയാണ്.
2. ചെറിയ മെഷീനുകൾക്ക് സ്വാപ്പ് വേണം. ഒരാഴ്ചയ്ക്ക് ശേഷം ഈ സെർവറുകളിലൊന്ന് മെമ്മറി സമ്മർദ്ദം കാരണം മരവിച്ചു, സാങ്കേതികമായി മെമ്മറി തീരാതെ തന്നെ — കാണാതായ സ്വാപ്പ് ഫയലിന്റെ കഥ.

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

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