動機

這是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
  • DBs: DB(structrual)(read) (active-active or active-passive)
    • SQL scaling patterns include:
      • Federation
      • Sharding
      • Denormalization
      • SQL Tuning
  • CDN: proxy server to object store(static)
  • obejct store: SQL/NoSQl/S3(static)

Ref

source