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 સામાન્ય વેબ સ્ટેક માટે ઓછા જોખમવાળી જીત છે.
• પહેલાં રોલબેક લખો. તે ફેરફારને શાંત બનાવે છે, ભલે તમે ક્યારેય તેનો ઉપયોગ ન કરો.