YouTube Architecture

YouTube · 2007 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Nguồn thứ cấp: HighScalability tóm tắt một talk của YouTube (nguồn ghi "Google Video"); ghi "theo YouTube qua lời kể của HighScalability".

Bối cảnh

• Thành lập 2/2005; 3/2006 30 triệu lượt xem/ngày, 7/2006 100 triệu, với một nhóm rất nhỏ (2 sysadmin, 2 kiến trúc sư scale, 2 dev tính năng, 2 kỹ sư mạng, 1 DBA). Stack: Apache, Python, Linux (SuSE), MySQL, psyco, lighttpd cho video.

Thay đổi chính

• Web: NetScaler cân bằng tải và cache tĩnh, Apache + mod_fastcgi, app server Python; Python không phải nút thắt vì chủ yếu chờ RPC; dưới 100 ms mỗi trang. Cache nhiều tầng: HTML dựng sẵn, cache dòng trong DB, object Python, giá trị tính sẵn đẩy vào bộ nhớ từng app server.
• Video: mỗi video nằm trên một mini-cluster nhiều máy; lighttpd thay Apache (epoll, nhiều process). Video phổ biến đẩy lên CDN; video ít xem (1–20 lượt/ngày) phục vụ từ colo của YouTube, nơi truy cập đĩa ngẫu nhiên kiểu long tail nên cache ít tác dụng, phải tune RAID và bộ nhớ.
• Thumbnail khó hơn video: số lượng gấp khoảng 4, nhiều file nhỏ gây seek, giới hạn file mỗi thư mục của ext3; squid trước Apache từ 300 xuống 20 request/giây khi tải tăng; máy mới dựng mất hơn 24 giờ, reboot mất 6–10 giờ làm ấm cache. Giải bằng BigTable (gom file nhỏ, cache nhiều tầng xuyên colo).
• Database: một server → master + nhiều read slave → partition → shard theo user. Slave đơn luồng tụt sau master; tạm thời tách hai cụm: pool phục vụ xem video được ưu tiên, tính năng mạng xã hội sang cụm kém hơn. Sharding giảm 30% phần cứng và replica lag về 0.
• Data center: từ managed hosting (sống bằng thẻ tín dụng) sang colocation để tự quyết phần cứng và hợp đồng mạng; 5–6 DC cộng CDN.

Vì sao

• Theo bài, vòng lặp "tìm nút thắt, sửa, gặp nút thắt mới" chạy nhiều lần mỗi ngày; ưu tiên thứ cốt lõi (xem video), thuê ngoài thứ không đáng tự làm (CDN).

Bài học cho SWE

• Với workload long tail, thêm cache không cứu được; tối ưu đường đĩa ngẫu nhiên.
• Hàng triệu file nhỏ là bài toán khác hẳn file lớn.
• Replica đọc mua được thời gian nhưng không mua được write; khi lag do slave đơn luồng, shard là bước tiếp.

Liên quan

• Sharding và tách database · Cache và invalidation · Chi phí hạ tầng và build vs buy
• Vitess (YouTube làm) về sau: Vitess 2015