Mengapa Kami Memindahkan Server Mythex ke ARM

Pada 19 September kami memindahkan backend produksi Mythex dari server x86 ke server AWS Graviton berbasis ARM yang lebih kecil, dan database platform juga kami pindahkan ke instance Graviton. Pemicunya sederhana: setelah kami memindahkan pekerjaan berat, yaitu menjalankan dan membangun setiap aplikasi pengguna, ke sandbox per proyek yang terisolasi, server utama kami memuncak di sekitar sepertiga memorinya. Mesin ARM yang lebih kecil cukup untuk beban nyata dan memangkas tagihan server bulanan sekitar 30%.

Apa yang sebenarnya dilakukan server kami sekarang

Sebelumnya, server backend melakukan banyak pekerjaan secara langsung. Sekitar pertengahan September kami menyelesaikan pemindahan bagian yang mahal, yaitu menjalankan kode setiap proyek, memasang paket, dan membangun aplikasi, ke sandbox cloud pribadi, satu untuk setiap proyek. Itu juga yang memberi setiap proyek lingkungan yang terisolasi dan pratinjau langsung sendiri.

Yang tetap berada di server kami adalah koordinasinya: API, orkestrator yang mengelola sandbox dan publikasi, autentikasi, penagihan, dan gateway. Pekerjaan itu stabil dan ringan. Setelah pemindahan, server memuncak di sekitar 1,3 GB memori pada mesin yang kapasitasnya sekitar tiga kali lipat.

Mengapa ARM

Prosesor Graviton AWS adalah chip ARM yang dirancang oleh AWS. Dengan biaya yang sama, Anda umumnya mendapatkan kapasitas lebih banyak daripada instance x86 yang setara, atau kapasitas yang sama dengan biaya lebih rendah. Untuk beban kerja seperti kami (layanan Node.js, Docker, Postgres), tidak ada yang mengikat kami pada x86.

Kami memindahkan:

• Dua server aplikasi dari instance x86 ukuran menengah ke instance Graviton kecil dengan RAM 2 GB masing-masing.
• Database platform dari instance database x86 kecil ke padanan Graviton-nya.

Satu komplikasi nyata: image untuk dua arsitektur

Lingkungan staging kami masih berjalan di server x86 kecil. Produksi sekarang berjalan di ARM. Image container yang dibangun untuk salah satunya tidak akan berjalan di yang lain.

Jadi setiap image sekarang dibangun untuk kedua arsitektur di bawah satu tag, yaitu image multi-arsitektur. Docker memilih varian yang tepat di setiap mesin secara otomatis, dan pipeline deploy tidak perlu tahu ke lingkungan mana ia mendorong. Biayanya adalah build CI yang lebih lama; manfaatnya adalah staging dan produksi menjalankan kode yang persis sama dari tag yang persis sama.

Merencanakan rollback sebelum pemindahan

Mengubah arsitektur CPU pada layanan yang sedang aktif adalah jenis perubahan yang ingin Anda bisa batalkan dalam hitungan menit. Sebelum beralih, kami:

• menyimpan versi template server sebelumnya sebagai target rollback yang bernama,
• mengambil snapshot database tepat sebelum mengubah ukuran database, dan
• menulis runbook yang mencakup pemindahan dan jalan kembalinya.

Kami tidak membutuhkan rollback. Kami tetap akan melakukannya dengan cara yang sama.

Yang akan kami perhatikan

Server yang lebih kecil memiliki ruang cadangan yang lebih sedikit. Dua hal berikut mengikuti dari itu:

1. Jika pekerjaan berat suatu saat kembali dipindahkan ke server ini, 2 GB tidak akan cukup. Solusinya kemudian adalah ukuran Graviton yang lebih besar, bukan kembali ke x86.
2. Mesin kecil membutuhkan swap. Seminggu kemudian, salah satu server ini membeku karena tekanan memori tanpa benar-benar kehabisan memori secara teknis: kisah file swap yang hilang.

Yang kami ambil dari ini

• Ukur ulang setelah perubahan arsitektur. Memindahkan pekerjaan ke sandbox mengubah apa yang dibutuhkan server kami; ukuran instance belum menyesuaikan.
• ARM adalah kemenangan dengan risiko rendah untuk stack web yang umum setelah image Anda multi-arsitektur.
• Tulis rollback terlebih dahulu. Itu membuat perubahan terasa lebih tenang, bahkan jika Anda tidak pernah memakainya.