Mengapa Kami Memindahkan Pelayan Mythex ke ARM

Pada 19 September kami memindahkan bahagian belakang pengeluaran Mythex daripada pelayan x86 ke pelayan AWS Graviton berasaskan ARM yang lebih kecil, dan memindahkan pangkalan data platform ke contoh Graviton juga. Puncanya mudah: selepas kami memindahkan kerja berat (menjalankan dan membina setiap aplikasi pengguna) ke dalam sandbox projek yang terasing, pelayan utama kami memuncak pada kira-kira satu pertiga daripada memorinya. Mesin ARM yang lebih kecil sesuai dengan beban sebenar dan memotong bil pelayan bulanan kira-kira 30%.

Apa yang dilakukan pelayan kami sekarang

Di awal, pelayan bahagian belakang melakukan banyak kerja secara langsung. Sekitar pertengahan September kami selesai memindahkan bahagian yang mahal, iaitu menjalankan kod setiap projek, memasang pakej dan membina aplikasi, ke dalam sandbox awan persendirian, satu untuk setiap projek. Itulah juga yang memberikan setiap projek persekitaran terasing dan pratonton langsungnya.

Apa yang kekal pada pelayan kami ialah penyelarasan: API, orkestra yang mengurus sandbox dan penerbitan, pengesahan, bil dan gerbang laluan. Kerja itu stabil dan ringan. Selepas pemindahan, pelayan memuncak pada kira-kira 1.3 GB memori pada mesin yang kira-kira tiga kali ganda saiznya.

Mengapa ARM

Pemproses Graviton AWS ialah cip ARM yang direka oleh AWS. Untuk wang yang sama, biasanya anda mendapat kapasiti lebih banyak berbanding contoh x86 yang setara, atau kapasiti yang sama dengan harga lebih murah, dan bagi beban seperti kami (perkhidmatan Node.js, Docker, Postgres) tiada apa yang mengikat kami kepada x86.

Kami memindahkan:

• Dua pelayan aplikasi daripada contoh x86 bersaiz sederhana kepada contoh Graviton kecil dengan 2 GB RAM setiap satu.
• Pangkalan data platform daripada contoh pangkalan data x86 kecil kepada setara Graviton-nya.

Satu komplikasi sebenar: imej untuk dua seni bina

Persekitaran staging kami masih berjalan pada pelayan x86 kecil. Pengeluaran kini berjalan ARM. Imej kontena yang dibina untuk satu tidak akan berjalan pada yang lain.

Jadi setiap imej kini dibina untuk kedua-dua seni bina di bawah satu tag, iaitu imej multi-arch. Docker memilih varian yang betul pada setiap mesin secara automatik, dan saluran penerbitan tidak perlu tahu ke persekitaran mana ia menolak. Kosnya ialah binaan CI yang lebih panjang; faedahnya ialah staging dan pengeluaran menjalankan kod yang sama tepat daripada tag yang sama.

Merancang pemulihan sebelum pemindahan

Mengubah seni bina CPU di bawah perkhidmatan yang sedang hidup ialah jenis perubahan yang anda mahu boleh dibatalkan dalam masa beberapa minit. Sebelum bertukar, kami:

• menyimpan versi templat pelayan sebelumnya sebagai sasaran pemulihan yang dinamakan,
• mengambil gambar pangkalan data sejurus sebelum menukar saiz pangkalan data, dan
• menulis runbook yang merangkumi pemindahan dan jalan kembali.

Kami tidak memerlukan pemulihan itu. Kami tetap akan melakukannya dengan cara yang sama.

Apa yang patut kami perhatikan

Pelayan yang lebih kecil mempunyai ruang lebih sedikit. Dua perkara mengikut daripada itu:

1. Jika kerja berat pernah dipindahkan semula ke pelayan ini, 2 GB tidak akan mencukupi. Penyelesaiannya ketika itu ialah saiz Graviton yang lebih besar, bukan kembali ke x86.
2. Mesin kecil memerlukan swap. Seminggu kemudian, salah satu pelayan ini beku akibat tekanan memori tanpa secara teknikal kehabisan memori. Kisah fail swap yang hilang.

Apa yang kami pelajari daripadanya

• Ukur semula selepas perubahan seni bina. Memindahkan kerja ke sandbox mengubah apa yang diperlukan pelayan kami; saiz contoh belum mengejar.
• ARM ialah kemenangan risiko rendah untuk tindanan web biasa apabila imej anda sudah multi-arch.
• Tulis rancangan pemulihan dahulu. Ia menjadikan perubahan itu lebih tenang walaupun anda tidak pernah menggunakannya.