Ինչու տեղափոխեցինք Mythex-ի սերվերները ARM-ի վրա

Սեպտեմբերի 19-ին մենք Mythex-ի արտադրական backend-ը x86 սերվերներից տեղափոխեցինք ավելի փոքր ARM հիմքով AWS Graviton սերվերների վրա, իսկ հարթակի տվյալների բազան նույնպես տեղափոխեցինք Graviton ինստանսի։ Պատճառը պարզ էր․ երբ ծանր աշխատանքը՝ յուրաքանչյուր օգտվողի հավելվածի գործարկումն ու build-ը՝ տեղափոխեցինք մեկուսացված նախագծային sandbox-ների մեջ, մեր հիմնական սերվերները հասնում էին իրենց հիշողության մոտ մեկ երրորդին։ Ավելի փոքր ARM մեքենաները տեղավորում են իրական բեռը և ամսական սերվերի հաշիվը իջեցնում մոտ 30%-ով։

Ինչ են անում մեր սերվերները հիմա

Նախկինում backend սերվերները շատ աշխատանք անում էին ուղղակիորեն։ Սեպտեմբերի կեսերին ավարտեցինք ծանր մասերի տեղափոխումը՝ յուրաքանչյուր նախագծի կոդի գործարկում, փաթեթների տեղադրում, հավելվածների build՝ մասնավոր cloud sandbox-ների մեջ, մեկը յուրաքանչյուր նախագծի համար։ Դա է նաև տալիս յուրաքանչյուր նախագծին իր մեկուսացված միջավայրը և կենդանի նախադիտումը։

Ինչ մնաց մեր սեփական սերվերների վրա, դա համակարգումն է․ API-ն, orchestrator-ը, որ կառավարում է sandbox-ները և հրապարակումը, նույնականացումը, billing-ը և gateway-ը։ Այդ աշխատանքը կայուն է և թեթև։ Տեղափոխությունից հետո սերվերները գագաթնակետին հասնում էին մոտ 1.3 ԳԲ հիշողության՝ մոտ երեք անգամ ավելի մեքենաների վրա։

Ինչու ARM

AWS-ի Graviton պրոցեսորները AWS-ի կողմից նախագծված ARM չիպեր են։ Նույն գնով սովորաբար ստանում եք ավելի հզորություն, քան համարժեք x86 ինստանսը, կամ նույն հզորությունը ավելի էժան․ և մեր բեռի համար (Node.js ծառայություններ, Docker, Postgres) ոչինչ չի կապում մեզ x86-ին։

Տեղափոխեցինք․

• Երկու հավելվածի սերվեր միջին x86 ինստանսներից փոքր Graviton ինստանսների վրա՝ յուրաքանչյուրը 2 ԳԲ RAM-ով։
• Հարթակի տվյալների բազան փոքր x86 տվյալների բազայի ինստանսից՝ նրա Graviton համարժեքի վրա։

Մեկ իրական բարդություն․ երկու ճարտարապետության համար պատկերներ

Մեր staging միջավայրը դեռ աշխատում է փոքր x86 սերվերի վրա։ Արտադրությունն այժմ ARM-ի վրա է։ Մեկի համար կառուցված կոնտեյների պատկերը չի աշխատի մյուսի վրա։

Ուստի յուրաքանչյուր պատկեր այժմ կառուցվում է երկու ճարտարապետության համար մեկ tag-ի տակ՝ multi-arch պատկեր։ Docker-ը ավտոմատ ընտրում է ճիշտ տարբերակը յուրաքանչյուր մեքենայի վրա, և deploy խողովակաշարը պետք չէ իմանա, թե որ միջավայրն է հրում։ Գինն այն է, որ CI build-ը ավելի երկար է․ օգուտը այն է, որ staging-ը և արտադրությունը աշխատում են ճիշտ նույն կոդը նույն tag-ից։

Վերադարձը պլանավորելը տեղափոխությունից առաջ

Կենդանի ծառայության պրոցեսորի ճարտարապետությունը փոխելը այն տեսակի փոփոխություն է, որը ցանկանում եք մի քանի րոպեում հետ շրջել։ Փոխելուց առաջ մենք՝

• պահեցինք սերվերի նախորդ ձևանմուշի տարբերակը որպես անվանված հետադարձ նպատակակետ,
• վերցրինք տվյալների բազայի snapshot անմիջապես տվյալների բազան չափափոխելուց առաջ, և
• գրեցինք runbook, որը ծածկում է տեղափոխությունը և վերադարձի ուղին։

Վերադարձ մեզ պետք չեկավ։ Դարձյալ նույնն կանեինք։

Ինչին պետք է հետևել

Փոքր սերվերներն ավելի քիչ ազատ տեղ ունեն։ Դրանից երկու բան է հետևում․

1. Եթե ծանր աշխատանքը երբևէ վերադառնա այս սերվերներին, 2 ԳԲ-ը բավարար չի լինի։ Շտկումը այն ժամանակ կլինի ավելի մեծ Graviton չափը, ոչ թե վերադարձ x86-ին։
2. Փոքր մեքենաներին swap է պետք։ Մեկ շաբաթ անց այս սերվերներից մեկը սառեց հիշողության ճնշումից՝ առանց տեխնիկապես հիշողությունը սպառելու․ պատմությունը բացակայող swap ֆայլի մասին։

Ինչ սովորեցինք

• Ճարտարապետության փոփոխություններից հետո նորից չափեք։ Աշխատանքի տեղափոխումը sandbox-ներ փոխեց այն, ինչ պետք էր մեր սերվերներին, իսկ ինստանսի չափերը չէին հասցրել հետևել։
• ARM-ը ցածր ռիսկով շահույթ է տիպիկ վեբ stack-երի համար, երբ ձեր պատկերները multi-arch են։
• Նախ գրեք վերադարձը։ Այն տեղափոխությունը հանգստացնում է, նույնիսկ եթե երբեք չօգտագործեք այն։