Amazon on Tarragonhttps://tarrragon.github.io/blog/backend/06-reliability/cases/amazon/Recent content in Amazon on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 01 May 2026 00:00:00 +0000Amazon：Shuffle Sharding 與 Cell 邊界的失效局部化https://tarrragon.github.io/blog/backend/06-reliability/cases/amazon/shuffle-sharding-and-cell-boundary/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/06-reliability/cases/amazon/shuffle-sharding-and-cell-boundary/<p>Amazon 可靠性設計的核心責任是把失效影響限制在局部邊界。當系統採用多租戶與大規模共享資源，隔離策略必須先於恢復策略被定義，否則任何回復動作都會變成全域風險。</p> <h2 id="問題場景">問題場景</h2> <p>多租戶服務常見的放大路徑是「單租戶異常 → 共享資源飽和 → 全域退化」。若路由與容量都沒有明確邊界，團隊只能在事故後做整體降載，代價高且恢復慢。</p> <p>cell-based architecture 與 shuffle sharding 提供的是前置結構：先限制擴散，再談恢復。</p> <h2 id="決策機制">決策機制</h2> <table> <thead> <tr> <th>機制</th> <th>核心問題</th> <th>交付結果</th> </tr> </thead> <tbody> <tr> <td>Cell 邊界</td> <td>一個失效最多影響到哪裡</td> <td>局部故障域</td> </tr> <tr> <td>Shuffle sharding</td> <td>熱點租戶如何避免重疊影響</td> <td>隨機子集合隔離</td> </tr> <tr> <td>Static stability</td> <td>控制面失效時資料面如何維持</td> <td>降級持續服務</td> </tr> <tr> <td>Constant work</td> <td>失敗模式下是否維持固定工作量</td> <td>防放大設計</td> </tr> </tbody> </table> <p>這組機制讓恢復策略從「全域搶救」轉為「分批收斂」。在可用性與成本取捨上，局部隔離通常比全域冗餘更可持續。</p> <h2 id="可觀測訊號">可觀測訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>判讀重點</th> <th>對應章節</th> </tr> </thead> <tbody> <tr> <td>shard contention</td> <td>熱點是否跨 shard 擴散</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dependency-reliability-budget/" data-link-title="6.14 Dependency Reliability Budget" data-link-desc="把內外依賴的可靠性納入 SLO 計算與設計約束">6.14</a></td> </tr> <tr> <td>cell error isolation ratio</td> <td>錯誤是否被限制在局部</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/experiment-safety-boundary/" data-link-title="6.20 Experiment Safety Boundary" data-link-desc="定義 chaos、load test、DR drill 的 [blast radius](/backend/knowledge-cards/blast-radius/)、停止條件與權限約束">6.20</a></td> </tr> <tr> <td>recovery batch completion</td> <td>分批恢復是否可預測</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/containment-recovery-strategy/" data-link-title="8.3 止血、降級與回復策略" data-link-desc="把短期止血與正式回復拆成可執行步驟">8.3</a></td> </tr> <tr> <td>control-plane dependency lag</td> <td>控制面異常是否拖累資料面</td> <td><a href="https://tarrragon.github.io/blog/backend/04-observability/service-topology/" data-link-title="4.13 Service Topology 與 Dependency Map" data-link-desc="把跨服務依賴從文件變成自動發現的觀測訊號">4.13</a></td> </tr> </tbody> </table> <h2 id="常見陷阱">常見陷阱</h2> <p>把 sharding 當成純擴容手段會忽略隔離責任。當分片策略只服務容量，沒有對齊失效邊界，事故時仍會看到跨租戶共振。真正的設計重點是「隔離優先，擴容其次」。</p> <h2 id="下一步路由">下一步路由</h2> <p>要把案例轉成可執行設計，先定義 <a href="https://tarrragon.github.io/blog/backend/06-reliability/dependency-reliability-budget/" data-link-title="6.14 Dependency Reliability Budget" data-link-desc="把內外依賴的可靠性納入 SLO 計算與設計約束">6.14</a> 的依賴預算與共享邊界，再在 <a href="https://tarrragon.github.io/blog/backend/06-reliability/experiment-safety-boundary/" data-link-title="6.20 Experiment Safety Boundary" data-link-desc="定義 chaos、load test、DR drill 的 [blast radius](/backend/knowledge-cards/blast-radius/)、停止條件與權限約束">6.20</a> 驗證局部化假設。事故時的分批回復流程回到 <a href="https://tarrragon.github.io/blog/backend/08-incident-response/multi-incident-coordination/" data-link-title="8.14 Multi-incident Coordination" data-link-desc="把同時多事故的優先序、資源分配與 incident command system pool 協調變成可執行流程">8.14</a>。</p>Amazon 可靠性設計的核心責任是把失效影響限制在局部邊界。當系統採用多租戶與大規模共享資源，隔離策略必須先於恢復策略被定義，否則任何回復動作都會變成全域風險。

問題場景

多租戶服務常見的放大路徑是「單租戶異常 → 共享資源飽和 → 全域退化」。若路由與容量都沒有明確邊界，團隊只能在事故後做整體降載，代價高且恢復慢。

cell-based architecture 與 shuffle sharding 提供的是前置結構：先限制擴散，再談恢復。

決策機制

機制 核心問題 交付結果
Cell 邊界 一個失效最多影響到哪裡 局部故障域
Shuffle sharding 熱點租戶如何避免重疊影響 隨機子集合隔離
Static stability 控制面失效時資料面如何維持 降級持續服務
Constant work 失敗模式下是否維持固定工作量 防放大設計

這組機制讓恢復策略從「全域搶救」轉為「分批收斂」。在可用性與成本取捨上，局部隔離通常比全域冗餘更可持續。

可觀測訊號

訊號 判讀重點 對應章節
shard contention 熱點是否跨 shard 擴散 6.14
cell error isolation ratio 錯誤是否被限制在局部 6.20
recovery batch completion 分批恢復是否可預測 8.3
control-plane dependency lag 控制面異常是否拖累資料面 4.13

常見陷阱

把 sharding 當成純擴容手段會忽略隔離責任。當分片策略只服務容量，沒有對齊失效邊界，事故時仍會看到跨租戶共振。真正的設計重點是「隔離優先，擴容其次」。

下一步路由

要把案例轉成可執行設計，先定義 6.14 的依賴預算與共享邊界，再在 6.20 驗證局部化假設。事故時的分批回復流程回到 8.14。

]]>Amazon：Static Stability 與 Constant Work Patternhttps://tarrragon.github.io/blog/backend/06-reliability/cases/amazon/static-stability-and-constant-work/Tue, 23 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/06-reliability/cases/amazon/static-stability-and-constant-work/<p><a href="https://tarrragon.github.io/blog/backend/knowledge-cards/static-stability/" data-link-title="Static Stability" data-link-desc="控制面失效時資料面用快取的已知好配置繼續服務的設計模式">Static stability</a> 的責任是讓資料面在控制面故障時仍能維持服務。Constant work pattern 的責任是讓系統在失敗模式下的工作量與正常時相同。兩者共同保護系統在最需要穩定時不會因為自救動作而崩潰。</p> <h2 id="問題場景">問題場景</h2> <p>控制面管理路由、配置推送、服務發現與 auto-scaling。當控制面本身失效，依賴控制面的資料面會同時進入未知狀態。最危險的放大路徑是：控制面掛掉後，資料面節點同時嘗試重新連線或重新取得配置，retry storm 把殘餘容量耗盡，資料面跟著崩潰。</p> <p>這個問題在大規模平台上尤其嚴重。節點越多，控制面恢復時的同時 pull 量越大，恢復本身就會變成新的負載來源。</p> <h2 id="決策機制">決策機制</h2> <table> <thead> <tr> <th>機制</th> <th>核心問題</th> <th>設計約束</th> </tr> </thead> <tbody> <tr> <td>Static stability</td> <td>控制面不可用時資料面能否繼續服務</td> <td>快取的配置必須是完整可用狀態，不能是 partial update</td> </tr> <tr> <td>Constant work</td> <td>失敗模式下的系統工作量是否跟正常時相同</td> <td>push-based 優於 pull-based：定時推全量，不靠拉取</td> </tr> <tr> <td>Pre-computed fallback</td> <td>控制面失效時是否有不需要即時計算的備援路徑</td> <td>fallback 路徑預先建好，切換動作本身不依賴控制面</td> </tr> </tbody> </table> <p>Static stability 的實作核心是讓每個資料面節點持有控制面最後已知的好配置。當控制面恢復通訊時，節點用最新配置更新快取；當通訊中斷時，節點用快取繼續服務。這個設計要求配置快取是完整的（能獨立驅動服務），而不是差分的（需要跟控制面合併才能用）。</p> <p>Constant work pattern 的核心是讓系統無論在正常或故障狀態下都執行相同的工作量。push-based config distribution 在每個週期推送全量配置給所有節點，不管配置是否有變更。這樣在控制面恢復時，不會因為所有節點同時 pull 而產生 thundering herd。相比之下，pull-based 在正常時流量低，但控制面恢復瞬間流量暴增。</p> <h2 id="可觀測訊號">可觀測訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>判讀重點</th> <th>對應章節</th> </tr> </thead> <tbody> <tr> <td>control-plane health</td> <td>控制面是否可用、是否在退化中</td> <td><a href="https://tarrragon.github.io/blog/backend/04-observability/service-topology/" data-link-title="4.13 Service Topology 與 Dependency Map" data-link-desc="把跨服務依賴從文件變成自動發現的觀測訊號">4.13</a></td> </tr> <tr> <td>cache staleness</td> <td>快取配置距離最後更新多久</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/steady-state-definition/" data-link-title="6.22 Steady State Definition" data-link-desc="在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化">6.22</a></td> </tr> <tr> <td>recovery work amplification</td> <td>恢復過程中負載是否比正常時更高</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dependency-reliability-budget/" data-link-title="6.14 Dependency Reliability Budget" data-link-desc="把內外依賴的可靠性納入 SLO 計算與設計約束">6.14</a></td> </tr> <tr> <td>data-plane autonomous duration</td> <td>資料面在無控制面時能獨立運作多久</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dr-rollback-rehearsal/" data-link-title="6.7 DR 演練與 Rollback Rehearsal" data-link-desc="把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程">6.7</a></td> </tr> </tbody> </table> <p>cache staleness 是 static stability 最關鍵的健康指標。當快取新鮮度超過預設門檻（取決於配置變更頻率），資料面仍能服務，但服務行為可能與最新意圖不一致。這個門檻決定了 degraded mode 的可接受時間窗。</p> <h2 id="常見陷阱">常見陷阱</h2> <p>把控制面失效視為低概率事件而不做 static stability 設計，會在真正發生時暴露循環依賴。Meta 2021-10 事故中，BGP 配置變更導致控制面與資料面共用的網路路徑同時失效，而恢復工具本身也依賴這條路徑，恢復動作陷入循環等待。這個案例說明 static stability 的價值在事前設計，而非事後補救。</p> <h2 id="下一步路由">下一步路由</h2> <ul> <li><a href="https://tarrragon.github.io/blog/backend/06-reliability/dr-rollback-rehearsal/" data-link-title="6.7 DR 演練與 Rollback Rehearsal" data-link-desc="把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程">6.7 DR rollback rehearsal</a>：static stability 讓資料面在災難期間自主運作，是 DR by design</li> <li><a href="https://tarrragon.github.io/blog/backend/06-reliability/dependency-reliability-budget/" data-link-title="6.14 Dependency Reliability Budget" data-link-desc="把內外依賴的可靠性納入 SLO 計算與設計約束">6.14 dependency reliability budget</a>：控制面是最高風險的內部依賴，budget 設計要先處理控制面失效</li> <li><a href="https://tarrragon.github.io/blog/backend/06-reliability/steady-state-definition/" data-link-title="6.22 Steady State Definition" data-link-desc="在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化">6.22 steady state definition</a>：degraded mode 下的穩態需要包含「控制面不可用但資料面仍服務」的定義</li> </ul> <h2 id="引用源">引用源</h2> <ul> <li><a href="https://aws.amazon.com/builders-library/static-stability-using-availability-zones/">Static stability using Availability Zones</a></li> <li><a href="https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/">Avoiding insurmountable queue backlogs</a></li> </ul>Static stability 的責任是讓資料面在控制面故障時仍能維持服務。Constant work pattern 的責任是讓系統在失敗模式下的工作量與正常時相同。兩者共同保護系統在最需要穩定時不會因為自救動作而崩潰。

問題場景

控制面管理路由、配置推送、服務發現與 auto-scaling。當控制面本身失效，依賴控制面的資料面會同時進入未知狀態。最危險的放大路徑是：控制面掛掉後，資料面節點同時嘗試重新連線或重新取得配置，retry storm 把殘餘容量耗盡，資料面跟著崩潰。

這個問題在大規模平台上尤其嚴重。節點越多，控制面恢復時的同時 pull 量越大，恢復本身就會變成新的負載來源。

決策機制

機制 核心問題 設計約束
Static stability 控制面不可用時資料面能否繼續服務 快取的配置必須是完整可用狀態，不能是 partial update
Constant work 失敗模式下的系統工作量是否跟正常時相同 push-based 優於 pull-based：定時推全量，不靠拉取
Pre-computed fallback 控制面失效時是否有不需要即時計算的備援路徑 fallback 路徑預先建好，切換動作本身不依賴控制面

Static stability 的實作核心是讓每個資料面節點持有控制面最後已知的好配置。當控制面恢復通訊時，節點用最新配置更新快取；當通訊中斷時，節點用快取繼續服務。這個設計要求配置快取是完整的（能獨立驅動服務），而不是差分的（需要跟控制面合併才能用）。

Constant work pattern 的核心是讓系統無論在正常或故障狀態下都執行相同的工作量。push-based config distribution 在每個週期推送全量配置給所有節點，不管配置是否有變更。這樣在控制面恢復時，不會因為所有節點同時 pull 而產生 thundering herd。相比之下，pull-based 在正常時流量低，但控制面恢復瞬間流量暴增。

可觀測訊號

訊號 判讀重點 對應章節
control-plane health 控制面是否可用、是否在退化中 4.13
cache staleness 快取配置距離最後更新多久 6.22
recovery work amplification 恢復過程中負載是否比正常時更高 6.14
data-plane autonomous duration 資料面在無控制面時能獨立運作多久 6.7

cache staleness 是 static stability 最關鍵的健康指標。當快取新鮮度超過預設門檻（取決於配置變更頻率），資料面仍能服務，但服務行為可能與最新意圖不一致。這個門檻決定了 degraded mode 的可接受時間窗。

常見陷阱

把控制面失效視為低概率事件而不做 static stability 設計，會在真正發生時暴露循環依賴。Meta 2021-10 事故中，BGP 配置變更導致控制面與資料面共用的網路路徑同時失效，而恢復工具本身也依賴這條路徑，恢復動作陷入循環等待。這個案例說明 static stability 的價值在事前設計，而非事後補救。

下一步路由

引用源

]]>