Poolování linků ve WebMedea
led
27
2019
WebMedea je založena na microservices architektuře, rozprostřené přes vlastní síť dedikovaných a virtuálních serverů. Jak si ji nejlépe představit? Viděli jste film Na hraně zítřka s Tomem Cruisem na motivy knihy All You Need Is Kill? Tak mimozemská entita, proti které hlavní hrdina bojoval, odpovídá architektuře WebMedei. Omegy jsou dedikované servery s aplikacemi nazvanými registry, ty všechno ví - jsou napojeny přímo na Cassandru a opečovávány ve špičkových datových centrech. Alphy odpovídají uzlům s aplikací nazvanou master, která dokáže nezávisle pracovat na složitějších výpočtech a řídit armádu slavů. Chobotnaté vetřelčí Bety z filmu představují aplikace typu slave, nasazené na velkém množství virtuálních serverů po celé republice. Každý slave vidí jen svého mastera, dotazuje se ho pro úkoly a odvádí rutinní práci. Slave je úplně odstíněn od registrů, může být okamžitě nahrazen a znásoben. Nutno podotknout, že slave se na internetu chová slušně.
Jedním z nejvíce zatížených míst v systému jsou registry, které musí neustále poskytovat data pro byznysové analýzy master uzlů. Přičemž největší tok dat způsobuje více než miliarda hypertextových odkazů napříč všemi weby v ČR, které jsou neustále sbírány, ukládány a analyzovány. Původní implementace registrů byla založena na javovském Cassandra driveru od Datastax a knihovně Spring Boot a umožňovala následující workflow:
- Master se dotázal REST rozhraní registrové aplikace
- Registry aplikace sestavila požadovaný dotaz a poslala jej Cassandře
- Pomocí
CassandraConverterRowCallback se z výsledkové sady vytvořily požadované objekty - Objekty se zpracovaly (druhotné vyfiltrování, seřazení, či jiné předzpracování)
- REST rozhraní registrů vrátilo Masterovi serializované pole požadových objektů
- Master deserializoval objekty a provedl s nimi potřebné operace
Uvedené řešení fungovalo spolehlivě zhruba do začátku léta 2018. Mezitím přerostl počet evidovaných hyperlinků miliardu. Narostla také hustota linků v okolí jednotlivých webů. Při zpracování začalo docházet k enormnímu paměťovému zatížení a to zejména u registry aplikací.
Situaci jsme se rozhodli vyřešit poolováním objektů v registry a master aplikacích. Protože jsme neměli kontrolu nad instancováním tříd v CassandraConverterRowCallback a při deserializaci Sprint Boot, byli jsme nuceni tuto funkci přenechat poolu. Implementace poolu byla jednoduchá, bylo jen potřeba pamatovat na to, že si do něj souběžně chce šahat více vláken...
@Component
public class LinkPool {
Deque<Link> links = new ConcurrentLinkedDeque<>();
public void recycle(Collection<Link> links) {
synchronized (this.links) {
this.links.addAll(links);
}
}
public void recycle(Link link) {
synchronized (links) {
this.links.add(link);
}
}
public Link getLink(Row row) {
Link link = null;
synchronized(links) {
while (link == null) {
if (links.isEmpty()) {
return new Link(row);
}
link = links.poll();
}
}
return link.fromResultSetRow(row);
}
}
Další optimalizací bylo snížení trafficu mezi registry a masterem. Byznys vrstvy pracují s linky na úrovni logických celků. Naše výpočetní algoritmy jsou založeny na principu procházení grafu do šířky. Tím pádem se systematicky přesouvají od jedné domény na druhou a zpracovávají jejich okolí. No a projít okolí domácích gigantů jakými jsou iDnes, nebo Firmy.cz vyžaduje přechroustat velké množství linků, ve kterých se zdrojové a cílové domény často opakují. Indexací duplicit při serializaci v registrech a opětovným zrekonstruováním linků při deserializaci v master aplikacích se nám v ideálním případě podařilo zmenšit traffic až o 50%.
Souběžně s optimalizací aplikace Marek vyčlenil master server Ares pouze k účelu analýz nad linky. Řešení se ukázalo být stabilní a neustále rostoucí databázi zvládáme bez velké zátěže vyhodnocovat.