動機
這是system design primer筆記的最後一篇,講要怎麼把system一步一步scale out 但還是有沒提到的部分,像NoSQL/SQL的實際比較、DB的優化手法比較,這些都是輕描淡寫帶過去而已,儘管如此
建議閱讀順序
先讀 Design a system that scales to millions of users on AWS 再看其他題目
整理
keyword大概的感覺
- API: controller in MVC
- service: functions implmenting bussness logic
evoluation
從single box一步一步把功能分離出來,要注意手法是怎麼與痛點關連起來
其實最核心的想法是把bottleneck分離出來,如果分離出來還不夠,就是多台(水平scale),之後就是自動scale,來省$$
DB的多台就是failover或是replica,還有一種是分割,有 從table去切、從DB去切
最後設計系統就是分析需求,把動詞找出來,變成service,之後開API給使用者呼叫
single box
- web server: DB(structrual&static&tmp) + APP write(real-time&batch) + APP read + Req handle(session data) + SSL
how to scale:
- Vertical Scaling
- Use basic monitoring to determine bottlenecks: CPU, memory, IO, network, etc
- No redundancy/failover
- expensive
separate storage(DB + obejct store)
- pain: MySQL Database taking up more and more memory and CPU resources
- web server: APP write(real-time&batch) + APP read + Req handle + SSL
- DB: DB(structrual&tmp)(write&read)
- obejct store: SQL/NoSQl/S3(static)
Horizontal Scaling & separate APP
- pain: single Web Server bottlenecks during peak hours
- laod balancers: SSL
- web servers: Req handle
- APP writes: APP write(real-time&batch)
- APP reads: APP raed
- DBs: DB(structrual&tmp)(write&read) (active-active or active-passive)
- CDN: proxy server to object store(static)
- obejct store: SQL/NoSQl/S3(static)
how to scale:
- Horizontal Scaling
- multiple instances to handle requests
memory cache & read replicas
- pain: read-heavy
- laod balancers: SSL
- web servers: Req handle
- APP writes: APP write(real-time&batch)
- APP reads: APP raed
- memory cache: memory cache(structrual)
- DBs: DB(structrual&tmp)(write) (active-active or active-passive)
- DBs: DB(structrual&tmp)(read) (active-active or active-passive)
- CDN: proxy server to object store(static)
- obejct store: SQL/NoSQl/S3(static)
memory cache & read replicas
- pain: traffic spikes during regular business hours and drop significantly (cost)
- laod balancers: SSL
- auto-scaling (CPU load, Latency, Network traffic, Custom metric)
- web servers: Req handle
- APP writes: APP write(real-time&batch)
- APP reads: APP raed
- memory cache: memory cache(structrual)
- DBs: DB(structrual&tmp)(write) (active-active or active-passive)
- DBs: DB(structrual&tmp)(read) (active-active or active-passive)
- CDN: proxy server to object store(static)
- obejct store: SQL/NoSQl/S3(static)
how to scale:
- Horizontal Scaling
- multiple instances to handle requests
- Automate DevOps
- Continue monitoring metrics to address bottlenecks
- Host level - Review a single EC2 instance
- Aggregate level - Review load balancer stats
- Log analysis - CloudWatch, CloudTrail, Loggly, Splunk, Sumo
- External site performance - Pingdom or New Relic
- Handle notifications and incidents - PagerDuty
- Error Reporting - Sentry
async write & DB optimization
- pain: DB starts to grow too large & high read&write req
- laod balancers: SSL
- auto-scaling (CPU load, Latency, Network traffic, Custom metric)
- web servers: Req handle
- APP writes: APP write(real-time&batch)
- APP reads: APP raed
- queues: msg queue
- worker services: handle req
- memory cache: memory cache(structrual)
- NoSQL: DB(tmp)
- DBs: DB(structrual)(write) (active-active or active-passive)
- SQL scaling patterns include:
- Federation
- Sharding
- Denormalization
- SQL Tuning
- SQL scaling patterns include:
- DBs: DB(structrual)(read) (active-active or active-passive)
- SQL scaling patterns include:
- Federation
- Sharding
- Denormalization
- SQL Tuning
- SQL scaling patterns include:
- CDN: proxy server to object store(static)
- obejct store: SQL/NoSQl/S3(static)