Tổng quan và góc nhìn sâu sắc về hạ tầng hyperscale của Meta

(cacm.acm.org)

22 điểm bởi GN⁺ 2025-02-12 | 3 bình luận | Chia sẻ qua WhatsApp

Văn hóa kỹ thuật của Meta nhấn mạnh triển khai nhanh, tính cởi mở công nghệ, nghiên cứu trong môi trường production và hạ tầng dùng chung
Để nâng cao năng suất của lập trình viên, công ty áp dụng triển khai liên tục và cho phép nhiều lập trình viên viết hàm serverless thay vì mã dịch vụ truyền thống
Để giảm chi phí phần cứng, Meta tận dụng đồng thiết kế phần cứng-phần mềm ở quy mô trung tâm dữ liệu và tự động tối ưu hóa phân bổ tài nguyên giữa các trung tâm dữ liệu trên toàn cầu thay vì chỉ giới hạn trong từng cụm riêng lẻ
Chiến lược AI của Meta là đồng thiết kế toàn bộ stack, từ PyTorch đến bộ tăng tốc AI, mạng và các mô hình ML như Llama

# [Văn hóa kỹ thuật]

Triển khai nhanh (Move Fast)

Meta duy trì văn hóa "triển khai nhanh" nhấn mạnh tính linh hoạt và lặp lại nhanh
Công ty ủng hộ mạnh mẽ triển khai liên tục (Continuous Deployment) để đưa mã mới nhất lên production nhanh nhất có thể
Các kỹ sư sản phẩm viết hàm serverless không trạng thái bằng các ngôn ngữ như PHP, Python, Erlang
Có thể thay đổi mức độ ưu tiên mà không cần quy trình lập kế hoạch kéo dài, và giải quyết các vấn đề chưa chắc chắn thông qua thực thi lặp lại
Cách làm này cho phép phản ứng nhanh với thị trường và ra mắt sản phẩm kịp thời

Tính cởi mở công nghệ (Technology Openness)

Cởi mở nội bộ: sử dụng cách tiếp cận monorepo để lưu mã của mọi dự án trong một kho lưu trữ duy nhất
- Dễ dàng tìm kiếm mã, tái sử dụng và cộng tác giữa các nhóm
- Trong phần lớn dự án, không có hạn chế nghiêm ngặt về quyền sở hữu mã, nên lập trình viên có thể tự do đóng góp
Cởi mở bên ngoài: tích cực chia sẻ các dự án phần cứng và phần mềm mã nguồn mở
- Công bố thiết kế phần cứng thông qua Open Compute Project
- Vận hành nhiều dự án phần mềm mã nguồn mở như PyTorch, Llama, Presto, RocksDB, Cassandra
- Chia sẻ công nghệ hạ tầng thông qua các bài báo nghiên cứu

Nghiên cứu trong production (Research in Production)

Meta tiến hành nghiên cứu ngay trong môi trường vận hành thực tế mà không cần phòng thí nghiệm hệ thống chuyên biệt
Các nhóm phát triển hệ thống production trực tiếp viết bài báo nghiên cứu để giải quyết vấn đề thực tế và cung cấp các giải pháp đã được kiểm chứng trong môi trường vận hành quy mô lớn
Cách tiếp cận này mang tính thực tiễn và đáp ứng các tiêu chí cốt lõi của nghiên cứu hệ thống thành công

Hạ tầng chung (Common Infrastructure)

Thay vì để từng nhóm tự do lựa chọn stack công nghệ, Meta ưu tiên chuẩn hóa và tối ưu hóa toàn cục
Phần cứng:
- Tất cả máy chủ được cấp phát từ pool máy chủ dùng chung
- Với khối lượng công việc tính toán không phải AI, công ty cung cấp một loại máy chủ duy nhất (về cơ bản là 1 CPU, 256GB DRAM) để giảm độ phức tạp của các loại máy chủ
Phần mềm:
- Trước đây công ty dùng nhiều kho key-value như Cassandra, HBase, ZippyDB, nhưng hiện đã hợp nhất vào ZippyDB
- Triển khai phần mềm, quản lý cấu hình, service mesh, kiểm thử hiệu năng... đều được hợp nhất bằng các công cụ chung
Ưu tiên các thành phần có thể tái sử dụng:
- Xây dựng chuỗi tái sử dụng thành phần gồm Tectonic file system → ZippyDB (lưu trữ metadata) → Shard Manager (quản lý sharding dữ liệu) → ServiceRouter (tra cứu shard và định tuyến yêu cầu) → Delos (kho lưu trữ dữ liệu độ tin cậy cao)
- Thay vì các hệ thống nguyên khối như HDFS, Meta sử dụng các thành phần mô-đun có thể tái sử dụng để tối đa hóa khả năng mở rộng

Nghiên cứu tình huống văn hóa: phát triển ứng dụng Threads (Culture Case Study: The Threads App)

Trường hợp phát triển ứng dụng Threads thể hiện rõ văn hóa kỹ thuật của Meta
Chỉ trong 5 tháng, công việc kỹ thuật đã hoàn tất, và sau thông báo trước 2 ngày, nhóm hạ tầng đã sẵn sàng cho việc triển khai production
Ở hầu hết các tập đoàn lớn, việc viết xong bản kế hoạch dự án chỉ trong hai ngày cũng rất khó. Nhưng Meta đã thiết lập war room để giải quyết vấn đề theo thời gian thực và phản ứng cực nhanh
Kết quả là vượt mốc 100 triệu người dùng chỉ sau 5 ngày ra mắt, trở thành ứng dụng tăng trưởng nhanh nhất trong lịch sử
Threads có thể mở rộng nhanh nhờ tái sử dụng hạ tầng hiện có:
- Backend Python của Instagram
- Hạ tầng dùng chung của Meta (cơ sở dữ liệu social graph, kho key-value, nền tảng serverless, nền tảng ML, quản lý cấu hình ứng dụng di động...)
Cởi mở nội bộ: tận dụng monorepo để tái sử dụng một phần mã của Instagram và tăng tốc phát triển
Cởi mở bên ngoài: hướng tới khả năng tương tác với các ứng dụng khác bằng ActivityPub
Chia sẻ trải nghiệm phát triển: công khai chia sẻ kinh nghiệm phát triển và triển khai nhanh

# [Luồng yêu cầu người dùng đầu-cuối (End-to-End User Request Flow)]

Để xem xét sâu hơn công nghệ hạ tầng của Meta, phần này mô tả toàn bộ quá trình xử lý một yêu cầu từ người dùng
Các sản phẩm của Meta được hỗ trợ bởi hạ tầng dịch vụ dùng chung, bao gồm nhiều thành phần cốt lõi khác nhau

Định tuyến yêu cầu (Request Routing)

Ánh xạ DNS động (Dynamic DNS Mapping)
- Khi người dùng truy cập facebook.com, máy chủ DNS của Meta sẽ động trả về địa chỉ IP của PoP (Point of Presence) gần nhất
- PoP là các trung tâm dữ liệu biên quy mô nhỏ, giúp phân tán tải mạng ở vị trí gần người dùng
- PoP duy trì các kết nối TCP dài hạn với các trung tâm dữ liệu của Meta để giảm thời gian thiết lập kết nối TCP và cải thiện hiệu năng mạng
- Có hàng trăm PoP được triển khai trên toàn thế giới, mang lại độ trễ mạng thấp cho phần lớn người dùng
Bộ nhớ đệm nội dung tĩnh (Static-Content Caching)
- Nội dung tĩnh như hình ảnh, video được cache tại PoP để có thể phục vụ trực tiếp
- Ngoài ra, Meta còn vận hành CDN (mạng phân phối nội dung) và hợp tác với các ISP (nhà cung cấp dịch vụ Internet) để xây dựng các điểm CDN
- Nếu yêu cầu của người dùng là facebook.com/image.jpg, Meta sẽ viết lại thành CDN109.meta.com/image.jpg để phân phối nội dung từ điểm CDN gần đó
- Nếu CDN không có nội dung tương ứng, yêu cầu sẽ được chuyển theo tuyến PoP → bộ cân bằng tải trung tâm dữ liệu → hệ thống lưu trữ
Định tuyến yêu cầu nội dung động (Dynamic-Content Request Routing)
- Các yêu cầu nội dung động như News Feed sẽ được chuyển từ PoP đến trung tâm dữ liệu
- Công cụ traffic engineering sẽ chọn trung tâm dữ liệu tối ưu dựa trên năng lực của trung tâm dữ liệu và độ trễ mạng
- Lưu lượng từ PoP đến trung tâm dữ liệu được truyền qua WAN riêng (mạng diện rộng) của Meta
- Lưu lượng giữa các trung tâm dữ liệu lớn hơn rất nhiều so với lưu lượng giữa người dùng và PoP, do việc sao chép dữ liệu và tương tác giữa các microservice

Cấu trúc liên kết hạ tầng (Infrastructure Topology)

Hạ tầng toàn cầu của Meta được cấu thành từ các thành phần hạ tầng nhiều tầng lớp khác nhau
Mỗi thành phần đảm nhiệm một vai trò cụ thể và được vận hành ở quy mô như sau:
- Vùng trung tâm dữ liệu (Region): Trên toàn thế giới có khoảng 10 vùng trung tâm dữ liệu, và mỗi vùng có thể vận hành tối đa 1 triệu máy chủ
- PoP (Point of Presence, trung tâm dữ liệu biên): Có khoảng hơn 100 PoP, và mỗi PoP thường bao gồm 100~1.000 máy chủ. Chúng xử lý lưu lượng gần người dùng để giảm độ trễ
- CDN site: Có hơn 1.000 CDN site, thường bao gồm từ 10 máy chủ trở lên, và một số site lớn vận hành hơn 100 máy chủ. Chúng cache nội dung tĩnh (hình ảnh, video, v.v.) để phân phối nhanh hơn
- Trung tâm dữ liệu (Datacenter): Mỗi vùng trung tâm dữ liệu có nhiều trung tâm dữ liệu, và mỗi trung tâm dữ liệu có thể vận hành khoảng hơn 100.000 máy chủ
- MSB (bảng chuyển mạch chính, Main Switchboard): Bên trong trung tâm dữ liệu có thể có tối đa 12 MSB, và mỗi MSB phụ trách 10.000~20.000 máy chủ. Chúng đảm nhiệm vai trò phân phối điện năng và là miền lỗi chính trong trung tâm dữ liệu. Nếu MSB gặp sự cố, tối đa 20.000 máy chủ có thể bị ngừng hoạt động
Mạng biên:
- PoP kết nối với nhiều hệ tự trị Internet (AS), và sử dụng BGP (Border Gateway Protocol) để chọn tuyến đường tối ưu
Mạng trung tâm dữ liệu:
- Các máy chủ được kết nối bằng cấu trúc liên kết Clos 3 tầng
- Được thiết kế để ngăn tắc nghẽn mạng và cung cấp băng thông tối đa giữa các máy chủ
Mạng khu vực:
- Các trung tâm dữ liệu được kết nối bằng fabric aggregator, cho phép giao tiếp với WAN
- Sử dụng cấu trúc liên kết Fat-Tree để có thể mở rộng dần theo từng bước

Xử lý yêu cầu (Request Processing)

Xử lý trực tuyến (Online Processing)
- Yêu cầu của người dùng được phân phối qua load balancer đến hàng chục nghìn hàm frontend serverless (FrontFaaS)
- Các hàm frontend có thể gọi nhiều dịch vụ backend, và cũng có thể gọi dịch vụ suy luận ML (ví dụ: gợi ý quảng cáo, gợi ý nội dung News Feed)
- Trong khi thực thi, các hàm frontend thêm sự kiện vào hàng đợi sự kiện để các hàm serverless hướng sự kiện (XFaaS) chạy bất đồng bộ
- Tỷ lệ máy chủ giữa hàm frontend và hàm hướng sự kiện được vận hành ở mức khoảng 5:1
Xử lý ngoại tuyến (Offline Processing)
- Hệ thống xử lý ngoại tuyến hỗ trợ hệ thống trực tuyến, thực hiện phân tích dữ liệu và huấn luyện machine learning
- Các hàm frontend và dịch vụ backend lưu nhiều loại dữ liệu log vào kho dữ liệu
  - Huấn luyện ML: Sử dụng dữ liệu log để cập nhật mô hình machine learning
  - Xử lý luồng: Cập nhật các chủ đề được thảo luận nhiều nhất trên site rồi lưu vào cơ sở dữ liệu và cache
  - Phân tích theo lô: Sử dụng Spark và Presto để cập nhật hệ thống gợi ý kết bạn
  - Thực thi hàm serverless hướng sự kiện: Cập nhật dữ liệu đóng vai trò là trigger sự kiện để tự động chạy các hàm serverless

# [Nâng cao năng suất nhà phát triển (Boosting Developer Productivity)]

Hạ tầng dùng chung của Meta hướng tới tối đa hóa năng suất của nhà phát triển
Để làm được điều đó, Meta khai thác Continuous Deployment và Serverless Functions đến mức tối đa

Continuous Deployment

Meta được tối ưu để triển khai nhanh các thay đổi về mã nguồn và cấu hình (Configuration)
Các tính năng mới và bản sửa lỗi được triển khai ngay lập tức, cho phép phản hồi nhanh và cải tiến lặp lại
Thay đổi cấu hình (Configuration Changes)
- Công cụ quản lý cấu hình của Meta triển khai hơn 100.000 thay đổi thời gian thực mỗi ngày vào production
- Cấu hình được tự động cập nhật trên hơn 10.000 dịch vụ và hàng triệu máy chủ
- Nhiều tác vụ như cân bằng tải, rollout tính năng, A/B testing, chống quá tải, v.v. được thực hiện tự động
- Thay đổi cấu hình được review và commit vào kho mã nguồn như thay đổi mã nguồn, và các thay đổi này được lan truyền tới toàn bộ hệ thống chỉ trong vài giây
Thay đổi mã nguồn (Code Changes)
- Công cụ triển khai của Meta vận hành hơn 30.000 deployment pipeline để quản lý cập nhật phần mềm
- 97% dịch vụ áp dụng triển khai hoàn toàn tự động, được cập nhật mà không cần can thiệp thủ công:
  - 55% sử dụng continuous deployment (CD) hoàn toàn, nên thay đổi mã nguồn được tự động phản ánh vào production
  - 42% được tự động triển khai theo lịch cố định (hàng ngày hoặc hàng tuần)
- Các hàm frontend serverless (FrontFaaS) chạy trên hơn 500.000 máy chủ, và hơn 10.000 nhà phát triển thực hiện hàng nghìn commit mã nguồn mỗi ngày
- Ngay cả trong môi trường năng động như vậy, mọi hàm serverless đều có phiên bản mới được triển khai lên production mỗi 3 giờ
Cập nhật phần mềm mạng và hạ tầng
- Private WAN của Meta duy trì nhiều network plane song song, cho phép kiểm thử độc lập các thuật toán mạng mới
- Phần mềm switch mạng cũng được cập nhật thường xuyên, và tận dụng tính năng "Warm Boot" của switch để cập nhật phần mềm mà không làm gián đoạn lưu lượng mạng
- Mã nguồn được cập nhật thường xuyên và thay đổi cấu hình làm tăng rủi ro sự cố site, vì vậy Meta đầu tư rất nhiều vào kiểm thử, triển khai theo giai đoạn và health check
  - Thực hiện một chiến dịch nội bộ để tăng tự động hóa triển khai mã nguồn từ 12% lên 97%
  - Thực hiện kiểm thử Canary tự động cho mọi thay đổi cấu hình để bảo đảm tính ổn định

Hàm serverless (Serverless Functions)

Hàm serverless (hoặc FaaS, Function-as-a-Service) là một yếu tố cốt lõi khác giúp nâng cao năng suất của nhà phát triển
Khác với các dịch vụ backend truyền thống, hàm serverless không lưu trạng thái và triển khai một giao diện hàm đơn giản
Mỗi lần gọi hàm được thực thi độc lập, và trạng thái được quản lý thông qua cơ sở dữ liệu hoặc hệ thống cache bên ngoài
Ưu điểm của hàm serverless
- Nhà phát triển chỉ cần viết logic sản phẩm mà không phải quản lý hạ tầng
- Tự động triển khai mã và tự động mở rộng (Auto-Scaling) theo biến động tải
- Ngăn lãng phí phần cứng, và nhà phát triển không cần phân bổ tài nguyên quá mức
Nền tảng serverless của Meta
- Trong số hơn 10.000 nhà phát triển của Meta, số người viết hàm serverless nhiều hơn 50% so với số người viết mã dịch vụ truyền thống
- Môi trường phát triển serverless (IDE) của Meta hỗ trợ truy cập dễ dàng vào cơ sở dữ liệu social graph và nhiều hệ thống backend khác nhau, đồng thời cung cấp kiểm thử tích hợp liên tục (CI) để cho phép phản hồi nhanh
Nền tảng serverless của Meta: FrontFaaS và XFaaS
- FrontFaaS: hàm serverless frontend dựa trên PHP, chạy trên hơn 500.000 máy chủ
  - Luôn duy trì runtime PHP để có thể xử lý yêu cầu ngay lập tức mà không gặp vấn đề cold start
  - Khi tải máy chủ thấp, hệ thống dùng auto-scaling để giải phóng một phần máy chủ và tận dụng cho công việc khác
- XFaaS: hàm serverless dựa trên sự kiện chạy bất đồng bộ
  - Xử lý các tác vụ nền không cần phản hồi ngay lập tức
  - Để tránh các tác vụ tải cao, hệ thống trì hoãn thực thi, áp dụng cân bằng tải toàn cầu và throttling dựa trên hạn ngạch
Đổi mới serverless của Meta
- Đã sử dụng phương thức serverless làm mô hình phát triển mặc định từ cuối những năm 2000
- Khác biệt với nền tảng serverless của public cloud:
  - Public cloud sử dụng một máy ảo cho mỗi hàm để đảm bảo mức cô lập mạnh
  - Trong khi đó, Meta thiết kế để nhiều hàm có thể chạy đồng thời trong một tiến trình Linux duy nhất nhằm tối đa hóa hiệu quả phần cứng

# [Giảm chi phí phần cứng (Reducing Hardware Costs)]

Hạ tầng dùng chung của Meta không chỉ nâng cao năng suất của nhà phát triển mà còn đóng vai trò quan trọng trong việc giảm chi phí phần cứng
Để làm được điều này, Meta sử dụng chiến lược tối đa hóa hiệu quả phần cứng thông qua tối ưu hóa phần mềm

Vận hành toàn bộ trung tâm dữ liệu toàn cầu như một máy tính (All Global Datacenters as a Computer)

Trong môi trường cloud truyền thống, người dùng phải tự thiết lập số lượng bản sao dịch vụ (replica), khu vực triển khai, v.v.
Cách quản lý thủ công này gây ra các vấn đề như lãng phí tài nguyên, mất cân bằng tải và thiếu di chuyển giữa các trung tâm dữ liệu
Meta phát triển từ cách tiếp cận hiện có là "vận hành trung tâm dữ liệu như một máy tính" (DaaC, Datacenter as a Computer) để triển khai Global-DaaC, tức "vận hành các trung tâm dữ liệu trên toàn thế giới như một máy tính duy nhất"
Các đặc điểm chính của Global-DaaC:
- Người dùng chỉ cần gửi yêu cầu triển khai toàn cầu, hạ tầng sẽ tự động quyết định số lượng bản sao tối ưu, khu vực triển khai, loại phần cứng và cách định tuyến lưu lượng
- Có thể thay đổi vị trí của dịch vụ khi cần, đồng thời thích ứng với biến động nguồn cung và biến động tải
- Không giống public cloud, Meta tự vận hành toàn bộ ứng dụng nên có thể di chuyển workload linh hoạt hơn
Cách triển khai Global-DaaC
- Tự động hóa phân bổ tài nguyên ở cấp toàn cầu, khu vực và máy chủ riêng lẻ:
  - Công cụ quản lý dung lượng toàn cầu: phân tích sự phụ thuộc giữa các dịch vụ bằng RPC tracing, và dùng lập trình số nguyên hỗn hợp (MIP) để quyết định phân bổ dung lượng tối ưu
  - Công cụ quản lý dung lượng khu vực: phân bổ tài nguyên máy chủ theo từng trung tâm dữ liệu để hình thành cụm ảo (Virtual Cluster)
  - Công cụ quản lý container: đặt container trong cụm ảo, đồng thời phân bố trên nhiều trung tâm dữ liệu để đảm bảo khả năng chịu lỗi (Fault Tolerance)
  - Kỹ thuật quản lý kernel: chia sẻ và cô lập hợp lý tài nguyên bộ nhớ và I/O giữa các container
Các trường hợp áp dụng của Global-DaaC
- Cơ sở dữ liệu và dịch vụ lưu trạng thái:
  - Mỗi container lưu trữ nhiều shard dữ liệu để tối đa hóa hiệu quả
  - Global Service Placer (GSP) quyết định số lượng bản sao shard tối ưu và khu vực размещения
  - Dựa trên đó, framework sharding phân bổ shard vào container và di chuyển động
- Workload machine learning (ML):
  - Tác vụ suy luận ML (Inference) quản lý các bản sao mô hình tương tự như shard dữ liệu
  - Huấn luyện ML (Training) yêu cầu dữ liệu và GPU phải được đặt trong cùng một trung tâm dữ liệu
  - Sau khi nhận phân bổ dung lượng GPU toàn cầu, trình lập lịch huấn luyện ML sẽ thực hiện sao chép dữ liệu và bố trí GPU tối ưu

Đồng thiết kế phần cứng-phần mềm (Hardware and Software Co-Design)

Việc áp dụng đồng thiết kế phần cứng-phần mềm (Co-Design) ở cấp độ một máy chủ đơn lẻ là điều phổ biến, nhưng Meta đã mở rộng điều này lên quy mô toàn cầu để vượt qua giới hạn của phần cứng chi phí thấp bằng tối ưu hóa phần mềm
Khả năng chịu lỗi chi phí thấp (Low-Cost Fault Tolerance)
- Các đám mây công cộng cung cấp phần cứng có độ sẵn sàng cao, nhưng Meta áp dụng cách khắc phục sự cố bằng phần mềm để tận dụng phần cứng rẻ hơn
- Những khác biệt chính:
  - Rack máy chủ của đám mây công cộng sử dụng nguồn điện kép và switch ToR (Top-of-Rack) kép, trong khi Meta sử dụng nguồn đơn và switch ToR đơn
  - Máy ảo (VM) của đám mây công cộng dùng bộ nhớ khối kết nối qua mạng nên có thể live migration, trong khi container của Meta sử dụng SSD cục bộ chi phí thấp
- Chiến lược khắc phục lỗi dựa trên phần mềm:
  - Công cụ phân bổ tài nguyên: phân tán container của dịch vụ và các data shard sang những fault domain khác nhau trong trung tâm dữ liệu
  - Giao thức phối hợp: cho phép ứng dụng can thiệp vào quản lý vòng đời của container, từ đó bảo vệ để các bản sao của data shard không bị gián đoạn cùng lúc
  - Đảm bảo độ bền trên nhiều trung tâm dữ liệu: được thiết kế để dịch vụ vẫn duy trì ngay cả khi cả một khu vực bị ngừng hoạt động, đồng thời thường xuyên kiểm thử thực chiến để xác minh độ tin cậy
Giảm chi phí proxy định tuyến (Eliminating Routing Proxy Costs)
- Service mesh truyền thống sử dụng sidecar proxy để định tuyến các yêu cầu RPC, nhưng Meta xử lý 99% yêu cầu RPC bằng cơ chế định tuyến trực tiếp client-server
- Cách này giúp tiết kiệm khoảng 100.000 máy chủ proxy
- Tuy nhiên, có thách thức là phải biên dịch và triển khai thư viện định tuyến tới hơn 10.000 dịch vụ, nhưng Meta đã giải quyết điều này bằng các công cụ triển khai phần mềm và quản lý cấu hình của mình
Lưu trữ phân tầng và tận dụng SSD cục bộ (Tiered Storage and Local SSDs)
- Phân loại lưu trữ theo tần suất truy cập dữ liệu và yêu cầu độ trễ để tối đa hóa hiệu quả chi phí:
  - Dữ liệu nóng (Hot Data): lưu trong bộ nhớ và SSD (ví dụ: cơ sở dữ liệu social graph)
  - Dữ liệu ấm (Warm Data): lưu trong hệ thống tệp phân tán dựa trên HDD (ví dụ: video, hình ảnh, dữ liệu log)
  - Dữ liệu lạnh (Cold Data): lưu trong các máy chủ HDD dung lượng lớn (ví dụ: video độ phân giải cao cũ)
    - Được duy trì ở chế độ điện năng thấp để giảm chi phí
- Tận dụng SSD cục bộ:
  - Với một số workload, SSD cục bộ cho hiệu năng tốt hơn lưu trữ từ xa dùng chung (Remote Storage)
  - Tuy nhiên, vẫn có rủi ro mức độ sử dụng SSD thấp do phân bổ tải không cân bằng
  - Sử dụng framework sharding dùng chung của Meta để giải quyết vấn đề mất cân bằng và tối đa hóa hiệu quả SSD

Tự thiết kế phần cứng (In-House Hardware Design)

Meta tự thiết kế trung tâm dữ liệu, máy chủ, switch mạng và chip AI để tối ưu chi phí và hiệu quả điện năng
Vì điện năng là tài nguyên hạn chế nhất trong trung tâm dữ liệu, công ty vận hành các công cụ tự động hóa để tối ưu mức tiêu thụ điện
Giảm chi phí và điện năng thông qua đồng thiết kế phần cứng-phần mềm:
- Tối ưu hóa việc sử dụng SRAM của chip AI
- Loại bỏ thiết bị làm mát dùng máy nén trong trung tâm dữ liệu
Meta cũng tự phát triển switch mạng và phần mềm, cho phép cập nhật định kỳ, đồng thời chia sẻ mã nguồn mở phần lớn thiết kế phần cứng của mình thông qua Open Compute Project

# [Thiết kế hệ thống có khả năng mở rộng (Designing Scalable Systems)]

Trong hạ tầng hyperscale, thiết kế hệ thống có khả năng mở rộng là yếu tố cốt lõi
Các hệ thống phân tán được thiết kế cho môi trường Internet (BGP, BitTorrent, DHT, v.v.) có khả năng mở rộng rất tốt, nhưng trong môi trường trung tâm dữ liệu, bộ điều khiển tập trung có thể mang lại khả năng mở rộng và hiệu quả cao hơn

Loại bỏ bộ điều khiển phi tập trung (Deprecating Decentralized Controllers)

Meta chọn hướng chuyển từ bộ điều khiển phi tập trung hiện có sang bộ điều khiển tập trung
Ngoại lệ là switch mạng vẫn duy trì BGP, nhưng được thiết kế để bộ điều khiển tập trung có thể đặt lại tuyến khi xảy ra nghẽn lưu lượng hoặc lỗi liên kết
Bộ điều khiển tập trung cho phép cân bằng tải tốt hơn và phản ứng sự cố nhanh hơn, phù hợp hơn với môi trường trung tâm dữ liệu

Các trường hợp chuyển hệ thống phi tập trung hiện có sang tập trung

WAN riêng (Private WAN)
- Trước đây dùng RSVP-TE (thiết lập tuyến phi tập trung), nhưng đã chuyển sang hệ thống dựa trên bộ điều khiển tập trung
- Tự động tính toán tuyến lưu lượng tối ưu và thiết lập sẵn tuyến dự phòng khi có sự cố để có thể khôi phục nhanh
Kho key-value (Key-Value Store)
- Đã chuyển từ cách dùng định tuyến nhiều bước dựa trên DHT (distributed hash table) sang framework sharding dựa trên bộ điều khiển tập trung
- Bộ điều khiển tập trung điều chỉnh động việc tái phân bố shard để tối ưu cân bằng tải
Phân phối dữ liệu dung lượng lớn
- Trước đây sử dụng BitTorrent (tải xuống P2P phi tập trung), nhưng đã chuyển sang hệ thống phân phối tập trung tên Owl của Meta
- Đường đi tải dữ liệu được quyết định tập trung, giúp cung cấp tốc độ tải nhanh hơn nhiều
Phân phối metadata quy mô nhỏ
- Ban đầu dùng cấu trúc cây phân tán 3 tầng (dựa trên Java), nhưng do vấn đề về khả năng mở rộng nên chuyển sang cấu trúc cây dựa trên P2P
- Tuy nhiên, vì hiệu năng không ổn định của một số nút làm suy giảm hiệu năng toàn hệ thống, cuối cùng đã quay lại kiến trúc máy chủ proxy tập trung hiệu năng cao dựa trên C++

Nghiên cứu trường hợp: service mesh có khả năng mở rộng (Scalable Service Mesh)

Meta vận hành service mesh nội bộ có tên ServiceRouter,
qua hệ thống này, công ty chứng minh hiệu quả của kiến trúc tập trung có khả năng mở rộng.

Vấn đề của kiến trúc service mesh hiện có
- Service mesh thông thường định tuyến yêu cầu RPC thông qua sidecar proxy L7 của từng tiến trình dịch vụ
- Nhưng trong môi trường hyperscale, việc bộ điều khiển tập trung trực tiếp quản lý hàng triệu sidecar proxy là không hiệu quả
- Meta đã chuyển từ mô hình sidecar proxy sang cấu trúc để chính dịch vụ tự xử lý định tuyến
Kiến trúc ServiceRouter của Meta
- Metadata định tuyến được tạo tại bộ điều khiển tập trung, nhưng mỗi bộ định tuyến L7 tự xây dựng bảng định tuyến của riêng mình
- Sử dụng cơ sở dữ liệu dựa trên Paxos (RIB, Routing Information Base) để đảm bảo khả năng mở rộng
  - Sharding bộ điều khiển để phân tán tải, cho phép nhiều bộ điều khiển tính toán song song bảng định tuyến cho một dịch vụ cụ thể
- Tầng phân phối (Distribution Layer) sử dụng hàng nghìn bản sao RIB để xử lý các yêu cầu đọc từ hàng triệu bộ định tuyến L7
- Cuối cùng, mỗi bộ định tuyến L7 có thể được cấu hình độc lập mà không cần bộ điều khiển tập trung can thiệp trực tiếp
Cách ServiceRouter đạt được khả năng mở rộng
1. Áp dụng bộ điều khiển stateless: bộ điều khiển không trực tiếp quản lý từng bộ định tuyến cụ thể mà chỉ duy trì thông tin định tuyến toàn cục
2. Sharding bộ điều khiển: nhiều bộ điều khiển vận hành độc lập với nhau và có thể xử lý song song thông tin định tuyến của các dịch vụ khác nhau
3. Loại bỏ chức năng không thiết yếu: loại bỏ khỏi bộ điều khiển chức năng quản lý từng bộ định tuyến L7 riêng lẻ, và thiết kế để mỗi bộ định tuyến tự quản lý
Kết quả và bài học
- Kiến trúc kết hợp bộ điều khiển tập trung với data plane phân tán mang lại khả năng mở rộng tối ưu
- Tối ưu chi phí vận hành và hiệu năng bằng cách loại bỏ các sidecar proxy không cần thiết
- Thông qua sharding chiến lược và thiết kế stateless, có thể quản lý hiệu quả việc định tuyến cho hàng triệu dịch vụ

# [Triển vọng tương lai (Future Directions)]

Hạ tầng hyperscale của Meta rất phức tạp, nhưng tài liệu này cung cấp bản tóm tắt các insight kỹ thuật cốt lõi
Cuối cùng, chia sẻ triển vọng về các xu hướng tương lai của hạ tầng hyperscale

AI (trí tuệ nhân tạo)

Workload AI hiện đã trở thành loại workload chiếm tỷ trọng lớn nhất trong trung tâm dữ liệu
Dự kiến trước năm 2030, hơn một nửa mức tiêu thụ điện của trung tâm dữ liệu sẽ được dùng cho workload AI
AI có khả năng làm thay đổi căn bản cấu trúc hạ tầng hiện có do mạng hiệu năng cao và mức tiêu thụ tài nguyên lớn
Trước đây, hạ tầng hyperscale phát triển theo mô hình scale-out (Scaling-Out) (triển khai số lượng lớn máy chủ chi phí thấp), nhưng
các cụm AI trong tương lai nhiều khả năng sẽ chuyển sang mô hình scale-up (Scaling-Up) (kiến trúc siêu máy tính)
- Ví dụ: tận dụng mạng Ethernet dựa trên RDMA (Remote Direct Memory Access) để tối ưu cho huấn luyện machine learning (ML) quy mô lớn
Meta đang tiến hành đồng thiết kế full-stack (co-design) bao trùm từ PyTorch → mô hình ML → chip AI → mạng → trung tâm dữ liệu → máy chủ → lưu trữ → điện năng và làm mát

Phần cứng chuyên biệt theo miền (Domain-Specific Hardware)

Trong những năm 2000, phần cứng ngày càng được tiêu chuẩn hóa, nhưng
trong tương lai, nhiều loại phần cứng chuyên biệt cho huấn luyện/suy luận AI, ảo hóa, mã hóa video, mã hóa, nén, bộ nhớ phân tầng và các tác vụ khác sẽ gia tăng
Các công ty hyperscale có thể thiết kế và triển khai phần cứng tùy biến một cách kinh tế nhờ sản xuất số lượng lớn
Tuy nhiên, sự gia tăng đa dạng phần cứng này sẽ làm độ phức tạp của software stack tăng lên, đồng thời tạo ra thách thức trong việc quản lý môi trường dị biệt

Trung tâm dữ liệu biên (Edge Datacenters)

Do sự gia tăng của các ứng dụng metaverse và Internet vạn vật (IoT), việc mở rộng các trung tâm dữ liệu biên được dự báo sẽ diễn ra
Cloud gaming thực hiện dựng hình đồ họa trên máy chủ GPU tại trung tâm dữ liệu biên thay vì trên thiết bị của người dùng, và
độ trễ mạng thấp dưới 25ms là điều bắt buộc
Khi số lượng ứng dụng đòi hỏi khả năng phản hồi thời gian thực tăng lên, số lượng và quy mô của các trung tâm dữ liệu biên nhiều khả năng sẽ tăng mạnh
Để vận hành hiệu quả, cần mở rộng Global-DaaC (khái niệm vận hành các trung tâm dữ liệu trên toàn cầu như một máy tính duy nhất) để tối ưu hóa sao cho các nhà phát triển không phải bận tâm đến việc quản lý hạ tầng phức tạp

Nâng cao năng suất của nhà phát triển (Developer Productivity)

Trong 20 năm qua, các công cụ tự động hóa đã cải thiện đáng kể năng suất của quản trị viên hệ thống, khiến tỷ lệ số máy chủ mà mỗi quản trị viên phụ trách tăng vọt
Tuy nhiên, phát triển phần mềm vẫn mang tính thâm dụng lao động và mức cải thiện năng suất còn chậm
Trong tương lai, năng suất của nhà phát triển được dự báo sẽ tăng mạnh nhờ hai yếu tố:
1. Sự phát triển của các công cụ tạo mã và gỡ lỗi dựa trên AI
2. Sự xuất hiện của mô hình lập trình serverless tích hợp hoàn chỉnh, chuyên biệt theo miền
FrontFaaS của Meta là một ví dụ cho cách lập trình serverless này, và
trong tương lai, các mô hình lập trình mới được tối ưu cho những ngành cụ thể (ví dụ: tài chính, y tế, v.v.) được dự đoán sẽ xuất hiện

Kết luận

Đổi mới hạ tầng lấy AI làm trung tâm sẽ tiến triển nhanh trong 10 năm tới
Các công ty hyperscale cần đóng góp để toàn bộ cộng đồng có thể phát triển nhanh hơn bằng cách chia sẻ insight của mình

3 bình luận

secret3056 2025-02-13

PoP kia chắc là BGP4 hoặc TCP anycast, và có lẽ cá nhân cũng không có cách nào để sử dụng nó đúng không..? T_T

pribess 2025-02-13

Tôi không rõ chính xác mô tả PoP là BGP4 hay TCP anycast có ý gì, nhưng nếu ý là có tự vận hành AS riêng hay không thì là đúng.
Thông thường, các dịch vụ multi-region phổ biến sẽ chủ yếu dùng anycast DNS kết hợp với cân bằng tải dựa trên geolocation.
Vâng, hiện tại thì chưa có. Nếu bạn cần PoP multi-region thì có thể dùng nhà cung cấp khác.

GN⁺ 2025-02-12

Ý kiến trên Hacker News

Sau khi phát triển Threads, đội hạ tầng chỉ được báo trước đúng hai ngày để chuẩn bị ra mắt. Phần lớn các tổ chức lớn thậm chí còn mất hơn hai ngày chỉ để lập kế hoạch cho một dự án có hàng chục đội phụ thuộc lẫn nhau. Nhưng tại Meta, họ nhanh chóng dựng các war room ở nhiều địa điểm phân tán để đội hạ tầng và đội sản phẩm xử lý sự cố theo thời gian thực. Ứng dụng này đạt 100 triệu người dùng chỉ sau 5 ngày ra mắt, trở thành ứng dụng tăng trưởng nhanh nhất trong lịch sử
Khả năng duy trì việc đưa sản phẩm ra mắt nhanh như vậy thật ấn tượng. Cần rất nhiều nỗ lực để không làm bộ máy quan liêu phình to, và để pháp chế hay các bộ phận khác không tạo ra các cổng phê duyệt. Hoặc cần có khả năng dùng war room để hoàn thành công việc thật nhanh
Khi còn ở FB, tôi đã trực tiếp thấy hạ tầng ở đó mạnh đến mức nào. Các kỹ sư sản phẩm xây dựng những dự án quy mô lớn chỉ trong vài ngày. Tôi từng là tech lead của nhiều đội, trong đó có một số đội được nhắc tới ở đây như HBase và ZippyDB
Thật hay khi ZippyDB lần đầu tiên được nhắc đến công khai. Việc cải thiện hiệu suất làm việc của lập trình viên cũng được nhắc tới, điều đó cũng rất tuyệt. Mỗi ngày có 10.000 service được push, hay nói cách khác là mọi commit đều được triển khai
Sau khi rời FB, tôi không tìm thấy thứ gì tương tự. Vì vậy tôi đang xây dựng hạ tầng mà mình từng cần cho startup của mình. Batteries Included
Thật tiếc khi có quá nhiều sự mỉa mai và phản ứng tiêu cực trong các bình luận này. Nhiều người ghét Meta, nhưng bản thân bài viết thực sự khiến tôi kinh ngạc. Tôi không hề biết hạ tầng chống đỡ thế giới số hiện đại lại rộng lớn và phức tạp đến vậy. Đọc bài này và nhìn thấy quy mô đó thật đáng kinh ngạc
Công ty có thể tệ trên nhiều phương diện, nhưng mọi thứ trong bài viết vẫn khiến tôi kinh ngạc
Tôi không phải kỹ sư như các bạn nên có thể bài này là chuyện cũ với các bạn, nhưng tôi vẫn không thể không thốt lên rằng "wow"
Nếu đưa bài này cho các nhà văn khoa học viễn tưởng ngày trước xem, có lẽ họ cũng sẽ thấy kinh ngạc
Thật đáng kinh ngạc. Tất cả công nghệ tuyệt vời, ấn tượng này cùng những kỹ sư giỏi nhất thế giới lại chỉ được dùng để nhét thêm quảng cáo vào trước mắt mọi người. Thở dài
Thật thú vị khi mô tả web frontend PHP là kiến trúc "serverless" hoặc "function as a service". Có vẻ đây là vấn đề góc nhìn. Đây là một service với một codebase duy nhất được triển khai ra nhiều endpoint. Từ góc nhìn của người bảo trì endpoint thì có thể là "serverless", nhưng như mọi abstraction khác, nó vẫn bị rò rỉ
Trong môi trường datacenter, tôi thích controller tập trung vì tính đơn giản và khả năng ra quyết định chất lượng cao. Trong nhiều trường hợp, cách tiếp cận hybrid kết hợp control plane tập trung với data plane phân tán là tối ưu nhất
Cách tiếp cận này có vẻ là một trong những thiết kế tối ưu nhất cho software networking (service mesh) và storage (vận hành cơ sở dữ liệu) ở các tổ chức có số lượng máy chủ rất lớn. Điều đáng ngạc nhiên là mạng IP lại không chủ yếu dựa vào BGP mà đi theo cùng một mô hình
Tôi đoán họ sẽ dùng local caching để giảm tải cho router L7 và cải thiện độ trễ của truy vấn cơ sở dữ liệu. Client có thể invalidate cache rồi truy vấn lại service mesh sau một khoảng timeout hợp lý
Các hàm serverless được phát triển nhanh kết hợp với continuous deployment, trong đó ai cũng có thể chỉnh sửa toàn bộ codebase, nghe như một cơn ác mộng phản địa đàng. Lượng logging cần thiết để debug và tìm bug chắc hẳn là cực kỳ khủng khiếp
Việc dùng Erlang để viết hàm serverless dường như né tránh mọi lợi thế lớn mà BEAM có thể mang lại
Các kỹ sư sản phẩm chủ yếu viết code bằng PHP, Python và Erlang dưới dạng các hàm serverless không trạng thái. Điều này có lợi về tính đơn giản, năng suất và tốc độ lặp
Để nâng cao năng suất lập trình viên, Meta áp dụng continuous deployment trên toàn bộ hệ thống, đồng thời cho phép nhiều lập trình viên viết hàm serverless hơn thay vì code service truyền thống
Với các tác vụ tính toán không phải AI, họ chỉ cung cấp một loại server duy nhất, trang bị một CPU và cùng một lượng DRAM (trước đây là 64GB, hiện là 256GB). Tôi tự hỏi đây có phải là thông lệ chung trong toàn ngành hay chỉ phổ biến ở Meta
Khi hình ảnh chưa được cache tại CDN109, nếu người dùng yêu cầu thì CDN109 sẽ chuyển tiếp yêu cầu tới PoP gần đó. PoP sẽ chuyển yêu cầu tới load balancer trong khu vực datacenter, và load balancer sẽ lấy hình ảnh từ hệ thống storage
Khi yêu cầu một ảnh 1MB, liệu việc phục vụ ảnh 1MB qua một kết nối chậm với độ trễ 100ms có nhanh hơn việc phải đi qua nhiều vòng round-trip và độ trễ tăng dần không?
Giả sử yêu cầu đi qua hệ thống của Meta thì cuối cùng vẫn tới cùng một datacenter, và giả sử không có công nghệ FTL
Việc so sánh tường minh với các hyperscaler đặc biệt thú vị. Tôi tự hỏi liệu họ có đang chuẩn bị tung ra public cloud của riêng mình hay không. Mong ai đó ở Meta cho ý kiến