Tóm tắt: Diễn tập phòng cháy chữa cháy hai tháng một lần quanh năm, mô phỏng tải trọng gấp 150% so với BFCM năm ngoái. Các bài kiểm tra quy mô lớn đến mức chúng tôi phải thực hiện vào ban đêm và phối hợp với YouTube. Mỗi bài kiểm tra đều phát hiện ra các điểm nghẽn—Kafka, bộ nhớ, thời gian chờ—mà chúng tôi đã khắc phục và kiểm tra lại. Chúng tôi không dừng lại cho đến khi cơ sở hạ tầng hoạt động tốt dưới tải trọng cực lớn.

Cuối tuần Black Friday và Cyber ​​Monday (BFCM) là bài kiểm tra cuối cùng về... ShopifyCơ sở hạ tầng của chúng tôi. Hàng triệu thương nhân và hàng chục triệu người mua hàng phụ thuộc vào chúng tôi trong bốn ngày quan trọng nhất trong năm.

Năm 2024, chúng tôi đã phá vỡ nhiều kỷ lục về hiệu suất.: 57.3 PB dữ liệu, 10.5 nghìn tỷ truy vấn cơ sở dữ liệu, 1.19 nghìn tỷ yêu cầu biên và 1.17 nghìn tỷ lượt ghi cơ sở dữ liệu. Chúng tôi đạt đỉnh điểm 284 triệu yêu cầu mỗi phút trên máy chủ biên và 80 triệu trên máy chủ ứng dụng, đẩy 12TB mỗi phút chỉ riêng trong ngày Black Friday. Hiện tại, mức lưu lượng truy cập này chỉ là một ngày bình thường đối với chúng tôi. Shopify.

Dĩ nhiên, năm nay sẽ còn lớn hơn nữa. Để đối phó với làn sóng giao thông khổng lồ sắp ập đến, chúng tôi đã xây dựng lại chương trình chuẩn bị cho BFCM từ đầu. 

Benjamin Franklin từng nói: “Không chuẩn bị tức là chuẩn bị cho thất bại.” Đó là cách chúng tôi đã chuẩn bị suốt cả năm để thành công trong trận Siêu cúp thương mại.

Xây dựng khả năng phục hồi quanh năm

Công tác chuẩn bị cho BFCM của chúng tôi bắt đầu từ tháng 3 với việc lập kế hoạch năng lực và chiến lược đa vùng trên Google Cloud. Đảm bảo độ tin cậy là công việc quanh năm. Chúng tôi không sử dụng BFCM như một hạn chót phát hành—mọi thay đổi kiến ​​trúc và quá trình di chuyển đều diễn ra nhiều tháng trước thời điểm quan trọng đó.

Ba luồng công việc song song được thực hiện đồng thời trong quá trình chuẩn bị của chúng tôi:

1. Kế hoạch năng lựcChúng tôi xây dựng mô hình lưu lượng truy cập dựa trên dữ liệu lịch sử và sự tăng trưởng của các nhà bán lẻ, sau đó gửi các ước tính này cho các nhà cung cấp dịch vụ đám mây để họ không bị thiếu tài nguyên đám mây. Kế hoạch này xác định chúng tôi cần bao nhiêu cơ sở hạ tầng và cần đặt ở đâu trên bản đồ.
   
2. Lộ trình cơ sở hạ tầngChúng tôi xem xét lại hệ thống công nghệ hiện có, đánh giá các thay đổi về kiến ​​trúc và xác định các nâng cấp để đạt được dung lượng mục tiêu. Điều này giúp chúng tôi sắp xếp công việc theo trình tự hợp lý.
3. Đánh giá rủi ro: Các bài tập "Điều gì có thể xảy ra sai sót" (WCGW) ghi lại các kịch bản lỗi, thiết lập thứ tự ưu tiên leo thang và tạo ra các thông tin đầu vào cho "Ngày diễn ra sự cố". Với thông tin này, chúng ta kiểm tra và tăng cường bảo mật hệ thống trước khi sự cố xảy ra.

Mỗi khía cạnh đều ảnh hưởng đến các khía cạnh khác. Kết quả đánh giá rủi ro có thể cho thấy những thiếu hụt về năng lực, những thay đổi về cơ sở hạ tầng có thể dẫn đến những rủi ro mới, v.v.

Ngày thi đấu

Để đánh giá rủi ro, chúng tôi đã tập trung mạnh vào Game Days: các bài tập kỹ thuật hỗn loạn mô phỏng các sự cố sản xuất ở quy mô BFCM.

Chúng tôi bắt đầu tổ chức các Ngày hội trò chơi vào đầu mùa xuân. Chúng tôi cố tình đưa lỗi vào hệ thống để kiểm tra cách chúng phản ứng trong điều kiện lỗi và liệu chúng có xác thực quy trình xử lý sự cố của chúng tôi hay không. Chúng tôi dành thêm thời gian cho các luồng người dùng quan trọng nhất đối với hoạt động kinh doanh. ShopifyGiống như quy trình thanh toán, xử lý thanh toán, tạo đơn hàng và hoàn tất đơn hàng—chúng tôi gọi đây là “các hành trình quan trọng”.

Các buổi diễn tập Critical Journey Game Days đã thực hiện mô phỏng thảm họa trên nhiều hệ thống, kiểm tra các điểm cuối tìm kiếm và trang, ngẫu nhiên hóa điều hướng để mô phỏng người dùng thực, đưa vào các lỗi mạng và độ trễ, và phá vỡ bộ nhớ cache để tạo ra các mô hình tải thực tế. Các nhóm phát triển giao diện người dùng đã thực hiện các đợt tìm lỗi để xác định các lỗi hồi quy, kiểm tra các luồng người dùng quan trọng và xác thực trải nghiệm người dùng trong điều kiện tải cao điểm.

Những bài tập này đã giúp chúng tôi ghi nhớ phản xạ khi ứng phó sự cố và phát hiện ra những lỗ hổng trong quy trình và công cụ giám sát của chúng tôi. Chúng tôi đã khắc phục những lỗ hổng đó trước thềm BFCM.

Tất cả các phát hiện đều được đưa vào Ma trận Khả năng phục hồi của chúng tôi: một tài liệu tập trung ghi lại các lỗ hổng, quy trình ứng phó sự cố và các biện pháp khắc phục. 

Ma trận khả năng phục hồi

Ma trận hiện đóng vai trò là lộ trình tăng cường bảo mật hệ thống của chúng tôi trước thềm BFCM. Các nhóm liên tục cập nhật Ma trận trong suốt cả năm, ghi lại khả năng phục hồi của chúng tôi trên toàn hệ thống Shopify. Ma trận bao gồm:

• Tình trạng dịch vụ: Tình trạng hoạt động hiện tại của tất cả các dịch vụ thiết yếu
• Các kịch bản thất bại: Các chế độ hỏng hóc được ghi nhận kèm theo phân tích tác động.
• Thủ tục phục hồi: Mục tiêu thời gian phục hồi dự kiến ​​(RTO) và sổ tay hướng dẫn vận hành chi tiết.
• Sổ tay hướng dẫn vận hành: Hướng dẫn xử lý sự cố từng bước
• Chế độ trực ca: Lịch trình nhóm và quy trình xử lý sự cố của PagerDuty nhằm đảm bảo phản ứng nhanh chóng trước sự cố.

Kiểm tra tải

Chúng tôi không thể chờ đến BFCM để tìm ra giới hạn năng lực của mình, vì vậy chúng tôi sử dụng kiểm thử tải để mô phỏng lưu lượng truy cập đó trước đó. Điều này cho phép chúng tôi tìm ra các điểm nghẽn trước nhiều tháng và cho các nhóm của chúng tôi thời gian để mở rộng cơ sở hạ tầng và tối ưu hóa mã cho phù hợp.

Công cụ kiểm thử tải Genghis của chúng tôi chạy các quy trình làm việc được lập trình sẵn mô phỏng hành vi người dùng như duyệt web, thêm sản phẩm vào giỏ hàng và quy trình thanh toán. Chúng tôi tăng dần lưu lượng truy cập để tìm ra các điểm nghẽn. Các bài kiểm tra được chạy đồng thời trên cơ sở hạ tầng sản xuất từ ​​ba khu vực GCP (us-central, us-east và europe-west4) để mô phỏng các mô hình lưu lượng truy cập toàn cầu. Chúng tôi thêm các đợt giảm giá chớp nhoáng vào tải cơ bản để kiểm tra công suất tối đa.

Độc tốroxyChúng tôi sử dụng một khung phần mềm mã nguồn mở được xây dựng để mô phỏng các điều kiện mạng, tạo ra các lỗi và sự cố phân vùng mạng (khi các dịch vụ không thể kết nối với nhau). Chúng tôi giám sát bảng điều khiển theo thời gian thực, sẵn sàng dừng hoạt động nếu hệ thống gặp sự cố. Nhiều nhóm phối hợp để tìm và khắc phục các điểm nghẽn.

Khi đạt đến giới hạn, các đội có ba lựa chọn:

• Tỷ lệ theo chiều ngang: nhiều trường hợp hơn
• Mở rộng theo chiều dọc: nhiều tài nguyên hơn cho mỗi phiên bản
• Tối ưu hóa: những thay đổi ở lớp kiến ​​trúc nhằm cải thiện hiệu suất 

Các tối ưu hóa bao gồm từ việc cải thiện truy vấn ở cấp độ cơ sở dữ liệu, đến việc tinh chỉnh hiệu suất trên các lớp sử dụng, cho đến tận giao diện người dùng. Những quyết định này sẽ thiết lập dung lượng BFCM cuối cùng và thúc đẩy công việc tối ưu hóa trên toàn bộ hệ thống của chúng tôi.

Những thách thức phân tích mới

BFCM (Black Lives Matter) kiểm tra mọi hệ thống tại Shopify, nhưng năm 2025 đặt ra một thách thức độc đáo: một phần cơ sở hạ tầng của chúng tôi chưa từng trải qua lưu lượng truy cập mùa lễ hội. Làm thế nào để chuẩn bị cho tải trọng cao điểm khi bạn không có dữ liệu lịch sử để tham khảo?

Năm 2024, nhóm của chúng tôi đã xây dựng lại nền tảng phân tích, tạo ra các quy trình ETL (Trích xuất, Tải, Chuyển đổi) mới, chuyển đổi lớp lưu trữ dữ liệu và thay thế hệ thống cũ bằng các API mới. Quá trình chuyển đổi được triển khai trong suốt cả năm.

Điều này tạo ra sự bất đối xứng. Các đường dẫn ETL của chúng tôi đã hoạt động xuyên suốt BFCM 2024, nghĩa là chúng tôi chỉ có dữ liệu sản xuất của một mùa. Nhưng lớp API của chúng tôi lại được ra mắt sau mùa cao điểm. Chúng tôi đang chuẩn bị cho BFCM trên các API chưa từng có lưu lượng truy cập trong mùa lễ hội.

Hệ thống phân tích dữ liệu của chúng tôi phản ánh kiến ​​trúc tổng thể của Shopify: các dịch vụ độc lập xử lý các báo cáo chuyên sâu, tổng hợp và xử lý thời gian thực. Chúng tôi cũng đã tiến hành các "Ngày hội thử nghiệm" tại đây: các thí nghiệm có kiểm soát được thiết kế để phát hiện các lỗi và điểm nghẽn. Chúng tôi mô phỏng lưu lượng truy cập tăng cao, tạo ra độ trễ cơ sở dữ liệu và kiểm tra lỗi bộ nhớ cache — lập bản đồ một cách có hệ thống hành vi của hệ thống khi chịu tải.

Kết quả cho thấy các pipeline ETL của chúng tôi cần tăng số lượng phân vùng Kafka để duy trì tính cập nhật của dữ liệu trong các đợt tăng đột biến. Việc sử dụng bộ nhớ ở lớp API cần được tối ưu hóa, điều này được phát hiện thông qua việc phân tích hiệu năng. Thời gian chờ kết nối cần được điều chỉnh để tránh tình trạng cạn kiệt tài nguyên. Chúng tôi đã chuyển các yêu cầu đến một khu vực khác thông qua một phương pháp cân bằng tải khác để có thêm không gian xử lý. Bên cạnh việc khắc phục các vấn đề về hiệu năng, chúng tôi đã xác thực hệ thống cảnh báo và ghi lại các quy trình phản hồi. Kết quả là, các nhóm của chúng tôi đã được đào tạo và chuẩn bị sẵn sàng để xử lý và phản hồi khi xảy ra sự cố.

BFCM 2025 sẽ là bài kiểm tra cuối cùng, đặt các API của chúng tôi vào tình trạng truy cập khổng lồ chưa từng có trong mùa lễ hội. Chúng tôi đã giải quyết tất cả các điểm nghẽn đã biết và sẵn sàng xử lý những điều không lường trước được.

Chương trình kiểm tra quy mô

Các ngày thi đấu và kiểm thử tải giúp chúng ta chuẩn bị, nhưng chúng chỉ kiểm tra các thành phần một cách riêng lẻ. Kiểm thử quy mô thì khác – nó xác thực toàn bộ nền tảng hoạt động cùng nhau ở mức tải cao như trong các sự kiện BFCM, từ đó phát hiện ra các vấn đề chỉ xuất hiện khi mọi thứ hoạt động hết công suất cùng một lúc.

Từ tháng Tư đến tháng Mười, chúng tôi đã thực hiện năm bài kiểm tra quy mô lớn ở mức lưu lượng truy cập dự báo, dựa trên giả định lưu lượng truy cập p90 cao điểm của chúng tôi. Hai bài kiểm tra đầu tiên đã xác thực hiệu suất cơ bản so với hiệu suất năm 2024. Các bài kiểm tra thứ ba đến thứ năm được nâng cấp lên mức dự báo năm 2025. Đến bài kiểm tra thứ tư, chúng tôi đã đạt 146 triệu yêu cầu mỗi phút và hơn 80,000 lượt thanh toán mỗi phút. Trong bài kiểm tra cuối cùng của năm, chúng tôi đã kiểm tra p99, đạt 200 triệu lượt mỗi phút.

Các bài kiểm tra này quy mô lớn đến mức chúng tôi phải thực hiện chúng vào ban đêm và phối hợp với YouTube. Chúng tôi đã kiểm tra khả năng phục hồi, chứ không chỉ tải trọng. Chúng tôi đã thực hiện chuyển đổi dự phòng khu vực, chuyển hướng lưu lượng truy cập khỏi các khu vực cốt lõi của Mỹ và EU để xác thực khả năng phục hồi sau thảm họa.

Chúng tôi đã tiến hành nhiều cuộc thử nghiệm:

• Mở rộng quy mô kiến ​​trúc: Đã xác nhận rằng cơ sở hạ tầng của chúng tôi đáp ứng được công suất theo kế hoạch.
• Kiểm tra tải (hoạt động bình thường): Hiệu suất cơ bản được thiết lập ở mức tải tối đa
• Kiểm tra tải (có chức năng dự phòng): Đã được xác thực khả năng phục hồi sau sự cố và chuyển đổi dự phòng giữa các khu vực.
• Mô phỏng ngày thi đấu: Đã kiểm tra khả năng phục hồi liên hệ giữa các hệ thống thông qua kỹ thuật hỗn loạn.

Chúng tôi đã mô phỏng hành vi người dùng thực tế: duyệt và thanh toán trên cửa hàng trực tuyến, lưu lượng truy cập API quản trị từ các ứng dụng và tích hợp. phân tích và báo cáo Tải trọng và xử lý webhook phía máy chủ. Chúng tôi cũng đã thử nghiệm các kịch bản quan trọng: tải trọng cao điểm, chuyển đổi dự phòng khu vực và lỗi lan truyền khi nhiều hệ thống gặp sự cố đồng thời. 

Mỗi chu kỳ thử nghiệm đều xác định được những vấn đề mà chúng ta sẽ không bao giờ gặp phải trong điều kiện tải ổn định, và chúng tôi đã khắc phục từng vấn đề ngay khi chúng xuất hiện.

• Bài kiểm tra thang điểm 1-2: Khi hoạt động quá tải, các thao tác cốt lõi phát sinh lỗi và hàng đợi thanh toán bị tắc nghẽn.
• Bài kiểm tra thang đo 3: Việc di chuyển khóa đã được xác thực và định tuyến khu vực được xác nhận hoạt động như mong đợi sau khi thay đổi.
• Bài kiểm tra thang đo 4: Đã gặp phải các giới hạn gây ra sự cố chuyển đổi dự phòng ngoài kế hoạch. Đã xác định các vấn đề về ưu tiên trong định tuyến lưu lượng truy cập thử nghiệm và phát hiện ra sự chậm trễ khi đưa các khu vực trở lại trực tuyến trong quá trình cân bằng lại.
• Bài kiểm tra thang đo 5: Đã thực hiện buổi tổng duyệt đầy đủ, đây là buổi chạy thử duy nhất trong giờ làm việc của Bắc Mỹ để mô phỏng các điều kiện thực tế của BFCM (các buổi còn lại diễn ra vào ban đêm).
• Thay đổi giữa chương trình: Đã thêm quy trình thanh toán xác thực vào các kịch bản thử nghiệm. Mô phỏng người mua thực tế đã phát hiện ra các đường dẫn giới hạn tỷ lệ truy cập. duyệt web ẩn danh Không bao giờ chạm vào. Ngay cả khi chỉ chiếm một tỷ lệ nhỏ trong lưu lượng truy cập, các luồng được xác thực vẫn cho thấy các điểm nghẽn.

Kiểm thử khả năng mở rộng là một hoạt động nhóm. Nhóm hạ tầng chịu trách nhiệm mở rộng nền tảng và giám sát tình trạng hoạt động, nhóm sản phẩm kiểm định tính năng dưới tải trọng, nhóm SRE chuẩn bị phản hồi sự cố, và nhóm Hỗ trợ chuẩn bị cho các câu hỏi từ phía nhà cung cấp. Chúng tôi cũng phối hợp chặt chẽ các bài kiểm thử này với các nhà cung cấp dịch vụ đám mây và CDN.

Kế hoạch hoạt động của BFCM

Công tác chuẩn bị BFCM giúp chúng ta sẵn sàng, và sự xuất sắc trong vận hành giúp chúng ta duy trì ổn định khi lưu lượng truy cập tăng đột biến. Kế hoạch vận hành của chúng tôi phối hợp các nhóm kỹ thuật, ứng phó sự cố và điều chỉnh hệ thống trực tiếp.

Kế hoạch hoạt động của chúng tôi cho cuối tuần BFCM bao gồm:

• Giám sát thời gian thực: Khả năng hiển thị bảng điều khiển trên tất cả các khu vực với cảnh báo tự động.
• Ứng phó sự cố: Các nhóm Quản lý Sự cố Trực ban (IMOC) với khả năng hoạt động 24/7 và các quy trình leo thang sự cố.
• Thông tin liên lạc giữa người bán và nhà cung cấp: Cập nhật trạng thái và thông báo
• Tối ưu hóa trực tiếp: Điều chỉnh hệ thống dựa trên mô hình lưu lượng truy cập thời gian thực.
• Buổi tổng kết sau sự kiện BFCM: Đối chiếu dữ liệu giám sát với kết quả kinh doanh của người bán.

Đây là thời điểm tuyệt vời nhất trong năm

Hàng ngàn kỹ sư. Chín tháng. Năm lần thử nghiệm quy mô. Bốn ngày giao dịch cao điểm, và một nền tảng vững chắc sẵn sàng xử lý tất cả.

Chương trình chuẩn bị cho năm 2025 của chúng tôi rất chuyên sâu. Chúng tôi đã thực hiện các chuyển đổi dự phòng khu vực, chạy các bài tập kỹ thuật hỗn loạn, ghi lại các lỗ hổng hệ thống và tăng cường bảo mật hệ thống bằng các sổ tay vận hành được cập nhật trước khi các đối tác kinh doanh của chúng tôi cần đến chúng.

Thêm vào đó, các công cụ chúng tôi xây dựng không chỉ là giải pháp tạm thời cho mùa cao điểm Black Friday và Manipulation (BFCM). Ma trận Khả năng phục hồi, Ngày hội hành trình quan trọng và dự báo thích ứng theo thời gian thực là những cải tiến cơ sở hạ tầng lâu dài. Chúng giúp Shopify trở nên mạnh mẽ hơn mỗi ngày, chứ không chỉ trong mùa cao điểm.

BFCM bắt đầu vào ngày 28 tháng 11. Chúng tôi đã sẵn sàng! 🚀

Nếu bạn quan tâm đến việc cùng chúng tôi thực hiện sứ mệnh làm cho thương mại tốt hơn cho mọi người, hãy xem thông tin chi tiết tại đây. trang nghề nghiệp.

Kyle Petroski Là Trưởng phòng Kỹ thuật trong nhóm Phân tích dữ liệu.

Matthew Frail Là Quản lý Chương trình Kỹ thuật cấp cao thuộc nhóm Vận hành Kỹ thuật.