2 tỷ yêu cầu, thời hạn 100ms, 10.000 đô la mỗi tháng: Xây dựng hệ thống RTB toàn cầu tinh gọn

Trong thế giới quảng cáo âm thanh tự động, 101ms đồng nghĩa với việc không thu được doanh thu nào. Đó không phải là vấn đề về hiệu suất. Đó là vấn đề sống còn. Chúng tôi vận hành một hệ thống xử lý tín hiệu số (DSP) quảng cáo âm thanh, xử lý khoảng Mỗi yêu cầu đều phải được tiếp nhận, đánh giá và phản hồi trong vòng chưa đầy Nếu trễ hạn, giá thầu sẽ bị hủy. Ở mức 101ms, về cơ bản chúng tôi không hoạt động được. 350 triệu yêu cầu mỗi ngày - tương đương khoảng 2 tỷ yêu cầu mỗi tuần. 100 mili giây. Chúng tôi thực hiện điều này với một nhóm kỹ sư ba người và chi phí điện toán đám mây dưới 10.000 đô la mỗi tháng. Cùng một nhóm chịu trách nhiệm mọi thứ - cơ sở hạ tầng đấu thầu, lớp ứng dụng, cơ sở dữ liệu và hoạt động. Hệ sinh thái RTB Nếu bạn không am hiểu sâu về công nghệ quảng cáo, đây là phiên bản ngắn gọn: Quảng cáo lập trình tự động hoạt động dựa trên đấu thầu thời gian thực (RTB). Về phía nguồn cung là . Đây là những nền tảng như AdsWizz hoặc Triton, tổng hợp kho quảng cáo từ hàng ngàn ứng dụng và nhà xuất bản - trình phát podcast, ứng dụng phát trực tuyến và các nền tảng âm thanh khác. các SSP (Supply-Side Platforms) Về phía cầu là những hệ thống như của chúng tôi, đại diện cho các nhà quảng cáo và quyết định, trong thời gian thực, liệu có nên đặt giá thầu cho một lượt hiển thị cụ thể hay không. các DSP (Demand-Side Platforms) - Khi người nghe mở ứng dụng podcast và có vị trí quảng cáo trống, ứng dụng sẽ liên lạc với SSP (Supply-Side Platform) của nó. SSP sau đó gửi yêu cầu đấu thầu đến nhiều DSP (Digital Platform). Hệ thống của chúng tôi nhận được yêu cầu đó, đánh giá người dùng và các chiến dịch đang hoạt động, tính toán giá thầu và gửi lại phản hồi. Toàn bộ quá trình này phải diễn ra trong vòng chưa đầy 100ms, từ đầu đến cuối. Độ trễ không chỉ là một chỉ số ở đây. Nó chính là sản phẩm. Khi đã chấp nhận điều đó, rõ ràng là các mô hình ứng dụng web tiêu chuẩn sẽ không hoạt động. Chúng tôi không thể chấp nhận việc phải thực hiện nhiều bước nhảy mạng giữa các microservice, và chắc chắn không thể chấp nhận chi phí điện toán đám mây đi kèm với một thiết lập Kubernetes rộng lớn. Để tồn tại, chúng tôi phải thiết kế sao cho phù hợp với các hạn chế trước tiên. Hạn chế đó không chỉ là lý thuyết. Ban đầu, khi chúng tôi vẫn còn tín dụng đám mây, chúng tôi không quá lo lắng về hiệu quả. Khi các tín dụng đó cạn kiệt, mọi quyết định về kiến trúc đột nhiên đều có một cái giá thực tế. Đó là lúc chúng tôi phải xem xét lại và thiết kế lại hệ thống để giảm độ trễ, chi phí và đơn giản hóa vận hành. Sau đây là kiến trúc cho phép một nhóm ba người vận hành hệ thống RTB toàn cầu ở quy mô lớn mà không tốn quá nhiều tiền hoặc mất ngủ. 1. Địa lý như bộ lọc đầu tiên: Thiết kế dựa trên vật lý mạng Các nền tảng SSP âm thanh chính mà chúng tôi tích hợp - - được đặt máy chủ tại Mỹ, châu Âu và Đông Nam Á. Lớp ứng dụng của chúng tôi, nơi lưu trữ logic chiến dịch cho các nhà quảng cáo tại Ấn Độ, được đặt tại Ấn Độ. Triton, AdsWizz, Magnite (trước đây là Rubicon) và MCTV Thời gian phản hồi mạng giữa các khu vực này riêng lẻ đã lên tới khoảng , ngay cả trước khi bất kỳ logic ứng dụng nào được thực thi. Điều đó đã khiến chúng ta vượt quá ngân sách cho phép hơn gấp đôi. 240 mili giây Giải pháp khá đơn giản nhưng không thể thương lượng. Chúng tôi đã triển khai các cụm đấu thầu của mình trên : US-West (Oregon), EU-Central (Frankfurt) và Asia-Pacific (Singapore và Hong Kong). bốn khu vực chiến lược của AWS Điều này đảm bảo rằng khi một SSP gửi yêu cầu đấu thầu, khoảng cách của chúng ta đến phần cứng là không đáng kể - thường chỉ vài mili giây - để lại phần lớn ngân sách 100ms cho việc tính toán thực tế. 2. Mô hình lai giữa kiến trúc nguyên khối và kiến trúc vi dịch vụ Chúng tôi đã xây dựng một kiến trúc nằm giữa kiến trúc monolith truyền thống và kiến trúc microservices. Thay vì phân tán các dịch vụ trên toàn mạng, chúng tôi đặt một , sau đó mở rộng quy mô các máy ảo đó theo chiều ngang phía sau bộ cân bằng tải toàn cầu. cụm nhỏ các dịch vụ liên kết chặt chẽ trên một máy ảo duy nhất Bên trong mỗi máy ảo - được coi là một nút đơn lẻ - nó trông giống như một hệ thống phân tán thu nhỏ: : Một container ingress duy nhất đóng vai trò là người điều tiết lưu lượng truy cập nội bộ. Nginx : 3-5 bản sao của dịch vụ đấu giá Node.js chạy trên cùng một máy để tận dụng tối đa CPU. Người đấu giá : Một phiên bản Redis cục bộ chạy ngay bên cạnh mã nguồn. Redis Lợi ích mang lại là tính cục bộ của dữ liệu theo mặc định. Bên đấu thầu không cần phải truyền dữ liệu qua mạng; nó đọc dữ liệu từ máy cục bộ. Điều này cũng cho phép chúng ta nâng cao lên mức cao hơn nhiều. Bằng cách sử dụng các máy ảo lớn hơn (ví dụ: c6i.xlarge) và chia sẻ một tập dữ liệu trong bộ nhớ duy nhất cho nhiều máy chủ xử lý, chúng ta có được tỷ lệ RAM trên CPU tốt hơn nhiều - giảm thiểu lãng phí trong khi tối đa hóa thông lượng. mật độ tài nguyên 3. Phương pháp logic: Thất bại nhanh chóng Để đáp ứng thời hạn 100ms, chỉ có mã nhanh thôi là chưa đủ. Hệ thống phải nhanh chóng quyết định khi nào không nên thực hiện công việc. Hầu hết các yêu cầu đấu thầu đến sẽ không bao giờ dẫn đến chiến thắng. Cho phép các yêu cầu đó truy cập vào trạng thái, cơ sở dữ liệu hoặc đường dẫn ghi là cách nhanh nhất để vượt quá ngân sách độ trễ. Chúng tôi cấu trúc trình đấu thầu như một cây quyết định được sắp xếp theo "xác suất thất bại", thực hiện các kiểm tra ít tốn kém nhất trước. Các bước kiểm tra được thực hiện theo trình tự như sau: : Một phần lớn các hồ sơ dự thầu thất bại ở bước này. Đây là một phép so sánh đơn giản và cho kết quả gần như ngay lập tức. Kiểm tra vị trí địa lý : Nếu khu vực địa lý đáp ứng yêu cầu, chúng tôi sẽ xác thực các ràng buộc về nền tảng và thiết bị. Kiểm tra hệ điều hành và thiết bị : Kiểm tra xem ứng dụng có phù hợp với kho ứng dụng cho phép của chúng tôi hay không. Xác định nhà phát hành/ứng dụng mục tiêu : Chỉ khi yêu cầu vượt qua các bộ lọc này, chúng ta mới xử lý các luồng xử lý phức tạp hơn - dữ liệu cấp người dùng, logic ngân sách và tốc độ, hoặc bất cứ điều gì yêu cầu sự phối hợp. Logic có trạng thái Bằng cách nhanh chóng loại bỏ các lỗi, chúng tôi từ chối 90% lưu lượng truy cập chỉ trong vài micro giây, dành riêng chu kỳ CPU cho các giá thầu thực sự mang lại chuyển đổi. 4. Kiến trúc dữ liệu: Redis cho các quy tắc, Aerospike cho các hồ sơ Chúng tôi chia kiến trúc dữ liệu của mình thành hai tầng dựa trên mô hình truy cập và chi phí của việc "dữ liệu lỗi thời". Các quy tắc: Redis cục bộ Mỗi nút lưu trữ siêu dữ liệu "nóng" (các chiến dịch đang hoạt động và giới hạn ngân sách) trong Redis cục bộ của nó. Một tiến trình cron sử dụng , truy cập API trung tâm của chúng tôi cứ sau 60 giây để tải xuống "thông tin chính xác" mới nhất. mô hình kéo Ở quy mô của chúng tôi, sự chậm trễ 60 giây này tạo ra một rủi ro: . Nếu nhiều nút cùng xử lý dữ liệu ngân sách đã lỗi thời, chúng có thể chi tiêu nhiều hơn số tiền mà máy khách đã phân bổ. Chi tiêu vượt mức Chúng tôi xử lý vấn đề này bằng : chúng tôi coi quy mô đội ngũ máy chủ như một yếu tố đầu vào để kiểm soát ngân sách. Khi số lượng các nút đấu thầu đang hoạt động tăng lên, mỗi nút sẽ tự động điều chỉnh "phần" ngân sách mà nó được phép sử dụng. Ngay cả khi một nút đang làm việc với dữ liệu cũ, giới hạn cục bộ của nó cũng đã được điều tiết dựa trên quy mô đội ngũ hiện tại. Chi tiêu giảm dần một cách mượt mà thay vì tăng đột biến, và hệ thống sẽ hội tụ ở chu kỳ làm mới tiếp theo. Cơ chế Phanh Các tính năng nổi bật: Aerospike (Ưu điểm của SSD) Tra cứu hồ sơ người dùng, giới hạn tần suất và nhắm mục tiêu lại yêu cầu truy cập tức thời vào các tập dữ liệu khổng lồ, có thể thay đổi. Một hệ quản trị cơ sở dữ liệu quan hệ truyền thống không thể xử lý khối lượng công việc này với mức giá của chúng tôi. Chúng tôi sử dụng cho lớp này vì nó được tối ưu hóa để coi SSD là bộ nhớ chính, thay vì lưu trữ toàn bộ tập dữ liệu làm việc trong RAM. Điều này giúp chúng tôi có độ trễ có thể dự đoán được trong khi vẫn giữ chi phí phần cứng ở mức thấp hơn nhiều so với giải pháp chỉ sử dụng RAM như ElastiCache. Aerospike Để giữ cho lớp này có giá cả phải chăng, chúng tôi rất nghiêm ngặt trong việc đảm bảo tính toàn vẹn dữ liệu: Quy tắc 10 ngày: Chúng tôi chỉ lưu giữ dữ liệu của những người dùng hoạt động trong 10 ngày gần đây. Giới hạn 10 triệu người dùng: chúng tôi chủ động lọc dữ liệu để chỉ giữ lại vài triệu người dùng hoạt động tích cực nhất. Nếu người dùng ngừng tương tác, dữ liệu của họ sẽ bị xóa. Quy trình này đảm bảo chi phí lưu trữ không thay đổi trong khi nhà thầu chỉ tập trung vào những người dùng quan trọng. 5. Bí quyết "Bất đồng bộ": Tách rời gánh nặng Về mặt kỹ thuật, phiên bản đầu tiên của chúng tôi cố gắng hoạt động bất đồng bộ. Chúng tôi sẽ gửi phản hồi đấu thầu ngay lập tức, và để hàm Node.js tiếp tục chạy ngầm để ghi nhật ký vào MongoDB. : Lưu lượng truy cập không ổn định mà tăng đột biến. Trong giờ cao điểm, mặc dù phản hồi đấu thầu đã biến mất, các container Node.js của chúng tôi vẫn "trôi nổi" - giữ các kết nối mở và tiêu tốn chu kỳ CPU để cố gắng hoàn thành việc ghi dữ liệu vào cơ sở dữ liệu. Điều này khiến bộ tự động mở rộng quy mô phải tạo thêm nhiều máy ảo chỉ để xử lý , dẫn đến việc cơ sở dữ liệu bị quá tải bởi các kết nối. Cái bẫy lượng dữ liệu ghi tồn đọng : Chúng tôi đã chuyển từ "Mã bất đồng bộ" sang " ". Chúng tôi đã giới thiệu như một bộ giảm chấn giữa luồng xử lý yêu cầu và luồng ghi dữ liệu. Giờ đây, luồng xử lý yêu cầu đẩy một thông điệp đến Kafka và ngay lập tức giải phóng tài nguyên của nó. Quá trình "ghi" được xử lý bởi một nhóm các tiến trình tiêu thụ riêng biệt với tốc độ được kiểm soát. Giải pháp Kiến trúc bất đồng bộ Kafka 6. So sánh hiệu suất: Đo lường, đừng đoán mò. Ở quy mô này, việc đoán loại đối tượng rất tốn kém. Vì vậy, thay vì dựa vào lý thuyết, chúng tôi đã tiến hành đo hiệu năng. Chúng tôi có các giả thuyết - liệu trình đấu thầu bị giới hạn bởi khả năng tính toán hay bộ nhớ, số lượng tiến trình xử lý hợp lý trên mỗi nút là bao nhiêu và kích thước phiên bản ảnh hưởng đến độ trễ như thế nào. Chúng tôi đã thử nghiệm trên nhiều dòng và kích thước phiên bản AWS khác nhau, và thay đổi số lượng dịch vụ đấu thầu chạy trên một nút duy nhất. Chúng tôi cũng áp dụng cách tiếp cận tương tự với lớp dữ liệu, thử nghiệm các loại máy khác nhau để xem loại nào hoạt động tốt nhất cho MongoDB dưới tải thực tế, ưu tiên độ trễ ổn định hơn là thông lượng tối đa. Tất cả những điều này đã được kiểm chứng bằng các bài kiểm tra tải, trong đó hệ thống xử lý yêu cầu mỗi giây (QPS) tương tự như môi trường sản xuất, đồng thời đo thời gian phản hồi và độ trễ cuối. Một số giả định là đúng. Nhiều giả định khác thì không. Tóm lại rất đơn giản: . với ngân sách 100ms, kết quả thực tế luôn vượt trội hơn lý thuyết 7. FinOps: Làm thế nào chúng tôi giữ mức phí ở mức 10.000 đô la. Các công ty khởi nghiệp không chết khi lưu lượng truy cập tăng đột biến. Chúng chết khi hết dung lượng lưu trữ đám mây. Đối với chúng tôi, kiểm soát chi phí không phải là điều được nghĩ đến sau cùng mà là một phần của thiết kế hệ thống. Một số khoản tiết kiệm đến từ việc đàm phán. Chúng tôi chuyển việc thanh toán thông qua nhà phân phối để được giảm giá theo số lượng. Về băng thông, chúng tôi cam kết , điều này cho phép chúng tôi đàm phán giảm giá CDN hơn 60% so với giá theo yêu cầu. Với lưu lượng truy cập của chúng tôi, cam kết đó đã tạo ra sự khác biệt đáng kể. khoảng 1 PB truyền tải mỗi tháng Chúng tôi cũng phân tách các mối quan tâm: máy chủ đấu thầu không trạng thái hoạt động trên dung lượng giao ngay được giảm giá mạnh, trong khi cơ sở dữ liệu có trạng thái sử dụng các phiên bản có thể dự đoán được và hoạt động lâu dài. Ở quy mô của chúng tôi, việc lưu trữ hàng trăm triệu bản ghi mỗi ngày là một quả bom hẹn giờ. Nhật ký đấu thầu chi tiết có thời gian lưu trữ ngắn - chỉ vài ngày chứ không phải vài tháng. Dữ liệu chúng tôi muốn giữ lại được tổng hợp sớm - theo giờ thay vì theo từng sự kiện - và được chuyển vào các kho lưu trữ rẻ hơn, dễ truy vấn hơn. Bất kỳ dữ liệu nào chỉ cần thiết cho việc tuân thủ hoặc kiểm toán lịch sử đều được chuyển vào kho lưu trữ lạnh, nơi chi phí giảm 80-90% so với các cấp độ tiêu chuẩn. Tuy nhiên, yếu tố tiết kiệm lớn nhất không phải là giảm giá, mà là đa. tận dụng tối Hầu hết các hệ thống đều chạy CPU ở mức 20-30% “vì lý do an toàn”. Hệ thống của chúng tôi thì không cần phải vậy. Bởi vì kiến trúc của chúng tôi có khả năng chịu lỗi và được thiết kế để giảm tải một cách mượt mà, chúng tôi hoàn toàn có thể vận hành CPU ở . Chúng tôi không phải trả tiền cho các chu kỳ nhàn rỗi. Nếu chúng tôi phải trả tiền cho một lõi xử lý, thì lõi đó đang hoạt động hết công suất. mức sử dụng 80% Tư duy đó - coi hiệu quả là một yếu tố hạn chế hàng đầu - là điều giúp hóa đơn không thay đổi ngay cả khi lưu lượng giao thông tăng lên. 8. Vận hành với ba người: Triết lý "Học phí" Vận hành quy mô toàn cầu với một nhóm ba người chỉ hiệu quả nếu hệ thống - chứ không phải con người - gánh vác mọi việc. Chúng tôi thiết kế hoạt động để loại bỏ sự can thiệp của con người khỏi các khâu quan trọng và loại bỏ các điểm lỗi đơn lẻ bất cứ khi nào có thể. Chúng tôi cũng tránh sự phân chia vai trò - mỗi kỹ sư đều có thể điều hướng toàn bộ hệ thống - do đó kiến thức vận hành không bao giờ là điểm lỗi duy nhất. Cơ sở hạ tầng mặc định là có thể loại bỏ. Nếu một nút hoạt động không đúng cách, chúng tôi không gỡ lỗi tại chỗ mà sẽ chấm dứt nó và để trình tự động mở rộng quy mô thay thế. Khôi phục nhanh hơn điều tra, và mỗi phiên bản đều bắt nguồn từ một trạng thái sạch sẽ, đã biết. Khả năng quan sát rất quan trọng, nhưng chỉ riêng bảng điều khiển thôi thì không đủ cho một nhóm nhỏ. Chúng tôi dựa vào các cảnh báo có thể hành động (thông qua Datadog) chỉ được kích hoạt khi cần sự can thiệp của con người. Nếu một cụm máy chủ khu vực chậm lại hoặc một người dùng nào đó bị tụt lại phía sau, chúng tôi sẽ nhận được thông báo. Mọi thứ khác đều được tự động hóa. Tuy nhiên, tự động hóa không phải là phép thuật. Chúng ta vẫn phải trả học phí định kỳ. Trong một sự cố ban đầu, một tác vụ nền chịu trách nhiệm cập nhật trạng thái ngân sách đã bị lỗi mà không báo trước. Nhà thầu tiếp tục hoạt động với dữ liệu cũ và chi tiêu cho một chiến dịch đáng lẽ đã kết thúc - một kịch bản "nhà thầu ma" điển hình. Chúng tôi đã hoàn tiền cho khách hàng, khắc phục lỗi và tăng cường bảo mật hệ thống bằng các kiểm tra nhịp tim được giám sát bởi Datadog. Giờ đây, tính cập nhật của ngân sách được hiển thị rõ ràng, và chỉ cần không có phản hồi cũng sẽ kích hoạt cảnh báo. Nếu nhà thầu không nhận được bản cập nhật hợp lệ, nó sẽ bị đóng. Trong một nhóm nhỏ, sai lầm là điều không thể tránh khỏi. Việc lặp lại những sai lầm đó là điều không bắt buộc. Lời kết Không có quyết định nào trong hệ thống này là mới lạ nếu xét riêng lẻ. Điều làm nên hiệu quả của nó chính là cách các quyết định đó được kết hợp lại với nhau. Các định luật vật lý mạng thiết lập ranh giới. Tính cục bộ và logic xử lý lỗi nhanh chóng bảo vệ đường dẫn 100ms. Các ranh giới không đồng bộ hấp thụ các luồng lưu lượng đột biến. Đo lường thay thế trực giác. Kỷ luật chi phí và tỷ lệ sử dụng cao đảm bảo tính kinh tế minh bạch. Hoạt động được thiết kế sao cho con người chỉ can thiệp khi hệ thống không thể tự phục hồi. Đây không phải là câu chuyện về công nghệ quảng cáo hay một nền tảng cụ thể nào. Nó là lời nhắc nhở rằng ở quy mô lớn, . Khi bạn coi độ trễ, chi phí và số lượng nhân lực là những yêu cầu hàng đầu, kiến trúc được tạo ra sẽ có xu hướng đơn giản hơn chứ không phức tạp hơn. các hạn chế không phải là trở ngại mà là các yếu tố đầu vào thiết kế Mục tiêu không phải là xây dựng một công trình ấn tượng. Mục tiêu là xây dựng một công trình có thể tồn tại lâu dài.