Chuyện của sys

DevOps Blog

Đằng sau hệ thống Stack Overflow trông như thế nào? (Part 2) August 30, 2017

Tiếp tục câu chuyện ở part 1, trong bài viết này sẽ trình bày các thành phần tiếp theo của hệ thống Stack Overflow theo kiến trúc được cập nhật đến năm 2016.
Cache & Pub/Sub (Redis)
SO sử dụng Redis cho 2 việc là caching và pub/sub cho hệ thống, mặc dù chịu tải khoảng 160 tỷ câu lệnh trong vòng 1 tháng, những mỗi instance chỉ chạy khoảng 2% CPU, ở mức rất thấp. (Chắc chỉ tốn RAM).

SO sử dụng Redis làm caching 2 lớp L1/L2, L1 sử dụng cho HTTP Cache cho web server và bất kỳ ứng dụng nào đang chay, còn L2 dùng để lấy giá trị từ Redis, có thể hiểu là L1 dùng để write, còn L2 dùng để read. Giá trị của key trong Redis theo định dạng protobuf thông qua thư viện protobuf-dot-net của Marc Gravell.  Thư viện sử dụng cho client là StackExchange.Redis là một opensource và tự phát triển. Khi mà web server bị miss ở cả 2 L1 và L2, chúng sẽ lấy dữ liệu từ database thông qua query hoặc gọi API…và ghi kết quả vào cache local và Redis, khi đó 1 web server khác muốn lấy giá trị nào đó, có thể miss ở L1 nhưng chắc chắn sẽ lấy được ở L2 hoặc database hoặc thông qua việc gọi API.
Các trang Q&A đều có caching theo dạng key prefix thì đặt ở L1 còn L2 thì chứa database ID.
Bên cạnh 2 server Redis chạy master/slave cho toàn bộ các site hiện có, thì SO còn có thêm 1 server slave machine learning sử dụng cho việc thể hiện các câu hỏi khuyến nghị, job matching …được gọi là Providence.
Server Redis chính thì có 256GB RAM (96GB đã sử dụng) và Providence thì có 384GB RAM (125GB đã sử dụng).
Và tất nhiên không chỉ dùng để caching, SO còn dùng Redis theo cơ chế pub/sub để public 1 message cho toàn bộ subcriber bao gồm đã downstream ở Redis slave, SO dùng cơ chế này để xóa 1 lưu trữ trên L1 của 1 web server khi 1 web server khác bị loại bỏ khỏi tính đồng bộ của hệ thống.

Redis isn’t just for cache though, it also has a publish & subscriber mechanism where one server can publish a message and all other subscribers receive it—including downstream clients on Redis slaves. We use this mechanism to clear L1 caches on other servers when one web server does a removal for consistency, but there’s another great use: websockets.

(Đoạn này hơi rắc rối, mình xin phép để nguyên văn)
NetGain WebSockets
SO sử dụng websocket để push real-time cập nhật  của user ví dụ như các thông báo trên top bar, số lượng vote, hay câu hỏi hay câu trả lời mới và 1 vài thứ khác.
Và các server socket này sử dụng raw socket và chạy trên các web tier sử dụng thư viện StackExchange.NetGain, trong peak time( giờ cao điểm) ,số lượng kết nối đồng thời lên tới 500.000, và có những kết nối kéo dài 18 tháng, tác giả không chắc là người đó có tắt browser của mình hay có còn sống không nữa?

Search (Elasticsearch)
Nói chung là không có điều gì thú vị ở đây cả, SO sử dụng Elasticsearch 1.4 và thư viện StackExchange.Elastic cho client và sử dụng cho đường /search trên website, tính toán các câu hỏi có liên quan, và đề xuất khi đặt câu hỏi.
Mỗi cụm cluster ES đều có 3 node trên từng datacenter , và mỗi site đều đánh 1 index. Như site Careers thì có nhiều index hơn và được cấu hình theo 1 cách khác không theo dạng chuẩn, với 3 cụm cluster lớn hơn với SSD và 192 GB RAM và 2x10GBps cho card mạng.
Lý do chính để sử dụng ES là cho việc tìm kiếm full-text SQL một cách dễ dàng và ít chi phí hơn so với việc sử dụng database SQL. Vậy tại sao lại không dùng Solr thay thế cho ES? Việc này có thể xảy ra trong tương lai với version 2.x.
Databases (SQL Server)
SO sử dụng SQL Server là Single_source_of_truth , mọi dữ liệu trên Redis hay ES đều đến từ database và có 2 cụm cluster SQL Server được cài đặt, với mỗi cluster đều có 1 master và 1 replica ở New York, thêm vào đó là 1 replica ở Colorado, và tất cả các bản sao đều chạy bất đồng bộ.
Cụm đầu tiên bao gồm server Dell R720xd, mỗi con có 384GB Ram, 4TB PCIe SSD và 2×12 cores, chúng chứa Stack Overflow, Sites, PRIZM, và dữ liệu Mobile.
Cụm thứ 2 bao gồm server Dell R730xd, mỗi con có 768GB RAM, 6TB PCIe SSD và 2×8 core, chạy những thứ còn lại, bao gồm Talent, OpenID, Chat, Exception log và toàn bộ các trang Q&A ví dụ Super UserServer Fault
 
Mức sử dụng CPU hiện tại còn khá cao mặc dù đã được optimize, có thể thấy trong biểu đồ sau, với 04 là master, 01 và 03 là replica.
Thư viện
Dưới đây là toàn bộ các thư viện tự phát triển hoặc opensource được sử dụng cho SO.

  • Dapper (.Net Core) – High-performance Micro-ORM for ADO.Net
  • StackExchange.Redis – High-performance Redis client
  • MiniProfiler – Lightweight profiler we run on every page (also supports Ruby, Go, and Node)
  • Exceptional – Error logger for SQL, JSON, MySQL, etc.
  • Jil – High-performance JSON (de)serializer
  • Sigil – A .Net CIL generation helper (for when C# isn’t fast enough)
  • NetGain – High-performance websocket server
  • Opserver – Monitoring dashboard polling most systems directly and feeding from Orion, Bosun, or WMI as well.
  • Bosun – Backend monitoring system, written in Go

 
Sau một bài viết khá dài và chi tiết của tác giả Nick Craver, chúng ta có thể thấy được toàn bộ những gì phía sau của 1 hệ thống website vô cùng đồ sộ và đáp ứng được hàng triệu người dùng trên toàn thế giới. Bài viết của mình xin dừng ở đây và hi vọng sẽ trở lại với việc tìm hiểu những hệ thống lớn khác.

No Comments on Đằng sau hệ thống Stack Overflow trông như thế nào? (Part 2)

Đằng sau hệ thống Stack Overflow trông như thế nào? (part 1)

Không cần phải giới thiệu nhiều về Stack Overflow (SO), bởi vì nó quá nổi tiếng và phổ biến trong cộng đồng developer và có nguyên cụm từ “The full stackoverflow developer” để mô tả những developer sống không thể thiếu website này 😀 System Engineer cũng không ngoại lệ đâu nhé!
Vậy bạn có bao giờ tự hỏi Đằng sau SO là 1 hệ thống được xây dựng như thế nào chưa? Bài viết của Nick Craver, Architecture Lead, Developer, Site Reliability Engineer & DBA Stack Overflow viết năm 2016 trên website của ổng sẽ bật mí cho chúng ta biết phía sau cô gái ấy có gì. Trong bài viết này mình sẽ tóm tắt lại những ý chính trong bài viết trên, chi tiết thì các bạn có thể theo dõi trực tiếp theo link phía trên nhé.
SO là 1 hệ thống khổng lồ, phục vụ hàng triệu người dùng, được thể hiện qua các con số biết nói như sau, số liệu vào năm 2016:

  • 209,420,973 HTTP requests tới gateway ( load balancer)
  • 66,294,789 page loads
  • 1,240,266,346,053  bytes (1.24 TB) HTTP traffic gửi đến
  • 569,449,470,023 bytes (569 GB) tổng nhận
  • 3,084,303,599,266  bytes (3.08 TB) tổng gửi
  • 504,816,843  SQL Queries (từ HTTP requests)
  • 5,831,683,114  Redis hits
  • 17,158,874 Elastic searches
  • 3,661,134 Tag Engine requests
  • 607,073,066 ms (168 hours) xử lý SQL queries
  • 10,396,073 ms (2.8 hours) xử lý Redis hits
  • 147,018,571 ms (40.8 hours) xử lý Tag Engine requests
  • 1,609,944,301  ms (447 hours) xử lý trong ASP.Net
  • 22.71 ms trung bình (19.12 ms trong ASP.Net) cho 49,180,275 truy cập trang câu hỏi
  • 11.80 ms trung bình (8.81 ms trong ASP.Net) cho 6,370,076 truy cập trang home

Thật đáng kinh ngạc, để đạt được những con số này, thật không đơn giản, chúng ta cùng xem nhé. Bắt đầu nào!!
Dưới đây là sơ đồ logic tổng quan của hệ thống SO. Bao gồm:


“Everything is redundant” mọi thứ đều dư thừa là tôn chỉ của SO trong xây dựng hệ thống, luôn luôn là vậy trong mọi cài đặt.

  • Tất cả các server hay thiết bị mạng đều có tối thiểu 2x 10 Gbps cho card mạng.
  • Tất cả các server đều có 2 nguồn cấp điện thông qua 2 hệ thống UPS được hỗ trợ bởi 2 hệ thống cấp điện và 2 nguồn tiện ích khác.
  • Tất cả các server đều có dự phòng giữa 2 rack A và B.
  • Tất cả các server và dịch vụ đều có dự phòng ở datacenter khác (Colorado backup cho New York).

Kết nối Internets

Mỗi request khi truy cập vào trang web, sẽ đến với DNS đầu tiên, ta có thể thấy là stackoverflow.com được trỏ tới 4 ip .69 (có vẻ như mấy ổng thích con số này), truy cập nhanh chóng phục vụ cho toàn bộ user trên toàn thế giới, sử dụng CloudFlare làm DNS, tuy nhiên thì vẫn có những server chạy DNS dự phòng cho trường hợp có sự cố xảy ra.
Sau đó request sẽ đi đến từ 1 trong 4 nhà cung cấp mạng và đi qua 1 trong 4 router tương ứng. SO sử dụng đường truyền thì được cung cấp bởi 4 nhà mạng ISP tại New York đó là Level 3, Zayo, Cogent, và Lightower và sử dụng giao thức BGP để định tuyến. Tiếp đó sử dụng 2 cặp router  ASR-1001  và ASR-1001-X và mỗi cái thì gắn 2 nhà mạng dưới dạng active/active và băng thông của mỗi line là 10Gbps.
Tiếp đó, request sẽ được đón nhận tại load balancer.
Haproxy
Haproxy được dùng làm load balancer, đang chạy version 1.5.15 trên Centos 7 và sẽ sớm chuyển sang version 1.7 có hỗ trợ http/2. Tất cả các traffic TLS(SSL) đều được chặn và xử lý tại đây.
Khác với những server khác, sử dụng 2 interface 10 GBps chạy LACP, thì server LB này có 1 interface dành cho external và 1 dành cho DMZ, có thể giải thích là 1 card public, 1 card private. Với bộ nhớ từ 64GB trở lên để cache lại TLS và SSL.
Việc cài đặt haproxy tương đối đơn giản, chỉ cần bắt đúng Host header và route chúng tới backend dựa trên ip và domain từ DNS.
Web Tier (IIS 8.5, ASP.Net MVC 5.2.3, và .Net 4.6.1)
Load balancer sẽ đá các request xuống 9 web server primary chạy production và 2 server phụ dành cho môi trường dev/staging. Các site trên IIS cụ thể cho 2 môi trường như sau:

Các web server như sau:

Service Tier (IIS, ASP.Net MVC 5.2.3, .Net 4.6.1, and HTTP.SYS)
Phía dưới của các web tier đó chính là các service chạy dưới IIS 8.5 trên Windows 2012 R2. Các serivce này chỉ chạy và xử lý nội bộ và phục vụ cho web server. Có 2 dịch vụ lớn đó là “Stack server” chạy trên HTTP.SYS và Providence API chạy trên IIS.
Mời các bạn theo dõi tiếp ở part 2
Bài viết ở trên còn nhiều trúc trắc do khả năng đọc hiểu của mình còn chưa tốt, nên mong nhận được sự góp ý của mọi người để mình có thể viết tốt hơn. Thanks.

No Comments on Đằng sau hệ thống Stack Overflow trông như thế nào? (part 1)