Ứng dụng AI của bạn vừa được nhắc đến rầm rộ. Nó có trụ nổi lúc lượng truy cập tăng vọt không?
Ai đó chia sẻ ứng dụng của bạn và cả nghìn người ập đến cùng lúc. Đây là cách giúp ứng dụng do AI dựng nên trụ vững khi lưu lượng truy cập tăng vọt mà không phải xây lại nó vào đúng đêm trước thời khắc quan trọng.
Hãy hình dung phiên bản đẹp đẽ của một ngày tồi tệ. Bạn đăng ứng dụng do AI dựng nên của mình lên một cộng đồng bạn tham gia, hoặc một người có lượng theo dõi đông đảo dùng thử rồi chia sẻ nó, hoặc nó lọt lên trang nhất của một diễn đàn mà bạn còn chẳng gửi bài tới. Bỗng dưng dòng khách truy cập nhỏ giọt thường ngày biến thành một cơn lũ. Cả nghìn người, đều bấm dạo quanh trong cùng một giờ.
Đây chính là khoảnh khắc bạn đã dựng nên cái app này để chờ đợi. Nó cũng là khoảnh khắc nhiều ứng dụng do AI dựng nên lặng lẽ gục ngã — trang tải chậm, vòng xoay nạp dữ liệu quay mãi, một biểu mẫu đăng ký không chịu gửi đi. Những người cuối cùng cũng chịu xuất hiện thì đụng phải bức tường rồi bỏ đi, và đa số họ không bao giờ quay lại để thử thêm lần nữa.
Tin tốt: trụ vững qua đợt lưu lượng tăng vọt chủ yếu xoay quanh một nắm những quyết định nhàm chán mà bạn có thể đưa ra trước khi cơn tăng vọt xảy ra. Bạn không cần phải là kỹ sư. Bạn chỉ cần biết chỗ nào không nên cắt xén.
Điều gì thực sự hỏng khi lưu lượng vọt lên
Khi số người dùng app của bạn cùng lúc tăng gấp trăm lần bình thường, mọi thứ không hỏng một cách ngẫu nhiên. Chúng hỏng theo một trật tự có thể đoán trước, và gần như luôn là cùng ba chỗ giống nhau.
Cơ sở dữ liệu bị quá tải. Mỗi khi ai đó tải một trang, ứng dụng của bạn thường hỏi cơ sở dữ liệu một câu hỏi: “dữ liệu của người dùng này là gì?” Một người hỏi thì chẳng đáng gì. Một nghìn người hỏi cùng một câu trong cùng một phút có thể dồn ứ nhanh hơn tốc độ cơ sở dữ liệu trả lời được, và trang của mọi người chậm như bò.
Một thứ gì đó bên ngoài app của bạn trở nên chậm chạp. Hầu hết ứng dụng do AI dựng nên đều dựa vào các dịch vụ khác — gửi email, xử lý thanh toán, gọi một mô hình AI. Những dịch vụ đó thường giới hạn tốc độ bạn được phép gọi chúng. Dưới lưu lượng bình thường, bạn chẳng bao giờ để ý đến giới hạn đó. Trong một đợt tăng vọt, app của bạn chạm phải nó, và đột nhiên mọi hành động liên quan đến dịch vụ ấy đều đứng khựng.
App lặp đi lặp lại cùng một công việc tốn kém. Nếu trang chủ của bạn chạy một phép tính nặng nề mỗi lần có ai đó ghé thăm — lấy về một danh sách, xếp hạng nó, định dạng nó — thì điều đó ổn với mười khách nhưng tàn khốc với một nghìn người. Công việc ấy vốn dĩ luôn lãng phí. Lưu lượng thấp chỉ che giấu điều đó đi.
Hãy để ý quy luật: không cái nào trong số này là lỗi mới cả. Đợt tăng vọt không làm hỏng thứ gì. Nó phơi bày những điểm yếu vốn đã có sẵn, nằm im lìm dưới lưu lượng thấp.
Cách sửa rẻ nhất: Lưu đệm những thứ không đổi
Lưu đệm (caching) nghe có vẻ kỹ thuật, nhưng ý tưởng thì đơn giản: nếu câu trả lời cho một câu hỏi là giống nhau với mọi người và hiếm khi thay đổi, hãy tính nó một lần rồi tái sử dụng thay vì làm lại công việc đó cho từng khách.
Trang chủ của bạn có lẽ trông giống hệt nhau với cả 1.000 người đang truy cập vào đó. Vậy thì tại sao lại bắt cơ sở dữ liệu dựng lại nó 1.000 lần? Hãy dựng nó một lần, lưu kết quả trong vài phút, rồi phục vụ bản đã lưu đó cho tất cả mọi người. Bạn vừa biến một nghìn chuyến đi tốn kém tới cơ sở dữ liệu thành một.
Hãy nói chính xác điều đó với công cụ AI của bạn: “Lưu đệm trang chủ và danh sách sản phẩm công khai trong năm phút để chúng ta không phải truy vấn cơ sở dữ liệu mỗi lần truy cập.” Bất cứ thứ gì giống nhau với mọi người và không cần phải cập nhật từng giây — một trang bảng giá, một danh sách công khai, một trang chỉ mục blog — đều là ứng viên để lưu đệm. Phần nội dung cá nhân hóa (bảng điều khiển riêng của ai đó, cài đặt tài khoản của họ) không thể lưu đệm theo cùng cách, nhưng phần đó thường chỉ là một mảng nhỏ trong tổng lưu lượng lúc tăng vọt. Hầu hết mọi người đang xem cùng vài trang công khai giống nhau.
Đừng bắt người ta chờ những thứ có thể làm sau
Đây là một sai lầm dễ mắc và dễ sửa. Giả sử ai đó đăng ký, và app của bạn gửi cho họ một email chào mừng. Nếu app của bạn bắt họ chờ trên trang đăng ký cho đến khi email được gửi đi trọn vẹn, thì một dịch vụ email chậm sẽ làm cho việc đăng ký của bạn chậm theo — đúng vào lúc nhiều người đăng ký nhất.
Cách sửa là để cho những thứ chậm chạp diễn ra ở chế độ nền. Người dùng thấy ngay câu “Xong rồi!” tức thì, còn email gửi đi vài giây sau mà không ai phải chờ. Cùng một kết quả, nhưng khách không phải nhìn chằm chằm vào vòng xoay nạp dữ liệu trong khi một máy chủ email cách ba công ty đang đủng đỉnh làm việc của nó.
Hãy yêu cầu công cụ của bạn: “Gửi email chào mừng ở chế độ nền để việc đăng ký không phải chờ nó.” Cũng logic ấy áp dụng cho mọi thứ không cần phải hoàn tất trước khi người dùng đi tiếp được — tạo một báo cáo, đồng bộ sang một công cụ khác, gửi một thông báo. Nếu người dùng không cần kết quả ngay lúc này, thì đừng bắt họ chờ nó.
Hãy có một kế hoạch cho tình huống “Quá nhiều người”
Đôi khi đợt tăng vọt còn lớn hơn bất cứ thứ gì bạn đã chuẩn bị, và nước đi thành thật là suy thoái một cách duyên dáng thay vì sụp đổ. Một app chậm nhưng vẫn chạy được thì hơn một app hỏng.
Vài phiên bản đơn giản của cách này:
- Một thông báo chờ thân thiện. Nếu thứ gì đó thật sự quá tải, việc hiển thị “Hiện đang có rất nhiều khách truy cập — vui lòng chờ một chút” tốt hơn nhiều so với một màn hình trắng hay một lỗi thô. Người ta tha thứ cho một app đang bận. Họ không tha thứ cho một app bị hỏng.
- Tạm thời tắt tính năng nặng nhất. Nếu một tính năng là tính năng tốn kém — chẳng hạn một thao tác tạo nội dung bằng AI tốn tiền thật và thời gian thật cho mỗi lần bấm — bạn có thể ẩn nó đi trong đợt cao điểm và giữ phần còn lại của app chạy nhanh. Dù sao thì đa số khách trong đợt tăng vọt là đang xem dạo, chứ không phải đang dùng tính năng đòi hỏi nhiều nhất của bạn.
- Biết hóa đơn của bạn đến từ đâu. Nếu app của bạn gọi một mô hình AI trả phí mỗi lần truy cập, thì một nghìn khách có thể đồng nghĩa với một khoản phí bất ngờ, chứ không chỉ là một trang chậm. Biết được hành động nào tốn tiền sẽ giúp bạn quyết định trước thứ gì cần giới hạn.
Một buổi tổng duyệt ba mươi phút
Bạn không cần công cụ cầu kỳ để tìm ra điểm yếu của mình. Bạn cần vài người bạn và nửa tiếng đồng hồ.
Hãy nhờ năm hay sáu người mở app của bạn vào cùng một thời điểm và bấm dạo thật mạnh trong vài phút — đăng ký, dùng tính năng chính, tải những trang bận rộn. Cách này thô sơ, nhưng nó phơi bày những thứ rõ ràng một cách nhanh chóng. Nếu app đã có cảm giác ì ạch chỉ với sáu người quần thảo, thì một nghìn người sẽ san phẳng nó. Nếu nó vẫn mượt mà, ít nhất bạn đã vượt qua được ngưỡng thấp.
Trong lúc họ bấm, hãy quan sát xem trang nào có cảm giác chậm nhất. Trang chậm đó chính là chỗ một đợt lưu lượng tăng vọt thật sự sẽ gây đau đớn nhất, và nó là thứ đầu tiên đáng để lưu đệm hay đơn giản hóa. Bạn không cố mô phỏng một nghìn người dùng. Bạn đang cố tìm ra cái trang duy nhất vốn đã chật vật ngay với sáu người.
Mục tiêu thực sự
Bạn không thể làm cho app của mình chống đạn vô hạn, và bạn cũng không cần thế. Mục tiêu không phải là xử lý hoàn hảo mười nghìn người trong khoảnh khắc lan truyền đầu tiên của bạn. Mà là không tự làm bẽ mặt trước vài trăm người cuối cùng đã chịu xuất hiện — là đảm bảo những người mà bạn đã vất vả thu hút được nhận một app chạy được thay vì một vòng xoay quay mãi.
Lưu đệm các trang không đổi. Đẩy những thứ chậm chạp xuống chế độ nền. Có một kế hoạch cho tình huống “quá nhiều người”. Làm một buổi tổng duyệt năm-người-bạn trước khi bạn cần đến nó. Không điều nào trong số đó đòi hỏi bạn phải tự viết code — chỉ cần biết những điều đúng đắn để yêu cầu công cụ AI của bạn.
Rồi, khi khoảnh khắc của bạn đến, bạn được tận hưởng nó thay vì cuống cuồng gỡ lỗi. Vậy nên đây là câu hỏi đáng để ngẫm trong tuần này: nếu một nghìn người xuất hiện vào ngày mai, trang nào sẽ hỏng trước tiên — và bạn đã biết câu trả lời chưa?