Scale dọc trước khi scale ngang

Bài toán

Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.

Diễn tiến theo thời gian

• 2004→2010 · Facebook (Meta): mỗi trường đại học một DB → social graph liên trường → Memcache đỡ tải DB → xây TAO và nhiều hệ cache → hết đường scale phần mềm thì xuống tầng vật lý (DC riêng, edge cạnh ISP, backbone). Meta 2025
• 2007 · PlentyOfFish: (Qua HighScalability) Một người vận hành 1,2 tỉ page view/tháng trên 2 web server và 3 DB server; "RAM giải quyết mọi vấn đề", đến 2009 máy DB 512 GB RAM, 32 CPU. PlentyOfFish 2007
• ~2008→2019 · GitHub: liên tục "chuyển sang máy mới hơn, to hơn" cho mysql1, cho tới khi rủi ro một điểm hỏng buộc họ phải tách. GitHub 2021
• 2011 · Instagram: ba nguyên tắc: đơn giản, không phát minh lại, dùng đồ đã kiểm chứng. App stateless scale ngang dễ, còn DB thì giữ working set trong RAM vì EBS không đủ seek. PgBouncer được nhắc là thay đổi có tác động lớn. Instagram 2011
• 2011→2014 · WhatsApp (qua HighScalability): từ 200K lên 2,8 triệu kết nối mỗi máy (24 luồng, 100 GB RAM): nút thắt là tranh chấp khoá trong BEAM (khoá time-of-day, bộ cấp phát đơn điểm) chứ không phải CPU; vá cả BEAM lẫn FreeBSD, đo mỗi giây. Đầu 2014: 450 triệu user, 50 tỉ tin/ngày, 32 kỹ sư. WhatsApp 2014
• 2012 · WhatsApp: một server FreeBSD + Erlang giữ 2,28 triệu kết nối TCP mà CPU còn ~42% idle; chủ yếu nhờ nâng giới hạn kernel. WhatsApp 2012
• 2013 · Instagram: từ 90 lên hơn 10.000 like/giây vẫn trên Postgres nhờ: partial index (query 215ms → 3ms), functional index (index nhỏ 10 lần), pg_reorg để compact, WAL-E để backup/dựng replica, autocommit cho query chỉ đọc (trả connection về PgBouncer sớm). Instagram 2013
• 2013 · Stack Overflow: 148 triệu request/ngày (11/2013) trên 11 web server và 4 SQL Server, nhưng theo Nick Craver chỉ cần 2 web, 2 SQL, 1 Redis; web 5–15% CPU, SQL 5–10%. SQL Server 384 GB RAM; DB nằm gọn trong RAM nên đĩa có tỉ lệ đọc/ghi 40:60. Stack Overflow 2013
• 2014 · Booking.com: scale đọc bằng hàng nghìn slave MySQL nên crash slave là chuyện thường. Crash-safe replication của MySQL 5.6 tải lại binlog từ master mỗi lần khởi động, đè lên card mạng master (slave delayed giữ hàng chục GB); họ đặt Binlog Server cục bộ trên mỗi slave để phục hồi không chạm master. Booking.com 2014
• 2014→2023 · LinkedIn: Profile hơn 99% là đọc: Oracle → Espresso (2014, mở rộng bằng thêm node tới 1,4 triệu QPS) → Couchbase làm tầng cache trong storage khi Espresso chạm trần; đỉnh 4,8 triệu profile/giây (2023). LinkedIn 2023
• 2015 · Shopify: "không còn mua được server DB to hơn" là lúc buộc phải shard. Shopify 2018
• 2015 · LinkedIn (nhìn lại, năm không nêu): DB profile bị monolith Leo dồn tải: scale dọc trước, rồi replica chỉ đọc đồng bộ bằng bản đầu của Databus, kèm logic biết lúc nào đọc replica là an toàn. Theo LinkedIn master/slave chỉ là giải pháp trung hạn; về sau chuyển sang DB phân vùng. LinkedIn 2015
• 2016 · Stack Overflow: 209 triệu request/ngày, trang câu hỏi trung bình 22,7ms; thực tế chỉ cần 1 web server. So với 2013: thêm 61 triệu request/ngày mà tổng thời gian xử lý giảm (757 → 447 giờ) nhờ phần cứng mới và tối ưu code. Redis ~160 tỷ op/tháng dưới 2% CPU. Stack Overflow 2016
• 2016 · Stack Overflow: phụ lục phần cứng: SQL 384–768 GB RAM với SSD NVMe, 11 web server 64 GB, Redis 256 GB; mỗi máy được chọn cấu hình riêng cho đúng việc của nó (scale up hay scale out, loại SSD, ít nhân nhanh hay nhiều nhân chậm). Stack Overflow 2016
• 2017 · Instagram: tắt GC của CPython (gc.set_threshold(0) + os._exit khi thoát) giúp tiết kiệm 8GB RAM mỗi máy và ~10% capacity toàn cầu, không phải viết lại. Instagram 2017
• 2018 · OpenAI: scale một cụm Kubernetes là chuỗi nút cổ chai lần lượt lộ ra: khoảng 500 node thì etcd chậm vì ổ mạng (chuyển sang SSD cục bộ: 2 ms → 200 µs), khoảng 1.000 node thì agent giám sát quá tải API server, rồi etcd chạm giới hạn 2 GB, KubeDNS dồn một máy, ARP cache đầy. OpenAI 2018
• 2018 · Alibaba: với storage dùng chung, thêm read node không cần copy toàn bộ dữ liệu, chỉ đồng bộ metadata redo log; khác read replica binlog phải nhân bản cả dữ liệu và trễ theo replication đơn luồng (theo Alibaba). Alibaba 2018
• 2019 · Figma: "điều khiến người ta sốc nhất": cả Figma chạy trên một DB instance, máy mạnh nhất của AWS, theo nguyên tắc KISS. Họ đã thấy sắp chạm trần. Figma 2019
• 2019→2021 · Wix: hàng triệu site, HTML gần như tĩnh: cache nhiều tầng (proxy riêng ở nhiều region → trình duyệt → CDN), Brotli giảm 21–25% kích thước truyền; tỉ lệ site đạt Core Web Vitals tăng 10 lần trong một năm (theo Wix). Wix 2021
• 2019 · Stack Overflow: Redis 2 máy 256 GB, dùng dưới 96 GB, CPU trung bình 2% cho 308 triệu HTTP hit/ngày (7/2019); không dùng Redis Cluster vì cần ≥3 node trong khi một máy đã dư sức. Stack Overflow 2019
• 2020 · Figma: một RDS Postgres lên máy lớn nhất (r5.12xlarge → r5.24xlarge), mua thêm ~1 năm, rồi mới tách. Theo Figma: nếu DB bão hoà hoàn toàn thì sản phẩm ngừng. Figma 2023
• 2020 · Wix: service MetaSite bị đọc hơn 1 triệu request/phút: stream dữ liệu lên Kafka, dựng materialized view riêng cho một nhu cầu (Installed Apps) trong service chỉ-đọc, scale bằng replica ở nhiều data center. Wix 2020
• 2020 · LinkedIn (HDFS): một NameNode (1 tỷ object, heap 380 GB) chạm trần CPU; 95% thao tác là đọc nên thêm Observer (Standby phục vụ đọc) mà vẫn nhất quán mạnh: client mang LastSeenStateId trong header RPC, Observer chờ tới state đó; msync() cho trường hợp một bên thứ ba báo tin; JournalNode cache transaction trong RAM để Observer chỉ trễ 25–30 ms. Throughput namespace gấp 3, latency còn một phần ba (bài 2021). LinkedIn 2021
• 2021–2022 · Dropbox: host chứa 1,5–2 PB thì một SSD cache làm trần throughput ghi; bỏ hẳn SSD, ghi thẳng SMR, throughput toàn fleet +15–20% mà không thêm máy. Mật độ mỗi máy tăng thì nút thắt dời chỗ. Dropbox 2022
• 2021→2025 · DuckDB: vắt kiệt một máy cho sort: 2021 chuẩn hoá khoá + radix sort, gộp song song bằng Merge Path, tràn đĩa qua buffer manager; 2025 viết lại trên layout tràn đĩa chung với join/aggregation, đổi sang k-way merge (ít I/O khi vượt RAM): sort 1 tỉ số ngẫu nhiên nhanh 2,7 lần, bảng rộng vượt RAM nhanh hơn 3 lần. DuckDB Labs 2021 DuckDB Labs 2025
• 2021 · Stack Overflow: cái giá của tối ưu hiệu năng triệt để: theo bài, static field và memoization giảm GC nhưng làm code khó test; "best practice không phải bắt buộc", nhưng điều kiện thay đổi thì phải xem lại. Stack Overflow 2021
• 2022 · Gojek: đẩy đọc geo sang replica Redis Cluster vướng việc EVAL (Lua) luôn bị coi là lệnh ghi nên đi về master; Gojek đề xuất EVAL_RO lên Redis (được chấp nhận) và sửa go-redis. Mỗi query chia thành nhiều vùng nhỏ chạy song song trên nhiều replica, hết timeout thì trả kết quả một phần; đạt 200.000 lượt tìm/phút. Gojek 2022
• 2024 · Dropbox: QPS đọc metadata sắp vượt sức máy storage (Panda); cache nhất quán Chrono cho phép đọc linearizable từ follower bằng snapshot tại timestamp thử ghi gần nhất, nên phần lớn đọc rời khỏi leader. Dropbox 2024
• 2026 · Upstash: đọc từ replica chỉ khi replica đã áp lần ghi mới nhất của chính client (không thì chuyển sang primary), nên có read-your-writes kể cả khi đọc ở AZ khác; proxy đặt cạnh replica để đọc cục bộ, giảm phí xuyên AZ. Theo Upstash. Upstash 2026
• 2026 · Trigger.dev: query dashboard nặng tranh RAM với merge nền của ClickHouse và góp phần gây sự cố; tách instance ClickHouse chỉ đọc cho runs list và log. Trigger.dev 2026
• 2026 · Canva: read replica được thêm để chịu tải đọc do chính hệ thống tạo ra (gateway nạp cache khi deploy). Chuyển phần nạp hàng loạt sang object storage, chỉ còn 2 replica để dự phòng. Canva 2026
• 2026 · GitHub: "đọc dễ scale, ghi khó hơn nhiều": thêm replica đầy đủ để đỡ đọc làm mọi push chậm đi; tách năng lực đọc sang worker nhẹ có cache trên một lớp storage bền, để spike đọc (CI fan-out, đội agent, clone lớn) không thêm việc cho ghi. GitHub 2026
• 2026 · Kubernetes: mọi controller đọc từ bản sao trong bộ nhớ cập nhật bằng watch thay vì gọi API server mỗi lần reconcile; hàng đợi theo key có gộp biến bão sự kiện thành ít lần reconcile. Kubernetes 2026

Quy tắc rút ra

1. Đo trước, tối ưu đúng điểm nghẽn, rồi mới phân tán. Instagram dùng perf để tìm thủ phạm; Stack Overflow đo mọi request bằng MiniProfiler.
2. Runtime hợp bài toán nhân sức chứa mỗi máy (Erlang cho kết nối dài, xem Đổi ngôn ngữ và runtime).
3. Trần thật của scale dọc thường là database. Khi chạm trần thì sang Sharding và tách database (GitHub, Figma).
4. Theo dõi khoảng cách tới trần và hành động trước khi chạm (Figma bắt đầu ở 65% CPU).
5. Scale dọc không có nghĩa là một máy duy nhất. Stack Overflow vừa scale dọc vừa dư thừa theo chiều ngang ở mức hạ tầng (xem dưới).
6. Scale đọc bằng thêm bản sao đầy đủ có giới hạn khi mọi bản sao tham gia mọi lần ghi; đọc fan-out lớn (CI, agent) nên đi qua lớp cache tách khỏi lớp bền (GitHub 2026). GitHub 2026

Trả lời câu hỏi cũ: scale dọc thì xử lý một điểm hỏng thế nào?

Theo Stack Overflow (2016): "mọi thứ đều dư thừa": mỗi server có cặp ở rack còn lại, 2 nguồn điện/UPS/máy phát, 4 ISP, SQL Server AlwaysOn với replica ở New York và ở data center DR (Colorado), cả hệ thống nhân đôi ở Colorado. Web tier cố ý cấp dư (11 máy dù chỉ cần 1) cho rolling build và headroom. Stack Overflow 2016

Câu hỏi mở

• Thời gian failover thực tế sang Colorado của Stack Overflow là bao lâu? Bài 2016 không nói. Xem thêm Độ tin cậy và multi-region.