Mythex-இன் சர்வர்களை ARM-க்கு மாற்றியது ஏன்

செப்டம்பர் 19 அன்று, Mythex-இன் production backend-ஐ x86 சர்வர்களிலிருந்து சிறிய ARM அடிப்படையிலான AWS Graviton சர்வர்களுக்கு மாற்றினோம். தளத்தின் தரவுத்தளத்தையும் ஒரு Graviton instance-க்கு மாற்றினோம். தூண்டுதல் எளிமையானது: கனமான வேலையை — ஒவ்வொரு பயனரின் ஆப்பையும் இயக்குவதும் கட்டுவதும் — தனித்தனியான ஒவ்வொரு திட்டத்தின் sandbox-க்கும் மாற்றிய பின், எங்கள் முதன்மை சர்வர்கள் நினைவகத்தில் சுமார் மூன்றில் ஒரு பங்கை உச்சத்தில் பயன்படுத்தின. சிறிய ARM இயந்திரங்கள் உண்மையான சுமைக்குப் பொருந்தின. மாதாந்திர சர்வர் கட்டணம் சுமார் 30% குறைந்தது.

இப்போது எங்கள் சர்வர்கள் உண்மையில் என்ன செய்கின்றன

முன்பு backend சர்வர்கள் நேரடியாக நிறைய வேலை செய்தன. செப்டம்பர் நடுவில், விலையுயர்ந்த பகுதிகளை — ஒவ்வொரு திட்டத்தின் குறியீட்டை இயக்குவது, packages நிறுவுவது, ஆப்களைக் கட்டுவது — ஒரு திட்டத்துக்கு ஒன்று வீதம் தனியார் cloud sandbox-களுக்கு மாற்றி முடித்தோம். ஒவ்வொரு திட்டத்துக்கும் தனிமைப்படுத்தப்பட்ட சூழலையும் நேரடி preview-யையும் தருவதும் அதுதான்.

எங்கள் சொந்த சர்வர்களில் எஞ்சியிருப்பது ஒருங்கிணைப்பு: API, sandbox-களையும் வெளியீட்டையும் நிர்வகிக்கும் orchestrator, authentication, billing, மற்றும் gateway. அந்த வேலை நிலையானதும் இலகுவானதும். மாற்றத்துக்குப் பின், மூன்று மடங்கு நினைவகம் கொண்ட இயந்திரங்களில் சர்வர்கள் உச்சத்தில் சுமார் 1.3 GB பயன்படுத்தின.

ஏன் ARM

AWS-இன் Graviton செயலிகள் AWS வடிவமைத்த ARM சிப்புகள். அதே விலையில் பொதுவாக ஒப்பிடக்கூடிய x86 instance-ஐவிட அதிக திறனைப் பெறலாம். அல்லது அதே திறனை குறைந்த விலையில் பெறலாம். எங்களைப் போன்ற வேலைச்சுமைக்கு (Node.js சேவைகள், Docker, Postgres) x86-க்கு எதுவும் எங்களைக் கட்டிப்போடவில்லை.

நாங்கள் மாற்றியவை:

• இரண்டு app சர்வர்கள்: நடுத்தர அளவிலான x86 instances-இலிருந்து ஒவ்வொன்றிலும் 2 GB RAM கொண்ட சிறிய Graviton instances-க்கு.
• தளத்தின் தரவுத்தளம்: ஒரு சிறிய x86 தரவுத்தள instance-இலிருந்து அதன் Graviton சமமானதுக்கு.

ஒரே உண்மையான சிக்கல்: இரண்டு கட்டமைப்புகளுக்கான படங்கள்

எங்கள் staging சூழல் இன்னும் ஒரு சிறிய x86 சர்வரில் இயங்குகிறது. Production இப்போது ARM-இல் இயங்குகிறது. ஒன்றுக்காகக் கட்டப்பட்ட container image இன்னொன்றில் இயங்காது.

எனவே ஒவ்வொரு image-உம் இப்போது ஒரே tag-இன் கீழ் இரண்டு கட்டமைப்புகளுக்கும் கட்டப்படுகிறது. அது ஒரு multi-arch image. ஒவ்வொரு இயந்திரத்திலும் Docker சரியான variant-ஐத் தானாகத் தேர்ந்தெடுக்கும். deploy pipeline எந்தச் சூழலுக்குத் தள்ளுகிறது என்பதை அறிய வேண்டியதில்லை. விலை நீண்ட CI build. பலன் staging-உம் production-உம் ஒரே tag-இலிருந்து சரியாக ஒரே குறியீட்டை இயக்குவது.

மாற்றத்துக்கு முன்பே rollback-ஐத் திட்டமிடுதல்

நேரடி சேவையின் கீழ் CPU கட்டமைப்பை மாற்றுவது, நிமிடங்களில் திரும்பப் பெறக்கூடியதாக இருக்க வேண்டிய மாற்றம். மாறுவதற்கு முன், நாங்கள்:

• முந்தைய சர்வர் template பதிப்பை ஒரு பெயரிட்ட rollback இலக்காக வைத்தோம்,
• தரவுத்தளத்தின் அளவை மாற்றுவதற்கு சற்று முன் ஒரு தரவுத்தள snapshot எடுத்தோம், மற்றும்
• மாற்றத்தையும் திரும்பும் வழியையும் உள்ளடக்கிய ஒரு runbook எழுதினோம்.

Rollback எங்களுக்குத் தேவைப்படவில்லை. இருந்தாலும் அதையே மீண்டும் அதே முறையில் செய்வோம்.

நாங்கள் கவனிக்க வேண்டியவை

சிறிய சர்வர்களுக்கு குறைவான இடைவெளி உண்டு. அதிலிருந்து இரண்டு விஷயங்கள் வருகின்றன:

1. கனமான வேலை எப்போதாவது இந்த சர்வர்களுக்குத் திரும்பினால், 2 GB போதாது. அப்போதைய திருத்தம் x86-க்குத் திரும்புவது அல்ல, பெரிய Graviton அளவுக்கு மாறுவதுதான்.
2. சிறிய இயந்திரங்களுக்கு swap தேவை. ஒரு வாரம் கழித்து, இவற்றில் ஒரு சர்வர் நினைவக அழுத்தத்தால் உறைந்தது. நினைவகம் தொழில்நுட்ப ரீதியாகத் தீர்ந்திருக்கவில்லை. காணாமல் போன swap கோப்பின் கதை.

இதிலிருந்து நாங்கள் எடுத்துக்கொண்டவை

• கட்டமைப்பு மாற்றங்களுக்குப் பிறகு மீண்டும் அளவிடுங்கள். வேலையை sandbox-களுக்கு நகர்த்தியது எங்கள் சர்வர்களுக்குத் தேவையானதை மாற்றியது. instance அளவுகள் அதற்கு இன்னும் ஈடுகொடுக்கவில்லை.
• உங்கள் images multi-arch ஆனவுடன், வழக்கமான வலை stacks-க்கு ARM குறைந்த ஆபத்தான லாபம்.
• rollback-ஐ முதலில் எழுதுங்கள். நீங்கள் அதைப் பயன்படுத்தாவிட்டாலும், அது மாற்றத்தை அமைதியாக்குகிறது.