Regulated on Tarragonhttps://tarrragon.github.io/blog/tags/regulated/Recent content in Regulated on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Tue, 12 May 2026 00:00:00 +00009.C14 Standard Chartered：受監管銀行的 Aurora 4000 TPS 容量提升https://tarrragon.github.io/blog/backend/09-performance-capacity/cases/standard-chartered-aurora-banking/Tue, 12 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/09-performance-capacity/cases/standard-chartered-aurora-banking/<p>這個案例的核心責任是說明「受監管產業」的容量規劃跟「網路服務」的本質差異。銀行交易系統的容量目標不只是「能撐多少」、還要同時滿足合規（資料駐留、稽核、加密、可恢復性）、跟一般工程性能優化的取捨完全不同。</p> <h2 id="觀察">觀察</h2> <p>Standard Chartered 在 Aurora 的關鍵敘述（引自 <a href="https://aws.amazon.com/search/">AWS search results</a> 與相關 case study）：</p> <table> <thead> <tr> <th>指標</th> <th>遷移前</th> <th>遷移後 (Aurora)</th> </tr> </thead> <tbody> <tr> <td>交易吞吐 (TPS)</td> <td>（未公開、基線值）</td> <td>4000 TPS</td> </tr> <tr> <td>吞吐倍數</td> <td>1x baseline</td> <td>10x</td> </tr> <tr> <td>受監管市場</td> <td>-</td> <td>7 個（首批遷移）</td> </tr> <tr> <td>成本下降</td> <td>-</td> <td>「顯著」（未公開具體數字）</td> </tr> <tr> <td>主要驅動</td> <td>韌性 + 性能</td> <td>-</td> </tr> </tbody> </table> <p>服務組合：Amazon Aurora（PostgreSQL 或 MySQL 相容）、加密 at rest / in transit、多 AZ 部署、跨地區複製（受監管市場各自獨立）。</p> <h2 id="判讀">判讀</h2> <p>受監管銀行案例揭露三個合規驅動容量規劃的重點。</p> <ol> <li><strong>資料駐留限制 = 容量規劃的單位是「per 市場」</strong>：7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成「7 個獨立規劃 × 各自合規門檻」。對應 <a href="https://tarrragon.github.io/blog/backend/00-service-selection/" data-link-title="模組零：後端服務選型" data-link-desc="從需求類型判斷資料庫、快取、訊息佇列、觀測與部署平台的選型方向">00 服務選型模組</a> 的合規要求識別、跟 <a href="https://tarrragon.github.io/blog/backend/09-performance-capacity/" data-link-title="模組九：效能工程與容量規劃" data-link-desc="把『目前配置能撐多少、要加多少機器』變成可量化、可驗證、可改進的工程流程">9.6 容量規劃模型</a> 的地理分片。</li> <li><strong>「韌性 + 性能」並列、不是 trade-off</strong>：傳統工程文化常把可靠性跟性能視為對立、銀行業務要求兩者同時達標。Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 <em>韌性即性能</em> 的目標。對應 <a href="https://tarrragon.github.io/blog/backend/06-reliability/reliability-metrics-governance/" data-link-title="6.18 Reliability Metrics Governance" data-link-desc="DORA / SPACE 指標的選用、量測陷阱、anti-gaming 與團隊階段適配">06.18 reliability metrics governance</a> 的可靠性指標。</li> <li><strong>遷移本身的合規驗證 = 容量規劃延伸</strong>：受監管系統遷移不只是技術測試、還要過合規審查（中央銀行 / 金融監管機關）、每個市場各自審。這個審查 lead time（數月）必須算進遷移時程。對應 <a href="https://tarrragon.github.io/blog/backend/01-database/database-migration-playbook/" data-link-title="1.6 資料庫轉換實作：雙寫、回填、切流與回滾" data-link-desc="同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工">01.4 database migration playbook</a> 的合規驅動 migration。</li> </ol> <p>需要警惕：「10x throughput」是 <em>vs 舊系統</em>、不是 <em>vs 競爭對手</em>。受監管銀行的舊系統通常是 1990s-2000s 的 mainframe 或自建 OLTP、性能本來就低。讀案例時要對標的是「自家改善幅度」、不是「絕對性能」。</p> <h2 id="策略">策略</h2> <p>可重用的工程做法：</p> <ol> <li><strong>資料駐留是容量規劃的硬限制、不是優化選項</strong>：受監管市場必須各自獨立 cluster、不能用「全球單一 cluster」優化。對應 <a href="https://tarrragon.github.io/blog/backend/00-service-selection/traffic-data-scale/" data-link-title="0.5 流量與資料量評估" data-link-desc="用流量形狀、資料成長、hot key、保留期限與尖峰模式評估後端需求規模">00.4 traffic data scale</a> 的合規限制。</li> <li><strong>多 AZ + 跨地區複製是合規基線、不是優化</strong>：銀行業務 RPO / RTO 通常由監管要求（不能丟資料、必須 X 小時內恢復）、不是業務 SLA 選項。對應 <a href="https://tarrragon.github.io/blog/backend/06-reliability/dr-rollback-rehearsal/" data-link-title="6.7 DR 演練與 Rollback Rehearsal" data-link-desc="把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程">06.7 DR rollback rehearsal</a>。</li> <li><strong>遷移時程要算合規 lead time</strong>：每個受監管市場的審查可能 3-12 個月、合計遷移時程是「市場數 × 平均審查月份」、不是「技術遷移月份」。對應 <a href="https://tarrragon.github.io/blog/backend/01-database/database-migration-playbook/" data-link-title="1.6 資料庫轉換實作：雙寫、回填、切流與回滾" data-link-desc="同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工">01.4 database migration playbook</a>。</li> </ol> <p>跨平台等效：Azure SQL Hyperscale + Azure regions、GCP Cloud SQL / Spanner + regional configurations、各家雲端的受監管雲端方案（AWS GovCloud、Azure Government、GCP Assured Workloads）都是對等候選。差異是各家對特定監管框架（PCI-DSS、ISO27001、各國金融法規）的認證覆蓋。</p>這個案例的核心責任是說明「受監管產業」的容量規劃跟「網路服務」的本質差異。銀行交易系統的容量目標不只是「能撐多少」、還要同時滿足合規（資料駐留、稽核、加密、可恢復性）、跟一般工程性能優化的取捨完全不同。

觀察

Standard Chartered 在 Aurora 的關鍵敘述（引自 AWS search results 與相關 case study）：

指標 遷移前 遷移後 (Aurora)
交易吞吐 (TPS) （未公開、基線值） 4000 TPS
吞吐倍數 1x baseline 10x
受監管市場 - 7 個（首批遷移）
成本下降 - 「顯著」（未公開具體數字）
主要驅動 韌性 + 性能 -

服務組合：Amazon Aurora（PostgreSQL 或 MySQL 相容）、加密 at rest / in transit、多 AZ 部署、跨地區複製（受監管市場各自獨立）。

判讀

受監管銀行案例揭露三個合規驅動容量規劃的重點。

  1. 資料駐留限制 = 容量規劃的單位是「per 市場」：7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成「7 個獨立規劃 × 各自合規門檻」。對應 00 服務選型模組 的合規要求識別、跟 9.6 容量規劃模型 的地理分片。
  2. 「韌性 + 性能」並列、不是 trade-off：傳統工程文化常把可靠性跟性能視為對立、銀行業務要求兩者同時達標。Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標。對應 06.18 reliability metrics governance 的可靠性指標。
  3. 遷移本身的合規驗證 = 容量規劃延伸：受監管系統遷移不只是技術測試、還要過合規審查（中央銀行 / 金融監管機關）、每個市場各自審。這個審查 lead time（數月）必須算進遷移時程。對應 01.4 database migration playbook 的合規驅動 migration。

需要警惕：「10x throughput」是 vs 舊系統、不是 vs 競爭對手。受監管銀行的舊系統通常是 1990s-2000s 的 mainframe 或自建 OLTP、性能本來就低。讀案例時要對標的是「自家改善幅度」、不是「絕對性能」。

策略

可重用的工程做法：

  1. 資料駐留是容量規劃的硬限制、不是優化選項：受監管市場必須各自獨立 cluster、不能用「全球單一 cluster」優化。對應 00.4 traffic data scale 的合規限制。
  2. 多 AZ + 跨地區複製是合規基線、不是優化：銀行業務 RPO / RTO 通常由監管要求（不能丟資料、必須 X 小時內恢復）、不是業務 SLA 選項。對應 06.7 DR rollback rehearsal。
  3. 遷移時程要算合規 lead time：每個受監管市場的審查可能 3-12 個月、合計遷移時程是「市場數 × 平均審查月份」、不是「技術遷移月份」。對應 01.4 database migration playbook。

跨平台等效：Azure SQL Hyperscale + Azure regions、GCP Cloud SQL / Spanner + regional configurations、各家雲端的受監管雲端方案（AWS GovCloud、Azure Government、GCP Assured Workloads）都是對等候選。差異是各家對特定監管框架（PCI-DSS、ISO27001、各國金融法規）的認證覆蓋。

下一步路由

引用源

]]>