Mythex'in Sunucularını Neden ARM'e Taşıdık?

19 Eylül'de Mythex'in üretim arka ucunu x86 sunucularından daha küçük ARM tabanlı AWS Graviton sunucularına taşıdık; platform veritabanını da bir Graviton makinesine taşıdık. Tetikleyici basitti: ağır işleri (her kullanıcının uygulamasını çalıştırmak ve derlemek) izole proje başına sandbox'lara taşıdıktan sonra, ana sunucularımız belleklerinin yaklaşık üçte birinde zirve yapıyordu. Daha küçük ARM makineleri gerçek yüke uyuyordu ve aylık sunucu faturasını yaklaşık %30 düşürdü.

Sunucularımız artık gerçekte ne yapıyor?

Daha önce arka uç sunucuları çok iş doğrudan yapıyordu. Eylül ortasına doğru pahalı kısımları (her projenin kodunu çalıştırmayı, paketleri kurmayı, uygulamaları derlemeyi) proje başına biri olmak üzere özel bulut sandbox'larına taşımayı bitirdik. Her projeye kendi izole ortamını ve canlı önizlemesini veren de budur.

Kendi sunucularımızda kalan şey koordinasyondur: sandbox'ları ve yayınlamayı yöneten API, orkestratör, kimlik doğrulama, faturalandırma ve ağ geçidi. Bu iş sabit ve hafiftir. Taşınmadan sonra sunucular, yaklaşık üç katı kapasiteli makinelerde yaklaşık 1,3 GB bellek kullanımında zirve yapıyordu.

Neden ARM?

AWS'nin Graviton işlemcileri AWS'nin tasarladığı ARM çiplerdir. Aynı paraya genellikle karşılaştırılabilir bir x86 makinesinden daha fazla kapasite alırsınız ya da aynı kapasiteyi daha az parayla alırsınız. Bizim gibi bir iş yükü için (Node.js servisleri, Docker, Postgres) bizi x86'ya bağlayan hiçbir şey yoktur.

Şunları taşıdık:

• İki uygulama sunucusu, orta boy x86 makinelerinden, her biri 2 GB RAM'li küçük Graviton makinelerine.
• Platform veritabanı, küçük bir x86 veritabanı makinesinden onun Graviton karşılığına.

Tek gerçek karmaşıklık: iki mimari için imajlar

Staging ortamımız hâlâ küçük bir x86 sunucusunda çalışıyor. Üretim artık ARM üzerinde çalışıyor. Birine göre derlenmiş bir konteyner imajı diğerinde çalışmaz.

Bu yüzden her imaj artık tek bir etiket altında her iki mimari için derleniyor: çoklu mimarili (multi-arch) bir imaj. Docker her makinede doğru varyantı otomatik seçer ve dağıtım hattının hangi ortama gönderdiğini bilmesi gerekmez. Bedeli daha uzun bir CI derlemesi; kazancı ise staging ve üretimin tam olarak aynı kodu, tam olarak aynı etiketten çalıştırmasıdır.

Taşınmadan önce geri dönüşü planlamak

Canlı bir servisin altında CPU mimarisini değiştirmek, dakikalar içinde geri alabilmek isteyeceğiniz türden bir değişikliktir. Geçmeden önce:

• önceki sunucu şablonu sürümünü adlandırılmış bir geri dönüş hedefi olarak sakladık,
• veritabanını yeniden boyutlandırmadan hemen önce bir veritabanı anlık görüntüsü aldık ve
• taşımayı ve geri dönüş yolunu kapsayan bir runbook yazdık.

Geri dönüşe ihtiyacımız olmadı. Yine de aynı şekilde yapardık.

Nelere dikkat edeceğiz?

Daha küçük sunucuların daha az boşluğu vardır. Bundan iki şey çıkıyor:

1. Ağır işler bu sunuculara bir daha taşınırsa, 2 GB yetmez. O zamanki çözüm x86'ya geri dönmek değil, daha büyük bir Graviton boyutudur.
2. Küçük makinelerin takasa ihtiyacı vardır. Bir hafta sonra bu sunuculardan biri, teknik olarak bellek tükenmeden bellek baskısından dondu: eksik takas dosyasının hikâyesi.

Bundan çıkardıklarımız

• Mimari değişikliklerden sonra yeniden ölçün. İşleri sandbox'lara taşımak sunucularımızın neye ihtiyaç duyduğunu değiştirdi; makine boyutları buna yetişmemişti.
• Tipik web yığınları için, imajlarınız çoklu mimarili olduğunda ARM düşük riskli bir kazançtır.
• Geri dönüşü önce yazın. Hiç kullanmasanız bile değişikliği daha sakin hale getirir.