Cloudflare giải bài toán thu phí AI khi truy cập nội dung website

Masterclass miễn phí: Tìm hiểu các chiến lược thực tế để ghi dữ liệu với độ trễ thấp và có thể dự đoán được ở quy mô lớn

Masterclass miễn phí: Tối ưu hóa hiệu năng cơ sở dữ liệu ghi cường độ cao

Ghi dữ liệu vào cơ sở dữ liệu – ở quy mô lớn – là một trong những vấn đề khó khăn nhất trong các hệ thống phân tán. Masterclass này sẽ hướng dẫn bạn cách hiểu và tránh các đột biến độ trễ trong khối lượng công việc cơ sở dữ liệu thời gian thực, ghi cường độ cao. Hội đồng chuyên gia của chúng tôi sẽ chia sẻ một khung làm việc thực tế để chẩn đoán các điểm nghẽn ghi dữ liệu và biết cách áp dụng chiến lược nào trong các tình huống khác nhau.

Sau masterclass miễn phí kéo dài 2 giờ được thiết kế dành cho các lập trình viên, kỹ sư, kiến trúc sư và chuyên gia cơ sở dữ liệu này, bạn sẽ biết cách:

Xác định các yếu tố (nội tại cơ sở dữ liệu, cấu hình cơ sở dữ liệu, mô hình hóa dữ liệu…) đang ảnh hưởng đến hiệu suất ghi của bạn

Tránh những sai lầm từng gây ra tình trạng khuếch đại ghi (write amplification) gấp 40 lần trong môi trường production

Duy trì độ trễ P99 thấp ngay cả trong quá trình tăng trưởng liên tục và các đợt đột biến dữ liệu bất thường

Tất cả người tham dự sẽ nhận được trọn bộ sách Database Performance at Scale của giảng viên masterclass Felipe Mendes.

Đăng ký miễn phí

Làm thế nào một trang web có thể tính phí một khách truy cập ẩn danh, bỏ qua mọi quảng cáo và rời đi chỉ trong vòng một giây?

Trong phần lớn lịch sử của web, câu hỏi này hiếm khi xuất hiện, vì khách truy cập là một con người mà trang web có thể bán sự chú ý của họ thông qua quảng cáo hoặc đăng ký. Nếu trang web có nội dung tốt, chủ sở hữu trang web có thể trông đợi vào nhiều lượt truy cập như vậy từ cùng một người dùng. Nhưng hiện nay, việc khách truy cập là con người không phải lúc nào cũng đúng. Hơn một nửa lưu lượng truy cập trực tuyến hiện nay đến từ phần mềm hoạt động thay mặt cho con người, yêu cầu một trang web và rời đi mà không tương tác với bất kỳ quảng cáo hoặc đăng ký nào [2].

Cloudflare đang tìm cách thay đổi điều này.

Như bạn có thể biết, Cloudflare nằm giữa phần lớn các trang web trên thế giới và mọi yêu cầu gửi đến chúng. Nó hoạt động như một reverse proxy mà mỗi yêu cầu đều phải đi qua trước khi đến được máy chủ gốc (origin server) [1]. Điều này cho phép Cloudflare đọc yêu cầu và xử lý nó từ sớm. Trong năm qua, công ty đã tận dụng vị trí này để phân loại lưu lượng truy cập tự động theo hành vi, xác minh danh tính đằng sau một yêu cầu và gần đây nhất là thu phí cho một yêu cầu thông qua một giao thức mở có tên là x402 [1].

Trong bài viết này, chúng ta sẽ đi qua giải pháp của Cloudflare theo năm bước sau:

Cách kiếm tiền thông thường của web dựa vào sự chú ý của con người, và lưu lượng truy cập từ tác nhân (agent traffic) đang thay đổi điều đó một cách căn bản.

Cái nhìn về giải pháp ban đầu của Cloudflare xung quanh việc chặn lưu lượng truy cập tự động và sau đó tính phí cho mỗi lần thu thập dữ liệu (crawl).

Giải quyết danh tính, quyền hạn và thanh toán trong một yêu cầu duy nhất.

Cái nhìn về cách giao thức x402 hoàn tất quá trình thanh toán này.

Giao thức x402 hoàn tất quá trình thanh toán này thông qua một quy trình trao đổi ngắn qua HTTP thông thường.

Chi phí và các câu hỏi mở của phương pháp này.

Tuyên bố miễn trừ trách nhiệm: Bài viết này dựa trên các chi tiết được Cloudflare chia sẻ công khai. Tài liệu tham khảo ở cuối bài. Vui lòng bình luận nếu bạn phát hiện bất kỳ điểm nào không chính xác.

Trong phần lớn lịch sử của mình, các trang web kiếm tiền sau khi yêu cầu xảy ra thay vì trong lúc yêu cầu đó diễn ra. Trình duyệt yêu cầu một trang và máy chủ trả về miễn phí. Giá trị đến sau đó, khi một người xem quảng cáo, mua gói đăng ký hoặc quay lại truy cập lần nữa [1]. Bản thân yêu cầu vẫn miễn phí, và mô hình này đã tài trợ cho một phần lớn của Internet.

Sự gia tăng của lưu lượng truy cập từ tác nhân đang thay đổi điều này một cách đáng kể. Một tác nhân là phần mềm hoạt động thay mặt cho con người, trên thực tế có nghĩa là nó yêu cầu một trang hoặc một nguồn cấp dữ liệu một lần, lấy những gì nó cần và kết thúc trong một lượt duy nhất. Nó bỏ qua quảng cáo, hoạt động bên ngoài mọi gói đăng ký và hoàn thành nhiệm vụ trước khi trang web có cơ hội kiếm tiền từ sự chú ý đó [1]. Mỗi điểm thanh toán cũ đều phụ thuộc vào việc con người ở lại đủ lâu để được tính lượt, vì vậy lưu lượng truy cập từ phần mềm khiến các điểm đó trở nên vô ích.

Áp lực ở đây là loại lưu lượng truy cập này hiện đang nhanh chóng trở thành đa số. Hơn một nửa số yêu cầu gửi đến các trang web đến từ phần mềm thay vì con người [2]. Điều này có nghĩa là khối lượng yêu cầu tăng lên trong khi doanh thu vẫn đứng yên.

Để làm rõ, một số phần của Internet đã tính phí theo mức sử dụng trước cả khi điều này xảy ra. Các dịch vụ đám mây và API đã được bán theo lượt gọi và theo giờ trong nhiều năm, mặc dù chỉ dành cho người mua mà người bán đã biết, những người đã đăng ký và nhận được khóa API [1]. Việc tính phí một người gọi ẩn danh một phần nhỏ của một xu cho một yêu cầu duy nhất vẫn không thực tế, vì chi phí thu một khoản thanh toán nhỏ như vậy thường cao hơn số tiền thu được [1].

Nếu giá trị từng được thanh toán sau khi yêu cầu xảy ra, câu hỏi tự nhiên là bên nào có vị thế để chuyển việc thanh toán đó trở lại ngay tại thời điểm yêu cầu. Câu trả lời bắt đầu từ vị trí của Cloudflare.

Reverse proxy là một máy chủ đứng trước các máy chủ khác và nhận yêu cầu thay mặt cho chúng. Vì Cloudflare hoạt động như một reverse proxy cho phần lớn web, một yêu cầu hướng đến một trong những trang web đó sẽ đến mạng lưới của Cloudflare trước và đi qua nó trên đường đến máy chủ gốc [1]. Máy chủ gốc là máy chủ riêng của trang web, cỗ máy cuối cùng chứa trang hoặc chạy API.

Một lưu ý nhỏ, vị trí của một proxy mang tính đa năng hơn là lưu trữ đệm (caching). Caching lưu trữ một bản sao của phản hồi để có thể phục vụ nhanh chóng vào lần sau, và đó chỉ là một trong nhiều việc hữu ích mà một proxy có thể làm. Từ cùng một vị trí trung gian, một yêu cầu cũng có thể được đọc, phân loại, kiểm tra và xử lý trước khi nó tiếp tục đến máy chủ gốc. Khả năng mở rộng này khá quan trọng ở quy mô của Cloudflare [2].

Tuy nhiên, việc xử lý một yêu cầu từ sớm phụ thuộc vào việc biết trước yêu cầu đó là gì. Đây là một bài toán phân loại. Hãy xem cách Cloudflare xử lý vấn đề này.

Trước khi bất kỳ quy tắc nào có thể áp dụng cho một tác nhân, lưu lượng truy cập phải được phân loại theo hành vi của nó. Phân loại của Cloudflare nhóm lưu lượng truy cập tự động theo hành vi thay vì chỉ dùng nhãn "AI". Ba hành vi ảnh hưởng đến các quyết định chính sách quan trọng [4].

Tìm kiếm (Search) bao gồm hành vi xây dựng chỉ mục của một trang web để một công cụ tìm kiếm có thể trả lời các câu hỏi về nó sau này. Hành vi này chịu trách nhiệm gửi khách truy cập giới thiệu (referral) quay lại.

Tác nhân (Agent) bao gồm hành vi hoạt động trong thời gian thực thay mặt cho con người, thường là với một người đang chờ kết quả. Hãy nghĩ về nó như một trợ lý tìm nạp một trang trong khi trò chuyện.

Đào tạo (Training) bao gồm hành vi lấy nội dung để đào tạo hoặc tinh chỉnh một mô hình, nơi nội dung được hấp thụ vào mô hình thay vì hướng khách truy cập quay lại.

Ba hành vi này trông giống hệt nhau trong nhật ký yêu cầu thô, nhưng chúng mang lại những hậu quả rất khác nhau cho hoạt động kinh doanh của một trang web.

Một trình thu thập dữ liệu (crawler) đơn lẻ cũng có thể thực hiện nhiều hơn một trong các hành vi này, nhưng sự phân tách này cho phép họ ghi lại tất cả chúng [4]. Một trình thu thập dữ liệu vừa xây dựng chỉ mục tìm kiếm vừa thu thập dữ liệu đào tạo sẽ được theo dõi là thực hiện cả hai, điều này cho phép chủ sở hữu trang web nắm bắt toàn bộ các hoạt động mà trình thu thập dữ liệu đó thực hiện trên trang của họ.

Cloudflare cũng phân loại thêm các hành vi khác, bao gồm các hành động thanh toán và thu thập dữ liệu, đồng thời cho phép trang web thể hiện những gì bot có thể lưu trữ và chia sẻ lại sau khi truy cập một trang [4].