目的

依據預期壓力所建構的架構才會適配客戶需求情境

為何重要?

1. 預期系統擴展性: 評估使用者增加時，系統如何擴展並處理
2. 驗證提議架構: 預測有助於驗證所提架構是否能處裡預期負荷量
3. 辨別系統瓶頸: 估算有助於在設計階段辨別架構瓶頸，並調整設計
4. 演示構思流程: 估算一系列假設與限制，能依據各方案利弊，有效選擇最佳決策
5. 建立共識
6. 快速決策

評估技巧

1. 經驗法則(rule of thumb)
   評估情境的負荷量可以先以過往經驗作為參考，比如使用者影片串流20mbps
2. 粗估(Approximation)
   基於假設使用者量(1 million)，估算相關使用者產生的負載量(如request/s, bandwidth等等)
3. 問題拆分與整合處理方案(breakdown and aggregation)
   拆分複合問題為小問題，並個別設計方案，以滿足限制與需求。使用者上傳影片需求，可以拆為SQL Scheme，S3保存等問題，分別估算scheme與s3的大小需求。
4. 回顧驗證(Sanity check)
   設計完成後，使用相仿案例的數據，快速驗證估算是否合理。

估算項目

1. Load
   • request per second
   • data volume
   • user traffic
2. Storage
   • SQL database size
   • S3 storage size
3. Bandwidth
   • 基於Load估算可以得出
4. Lantency of response based on the system
5. Resource
   • VMs
   • CPUs
   • Memory

流程

1. 理解範圍，如有多少使用者
2. 基本計算出需要的資源與資料
3. 簡化計算(四捨五入，近似值)
4. 確認估算基於此問題

假設題目為設計一個twitter。
直覺上會有允許使用者發推文、使用者能看到關注推文等基本功能。
我會將每條推文在SQL Scheme中，如timestamp, author_id, context(500字), tweet_id, vedio_uri(100字)等。
那可以直接開發嗎?(可以想一下，我會丟個問題)
Q1: 產品初期目標預期人數是1百萬人，每日約有20%活躍用戶，其中有20%為活躍發文用戶(3 post per day)。
服務要跑一年，需要多大的VM支持SQL，延遲能降到1 millisecond嗎?
SQL bytes of each row: (8 + 36 + 500 + 36 + 100) = 680 bytes
post per day: 10^6 * 0.2 * 0.2 * 3 = 1210^4 post per day = 1.38 post/s
read per day: 10^6 * 0.2 0.8 = 1610^4 read per day = 1.85 read/s
row a year: 4.38 * 10^7 rows
storage a year: 680 bytes * 4.38 * 10^7 =2.9410^10 bytes = 30GB
bandwidth per second: 1.38 * 680 bytes/s + 1.85 * (50 * 680) = 0.1MB/s (假設使用者每次只能看到50篇)
storage price per year: 41.4$/year，依據AWS RDS pricing
IOPS price: 0 (1.38+1.85)10 IOPS < 29.4 * 3 IOPS
SQL lantency: 29.43IOPS / 1000 IOPS/ms = 0.0882ms
答: 可
Storage: 每年SQL實體需要增加30GB。
費用: 41.4$/30GB，跑十年約2277$(6萬台幣)
Lantency: 在限制SQL Select數量下，十年期間SQL lantency會由0.0882ms遞增到1.12ms

Q2: 未來趨勢人數5億人且每日活躍用戶約為99%，可以算一下，很刺激。

系統設計