我們為何把 Mythex 伺服器遷移到 ARM

九月十九日，我們把 Mythex 的正式後端由 x86 伺服器遷移到較小的 ARM 架構 AWS Graviton 伺服器，同時也把平台資料庫遷移到 Graviton 執行個體。觸發點很簡單：在我們把沉重的工作——運行和建構每個用戶的應用程式——轉移到獨立的專案沙盒之後，我們的主伺服器記憶體使用量的高峰只有大約三分之一。較小的 ARM 機器更貼合實際負載，並把每月的伺服器費用減少了大約 30%。

我們的伺服器現在做什麼

早前，後端伺服器直接承擔了很多工作。大約在九月中，我們完成了把昂貴的部分——運行每個專案的程式碼、安裝套件、建構應用程式——移到私人雲端沙盒，每個專案一個。這也是每個專案能擁有獨立環境和即時預覽的原因。

留在我們自己伺服器上的，是協調工作：API、管理沙盒和發佈的協調器、身分驗證、計費和閘道。這些工作穩定而且輕量。遷移之後，伺服器的記憶體使用高峰約為 1.3 GB，而機器本身大約有它的三倍。

為何選擇 ARM

AWS 的 Graviton 處理器是 AWS 自行設計的 ARM 晶片。以同樣的費用，通常可以獲得比同級 x86 執行個體更多的運算能力，或者以更低的費用取得同樣的能力——對於我們這種工作負載（Node.js 服務、Docker、Postgres），沒有任何東西把我們綁定在 x86 上。

我們遷移了：

兩台應用程式伺服器，從中型 x86 執行個體改為每台 2 GB RAM 的小型 Graviton 執行個體。
平台資料庫，從小型 x86 資料庫執行個體改為其 Graviton 對等版本。

唯一真正的複雜之處：同時支援兩種架構的映像檔

我們的預發佈環境仍然運行在一台小型 x86 伺服器上，而正式環境現在運行 ARM。為一種架構建構的容器映像檔，無法在另一種架構上運行。

因此，每個映像檔現在都會以一個標籤、同時為兩種架構建構——即多架構映像檔。Docker 會在每台機器上自動選取正確的版本，部署流程無需知道它正在推送到哪個環境。代價是 CI 建構時間變長；好處則是預發佈和正式環境運行的是來自同一個標籤的完全相同的程式碼。

遷移前先規劃回復方案

在一項正在運行的服務上更改 CPU 架構，是那種你希望能在幾分鐘內撤銷的改動。切換之前，我們：

把先前的伺服器範本版本保留為一個已命名的回復目標，
在調整資料庫大小之前，立即為它拍攝了一個快照，並且
撰寫了一份操作手冊，涵蓋遷移過程以及回復的方法。

我們最終沒有用到回復方案。若再做一次，我們仍會採用同樣的做法。

我們會留意的事項

較小的伺服器可用的餘裕較少。由此可見兩點：

如果沉重的工作日後又搬回這些伺服器，2 GB 就不夠用。 屆時的解決方法是使用更大的 Graviton 規格，而不是改回 x86。
小型機器需要交換空間。 一星期後，其中一台伺服器因記憶體壓力而凍結，技術上並沒有耗盡記憶體——缺失交換檔案的故事。

我們的心得

架構變更後要重新測量。 把工作移到沙盒改變了我們伺服器的需求；而執行個體規格沒有跟上這些變化。
一旦映像檔是多架構的，ARM 對典型的網頁技術棧而言是低風險的收益。
先寫好回復方案。 即使你從來不用它，它也會令改動過程更從容。