Các nhà quảng cáo (và các công ty quảng cáo) sử dụng các nền tảng phía cầu (DSP) để tham gia vào việc mua quảng cáo theo chương trình. DSP cho phép các nhà quảng cáo định cấu hình các chiến dịch quảng cáo của họ và đặt giá thầu cho kho quảng cáo (không gian quảng cáo trên trang web của nhà xuất bản). Khi khối lượng giá thầu từ các nhà quảng cáo và kho quảng cáo từ các nhà xuất bản tăng lên, thì tính phức tạp trong việc xử lý giá thầu và khớp chúng với kho quảng cáo khả dụng cũng tăng theo.
DSP yêu cầu cơ sở hạ tầng đám mây có hiệu suất và khả năng mở rộng để xử lý các chiến dịch quảng cáo và gửi giá thầu. Ngoài ra, độ trễ trong cơ sở hạ tầng này cần được giảm ở mọi bước. Độ trễ thấp hơn cho phép quảng cáo tải nhanh cùng với trang web của nhà xuất bản.
Hướng dẫn này đề cập đến giải pháp DSP phân cấp các thành phần cơ sở hạ tầng chính, bao gồm máy chủ giao diện người dùng và máy chủ đấu giá thời gian thực (RTB). Việc di chuyển cơ sở hạ tầng này đến gần người dùng hơn, cùng với việc thêm hệ thống lưu trữ đệm mạnh mẽ cho kho quảng cáo và hồ sơ người dùng, sẽ giải quyết được những thách thức chính đối với việc phân phối quảng cáo, bao gồm yêu cầu độ trễ thấp và giảm phí thoát.
Vượt qua thử thách
Giống như hầu hết mọi khối lượng công việc sản xuất chuyên biệt, một nền tảng phân tán theo nhu cầu đòi hỏi những cân nhắc về cơ sở hạ tầng độc đáo. Dưới đây là một số thách thức, mỗi thách thức có thể được giảm thiểu hoặc tối thiểu hóa thông qua kiến trúc được thiết kế chu đáo.
Độ nhạy độ trễ
Xác định các nguồn có độ trễ cao và giảm thiểu tác động của độ trễ từ các thành phần đó.
Việc phục vụ quảng cáo cần độ trễ thấp hơn đáng kể so với nhiều hệ thống khác. Quảng cáo cần được chọn cho – và hiển thị cho – người dùng cuối càng nhanh càng tốt. Ngay cả những sự gia tăng nhỏ về độ trễ cũng có thể có tác động tiêu cực lớn đến SLA của khách hàng và tỷ lệ chuyển đổi của người dùng cuối. Trong nhiều trường hợp, cơ sở hạ tầng phục vụ quảng cáo tập trung là nguyên nhân chính gây ra độ trễ cao, mặc dù bạn nên xác định bất kỳ thành phần nào khác trong hệ thống hiện tại của mình cũng có thể góp phần gây ra độ trễ cao.
Bản chất phân tán của giải pháp này đưa các thành phần chính đến gần người dùng cuối hơn, giảm độ trễ so với các hệ thống tập trung truyền thống hơn. Ngoài ra, chuyển đổi dự phòng được cung cấp cho từng vùng và diễn ra nhanh chóng để giảm thời gian chết và giảm thiểu tác động đến độ trễ.
Độ nhạy chi phí (biên lợi nhuận thấp)
Xác định các nguồn chi phí cơ sở hạ tầng đáng kể và tìm cách giảm các chi phí đó.
Do biên lợi nhuận tương đối nhỏ trong không gian phục vụ quảng cáo, chi phí cơ sở hạ tầng đám mây ảnh hưởng trực tiếp đến lợi nhuận. Giảm chi phí đám mây đóng vai trò quan trọng trong việc lập kế hoạch cơ sở hạ tầng.
Một nguồn chi phí cơ sở hạ tầng chính là phí thoát. Bằng cách lưu trữ hệ thống phục vụ quảng cáo phân tán trên nền tảng điện toán đám mây của Akamai, chi phí thoát có thể được loại bỏ hoặc giảm đáng kể so với các công ty siêu quy mô. Giải pháp trong hướng dẫn này đã giúp giảm 40% chi phí cho một khách hàng được lập hồ sơ.
Một nguyên nhân khác dẫn đến chi phí đám mây và phí thoát tăng là lượng lưu lượng cao. Phân cấp một số thành phần nhưng không phải những thành phần khác có thể làm tăng lưu lượng liên vùng khi cơ sở hạ tầng phân tán đang giao tiếp với cơ sở hạ tầng tập trung. Để hạn chế phí thoát liên quan đến lưu lượng này, cần triển khai hệ thống lưu trữ đệm trên các hệ thống phân tán. Sử dụng phương pháp này, các phiên bản cục bộ đồng bộ hóa dữ liệu quan trọng (như kho quảng cáo và giá thầu) để giảm lưu lượng mạng đến đám mây tập trung. Ngoài ra, do mạng lưới toàn cầu của Akamai và mối quan hệ với các siêu quy mô khác, chi phí thoát khi truyền dữ liệu được lưu trữ tập trung trên một siêu quy mô khác cũng bị loại bỏ hoặc giảm.
Nỗ lực hội nhập và di cư
Hãy cân nhắc lượng công sức cần bỏ ra khi thay đổi cơ sở hạ tầng và thiết kế một kiến trúc giúp giảm thiểu công sức này ở bất cứ nơi nào có thể.
Khi thiết kế lại một ứng dụng, lượng công sức bỏ ra để thiết kế và tích hợp các hệ thống mới — cũng như di chuyển sang nhà cung cấp khác — có thể đặt ra những thách thức đáng kể. Giải pháp trong hướng dẫn này chỉ yêu cầu di chuyển một phần quy trình phục vụ quảng cáo sang nền tảng Akamai, nghĩa là nhiều thành phần tập trung không cần phải di chuyển. Hệ thống lưu trữ quảng cáo vẫn không thay đổi, cũng như các cơ sở dữ liệu quan trọng khác. Lượng công sức bỏ ra được giảm đáng kể so với các giải pháp khả thi khác.
Sơ đồ thiết kế cơ sở hạ tầng
Sơ đồ bên dưới giới thiệu các thành phần cơ sở hạ tầng cho phép DSP đa vùng trên điện toán đám mây Akamai, trong khi vẫn giữ nguyên các hệ thống dữ liệu tập trung hiện có. Điều này bao gồm các thành phần để định tuyến các yêu cầu đến vùng gần nhất với người dùng cuối (các nhà quảng cáo và công ty quảng cáo), cân bằng tải các yêu cầu giữa nhiều hệ thống phụ trợ, lưu trữ đệm một bản sao của bất kỳ dữ liệu tập trung nào và giám sát cơ sở hạ tầng để phát hiện thời gian ngừng hoạt động.
- Khách hàng (nhà quảng cáo) tương tác với DSP để cấu hình chiến dịch và đặt giá thầu cho hàng tồn kho.
- Nhà quảng cáo gửi giá thầu để quảng cáo của họ được hiển thị cho người dùng cuối. Điều này có dạng yêu cầu API HTTPS.
- Yêu cầu được định tuyến đến một trong nhiều vùng tính toán (trung tâm dữ liệu). Vì đây là ứng dụng phân tán, yêu cầu được định tuyến thông qua giải pháp cân bằng tải thông minh dựa trên DNS, chẳng hạn như Akamai Global Traffic Manager (GTM) . Bộ cân bằng tải toàn cầu xác định vùng nào có thể phục vụ tốt nhất yêu cầu của khách hàng. Điều này tính đến vị trí, hiệu suất và tính khả dụng. Giải pháp cân bằng tải như thế này là cách lý tưởng để giảm độ trễ (cải thiện tốc độ hiển thị quảng cáo) và tăng khả năng phục hồi (một lỗi không ảnh hưởng đến toàn bộ dung lượng).
- Bộ cân bằng tải cục bộ, chẳng hạn như Compute Instance chạy HAProxy, định tuyến yêu cầu đến một trong nhiều cụm phụ trợ. Nhiều cụm thường được sử dụng trong một vùng duy nhất để dự phòng và mở rộng quy mô. Các nền tảng phối hợp, chẳng hạn như LKE , có thể được sử dụng để quản lý cơ sở hạ tầng và hoạt động của cụm.
- Cổng API frontend bắt đầu xử lý yêu cầu. Các hệ thống này hoạt động trước máy chủ đấu thầu để giảm chi phí xử lý đấu thầu và thoát. Các máy chủ frontend này thường có khả năng áp dụng logic kinh doanh để giao tiếp với các sàn giao dịch quảng cáo cũng như máy chủ đấu thầu và bất kỳ dịch vụ siêu nhỏ nào khác trên cụm.
- Cổng giao diện gửi yêu cầu đấu giá đến máy chủ đấu giá. Trong quá trình đấu giá này, giá thầu được khớp với kho quảng cáo cục bộ và so sánh với các nhà quảng cáo khác sử dụng nền tảng DSP.
- Khi xử lý giá thầu, một máy chủ lưu trữ cục bộ sẽ được truy vấn. Bộ nhớ đệm này bao gồm dữ liệu từ bất kỳ cơ sở hạ tầng tập trung nào, chẳng hạn như cơ sở dữ liệu cho kho quảng cáo, hồ sơ người dùng, v.v. Điều này loại bỏ sự chậm trễ liên quan đến việc truy vấn hệ thống lưu trữ tập trung trên mỗi yêu cầu.
- Bộ nhớ đệm cục bộ được cập nhật định kỳ. Dữ liệu trong bộ nhớ đệm được làm mới để đảm bảo thông tin mới nhất được sử dụng.
- Thông tin từ bộ nhớ đệm cục bộ được gửi trở lại máy chủ đấu giá.
- Giá thầu được xử lý bởi máy chủ đấu thầu. Ở đây, giá thầu được xác định là được chấp nhận (và sẽ được chuyển đến các sàn giao dịch quảng cáo hoặc nhà xuất bản) hay bị từ chối.
- DSP thông báo cho nhà quảng cáo về kết quả đấu thầu bằng cách cập nhật giao diện web.
Hệ thống và thành phần
- Bộ cân bằng tải toàn cầu. Akamai Global Traffic Manager (GTM) có thể được sử dụng để định tuyến các yêu cầu đến khu vực gần nhất với người dùng cuối.
- Bộ cân bằng tải cục bộ. Trong mỗi vùng, một bộ cân bằng tải được sử dụng để cân bằng lưu lượng giữa nhiều cụm backend. Bộ cân bằng tải này phải dự phòng và phải chuyển đổi dự phòng sang bộ cân bằng tải thứ cấp một cách nhẹ nhàng để tránh thời gian chết. Các giải pháp cân bằng tải khả thi bao gồm NodeBalancers , NGINX và HAProxy.
- Cụm phục vụ quảng cáo DSP. Các cụm phục vụ quảng cáo chạy trên nền tảng phối hợp container như LKE và bao gồm nhiều Compute Instance , mỗi cụm chạy một hoặc nhiều thành phần được chỉ định được liệt kê bên dưới. Nên sử dụng nhiều cụm trong mỗi vùng để duy trì tính dự phòng và cho phép tính khả dụng cao.
- Frontend API Gateway. Cổng này proxy tất cả các yêu cầu API cho các API liên quan đến quảng cáo khác được lưu trữ trên cụm. Các cổng API khả thi bao gồm Kong, NGINX, Tyk và Gravitee.
- Máy chủ đấu giá thời gian thực. Lưu trữ tất cả logic xác định giá thầu nào được chấp nhận hoặc từ chối. Có thể truy cập bằng API và các yêu cầu sẽ chỉ đến từ cổng API trong cụm đó.
- Hệ thống lưu trữ đệm. Mỗi cụm nên bao gồm một bộ nhớ đệm cục bộ của bất kỳ cơ sở dữ liệu liên quan đến quảng cáo tập trung quan trọng nào, chẳng hạn như kho quảng cáo và có thể là hồ sơ người dùng. Các hệ thống lưu trữ đệm cục bộ có thể bao gồm Redis, Apache Ignite, Memcached và Couchbase.
- Hệ thống giám sát. Để giám sát trạng thái của bộ cân bằng tải và cụm trong khu vực đó, cần cấu hình hệ thống giám sát và/hoặc ghi nhật ký. Các giải pháp giám sát khả thi bao gồm Prometheus, Grafana và ThousandEyes.
Nguồn : https://www.linode.com/docs/guides/distributed-demand-side-platform/