Platforma, która rozwiązuje problemy wydajności i skalowalności giełd reklam

Główne wyzwania, które postanowiliśmy rozwiązać, koncentrowały się wokół skalowalności i wydajności.

Konkretnie chcieliśmy zbudować giełdę reklamową, która może reagować na dużą liczbę żądań reklamowych i biddingowych bez opóźnień.

Na początku zidentyfikowaliśmy następujące wyzwania techniczne:

• Aby utrzymać szybki czas odpowiedzi, giełda musi się szybko skalować.
• Zapytanie o asortyment może zajmować dużo czasu, a w odpowiedzi może pojawić się duży pakiet danych.
• Zmiany w asortymencie dokonywane przez użytkownika (np. wydawcę lub AdOps obsługującego SSP) muszą być przekazywane do wszystkich instancji giełdy.
• Proces ten nie może być wykonywany po każdej aktualizacji w SSP, ponieważ spowodowałoby to nieprzewidywalną liczbę operacji “propagacji”, co mogłoby wpłynąć na wydajność giełdy.

Bez właściwego rozwiązania tych wyzwań dostawcy SSP/giełd reklamowych napotykają następujące problemy biznesowe:

• Wydawca nie jest w stanie sprzedać całego dostępnego asortymentu, co skutkuje niskimi wskaźnikami wypełnienia (fill rate) i mniejszymi dochodami z reklam.
• Wydawca traci możliwość wyświetlenia reklamy odwiedzającemu i potencjalnym dochodom z reklam, ponieważ giełda reklamowa nie odpowiada na czas – zazwyczaj licytacja RTB kończy się w ciągu 250 ms, co oznacza, że giełda reklamowa musi otrzymać i odpowiedzieć na żądania reklamowe/licytacyjne w tych ramach czasowym.

Na podstawie naszej wiedzy na temat SSP/giełd reklamowych i RTB, a także obszernej analizy tematu, rozwiązaliśmy wszystkie wyzwania.

Rozwiązaliśmy problem ze skalowalnością

Aby zapewnić skalowalność giełdy reklamowej – tj. otrzymywać, obsługiwać i przetwarzać więcej żądań reklamowych i biddongowych, wdrożyliśmy architekturę mikroserwisów w połączeniu z wzorcem skalowania horyzontalnego.

Taka architektura jest stosowana w projektach, gdzie działanie aplikacji dzieli się na indywidualne i powiązane ze sobą usługi.

Każda z takich usług może być rozwijana, wdrażana i utrzymywana niezależnie od reszty aplikacji i komunikuje się z resztą mikroserwisów za pomocą API.

Oto korzyści płynące z tego rozwiązania:

• Każdy mikroserwis może skalować się niezależnie, dzięki czemu jesteśmy w stanie wyskalować giełdę reklam do pożądanego poziomu.
• Możemy wdrażać te usługi indywidualnie, a nie jako całość, co skraca czas wdrożenia.
• J​eśli jeden mikroserwis będzie wadliwy, możemy odizolować go od reszty aplikacji. Taka wada nie wpłynie na działanie giełdy reklamowej, która wciąż pozostaje wydajna.

Rozwiązaliśmy problem z wydajnością

Główne wyzwania wydajności w SSP/giełdzie reklamowej dotyczą jej zdolności do:

• Obsługi dużych ilości zmian asortymentu dokonywanych w SSP.
• Przekazywania tych zmian do wszystkich instancji giełdy.
• Zapewnienia, aby instancje giełdy reklamowej mogły obsługiwać to zadanie wymagające dużych zasobów bez powodowania nieoczekiwanych problemów wydajnościowych w SSP.

Aby rozwiązać te wyzwania, wprowadziliśmy komunikację międzyserwisową za pomocą warstwy publikuj-prenumeruj (pub/sub) i opracowaliśmy usługę populatora.

Komunikacja międzyusługowa za pomocą warstwy publikuj-prenumeruj (pub/sub)

Pub/sub to wzorzec przesyłania wiadomości zaprojektowany do publikowania i odbierania wiadomości, subskrybując określony kanał lub temat.

Aby zrealizować wzorzec pub/sub, wybraliśmy NATS, usługę przesyłania wiadomości open-source.

Jego rolą w środowisku SSP jest informowanie instancji giełdy o wszelkich zmianach w asortymencie.

Z uwagi na charakter usług NATS, pub/sub dostarcza prostego, bezpiecznego i szybkiego rozwiązania problemu dystrybucji wiadomości.

Ponieważ pub/sub jest rozwiązaniem bez kolejek, eliminuje wiele problemów związanych z kolejkami i ich ograniczeniami.

Populator service

Zazwyczaj, gdy zmiana jest dokonywana w SSP, każda instancja giełdy musi pobrać zmiany w asortymencie przy starcie aplikacji.

Jeśli każda instancja giełdy odpytywałaby SSP i pobierała asortyment bezpośrednio, obsługa tych żądań wymagałaby dużych zasobów i prawdopodobnie spowodowałaby awarię SSP.

Aby poradzić sobie z tym wyzwaniem, wprowadziliśmy populator service (populator), która funkcjonuje jako proxy i punkt komunikacyjny między instancjami giełdy a SSP, zapewniając wysoką wydajność giełdy.

Populator service informuje instancje giełdy o nowych zmianach, aktualizuje asortyment w instancjach giełdy w określonym interwale i przygotowuje asortyment do łatwego ładowania.

To oznacza, że zadanie wymagające dużych zasobów, jakim jest dostarczenie nowego asortymentu, jest wykonywane w przewidywalny sposób. Wyeliminowaliśmy w ten sposób problem wydajności SSP.

Jak działa populator service

Usługa:

• Pyta SSP o asortyment przy starcie aplikacji.
• Tworzy unikalny skrót dla odpowiedzi.
• Przechowuje odpowiedź jako plik w usłudze takiej jak Google Cloud Storage.
• Publikuje lokalizację pliku na temat pub/sub.
• Pyta SSP o asortyment według harmonogramu.
• Porównuje skrót odpowiedzi z poprzednim.
• Jeśli się różni, przechowuje odpowiedź i publikuje lokalizację pliku na temat pub/sub.

Aby zapewnić sobie najnowszy asortyment, giełda:

• Pyta populatora o lokalizację pliku asortymentu przy uruchamianiu.
• Subskrybuje temat pub/sub, aby otrzymywać powiadomienia o nowych plikach asortymentu.
• Pobiera nowe pliki i zastępuje nimi swój asortyment.

Po pobraniu informacje są przechowywane lokalnie przez instancje giełdy.

Dzięki temu ustawieniu giełda zawsze ma informacje o stanie inwentarza w swojej pamięci. Aby zweryfikować ich ważność, nie musi pobierać plików z przechowywania, co zajęłoby dużo czasu i zasobów; zamiast tego słucha populatora (pub/sub) w celu uzyskania informacji o ewentualnych zmianach w inwentarzu.

To przekłada się na szybszą wydajność, ponieważ nie trzeba każdorazowo prosić SSP o identyfikatory ad-slotów przy każdej aukcji RTB. Dlatego, że giełda już ma je przechowywane w bazie danych w pamięci.

Szybsza wydajność przekłada się na ogólną poprawę czasu odpowiedzi reklamy/oferty potrzebnego do przeprowadzenia aukcji RTB.

• Stabilność: Ponieważ zmiany w inwentarzu dokonywane w SSP są pytane tylko przez populatora, są one przewidywalne i niezależne od liczby aktualizacji w systemie.
• Skalowalność: Architektura mikroserwisowa pozwala SSP na wdrożenie dużej liczby instancji giełdy, co ostatecznie przekłada się na większe przychody z reklam dla wydawców.
• Aktualny stan inwentarza: Wszystkie instancje giełdy są informowane o zmianach w inwentarzu jednocześnie.
• Poprawiona wydajność: Wszystkie instancje giełdy pobierają nowy inwentarz jednocześnie, bez obciążania SSP ani populatora.

Nasze rozwiązanie SSP/giełdy reklamowej zostało zaprojektowane, aby:

• Przyspieszyć fazę rozwoju SSP.
• Poprawić wydajność i skalowalność istniejących SSP.