擴展至 100K 使用者¶
每個擴展層級只需修改 terraform.tfvars。自動擴展完成其餘工作。
平台的設計使得沒有任何元件需要替換即可達到 100K 使用者。執行個體類型變大、複本數量增加、並行限制提升——但架構、程式碼和部署流水線保持不變。本頁記錄了每個數量級變化時的確切調整。
擴展觸發一覽
| 使用者數 | 關鍵變更 |
|---|---|
| 1K | Multi-AZ RDS 實現資料庫高可用；Lambda 並行數提升至 100；速率限制中介軟體 |
| 5K | 擴展至 r6i.2xlarge Worker（每執行個體 120 個）；讀取複本；基線執行個體的預留執行個體 |
| 10K | 擴展至 r6i.4xlarge（每執行個體 240 個）；Valkey 提升至 100K ECPU；Redis Sorted Set 實現 O(log N) Worker 追蹤；所有背景任務使用 SQS |
| 50K | Graviton（ARM64）執行個體節省 20%；佈建式 Valkey 叢集（3-6 分片）；Shield Advanced；跨區域災難恢復 |
| 100K | 73 台 r6i.8xlarge 機隊；3 年期預留執行個體 + Savings Plans；完整跨區域備份 |
擴展計算¶
尖峰同時在線 Worker 的經驗模型：
| 變數 | 值 | 依據 |
|---|---|---|
| 日活躍使用者率 (DAU Rate) | 50% | 任一交易日有一半的註冊使用者活躍 |
| 尖峰並行率 | 70% | 日活躍使用者中，70% 在交易時段同時在線（09:00-10:30 尖峰） |
| 尖峰 Worker 數 | 0.35 x N | 每位同時在線使用者需要一個專屬 Worker |
每個執行個體的 Worker 數¶
| 執行個體類型 | vCPU | RAM | $/hr（新加坡） | Worker 數 @ 384 MB 軟性 | Worker 數 @ 64 CPU | 保守值 | $/worker/hr |
|---|---|---|---|---|---|---|---|
| r6i.large | 2 | 16 GB | $0.152 | 42 | 32 | 30 | $0.00507 |
| r6i.xlarge | 4 | 32 GB | $0.304 | 85 | 64 | 60 | $0.00507 |
| r6i.2xlarge | 8 | 64 GB | $0.608 | 170 | 128 | 120 | $0.00507 |
| r6i.4xlarge | 16 | 128 GB | $1.216 | 340 | 256 | 240 | $0.00507 |
| r6i.8xlarge | 32 | 256 GB | $2.432 | 680 | 512 | 480 | $0.00507 |
保守目標
「保守值」欄位考慮了作業系統開銷（約 512 MB）、ECS 代理記憶體，以及券商 API 呼叫期間記憶體尖峰的餘裕。生產目標設定在理論最大值的 25-30% 以下。
所有規格的每 Worker 成本相同
r6i 系列定價完全線性——執行個體規格加倍，價格也恰好加倍。使用更大執行個體的優勢在於營運面：更少的執行個體需要管理、更少的 ECS 代理開銷、更少的維護 Lambda 掃描迭代，以及更充裕的記憶體尖峰餘裕。策略是隨著使用者增長而提升執行個體規格，將叢集維持在 15-40 個執行個體，無論處於哪個層級。
層級表¶
| 層級 | 尖峰 Worker | Worker EC2 | Worker 類型 | API EC2 | API 類型 | Lambda 並行數 | ElastiCache | RDS |
|---|---|---|---|---|---|---|---|---|
| 100 | 35 | 2 | r6i.large | 3 | m6i.large | 50 | Valkey Serverless 1 GB | db.t3.large |
| 500 | 175 | 6 | r6i.large | 5 | m6i.large | 50 | Valkey Serverless 1 GB | db.t3.large |
| 1K | 350 | 12 | r6i.large | 10 | m6i.large | 100 | Valkey 5 GB / 10K ECPU | db.r6g.large Multi-AZ |
| 5K | 1,750 | 15 | r6i.2xlarge | 20 | m6i.xlarge | 200 | Valkey 5 GB / 50K ECPU | db.r6g.large + 讀取複本 |
| 10K | 3,500 | 15 | r6i.4xlarge | 30 | m6i.xlarge | 500 | Valkey 10 GB / 100K ECPU | db.r6g.xlarge + 讀取複本 |
| 50K | 17,500 | 37 | r6i.8xlarge | 50 | m6i.2xlarge | 500 | Valkey 叢集 3 分片 | db.r6g.2xlarge + 2 複本 |
| 100K | 35,000 | 73 | r6i.8xlarge | 50 | m6i.2xlarge | 500 | Valkey 叢集 6 分片 | db.r6g.4xlarge + 2 複本 |
如何解讀此表
以 5K 層級為例：5,000 使用者 × 0.35 = 1,750 個尖峰 Worker。不使用 59 個 r6i.large，而是提升到 r6i.2xlarge（每個可容納 120 個 Worker）→ ceil(1750/120) = 15 個執行個體。這使叢集保持精簡且易於管理。每 Worker 成本相同（$0.00507/hr）——節省來自更少的 ECS 代理和更簡化的營運。API 擴展到 20 個 m6i.xlarge。Lambda 並行數增加到 200。Valkey ECPU 提升至 50K。RDS 增加一個讀取複本。
已完成 vs 待完成¶
目前已部署¶
前 500 位使用者所需的一切已上線就緒：
| 元件 | 狀態 | 詳情 |
|---|---|---|
| ECS EC2 容量提供者 | :white_check_mark: 已部署 | 雙 ASG（API + Worker），自動擴展策略 |
| Lambda 編排器 | :white_check_mark: 已部署 | 5 個函式，SQS + EventBridge 觸發 |
| SQS FIFO 佇列 | :white_check_mark: 已部署 | worker-control、order-tasks、pool-claim + DLQ |
| Pool 預熱 | :white_check_mark: 已部署 | Pool manager Lambda、認領流程、約 897ms 就緒 |
| ElastiCache Valkey Serverless | :white_check_mark: 已部署 | 自動擴展儲存空間和 ECPU |
| RDS Aurora + RDS Proxy | :white_check_mark: 已部署 | 連線池，單一執行個體 |
| ALB + WAF | :white_check_mark: 已部署 | TLS、速率限制、託管規則群組 |
| Terraform IaC | :white_check_mark: 已部署 | 約 80 個資源，可重現的環境 |
| CI/CD 流水線 | :white_check_mark: 已部署 | GitHub Actions → ECR → ECS 滾動式部署 |
| CloudWatch 監控 | :white_check_mark: 已部署 | Container Insights、自訂指標、警報、儀表板 |
未來擴展工作¶
| 變更 | 觸發條件 | 工作量 | 影響 |
|---|---|---|---|
| Multi-AZ RDS | 1K 使用者 | terraform.tfvars 修改 |
資料庫層的高可用性 |
| 讀取複本 | 5K 使用者 | 在 Terraform 中新增複本配置 | 分載讀取查詢 |
| Valkey ECPU 擴展 | 10K 使用者 | terraform.tfvars 修改 |
處理心跳流量 |
| Graviton 執行個體（r7g、m7g） | 50K 使用者 | AMI + 執行個體類型變更 | 節省 20% 成本 |
| 佈建式 Valkey 叢集 | 50K 使用者 | 從 Serverless 遷移到佈建式 | 大流量下的可預測定價 |
| 預留執行個體 (Reserved Instances) | 5K 使用者 | AWS 主控台 / Terraform | 穩定運算節省 30-40% |
| SQS 處理所有背景任務 | 10K 使用者 | 應用程式碼 + Terraform | 將背景任務從 API 熱路徑移除 |
| Redis sorted set 追蹤 Worker | 10K 使用者 | 應用程式碼變更 | O(log N) Worker 查找取代 O(N) 鍵掃描 |
各層級的架構變更¶
| 變更 | 100 | 500 | 1K | 5K | 10K | 50K | 100K |
|---|---|---|---|---|---|---|---|
| 單可用區 RDS | :white_check_mark: | :white_check_mark: | — | — | — | — | — |
| Multi-AZ RDS | — | — | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| RDS 讀取複本 | — | — | — | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| 速率限制中介層 | — | — | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| SQS 背景任務 | — | — | — | 部分 | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| 預留執行個體 | — | — | — | :white_check_mark: | :white_check_mark: | :white_check_mark: | :white_check_mark: |
| Graviton 執行個體 | — | — | — | — | — | :white_check_mark: | :white_check_mark: |
| Shield Advanced | — | — | — | — | — | :white_check_mark: | :white_check_mark: |
| 跨區域備份 | — | — | — | — | — | :white_check_mark: | :white_check_mark: |
| 佈建式 Valkey 叢集 | — | — | — | — | — | :white_check_mark: | :white_check_mark: |
| Redis Sorted Set 追蹤 | — | — | — | — | :white_check_mark: | :white_check_mark: | :white_check_mark: |
擴展瓶頸與緩解措施¶
已知瓶頸
以下是隨著使用者數量增長，最先承受壓力的元件。
| 瓶頸 | 閾值 | 症狀 | 緩解措施 |
|---|---|---|---|
| Redis 鍵掃描 | 5K Worker | 維護 Lambda 逾時增加 | 切換到 Redis sorted set，O(log N) 查找 |
| ECS API 速率限制 | 10K Task | RunTask 節流（預設 10 TPS） | 向 AWS 申請提高限制，批次操作 |
| RDS 連線數 | 500 Task | 連線池耗盡 | RDS Proxy（已部署），增加 Proxy 連線池 |
| Lambda 並行數 | 10K 使用者 | SQS 佇列深度增加 | 向 AWS 申請提高並行限制 |
| ALB 連線數 | 50K 同時在線 | ALB 產生 5xx 錯誤 | 增加 ALB 執行個體（自動）、增加閒置逾時 |
每個瓶頸都有已知的緩解措施，無需任何架構變更——只需配置調整或 AWS 支援工單。
擴展哲學
針對當前層級最佳化，規劃下一個層級，並確保沒有任何因素阻擋再下一個層級。在只有 100 位使用者時就為 100K 過度工程化會浪費金錢並增加複雜度。工程化不足則意味著成長來臨時需要重寫。