The WhatsApp Architecture Facebook Bought For $19 Billion
Bài tóm tắt WhatsApp 2014 2. Tăng trưởng Độ khó: Khó
WhatsApp · 2014 · 2. Tăng trưởng · Độ khó: Khó — bài gốc
Nguồn thứ cấp: Todd Hoff (HighScalability) gom từ talk của Rick Reed (2012), phỏng vấn và tài liệu rời rạc; chính tác giả cảnh báo "không biết nhiều về kiến trúc tổng thể". Nhận định ghi "theo WhatsApp qua lời kể của HighScalability". Bỏ qua phần bàn về giá trị thương vụ. Bài ngoài sheet, lấy để bổ sung kiến trúc cho WhatsApp 2012. Phần tiếp (talk 2014 của Rick Reed, cùng HighScalability): WhatsApp 2014.
Bối cảnh (đầu 2014)
- 450 triệu user hoạt động, hơn 1 triệu đăng ký mỗi ngày, 50 tỉ tin nhắn/ngày (vào + ra), với 32 kỹ sư (một kỹ sư trên 14 triệu user). Hàng trăm node, hơn 8.000 core, hàng trăm TB RAM, hơn 70 triệu message Erlang mỗi giây.
- Server gần như toàn bộ là Erlang trên FreeBSD, có patch riêng cho BEAM (máy ảo Erlang); máy phục vụ user là 2 CPU Westmere 6 nhân (24 CPU logic), 100 GB RAM, SSD, hai card mạng (công khai và nội bộ).
Tiến hoá
- Bắt đầu từ ejabberd (server Jabber mã nguồn mở bằng Erlang): chọn vì mở, dễ bắt đầu, và Erlang hợp với hệ liên lạc lớn. Những năm sau viết lại phần lớn: đổi XMPP sang giao thức tự phát triển, tái cấu trúc code, thiết kế lại thành phần lõi, sửa nhiều chỗ trong VM.
- Không lưu tin nhắn trên server lâu dài: tin xếp hàng trên server tới khi client kết nối lại và xác nhận đã nhận; lịch sử chat chỉ nằm trên điện thoại. Media tải lên một HTTP server riêng, tin nhắn chỉ mang link và thumbnail. Danh tính gắn với số điện thoại, theo HighScalability đó là một giới hạn chấp nhận để hệ đơn giản.
- Từ 200K tới 2,8 triệu kết nối mỗi máy (2011–2012): tắc nghẽn đầu tiên ở 425K kết nối: CPU chỉ 35–45% nhưng scheduler bận 95% vì tranh chấp khoá trong VM. Sửa vòng một lên hơn 1 triệu, một tháng sau lên 2 triệu, đỉnh 2,8 triệu (571K gói/giây); thử 3 triệu thì thất bại vì hàng đợi message dồn lại.
- Phần lớn chỗ nghẽn là khoá dùng chung trong VM: khoá time-of-day mà mọi scheduler cùng chạm, bộ cấp phát mseg đơn điểm (tách theo scheduler), bảng check-IO tăng kích thước cộng dồn gây thrash (đổi sang tăng nhân đôi), timer; cộng các chỉnh ở FreeBSD (backport bộ đếm thời gian rẻ và driver card mạng, tăng bảng băm PCB).
- Giảm từ hai process Erlang mỗi kết nối xuống một; tạm dừng GC khi hàng đợi message quá dài vì GC lúc đó làm hệ mất ổn định; chạy BEAM ở mức ưu tiên real-time để cron không chen vào.
- Đo lường: tự viết
wsarthu số liệu OS, phần cứng, BEAM (từ mỗi phút xuống mỗi giây vì sự kiện trong một phút bị che mất),pmcstatcho thấy chỉ 16% thời gian là chạy code Erlang; vá BEAM để có thống kê hàng đợi message theo process ở ba thang suy giảm (1, 10, 100 giây). Độ dài hàng đợi message là chỉ số sức khoẻ chính, có alert theo ngưỡng. - Kiểm thử tải: tải tổng hợp gần như vô dụng ở quy mô này (cần 30 máy để mở đủ cổng cho 1 triệu kết nối, và không tái tạo được hành vi thật theo nước, theo thiết bị, theo sự kiện). Họ rẽ traffic production sang hệ riêng cho phần không có tác dụng phụ, rồi dùng chính tải production (đưa một máy vào DNS vài lần để nhận gấp đôi, gấp ba traffic); hot code loading cho phép đổi code dưới tải thật và xem ngay kết quả.
- Vận hành: đẩy code gần như mỗi ngày, tránh giờ cao điểm; hot loading cho phép cập nhật không cần restart hay chuyển traffic. Chủ ý dư phần cứng cho đỉnh bất thường (một trận bóng đá làm tin gửi đi tăng 35% đúng lúc cao điểm trong ngày); giữ số server ít nhất có thể nhưng để đủ khoảng trống.
Vì sao
- Theo đội WhatsApp, số server nhỏ so với số user phần lớn là nhờ Erlang (mô hình process, khả năng mở rộng SMP gần tuyến tính: 85% CPU trên máy 24 luồng cả ngày). HighScalability lưu ý chính lượng patch và tinh chỉnh khổng lồ làm nhận định này bớt chắc. Facebook Chat cũng viết bằng Erlang năm 2009 nhưng sau bỏ vì khó tuyển người.
Bài học cho SWE
- Scale dọc tới cùng (một máy giữ hàng triệu kết nối) đi kèm việc đọc và vá cả runtime lẫn kernel; nút thắt thường là khoá dùng chung chứ không phải CPU.
- Đo ở độ phân giải giây, theo chỉ số gần với công việc thật (độ dài hàng đợi) hơn là CPU.
- Kiểm thử bằng traffic thật (rẽ nhánh, dồn DNS) khi tải tổng hợp không mô phỏng nổi thế giới thật.
- Một sản phẩm tập trung, ít tính năng giữ được hệ đơn giản đủ để 32 kỹ sư vận hành.
Liên quan
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định)
- Load test và kiểm chứng capacity
- WhatsApp 2012 (bài gốc ngắn về mốc 2 triệu kết nối) · Discord 2017 (cùng BEAM, khác workload)
- Scale dọc trước khi scale ngang · Đổi ngôn ngữ và runtime · Realtime và fan-out
Scale dọc trước khi scale ngangĐổi ngôn ngữ và runtimeRealtime và fan-outKiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định)Load test và kiểm chứng capacity
#Erlang#BEAM patch#FreeBSD#ejabberd#Custom XMPP#2 triệu kết nối/máy#Lock contention#Message queue length#Hot code loading#Tee'd traffic#wsar#pmcstat#Mnesia#Overprovision
Được nhắc tới trong
Chủ đề (5)
Công ty (1)
Bài tóm tắt (2)