[micro-service/55] 成本優化：免費午餐的 ROI 計算

結論先講

先做免費的優化，再花錢。 Multi-worker（PM2 cluster / Gunicorn workers）零成本提升 50-93% throughput——這是第 21 篇說的免費午餐。Redis cache 每月 $12 但能減少 50 - 70$ 70-200，3 個服務以下用 Docker Compose 就好。

優化 ROI 排行榜

優化項目	成本	效益	ROI	優先度
Multi-worker	$0	throughput +50-93%	無限大	P0
程式碼效能優化	$0（開發時間）	視 case 而定	高	P0
Right-sizing container	$0	省 20-40% 資源	無限大	P1
Redis cache	$12/月	省 1-2 台 AP server	150-400%	P1
Spot instance	$0	省 60-70% compute	無限大	P2
Reserved instance	預付 1-3 年	省 30-60%	高	P2
Serverless 改造	開發時間	低流量服務省 80%+	視流量	P3
換語言（Python→Go）	大量開發時間	省 40-60% compute	低	P4

P0：免費午餐

Multi-worker

如同第 21 篇的數據：

Node.js (Express) — 500 concurrent users：
  單 worker:   ~800 RPS, CPU 使用率 100%（一顆核心）
  4 workers:  ~1540 RPS, CPU 使用率 ~90%（四顆核心都用上）
  提升: +93%

Python (FastAPI) — 500 concurrent users：
  單 worker:   ~400 RPS
  4 workers:  ~750 RPS
  提升: +87%

成本：$0。 就是加一行設定：

// PM2 ecosystem.config.js
module.exports = {
  apps: [{
    name: 'order-service',
    script: 'dist/index.js',
    instances: 'max',    // ← 用滿所有 CPU 核心
    exec_mode: 'cluster',
  }]
};

# Gunicorn
gunicorn app:app --workers 4 --worker-class uvicorn.workers.UvicornWorker

如果你的服務還在用單 worker，這是你能做的最高 ROI 優化。

程式碼層面的免費優化

N+1 query 修復:     0 成本 → 減少 90% DB 查詢
連線池設定正確:      0 成本 → 減少連線建立開銷
JSON serialization:  換 fast-json-stringify → +30% throughput
Gzip compression:    Nginx 開 gzip → 減少 60-70% 傳輸量

P1：低成本高回報

Redis Cache

成本：
  AWS ElastiCache (cache.t3.micro): $12/月
  或 GCP Memorystore (basic-M1): $10/月

效益：
  假設 Order Service 的 GET /orders/:id 佔 70% 流量
  加上 Redis cache（TTL 60s）後：
  - 70% 的請求直接從 Redis 回（< 1ms）
  - 只有 30% 打到 DB

  原本需要 2 台 AP server ($30/月) 才能扛住
  加了 cache 後 1 台就夠 ($15/月)

  淨省：$15 - $12 = $3/月（很少）
  但真正的價值：DB 負載降 70%，不需要升級 DB instance
  如果 DB 從 db.t3.medium ($60) 降到 db.t3.small ($30)
  → 淨省 $30 - $12 = $18/月

Right-sizing Container

常見問題：
  DevOps 給每個 Pod 設了 1 CPU / 1GB RAM limit
  但實際上 Notification Service 只用了 0.2 CPU / 200MB

K8s 的 VPA（Vertical Pod Autoscaler）會告訴你建議值：

kubectl get vpa notification-service -o yaml
# recommendation:
#   containerRecommendations:
#   - containerName: notification-service
#     target:
#       cpu: 200m       ← 只需要 0.2 CPU
#       memory: 256Mi   ← 只需要 256MB

調整前：4 個 Pod × 1 CPU = 4 CPU → 需要 2 台 t3.medium
調整後：4 個 Pod × 0.25 CPU = 1 CPU → 1 台 t3.small 就夠

月省：$60 - $15 = $45

P2：需要評估的優化

Spot Instance

AWS Spot Instance 比 On-Demand 便宜 60-70%：
  t3.medium On-Demand: $30/月
  t3.medium Spot:      ~$9-12/月

但 Spot 隨時可能被收回（2 分鐘通知）。

適合：
  ✅ Stateless 的 API server（被收回就再起一台）
  ✅ Batch job / data pipeline
  ✅ CI/CD runner

不適合：
  ❌ 資料庫
  ❌ Kafka broker
  ❌ 任何 stateful 服務

K8s 混合策略

# Node pool 混合 On-Demand + Spot
apiVersion: v1
kind: NodePool
spec:
  # 基礎負載用 On-Demand（穩定）
  onDemand:
    minNodes: 2
    maxNodes: 4
 
  # 彈性負載用 Spot（便宜）
  spot:
    minNodes: 0
    maxNodes: 10
    # 設定多種 instance type，降低被收回機率
    instanceTypes: [t3.medium, t3a.medium, m5.large, m5a.large]

Reserved Instance / Savings Plans

如果你的基礎負載穩定（至少跑 12 個月不會關）：

1 年 RI:  省 ~30-40%
3 年 RI:  省 ~50-60%

Savings Plans（更彈性）：
  承諾每小時消費 $X → 該額度內享折扣
  不綁定 instance type，可以換

K8s 本身的隱藏成本

這是很多團隊忽略的：

AWS EKS 控制平面:   $73/月（固定費用，不管你跑幾個 Pod）
GCP GKE Autopilot:  $73/月
Azure AKS:          免費（但 uptime SLA 要加 $73/月）

如果你只有 3 個微服務：
  EKS 控制平面:         $73
  3 台 t3.small worker: $45
  ALB Ingress:          $16
  ECR:                  $5
  CloudWatch:           $10
  ────────────────────
  總計: ~$149/月

  vs Docker Compose on 1 台 t3.large: $60/月

  K8s 多花了 $89/月 ≈ $1,068/年

如同第 41 篇的結論：服務 < 5 個，Docker Compose 就夠了。 K8s 的價值在自動擴展、自動修復、滾動更新——但這些在小規模下，手動做就好。

成本監控

省錢不是一次性的事，需要持續監控：

工具推薦：
  AWS:   Cost Explorer + Budgets + Trusted Advisor
  GCP:   Cost Management + Recommender
  K8s:   Kubecost（開源）/ CAST AI
  通用:   Infracost（IaC 成本預估）

設定告警：
  - 月費用超過預算 80% → Slack 通知
  - 單日費用比前日增加 50% → P2 告警（可能忘記關測試環境）
  - Spot instance 被收回 → 確認服務正常遷移到 On-Demand

系列回顧

從第 1 篇的「為什麼要微服務」到這裡，55 篇走了完整的旅程：

第 1-10 篇:  基礎概念 — 為什麼拆、怎麼拆、通訊方式
第 11-20 篇: 設計模式 — Saga、CQRS、Event Sourcing
第 21-30 篇: 效能與壓測 — 免費午餐、框架選擇、壓測方法論
第 31-40 篇: 資料與基礎設施 — DB 選型、Cache、Event Driven
第 41-50 篇: 維運與安全 — Container、Observability、CI/CD、安全
第 51-55 篇: 成本與體驗 — DX、Debug、成本計算與優化

如同第 30 篇說的——微服務不是銀彈。它解決了「太多人改同一包程式碼」和「不同服務需要不同擴展策略」的問題，但同時帶來了分散式系統的所有複雜度：網路不可靠、資料一致性、部署複雜度、Debug 難度、基礎設施成本。

最後的建議：從單體開始。 當你的團隊超過 10 人、部署頻率被拖慢、某個模組的效能瓶頸影響整個系統——那時候再拆。拆的時候，這 55 篇文章裡的每一個坑，都是你的地圖。

搜尋的演進：MySQL LIKE → PG FTS → Elasticsearch — 成本算完了，接下來看搜尋——從最簡單的 LIKE 到 Elasticsearch，每一步的成本和效益。

本系列文章

完整 68 篇目錄見系列首頁

← 上一篇：每個 Request 多少錢：從壓測數據算雲端成本 → 下一篇：搜尋的演進：從 MySQL LIKE 到 PostgreSQL FTS 到 Elasticsearch

Terry Yao's Blog

分類

目錄