Slave roboti WebMedea

led 31 2019
V předchozím příspěvku jsem psal, že se naše slave aplikace na internetu chovají slušně. Co si pod tím představit? Ve WebMedea se na internet díváme jako na les. Les si žije svým životem, roste a mění se nezávisle na WebMedea. Ta jej pouze z každého jeho místa pozoruje. Jak? Naše infrastruktura představuje mraveniště rozesetá po lese. Slave aplikace pak představují mravenečky sbírající po lese kousíčky informací, které odnáši do mraveniště.
 

mravenci, PixaBay

Obr. 1: Roboti WebMedea jsou hodní mravenečci :), zdroj PixaBay

Za prvé, slave aplikace respektují robots.txt na webech. Pokud si autoři webu nepřejí, aby určité části webu procházeli roboti, naše slavy to respektují. Zkrátka mraveneček není dotěrný a nevleze do nory zvířátku, které si to nepřeje. 
 
Za druhé, slave aplikace poslouchají svého mastera, který je neposílá dvakrát na to samé místo dříve, než za určitou dobu. Z daného webu si tak slave odnese jen potřebné minimum informací, které předá masterovi (a ten registrům), a na web se vrátí až když je informaci nutné aktualizovat. Mravenečci jsou tedy organizovaní a neshlukují se opakovaně na jednom místě v lese a nepustoší ho.
 
Za třetí, slavy jsou šetrné ke službám Seznamu a Google, data si berou jednou za čas a v malých množstvích. Master aplikace vyhodnocují priority - o která data si kdy říci. Analogie: Mravenečci sbírají jehličí kolem stromů a nosí je do mraveniště.
 
Toto není samo sebou, zatímco WebMedea slave je mraveneček, existují aplikace, které se v lese chovají jako dřevorubci. Zadavatel řekne dřevorubci, co má natěžit, dřevorubec vezme sekeru a jde rubat. Rube hlava nehlava. Čím více lidí chce natěžit data, tím více dřevorubců nenávratně devastuje les. Ekonom i ajťák si snadno udělají obrázek o škálovatelnosti takové služby i její závislosti na okamžité dostupnosti plundrovaného lesa. :) 

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:
  1. Master se dotázal REST rozhraní registrové aplikace
  2. Registry aplikace sestavila požadovaný dotaz a poslala jej Cassandře
  3. Pomocí CassandraConverterRowCallback se z výsledkové sady vytvořily požadované objekty
  4. Objekty se zpracovaly (druhotné vyfiltrování, seřazení, či jiné předzpracování)
  5. REST rozhraní registrů vrátilo Masterovi serializované pole požadových objektů
  6. 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.