რატომ გადავიყვანეთ Mythex-ის სერვერები ARM-ზე

19 სექტემბერს ჩვენ Mythex-ის production ბექენდი x86 სერვერებიდან პატარა ARM-ზე დაფუძნებულ AWS Graviton სერვერებზე გადავიყვანეთ, და პლატფორმის მონაცემთა ბაზა Graviton ინსტანციაზე გადავიტანეთ. მიზეზი მარტივი იყო: მას შემდეგ, რაც მძიმე სამუშაო — თითოეული მომხმარებლის აპის გაშვება და აგება — იზოლირებულ, თითო პროექტის სანდბოქსებში გადავიტანეთ, ჩვენი მთავარი სერვერები მეხსიერების დაახლოებით მესამედს იყენებდა პიკზე. პატარა ARM მანქანები რეალურ დატვირთვას ეტევა და თვიურ სერვერულ ხარჯს დაახლოებით 30%-ით ამცირებს.

რას აკეთებენ ახლა ჩვენი სერვერები

ადრე ბექენდის სერვერები ბევრ სამუშაოს პირდაპირ ასრულებდა. დაახლოებით სექტემბრის შუა რიცხვებში დავასრულეთ მძიმე ნაწილების — თითოეული პროექტის კოდის გაშვების, პაკეტების დაყენებისა და აპების აგების — გადატანა კერძო ღრუბლის სანდბოქსებში, თითო პროექტზე. სწორედ ეს აძლევს ყოველ პროექტს იზოლირებულ გარემოს და ცოცხალ გადახედვას.

ჩვენს სერვერებზე დარჩა კოორდინაცია: API, ორკესტრატორი, რომელიც სანდბოქსებსა და გამოქვეყნებას მართავს, ავთენტიფიკაცია, ბილინგი და გეითვეი. ეს სამუშაო სტაბილურია და მსუბუქი. გადატანის შემდეგ სერვერები დაახლოებით 1.3 GB მეხსიერებას აღწევდა პიკზე, მანქანებზე, რომელთაც დაახლოებით სამჯერ მეტი აქვთ.

რატომ ARM

AWS-ის Graviton პროცესორები AWS-ის მიერ დაპროექტებული ARM ჩიპებია. იმავე ფასად ზოგადად უფრო მეტ სიმძლავრეს იღებთ, ვიდრე ანალოგიურ x86 ინსტანციაზე, ან იმავე სიმძლავრეს უფრო იაფად — და ჩვენნაირი დატვირთვისთვის (Node.js სერვისები, Docker, Postgres) x86-ზე არაფერი არ გვაკავებს.

ჩვენ გადავიყვანეთ:

• ორი აპის სერვერი საშუალო ზომის x86 ინსტანციებიდან პატარა Graviton ინსტანციებზე, თითო 2 GB RAM-ით.
• პლატფორმის მონაცემთა ბაზა პატარა x86 ბაზის ინსტანციიდან მის Graviton ეკვივალენტზე.

ერთადერთი რეალური გართულება: ორი არქიტექტურისთვის სურათები

ჩვენი სტეიჯინგ გარემო ჯერ კიდევ პატარა x86 სერვერზე მუშაობს. production ახლა ARM-ზეა. კონტეინერის სურათი ერთისთვის აგებული მეორეზე არ იმუშავებს.

ამიტომ ყველა სურათი ახლა ორივე არქიტექტურისთვის ერთ ტეგქვეშ იგება — მულტი-არხ სურათი. Docker თითოეულ მანქანაზე სწორ ვარიანტს ავტომატურად ირჩევს, და დეპლოიმენტის მილსადენს არ სჭირდება იცოდეს, რომელ გარემოში აგზავნის. ფასი არის უფრო გრძელი CI აგება; სარგებელი ის არის, რომ სტეიჯინგი და production ერთსა და იმავე ტეგიდან ზუსტად ერთსა და იმავე კოდს უშვებენ.

უკან დაბრუნების დაგეგმვა გადატანამდე

ცოცხალ სერვისზე პროცესორის არქიტექტურის შეცვლა ისეთი ცვლილებაა, რომლის უკან დაბრუნებაც წუთებში გინდა შეძლო. გადართვამდე:

• შევინახეთ სერვერის წინა შაბლონის ვერსია, როგორც დასახელებული უკან დაბრუნების სამიზნე,
• გადავიღეთ ბაზის სნეპშოტი ბაზის ზომის შეცვლამდე, და
• დავწერეთ რანბუკი, რომელიც გადატანასა და უკან დაბრუნებას ფარავს.

უკან დაბრუნება არ დაგვჭირდა. მაინც იმავე წესით გავაკეთებდით.

რას უნდა ვუყურებდით

პატარა სერვერებს ნაკლები თავისუფალი ადგილი აქვთ. ამან ორი რამ გამოიწვია:

1. თუ მძიმე სამუშაო ოდესმე ამ სერვერებზე დაბრუნდება, 2 GB არ იქნება საკმარისი. მაშინ გამოსავალი იქნება Graviton-ის უფრო დიდი ზომა, და არა x86-ზე დაბრუნება.
2. პატარა მანქანებს swap სჭირდება. ერთი კვირის შემდეგ ერთი ამ სერვერთაგანი მეხსიერების ზეწოლისგან გაიყინა, ტექნიკურად მეხსიერების ამოწურვის გარეშე — swap ფაილის გამოტოვების ისტორია.

რა ვისწავლეთ

• არქიტექტურის ცვლილების შემდეგ თავიდან გაზომეთ. სამუშაოს სანდბოქსებში გადატანამ შეცვალა ის, რაც ჩვენ სერვერებს სჭირდებოდა; ინსტანციის ზომები ჯერ არ შეუფერხებია.
• ARM დაბალრისკიანი მოგებაა ტიპიური ვებ სტეკებისთვის, როცა თქვენი სურათები მულტი-არხია.
• უკან დაბრუნება ჯერ დაწერეთ. ის გადატანას უფრო მშვიდს ხდის, თუნდაც არასდროს გამოიყენოთ.