概述#

多數在雲端運行 MySQL 的組織使用 Amazon Web Services (AWS) 平台，主要涉及 EC2（虛擬伺服器）、EBS（區塊儲存）以及 RDS（託管資料庫服務）。雲端 MySQL 部署可分為兩大類：

  • IaaS（Infrastructure as a Service）：在雲端虛擬機上自行安裝與管理 MySQL，可完全控制 MySQL 及作業系統設定，但無法觸及底層實體硬體。
  • DBaaS（Database as a Service）：由雲端供應商管理 MySQL 服務，使用者僅取得連線憑證，可調整部分 MySQL 設定，但無法存取底層 OS 或虛擬機。Amazon RDS 即為此類代表。

重點： 雲端是一種部署平台，而非架構。架構會受平台影響，但兩者是不同的概念。混淆兩者容易導致不良的技術決策。

雲端運算的利弊與迷思#

分類項目說明
優勢基礎設施外包無需自行採購硬體、建立供應鏈關係或更換故障硬碟
優勢按使用付費將前期資本支出（CapEx）轉換為持續性營運支出（OpEx）
優勢持續增值供應商不斷推出新服務與降價，無需自行升級即可受益
優勢彈性佈建快速建立或關閉伺服器，無需處理硬體處置或轉售
優勢API 驅動自動化基礎設施以 API 定義和控制，實現高度自動化
劣勢資源共享且不可預測你可能暫時獲得超額資源，但其他租戶隨時可能收回，導致效能突降。容量規劃因此變得困難
劣勢無容量或可用性保證供應商可能超額認購，無法保證隨時都能佈建新實例
劣勢排障困難虛擬化環境下，iostat、vmstat 等工具的讀數可能不準確。當遇到效能問題時，更需仰賴精確的量測方法

常見迷思#

迷思事實
「雲端天生更具擴展性」擴展性取決於應用程式架構和組織能力，雲端只是提供按需購買資源的便利
「雲端自動保證高可用」個別雲端伺服器其實比精心設計的專用基礎設施更容易故障。但雲端平台由專家建構，能幫你避免許多底層的初學者錯誤
「只有雲端才能提供某些好處」許多雲端優勢來自其底層技術（如虛擬化），這些技術在私有環境中同樣可以實現
「雲端是銀彈」世上沒有銀彈

雲端 MySQL 的經濟性#

適合雲端的場景#

  • 原型階段的企業或不斷快速迭代新概念的公司（如行動 App、遊戲開發商），可以極低成本快速上線，若產品未成功則迅速終止。
  • 小型公司：無力自建資料中心來應對病毒式成長的流量高峰，雲端幫助對沖資本風險。
  • 非關鍵基礎設施：整合環境、部署測試、評估環境等僅偶爾使用的資源，雲端可大幅節省成本。

實例： 作者團隊用雲端做面試環境（啟動預設的「故障」AMI 讓候選人排障），以及開發/暫存伺服器——某個專案的暫存伺服器跑了數月，帳單不到一美元。

長期成本考量#

長期而言，雲端可能更昂貴。需要進行完整的 TCO（Total Cost of Ownership） 分析，包含 benchmark 數據和未來技術發展的預估，最終歸結為一個指標：每美元的業務交易數。

雲端 MySQL 的擴展性與高可用#

  • MySQL 不會因在雲端而自動變得更具擴展性。相反，較弱的單機效能迫使你更早採用水平擴展策略。
  • 雲端伺服器的可靠性和可預測性不如專用硬體，實現高可用需要更多創意。
  • 在 AWS 中無法使用類似 Virtual IP 的機制進行快速原子切換，需改用 Proxy 方案（如 ScaleBase）。

Auto-scaling 的限制#

  • 對無狀態元件（如 Web 伺服器）auto-scaling 很可行。
  • 對有狀態的資料庫伺服器來說極為困難。MySQL 無法原生運行在 shared-nothing 叢集上。
  • 唯讀為主的應用可透過增加 replica 獲得有限的 auto-scaling 能力。
  • 真正的 auto-scaling 需要自動 reshard 架構，但 MySQL 本身不支援。

資料庫不是世界的中心。若雲端對應用程式其他部分（Web 伺服器、任務佇列、快取等）的好處足以抵消資料庫的額外成本，遷移仍然值得。問題不是「是否」，而是「如何」。

四大基礎資源在雲端的特性#

MySQL 運行需要四大基礎資源，它們在雲端均有顯著限制：

資源雲端限制對比實體硬體
CPU核心數少且速度較慢。最大 EC2 實例提供 8 個 vCPU實體伺服器可達數十核心
記憶體最大 EC2 實例提供 68.4 GB實體伺服器可達 512 GB - 1 TB
I/O吞吐量、延遲、穩定性均受限直接連接硬碟為個位數毫秒，Flash 更快數個數量級
網路共享資源，有變動性但通常表現尚可通常不是首要瓶頸

I/O 的兩種選項（AWS）#

  • EBS（Elastic Block Store）：類似雲端 SAN，最佳實踐是使用 RAID 10。但 EBS 是共享資源，延遲可能高達數百毫秒且不可預測。優點是整合 AWS 服務、快速快照等。
  • 本地儲存（Instance Storage）：直接連接底層伺服器，效能較穩定，但實例停止後資料消失，不適合大多數資料庫場景。

注意： 本地儲存在首次寫入每個區塊時會有效能懲罰（first-write penalty），因為區塊在寫入前未實際分配。可用 dd 預先填滿裝置來避免此問題。

雲端 MySQL 效能分析#

效能變異性問題#

雲端 MySQL 效能通常不如實體環境，且變異性（variability）是最大問題。InnoDB 對不穩定的 I/O 效能特別敏感：

  • I/O 操作可能在伺服器內部持有 mutex lock，當延遲過長會導致堆積效應（pileup）。
  • 表現為：大量「卡住」的程序、莫名的長時間查詢、Threads_running 或 Threads_connected 飆升。
  • 變異性導致**排隊（queueing）**加劇，難以實現高並發或穩定低延遲。

經驗法則： 在最大的 EC2 實例上，典型 Web OLTP 工作負載下，MySQL 的 Threads_running 建議控制在 8 到 12 以內。超過此數值，效能通常會變得不可接受。

哪些工作負載適合／不適合雲端#

適合度工作負載說明
不適合高並發需求受限於 vCPU 數量與速度。每條查詢在 MySQL 內部只使用單一 CPU，回應時間受限於原始 CPU 速度
不適合大量 I/O 需求I/O 緩慢且不穩定時，整體效能快速惡化
適合Working set 可放入記憶體讀取可由快取服務，大幅減少 I/O。寫入也可在記憶體中緩衝並合併
適合低 I/O 吞吐量/頻寬需求MySQL 可運行得相當順暢

緩解 I/O 限制的策略#

  • 增加記憶體：足夠記憶體可容納 working set，大幅降低 I/O 需求。更大的 EC2 實例也提供更好的網路效能，有助 EBS I/O。
  • 精心設計 schema 和索引：邏輯與物理資料庫設計是減少 I/O 的最有力槓桿。
  • 應用程式與查詢最佳化：減少不必要的 I/O 操作。
  • 使用分區（Partitioning）：對寫入密集型工作負載，可將 I/O 集中在索引可放入記憶體的單一分區。
  • 放鬆持久性要求：
-- 降低 I/O 壓力但犧牲持久性
SET innodb_flush_log_at_trx_commit = 2;
SET sync_binlog = 0;
  • 升級 MySQL 版本：MySQL 5.5+ 及 InnoDB Plugin 提供顯著更好的 I/O 效能和更少的內部瓶頸。Percona Server 的 buffer pool warmup 功能可將重啟暖機時間從數小時/數天縮短至分鐘級。

EBS RAID 的陷阱： 增加更多 EBS volume 做 RAID 確實能提升 I/O，但也增加了任一 volume 在任何時刻效能不佳的機率。由於 InnoDB I/O 的特性，最慢的那顆 volume 往往成為整個系統的瓶頸。實測中，20 顆 EBS 的 RAID 10 比 10 顆的版本遇到更多停滯問題。

分片的必然性#

當 working set 無法放入記憶體時（在最大 EC2 實例上約 50-60 GB），你必須進行 sharding。相比之下，實體硬體可輕鬆運行數 TB 的資料庫。雲端迫使你更早分片。

AWS 上的 MySQL Benchmark 結果#

作者使用 Percona Server 5.5.16，以 4 GB buffer pool 對 1000 萬列資料執行 SysBench read-only benchmark（純記憶體工作負載，排除 I/O 影響），並以一台 Cisco 實體伺服器（雙 Intel Xeon X5670，6 核 x 2 超執行緒 = 24 個邏輯 CPU）作為對照。

讀取效能比較#

  • 最大 EC2 實例在 8 個執行緒時達到上限（因為只有 8 個 vCPU 核心）。
  • Cisco 實體伺服器在高並發下的效能遠超所有 EC2 實例。
  • 讀寫混合的工作負載因包含 I/O 等待，可能支撐略高於 8 執行緒的有效並發。

Figure 13.1: SysBench read-only benchmarks for MySQL in the AWS cloud

CPU 效能比較#

為了釐清 Cisco 伺服器的優勢是否來自 CPU，作者進一步執行了 SysBench prime-number benchmark（純 CPU 運算）：

  • 出人意料的結果：EC2 伺服器的單核 CPU 效能實際上優於 Cisco 伺服器（因後者的 CPU 已有數年歷史）。
  • 但在執行資料庫等複雜任務時，虛擬化的額外開銷使 EC2 處於劣勢。
  • 慢 CPU、慢記憶體存取和虛擬化開銷之間不總是容易區分，但此測試讓差異較為明確。

Figure 13.2: SysBench CPU prime-number benchmarks for AWS servers

MySQL Database as a Service (DBaaS)#

Amazon RDS#

RDS 就是 MySQL——完全相容，可作為 drop-in replacement。普遍認為底層架構為 EC2 + EBS。

分類項目說明
優勢代管服務Amazon 代管系統管理和部分 DBA 工作（如自動處理 replication）
優勢成本效益視成本結構和人力，可能比自行管理更經濟
優勢限制即保護移除了你可能「搬石頭砸自己腳」的工具
限制無 OS 存取無法直接量測 I/O 回應時間或 CPU 使用率（需透過 CloudWatch，但有時不夠詳細）
限制無完整 slow query log只能記錄到 CSV 表格，消耗更多資源且缺少高解析度的查詢回應時間
限制無法使用進階版本如 Percona Server 的效能增強功能
限制排障受限查詢掛起或資料損毀時，只能等 Amazon 處理或將資料匯出到別處自行修復
限制權限限制無法使用 SELECT INTO OUTFILE、FILE()、LOAD DATA INFILE 或任何涉及檔案系統和 replication 的操作

RDS 的效能與同規格的 EC2 + EBS + 原生 MySQL 大致相當。使用 EC2 自行安裝 Percona Server 可以擠出稍多效能，但不會有數量級的差距。選擇 RDS 應基於業務需求而非效能考量——如果效能真的如此關鍵，不應使用 AWS 雲端。

其他 DBaaS 方案#

  • FathomDB：類似 RDS，支援 Rackspace Cloud 和 AWS。
  • Xeround：分散式叢集架構，前端為 MySQL + 專有儲存引擎，支援動態擴展（dynamic scaling），可自動 reshard 新增/移除節點。與 NDB Cluster 有相似之處。
  • DBaaS 市場持續變化，新服務不斷出現。

最佳實踐總結#

  • 設計以適應雲端限制：接受資源較弱且不穩定的事實，在架構層面做出調整。
  • Working set 放入記憶體：這是在雲端獲得良好效能的關鍵前提。
  • 控制寫入工作量：確保寫入 I/O 不超過雲端 I/O 的承受能力。
  • 選擇正確的 MySQL 版本：MySQL 5.5+ 或 Percona Server，利用其改進的 I/O 效能和 buffer pool warmup。
  • 提早規劃 sharding：雲端中 working set 超過 50-60 GB 就需要考慮分片。
  • 以業務理由驅動決策：即使長期每筆交易成本較高，彈性、降低前期成本、縮短上市時間、降低風險等因素可能更重要。
  • 雲端的最大成功案例都是由業務需求驅動的決策，而非純粹的技術選擇。
Backward High Availability Application-Level Optimization Forward