【案例研究】從每晚當機到自動擴展：我們如何協助跨國企業打造高可用 (HA) WordPress 架構
文章重點摘要 (Executive Summary)
- 挑戰：知名跨國企業網站每晚遭遇規律性服務中斷，雖有 Akamai WAF 防護卻無法阻擋，監控系統亦無法明確界定攻擊源頭。
- 根本原因：經排查確認非流量型 DDoS，而是 Apache 配置不當導致的記憶體溢出 (OOM)，加上 Bot 爬蟲觸發了資源耗盡。
- 解決方案：
- 短期：優化 Linux 底層參數與 Apache 記憶體管理，並啟用 Akamai Tarpit 策略緩解 Bot 流量。
- 長期：重構為 高可用性 (HA) 架構，導入負載平衡 (SLB)、自動擴展 (Auto Scaling) 與 OSS 儲存分離。
- 成效：徹底解決當機問題，消除單點故障 (SPOF)，並符合 MLPS Level 2 資安合規要求。
對於企業級營運的網站而言，系統的「可用性 (Availability)」與「可觀測性 (Observability)」是營運的基石。當網站發生異常中斷，且現有的監控工具無法給出明確答案時，便需要從系統架構層面進行深度的排查。
本文記錄了我們協助一家知名跨國企業（McK China），解決持續性服務中斷事件的完整技術路徑。我們從解決底層資源配置問題入手，進而協助客戶將傳統單機架構，升級為具備 高可用性 (High Availability) 與 自動擴展 (Auto Scaling) 的現代化雲端架構。
一、 事件背景：WAF 之後的異常中斷
去年底，客戶的網站面臨了規律性的服務中斷。監控數據顯示，每天凌晨 01:00 至 03:00 期間，伺服器 CPU 與記憶體負載會瞬間飽和，導致服務無法回應 (504 Gateway Timeout)。
此次事件的技術難點在於：
- WAF 數據不吻合： 前端部署的 Akamai WAF 顯示流量平穩（約 20-30 req/sec），並未偵測到典型的 Volumetric DDoS 攻擊特徵。
- 警報氾濫： 監控系統雖然發出大量資源警報，但 IT 團隊與資安廠商初期難以界定攻擊源頭，導致問題無法在第一時間收斂。
二、 根本原因分析 (Root Cause Analysis)
排除應用層（Application Layer）的常見問題後，我們直接切入 Linux 系統底層進行日誌分析與資源審計。經排查，確認本次事故為「資源耗盡」所致，主要由以下兩個因素疊加造成：
1. Web Server 配置與資源不匹配 (OOM)
經檢視 top 與系統日誌，發現伺服器運行的 Apache 仍採用 Prefork MPM 模式。此模式下，每個請求皆由獨立的 Process 處理，記憶體消耗較大。
我們計算出單一 Process 的記憶體佔用量約為 80MB。在凌晨的並發請求下，總記憶體需求遠超伺服器物理極限，觸發了 Linux Kernel 的 OOM (Out of Memory) Killer 機制，強制中止 Web Service 以保護系統核心，導致網站當機。
(詳細的記憶體計算與排查過程，請參考技術專文：WordPress 記憶體溢出 (OOM) 排查實錄)
2. 針對性 Bot 流量防禦策略調整
除了內部配置優化，我們與 Akamai 安全顧問 (Security Consultant) 深入分析流量日誌，識別出攻擊者偽裝成 “Unknown Bots” 進行持續掃描。
針對此類低流量但高頻率的請求，單純的封鎖 (Block) 容易被繞過。我們協同 Akamai 調整防禦策略，將 “Unknown Bots (Session Validation Failed)” 類別的處置動作，調整為 “Tarpit” (延遲回應) 模式。此舉有效消耗了攻擊端的連線資源，大幅降低了對源站 (Origin Server) 的衝擊。
三、 架構優化：導入高可用性 (HA) 解決方案
雖然透過參數調校解決了立即性危機，但單一伺服器架構仍存在單點故障 (SPOF) 風險。為了確保系統長期穩定並符合 MLPS (資訊安全等級保護) 合規要求，我們協助客戶執行了雲端架構的重構。
實施重點：
1. 負載平衡與自動擴展 (SLB & Auto Scaling)
我們在架構前端導入 Server Load Balancer，並配置 Auto Scaling Group。
效益： 系統可依據 CPU 使用率或連線數自動增減後端實例 (Instances)。在流量高峰自動擴容，離峰時自動縮減，兼顧效能與成本效益。
2. 儲存與運算分離 (OSS Integration)
為了解決 Auto Scaling 環境下，多台伺服器間的檔案同步問題，我們將 WordPress 的媒體資源 (wp-content/uploads) 全面遷移至 阿里雲 OSS (Object Storage Service)。
- 此舉實現了程式碼與數據的解耦 (Decoupling)。
- 針對資安需求，我們透過 DNS CNAME 配置，強制 OSS 流量必須經過 Akamai WAF，確保靜態資源同樣受到保護，避免源站 IP 暴露。
3. 部署流程優化 (Rolling Updates)
建立了標準化的 Staging 環境，並導入滾動更新 (Rolling Update) 機制。確保在進行核心更新或程式碼部署時，能以零停機 (Zero-Downtime) 的方式平滑過渡。
專案成果
透過此次的技術介入與架構升級，我們協助客戶達成了以下目標：
- 系統穩定性： 徹底解決 OOM 導致的當機問題，並消除單點故障風險。
- 資安防禦力： 建立 Akamai Tarpit 與阿里雲 WAF 的多層次防禦體系。
- 合規性遵循： 架構符合企業級資安規範與 MLPS Level 2 要求。
專業觀點：
WordPress 效能優化不應僅止於外掛層面。對於高流量的企業網站，底層的 Linux 參數調校與雲端架構的合理規劃，才是確保業務連續性的關鍵。