Vì sao chúng tôi chuyển máy chủ của Mythex sang ARM

Ngày 19 tháng 9, chúng tôi chuyển backend production của Mythex từ máy chủ x86 sang các máy chủ AWS Graviton dựa trên ARM nhỏ hơn, và chuyển cơ sở dữ liệu nền tảng sang một instance Graviton. Nguyên nhân rất đơn giản: sau khi chúng tôi chuyển công việc nặng — chạy và build ứng dụng của từng người dùng — vào các sandbox đám mây tách biệt theo từng dự án, các máy chủ chính của chúng tôi đạt đỉnh khoảng một phần ba bộ nhớ. Các máy ARM nhỏ hơn vừa với tải thực tế và giảm khoảng 30% hóa đơn máy chủ hàng tháng.

Các máy chủ của chúng tôi thực sự làm gì bây giờ

Trước đây, các máy chủ backend làm rất nhiều việc trực tiếp. Vào khoảng giữa tháng 9, chúng tôi hoàn tất việc chuyển các phần tốn kém — chạy mã của từng dự án, cài gói, build ứng dụng — vào sandbox đám mây riêng, mỗi dự án một cái. Đó cũng là điều mang lại cho mỗi dự án một môi trường tách biệt và bản xem trước trực tiếp riêng.

Những gì còn lại trên máy chủ của chúng tôi là phần điều phối: API, orchestrator quản lý sandbox và xuất bản, xác thực, thanh toán và gateway. Công việc đó đều đặn và nhẹ. Sau khi chuyển, các máy chủ đạt đỉnh khoảng 1,3 GB bộ nhớ trên những máy có dung lượng gấp khoảng ba lần.

Vì sao là ARM

Bộ xử lý Graviton của AWS là chip ARM do AWS thiết kế. Với cùng một mức giá, bạn thường có nhiều năng lực hơn một instance x86 tương đương, hoặc cùng năng lực với giá thấp hơn — và với một khối lượng công việc như của chúng tôi (dịch vụ Node.js, Docker, Postgres), không có gì ràng buộc chúng tôi vào x86.

Chúng tôi đã chuyển:

• Hai máy chủ ứng dụng từ các instance x86 cỡ vừa sang các instance Graviton nhỏ với 2 GB RAM mỗi cái.
• Cơ sở dữ liệu nền tảng từ một instance cơ sở dữ liệu x86 nhỏ sang phiên bản Graviton tương đương.

Một phức tạp thật sự: image cho hai kiến trúc

Môi trường staging của chúng tôi vẫn chạy trên một máy chủ x86 nhỏ. Production giờ chạy ARM. Một image container build cho một loại sẽ không chạy trên loại kia.

Vì vậy mọi image giờ được build cho cả hai kiến trúc dưới cùng một tag — một image đa kiến trúc. Docker tự chọn đúng biến thể trên mỗi máy, và quy trình triển khai không cần biết nó đang đẩy lên môi trường nào. Cái giá là một bước build CI dài hơn; lợi ích là staging và production chạy đúng cùng một mã từ đúng cùng một tag.

Lập kế hoạch đường lui trước khi chuyển

Đổi kiến trúc CPU dưới một dịch vụ đang hoạt động là kiểu thay đổi bạn muốn có thể hoàn tác trong vài phút. Trước khi chuyển, chúng tôi:

• giữ phiên bản mẫu máy chủ trước đó làm mục tiêu quay lui có tên,
• chụp một snapshot cơ sở dữ liệu ngay trước khi đổi kích thước cơ sở dữ liệu, và
• viết một sổ tay vận hành bao quát việc chuyển và cách quay lại.

Chúng tôi không cần đến đường lui. Nhưng chúng tôi vẫn sẽ làm nó y như vậy.

Điều chúng tôi sẽ theo dõi

Máy chủ nhỏ hơn có ít dư địa hơn. Hai điều đi theo từ đó:

1. Nếu công việc nặng từng quay lại các máy chủ này, 2 GB sẽ không đủ. Cách sửa khi đó là một kích thước Graviton lớn hơn, không phải quay lại x86.
2. Máy nhỏ cần swap. Một tuần sau, một trong các máy này bị đứng vì áp lực bộ nhớ mà về mặt kỹ thuật chưa hết bộ nhớ — câu chuyện về file swap bị thiếu.

Chúng tôi rút ra gì

• Đo lại sau khi thay đổi kiến trúc. Việc chuyển công việc vào sandbox đã thay đổi những gì máy chủ của chúng tôi cần; kích thước instance vẫn chưa theo kịp.
• ARM là một lợi ích rủi ro thấp cho các stack web thông thường khi image của bạn đa kiến trúc.
• Viết đường lui trước. Nó làm cho thay đổi bình tĩnh hơn, ngay cả khi bạn không bao giờ phải dùng đến.