Cách chúng tôi đang làm cho cơ sở hạ tầng của Roblox trở nên hiệu quả và bền bỉ hơn

Trong hơn 16 năm qua, cùng với sự phát triển của Roblox, quy mô và độ phức tạp của cơ sở hạ tầng kỹ thuật hỗ trợ hàng triệu trải nghiệm 3D nhập vai cũng tăng lên theo. Số lượng máy mà chúng tôi hỗ trợ đã tăng gấp ba lần trong hai năm qua, từ khoảng 36.000 vào ngày 30 tháng 6 năm 2021 lên gần 145.000 hiện nay. Để hỗ trợ các trải nghiệm luôn hoạt động cho người dùng trên toàn thế giới, chúng tôi cần hơn 1.000 dịch vụ nội bộ. Để kiểm soát chi phí và độ trễ mạng, chúng tôi triển khai và quản lý các máy chủ này trong một hạ tầng đám mây riêng lai được tùy chỉnh, chủ yếu vận hành tại chỗ.  

Hạ tầng của chúng tôi hiện đang hỗ trợ hơn 70 triệu người dùng hoạt động hàng ngày trên toàn thế giới, bao gồm cả các nhà sáng tạo dựa vào nền kinh tế của Roblox cho hoạt động kinh doanh của họ. Tất cả những người dùng này đều mong đợi mức độ tin cậy rất cao. Do tính chất đắm chìm của các trải nghiệm của chúng tôi, độ trễ hoặc gián đoạn là điều không thể chấp nhận được, huống chi là sự cố ngừng hoạt động. Roblox là nền tảng giao tiếp và kết nối, nơi mọi người tụ họp trong các trải nghiệm 3D đắm chìm. Khi mọi người giao tiếp dưới dạng avatar trong không gian đắm chìm, ngay cả những trễ nhỏ hay sự cố kỹ thuật cũng dễ nhận thấy hơn so với trên một cuộc trò chuyện văn bản hay cuộc gọi hội nghị.

Vào tháng 10 năm 2021, chúng tôi đã trải qua một sự cố ngừng hoạt động trên toàn hệ thống. Sự cố bắt đầu từ một vấn đề nhỏ trong một thành phần tại một trung tâm dữ liệu. Tuy nhiên, nó lan rộng nhanh chóng trong quá trình chúng tôi điều tra và cuối cùng dẫn đến sự cố ngừng hoạt động kéo dài 73 giờ. Lúc đó, chúng tôi đã chia sẻ chi tiết về sự cố cũng như một số bài học ban đầu từ sự kiện này. Kể từ đó, chúng tôi đã nghiên cứu những bài học này và nỗ lực tăng cường khả năng chống chịu của hạ tầng trước các sự cố thường xảy ra trong các hệ thống quy mô lớn do các yếu tố như đỉnh lưu lượng đột biến, thời tiết, hỏng hóc phần cứng, lỗi phần mềm hoặc đơn giản là sai sót của con người. Khi các sự cố này xảy ra, làm thế nào để đảm bảo rằng một vấn đề trong một thành phần, hoặc nhóm thành phần, không lan rộng ra toàn bộ hệ thống? Câu hỏi này đã là trọng tâm của chúng tôi trong hai năm qua và mặc dù công việc vẫn đang tiếp diễn, những gì chúng tôi đã làm cho đến nay đã bắt đầu mang lại kết quả. Ví dụ, trong nửa đầu năm 2023, chúng tôi đã tiết kiệm được 125 triệu giờ tương tác mỗi tháng so với nửa đầu năm 2022. Hôm nay, chúng tôi chia sẻ những công việc đã thực hiện, cũng như tầm nhìn dài hạn của chúng tôi trong việc xây dựng một hệ thống hạ tầng bền vững hơn.

Xây dựng hệ thống dự phòng

Trong các hệ thống cơ sở hạ tầng quy mô lớn, các sự cố quy mô nhỏ xảy ra nhiều lần trong ngày. Nếu một máy gặp sự cố và phải ngừng hoạt động, điều đó vẫn có thể xử lý được vì hầu hết các công ty đều duy trì nhiều phiên bản dịch vụ back-end. Vì vậy, khi một phiên bản gặp sự cố, các phiên bản khác sẽ đảm nhận khối lượng công việc. Để giải quyết các sự cố thường xuyên này, các yêu cầu thường được thiết lập để tự động thử lại nếu gặp lỗi.

Điều này trở nên thách thức khi hệ thống hoặc người dùng thử lại quá quyết liệt, điều này có thể trở thành nguyên nhân khiến các sự cố quy mô nhỏ lan rộng khắp hạ tầng sang các dịch vụ và hệ thống khác. Nếu mạng hoặc người dùng thử lại một cách kiên trì đủ lâu, cuối cùng sẽ làm quá tải mọi bản sao của dịch vụ đó, và có thể cả các hệ thống khác, trên toàn cầu. Sự cố ngừng hoạt động năm 2021 của chúng tôi là kết quả của một hiện tượng khá phổ biến trong các hệ thống quy mô lớn: Một sự cố bắt đầu từ quy mô nhỏ rồi lan truyền khắp hệ thống, trở nên nghiêm trọng đến mức khó có thể khắc phục trước khi toàn bộ hệ thống sập. 

Vào thời điểm xảy ra sự cố ngừng hoạt động, chúng tôi chỉ có một trung tâm dữ liệu đang hoạt động (với các thành phần bên trong đóng vai trò dự phòng). Chúng tôi cần khả năng chuyển đổi thủ công sang một trung tâm dữ liệu mới khi một sự cố khiến trung tâm hiện tại ngừng hoạt động. Ưu tiên hàng đầu của chúng tôi là đảm bảo có một bản triển khai dự phòng của Roblox, vì vậy chúng tôi đã xây dựng bản dự phòng này tại một trung tâm dữ liệu mới, nằm ở một khu vực địa lý khác. Điều này cung cấp lớp bảo vệ cho tình huống xấu nhất: sự cố lan rộng đến đủ các thành phần trong một trung tâm dữ liệu khiến nó trở nên hoàn toàn không thể hoạt động. Hiện tại, chúng tôi có một trung tâm dữ liệu xử lý tải công việc (hoạt động) và một trung tâm dữ liệu dự phòng (chờ sẵn). Mục tiêu dài hạn của chúng tôi là chuyển từ cấu hình chủ động-thụ động này sang cấu hình chủ động-chủ động, trong đó cả hai trung tâm dữ liệu đều xử lý khối lượng công việc, với bộ cân bằng tải phân phối các yêu cầu giữa chúng dựa trên độ trễ, dung lượng và tình trạng hoạt động. Khi điều này được thực hiện, chúng tôi kỳ vọng sẽ có độ tin cậy cao hơn cho toàn bộ Roblox và có thể chuyển đổi gần như ngay lập tức thay vì phải mất vài giờ.

Chuyển sang cơ sở hạ tầng dạng ô

Ưu tiên tiếp theo của chúng tôi là tạo ra các bức tường chống nổ vững chắc bên trong mỗi trung tâm dữ liệu để giảm thiểu khả năng toàn bộ trung tâm dữ liệu bị hỏng. Các ô (một số công ty gọi là cụm) về cơ bản là một tập hợp các máy và là cách chúng tôi tạo ra các bức tường này. Chúng tôi sao chép các dịch vụ cả trong và giữa các ô để tăng cường tính dự phòng. Cuối cùng, chúng tôi muốn tất cả các dịch vụ tại Roblox chạy trong các ô để chúng có thể hưởng lợi từ cả các bức tường chống nổ vững chắc và tính dự phòng. Nếu một cell không còn hoạt động, nó có thể được vô hiệu hóa một cách an toàn. Việc sao chép dữ liệu giữa các cell cho phép dịch vụ tiếp tục hoạt động trong khi cell đó được sửa chữa. Trong một số trường hợp, việc sửa chữa cell có thể đòi hỏi phải cài đặt lại hoàn toàn cell đó. Trong ngành công nghiệp, việc xóa và cài đặt lại một máy chủ riêng lẻ hoặc một nhóm nhỏ máy chủ là khá phổ biến, nhưng việc thực hiện điều này cho toàn bộ một cell (chứa khoảng 1.400 máy chủ) thì không. 

Để điều này hoạt động, các cụm này cần phải tương đối đồng nhất, để chúng tôi có thể di chuyển các tải công việc từ cụm này sang cụm khác một cách nhanh chóng và hiệu quả. Chúng tôi đã đặt ra một số yêu cầu mà các dịch vụ phải đáp ứng trước khi chạy trong một cụm. Ví dụ, các dịch vụ phải được container hóa, điều này giúp chúng linh hoạt hơn và ngăn chặn việc thay đổi cấu hình ở cấp độ hệ điều hành. Chúng tôi đã áp dụng triết lý cơ sở hạ tầng dưới dạng mã (infrastructure-as-code) cho các ô: Trong kho lưu trữ mã nguồn của chúng tôi, chúng tôi bao gồm định nghĩa của mọi thứ có trong một ô để có thể nhanh chóng xây dựng lại từ đầu bằng các công cụ tự động. 

Hiện tại, không phải tất cả các dịch vụ đều đáp ứng các yêu cầu này, vì vậy chúng tôi đã nỗ lực hỗ trợ chủ sở hữu dịch vụ đáp ứng chúng khi có thể, đồng thời xây dựng các công cụ mới để việc di chuyển dịch vụ vào các cell trở nên dễ dàng khi đã sẵn sàng. Ví dụ: công cụ triển khai mới của chúng tôi tự động “phân chia” việc triển khai dịch vụ trên các ô, do đó chủ sở hữu dịch vụ không cần phải suy nghĩ về chiến lược nhân bản. Mức độ nghiêm ngặt này khiến quá trình di chuyển trở nên khó khăn và tốn thời gian hơn nhiều, nhưng lợi ích lâu dài sẽ là một hệ thống trong đó: 

• Việc ngăn chặn sự cố và ngăn chặn sự cố lan sang các ô khác trở nên dễ dàng hơn rất nhiều; 
• Các kỹ sư cơ sở hạ tầng của chúng tôi có thể làm việc hiệu quả hơn và nhanh chóng hơn; và 
• Các kỹ sư xây dựng các dịch vụ cấp sản phẩm cuối cùng được triển khai trong các ô không cần biết hoặc lo lắng về việc dịch vụ của họ đang chạy trong ô nào.

Giải quyết những thách thức lớn hơn

Tương tự như cách cửa chống cháy được sử dụng để ngăn chặn ngọn lửa, các ô hoạt động như những bức tường chống nổ vững chắc trong cơ sở hạ tầng của chúng tôi để giúp ngăn chặn bất kỳ sự cố nào gây ra lỗi trong một ô duy nhất. Cuối cùng, tất cả các dịch vụ tạo nên Roblox sẽ được triển khai dự phòng bên trong và giữa các tế bào. Khi công việc này hoàn thành, các sự cố vẫn có thể lan rộng đủ để khiến một tế bào không thể hoạt động, nhưng sẽ cực kỳ khó khăn để sự cố lan rộng ra ngoài tế bào đó. Và nếu chúng tôi thành công trong việc làm cho các tế bào có thể hoán đổi cho nhau, quá trình phục hồi sẽ nhanh hơn đáng kể vì chúng tôi có thể chuyển sang một tế bào khác và ngăn chặn sự cố ảnh hưởng đến người dùng cuối. 

Điều phức tạp ở đây là phải tách biệt các tế bào đủ xa để giảm cơ hội lan truyền lỗi, đồng thời vẫn đảm bảo hệ thống hoạt động hiệu quả và ổn định. Trong một hệ thống cơ sở hạ tầng phức tạp, các dịch vụ cần giao tiếp với nhau để chia sẻ truy vấn, thông tin, tải công việc, v.v. Khi chúng ta nhân bản các dịch vụ này vào các tế bào, chúng ta cần cân nhắc kỹ lưỡng cách quản lý giao tiếp giữa các tế bào. Trong thế giới lý tưởng, chúng ta sẽ chuyển hướng lưu lượng từ một tế bào không khỏe mạnh sang các tế bào khỏe mạnh khác. Nhưng làm thế nào để quản lý một “truy vấn gây chết” – truy vấn khiến một ô trở nên không ổn định? Nếu chúng ta chuyển hướng truy vấn đó sang một ô khác, nó có thể khiến ô đó trở nên không ổn định theo chính cách mà chúng ta đang cố gắng tránh. Chúng ta cần tìm các cơ chế để chuyển lưu lượng “tốt” khỏi các ô không ổn định đồng thời phát hiện và ngăn chặn lưu lượng gây ra tình trạng không ổn định cho các ô. 

Trong ngắn hạn, chúng tôi đã triển khai các bản sao của dịch vụ tính toán vào mỗi tế bào tính toán để hầu hết các yêu cầu đến trung tâm dữ liệu có thể được xử lý bởi một tế bào duy nhất. Chúng tôi cũng đang cân bằng tải lưu lượng truy cập giữa các tế bào. Nhìn xa hơn, chúng tôi đã bắt đầu xây dựng quy trình phát hiện dịch vụ thế hệ tiếp theo sẽ được tận dụng bởi một mạng lưới dịch vụ (service mesh), mà chúng tôi hy vọng sẽ hoàn thành vào năm 2024. Điều này sẽ cho phép chúng tôi triển khai các chính sách phức tạp, chỉ cho phép giao tiếp giữa các tế bào khi điều đó không ảnh hưởng tiêu cực đến các tế bào dự phòng. Cũng trong năm 2024, chúng tôi sẽ triển khai phương pháp hướng các yêu cầu phụ thuộc đến phiên bản dịch vụ trong cùng một tế bào, giúp giảm thiểu lưu lượng giữa các tế bào và từ đó giảm rủi ro lan truyền sự cố giữa các tế bào.

Vào giờ cao điểm, hơn 70% lưu lượng dịch vụ back-end của chúng tôi được phục vụ từ các ô và chúng tôi đã học được rất nhiều về cách tạo ô, nhưng chúng tôi dự kiến sẽ có thêm nhiều nghiên cứu và thử nghiệm khi tiếp tục di chuyển các dịch vụ của mình trong năm 2024 và những năm tiếp theo. Khi chúng tôi tiến bộ, các bức tường chắn này sẽ ngày càng trở nên vững chắc hơn.

Di chuyển cơ sở hạ tầng luôn hoạt động

Roblox là một nền tảng toàn cầu hỗ trợ người dùng trên toàn thế giới, vì vậy chúng tôi không thể di chuyển các dịch vụ trong thời gian ngoài giờ cao điểm hoặc “thời gian ngừng hoạt động”, điều này làm cho quá trình di chuyển tất cả các máy của chúng tôi vào các ô và các dịch vụ của chúng tôi để chạy trong các ô đó trở nên phức tạp hơn. Chúng tôi có hàng triệu trải nghiệm luôn hoạt động cần tiếp tục được hỗ trợ, ngay cả khi chúng tôi di chuyển các máy chủ mà chúng chạy trên đó và các dịch vụ hỗ trợ chúng. Khi bắt đầu quá trình này, chúng tôi không có hàng chục nghìn máy chủ đang nằm im không sử dụng và sẵn sàng để di chuyển các khối lượng công việc này sang. 

Tuy nhiên, chúng tôi có một số lượng nhỏ máy chủ bổ sung được mua để dự phòng cho sự phát triển trong tương lai. Để bắt đầu, chúng tôi đã xây dựng các cụm mới bằng những máy chủ đó, sau đó di chuyển các khối lượng công việc sang chúng. Chúng tôi coi trọng cả hiệu quả lẫn độ tin cậy, vì vậy thay vì đi mua thêm máy chủ khi hết “máy dự phòng”, chúng tôi đã xây dựng thêm các cụm bằng cách xóa sạch và tái cấu hình các máy chủ đã di chuyển tải công việc ra khỏi đó. Sau đó, chúng tôi di chuyển các tải công việc lên các máy chủ đã được tái cấu hình này và bắt đầu quá trình lại từ đầu. Quy trình này phức tạp — khi các máy chủ được thay thế và giải phóng để xây dựng thành các cụm, chúng không được giải phóng theo cách lý tưởng và có trật tự. Chúng bị phân tán vật lý khắp các phòng dữ liệu, buộc chúng tôi phải cấu hình lại chúng theo từng phần, điều này yêu cầu một quy trình chống phân mảnh cấp phần cứng để đảm bảo vị trí phần cứng khớp với các vùng lỗi vật lý quy mô lớn. 

Một phần của đội ngũ kỹ sư hạ tầng của chúng tôi tập trung vào việc di chuyển các tải công việc hiện có từ môi trường cũ, hay “trước khi chia thành các cụm”, vào các cụm. Công việc này sẽ tiếp tục cho đến khi chúng tôi di chuyển hàng nghìn dịch vụ hạ tầng và hàng nghìn dịch vụ phía sau vào các cụm mới được xây dựng. Chúng tôi dự kiến điều này sẽ mất cả năm tới và có thể kéo dài đến năm 2025, do một số yếu tố phức tạp. Đầu tiên, công việc này yêu cầu phải xây dựng các công cụ mạnh mẽ. Ví dụ, chúng tôi cần các công cụ để tự động cân bằng lại số lượng lớn dịch vụ khi triển khai một cell mới — mà không ảnh hưởng đến người dùng. Chúng tôi cũng đã phát hiện ra các dịch vụ được xây dựng dựa trên các giả định về hạ tầng của chúng tôi. Chúng tôi cần điều chỉnh lại các dịch vụ này để chúng không phụ thuộc vào những yếu tố có thể thay đổi trong tương lai khi chúng tôi chuyển sang mô hình cell. Chúng tôi cũng đã triển khai cả một phương pháp để phát hiện các mẫu thiết kế đã biết không tương thích với kiến trúc tế bào, cũng như quy trình kiểm thử có hệ thống cho từng dịch vụ được di chuyển. Các quy trình này giúp chúng tôi ngăn chặn các vấn đề ảnh hưởng đến người dùng do dịch vụ không tương thích với các tế bào.

Hiện nay, gần 30.000 máy chủ đang được quản lý bởi các cụm. Đây chỉ là một phần nhỏ trong tổng số máy chủ của chúng tôi, nhưng quá trình chuyển đổi cho đến nay diễn ra rất suôn sẻ mà không gây ảnh hưởng tiêu cực đến người chơi. Mục tiêu cuối cùng của chúng tôi là hệ thống đạt được thời gian hoạt động 99,99% mỗi tháng, có nghĩa là chúng tôi sẽ không làm gián đoạn quá 0,01% thời gian tương tác. Trong toàn ngành, thời gian ngừng hoạt động không thể loại bỏ hoàn toàn, nhưng mục tiêu của chúng tôi là giảm thời gian ngừng hoạt động của Roblox xuống mức gần như không thể nhận thấy.

Chuẩn bị cho tương lai khi mở rộng quy mô

Mặc dù những nỗ lực ban đầu của chúng tôi đang chứng tỏ sự thành công, công việc của chúng tôi về các tế bào vẫn còn rất nhiều việc phải làm. Khi Roblox tiếp tục mở rộng quy mô, chúng tôi sẽ tiếp tục làm việc để cải thiện hiệu quả và khả năng phục hồi của hệ thống thông qua công nghệ này và các công nghệ khác. Trong quá trình đó, nền tảng sẽ ngày càng trở nên bền bỉ hơn trước các sự cố, và bất kỳ sự cố nào xảy ra sẽ ngày càng ít được chú ý và ít gây gián đoạn hơn đối với người dùng trên nền tảng của chúng tôi.

Tóm lại, đến nay, chúng tôi đã: 

• Xây dựng trung tâm dữ liệu thứ hai và đạt được trạng thái chủ động/thụ động thành công. 
• Tạo các ô trong trung tâm dữ liệu chủ động và dự phòng của chúng tôi và đã di chuyển thành công hơn 70% lưu lượng dịch vụ back-end sang các ô này.
• Thiết lập các yêu cầu và thực tiễn tốt nhất mà chúng tôi cần tuân thủ để giữ cho tất cả các ô đồng nhất khi chúng tôi tiếp tục di chuyển phần còn lại của cơ sở hạ tầng. 
• Khởi động quá trình liên tục nhằm xây dựng các “bức tường chắn” vững chắc hơn giữa các ô. 

Khi các ô này trở nên dễ thay thế hơn, sẽ có ít hiện tượng nhiễu chéo giữa các ô hơn. Điều này mở ra một số cơ hội rất thú vị cho chúng tôi trong việc tăng cường tự động hóa về giám sát, khắc phục sự cố và thậm chí là chuyển đổi khối lượng công việc một cách tự động. 

Vào tháng 9, chúng tôi cũng bắt đầu thực hiện các thử nghiệm active/active trên các trung tâm dữ liệu của mình. Đây là một cơ chế khác mà chúng tôi đang thử nghiệm để cải thiện độ tin cậy và giảm thiểu thời gian chuyển đổi dự phòng. Các thử nghiệm này đã giúp xác định một số mẫu thiết kế hệ thống, chủ yếu liên quan đến truy cập dữ liệu, mà chúng tôi cần phải điều chỉnh lại khi tiến tới mô hình active-active hoàn toàn. Nhìn chung, thử nghiệm đã thành công đủ để chúng tôi tiếp tục duy trì nó cho lưu lượng truy cập từ một số lượng người dùng hạn chế.