我們為什麼把 Mythex 的伺服器遷移到 ARM

9 月 19 日，我們把 Mythex 的正式環境後端從 x86 伺服器遷移到較小的 ARM 架構 AWS Graviton 伺服器，並把平台資料庫也遷移到 Graviton 執行個體。觸發的原因很單純：在我們把繁重的工作——執行與建置每位使用者的 App——移到獨立的每專案沙盒之後，主要伺服器的記憶體峰值只用到約三分之一。較小的 ARM 機器足以應付實際負載，並使每月的伺服器帳單降低約 30%。

我們的伺服器現在做什麼

早期，後端伺服器會直接做很多工作。大約在九月中旬，我們完成了把昂貴的部分——執行每個專案的程式碼、安裝套件、建置 App——移到 私人雲端沙盒 中的工作，每個專案一個沙盒。這也是每個專案能擁有獨立隔離環境與即時預覽的原因。

留在我們自己伺服器上的，是協調工作：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 是低風險的收穫。
先寫好回復方案。 即使你從未使用它，它也能讓變更更從容。