మేము Mythex సర్వర్లను ARMకు ఎందుకు మార్చాము

సెప్టెంబర్ 19న మేము Mythex యొక్క ప్రొడక్షన్ బ్యాకెండ్‌ను x86 సర్వర్ల నుంచి చిన్న ARM ఆధారిత AWS Graviton సర్వర్లకు మార్చాము, మరియు ప్లాట్‌ఫామ్ డేటాబేస్‌ను కూడా ఒక Graviton ఇన్‌స్టాన్స్‌కు మార్చాము. ట్రిగ్గర్ సులభం: భారీ పనిని — ప్రతి వినియోగదారు యాప్‌ను రన్ చేయడం మరియు నిర్మించడం — ప్రత్యేక ప్రతి-ప్రాజెక్ట్ sandbox లకు తరలించిన తర్వాత, మా ప్రధాన సర్వర్లు మెమరీలో మూడో వంతు వద్ద శిఖరాలు చేరాయి. చిన్న ARM యంత్రాలు నిజమైన లోడ్‌కు సరిపోతాయి మరియు నెలవారీ సర్వర్ బిల్లును సుమారు 30% తగ్గిస్తాయి.

ఇప్పుడు మా సర్వర్లు నిజంగా ఏమి చేస్తాయి

ఇంతకుముందు, బ్యాకెండ్ సర్వర్లు నేరుగా చాలా పని చేసేవి. సెప్టెంబర్ మధ్యలో మేము ఖరీదైన భాగాలను — ప్రతి ప్రాజెక్ట్ కోడ్‌ను రన్ చేయడం, ప్యాకేజీలు ఇన్‌స్టాల్ చేయడం, యాప్‌లను నిర్మించడం — ప్రైవేట్ క్లౌడ్ sandbox లకు, ప్రతి ప్రాజెక్ట్‌కు ఒకటి, తరలించడం పూర్తి చేశాము. ప్రతి ప్రాజెక్ట్‌కు దాని స్వంత ఐసోలేటెడ్ ఎన్విరాన్‌మెంట్ మరియు లైవ్ ప్రివ్యూ ఇచ్చేది కూడా అదే.

మా స్వంత సర్వర్లపై మిగిలింది సమన్వయం: API, sandboxలు మరియు ప్రచురణను నిర్వహించే ఆర్కెస్ట్రేటర్, ప్రమాణీకరణ, బిల్లింగ్, మరియు గేట్‌వే. ఆ పని స్థిరంగా మరియు తేలికగా ఉంటుంది. తరలించిన తర్వాత, మూడు రెట్లు ఉన్న యంత్రాలపై సర్వర్లు సుమారు 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. చిన్న యంత్రాలకు స్వాప్ అవసరం. ఒక వారం తర్వాత ఈ సర్వర్లలో ఒకటి సాంకేతికంగా out-of-memory కాకుండానే మెమరీ ఒత్తిడి వల్ల స్తంభించింది — తప్పిపోయిన స్వాప్ ఫైల్ కథ.

మేము ఏమి నేర్చుకున్నాము

• ఆర్కిటెక్చర్ మార్పుల తర్వాత మళ్లీ కొలవండి. పనిని sandboxలలోకి తరలించడం మా సర్వర్లకు ఏమి అవసరమో మార్చింది; ఇన్‌స్టాన్స్ సైజులు ఇంకా పట్టుకోలేదు.
• మల్టీ-ఆర్క్ ఇమేజ్‌లు ఉంటే, ARM సాధారణ వెబ్ స్టాక్‌లకు తక్కువ-రిస్క్ విజయం.
• రోల్‌బ్యాక్‌ను ముందుగానే రాయండి. మీరు దాన్ని ఎప్పుడూ ఉపయోగించకపోయినా, మార్పును ప్రశాంతంగా చేస్తుంది.