Abstrakní Wikipedie/První vyhodnocovací engine

Kde a jak by měl být náš první evaluační motor nasazen a jak by měl být navržen?

Cílem Wikifunkcí je nakonec vytvořit zdravý ekosystém interoperabilních hodnotících nástrojů. Poskytneme přesně definovaný popis toho, co evaluační engine MUSÍ a MĚL BY dělat, a doufáme, že budou existovat evaluační enginy běžící v mnoha různých kontextech - od malých vestavěných evaluačních enginů v nativních aplikacích, které chtějí používat určité funkce, přes evaluační enginy běžící jako mobilní aplikace nebo místní servery až po výkonné evaluační enginy běžící v cloudu nebo v distribuované síti peer-to-peer. Nadace Wikimedia bude muset provozovat jeden nebo více evaluačních enginů, aby mohla zajistit funkce, na kterých budou projekty Wikimedia záviset. Nad těmito a mnoha dalšími tématy se zamyslíme jindy.

Nyní musíme zjistit, kde by měl být umístěn náš první evaluační engine. Ačkoli by bylo skvělé, kdybychom nakonec realizovali všechny z nich, musíme být realističtí, pokud jde o naše zdroje, a měli bychom se nejprve zaměřit pouze na jednu z nich. Zdá se, že při první implementaci je třeba zvážit tři hlavní možnosti:

1. Zabudované v rozšíření WikiLambda.
2. Samostatná služba.
3. Vše se vyhodnocuje v prohlížeči čtenáře.

Musíme to rozhodnout dříve, než začneme pracovat na Fáze δ, kde tento evaluační engine implementujeme. Zde se budeme zabývat výhodami a nevýhodami těchto tří hlavních přístupů a také možnými variantami v rámci těchto přístupů.

Hlavní možnosti

Rozšíření WikiLambda

Samotné rozšíření WikiLambda poskytuje nejen rozšíření wiki pro úpravu a údržbu ZObjectů na wiki, ale také obsahuje evaluační engine. Rozšíření zpřístupňuje evaluační engine prostřednictvím rozhraní API světu a jeho internímu použití.

Klady:

• Nasazení rozšíření WikiLambda je snadné, protože nemusíme nasazovat sekundární balík pro evaluační engine (i kdybychom se nyní touto cestou nevydali, mělo by smysl mít v rozšíření zabudovaný evaluační engine, aby se umožnilo snadné nasazení, což také pomůže k tomu, aby lidé snadněji přispívali do báze kódu).
  V kódu PHP jsme již začali vytvářet objekty s určitými schopnostmi a můžeme na nich dále stavět.
• Je to zdaleka nejrychlejší a nejjednodušší způsob, jak získat přístup ke všem ostatním objektům ZObject, které bychom potřebovali k vyhodnocení daného volání.
• Protože chceme, aby rozšíření volalo přispívající funkce žijící na wiki, aby poskytlo některé ze svých zkušeností, mít je okamžitě k dispozici je zdaleka nejpohodlnější řešení s nejmenší režií.
• Je možné znovu použít vše, co již v MediaWiki existuje, a poskytnout tak rozhraní API, např. ověřování, tokeny atd.

Zápory:

• Z hlediska bezpečnosti je to vysoce rizikové, protože by při nasazení běželo na hlavním clusteru. Pokud by se někomu podařilo proniknout z vestavěného systému, měl by přímý přístup do produkčních databází, protože wiki má přístup k příslušným přihlašovacím údajům.
• Z hlediska bezpečnosti může být také prostředkem pro úmyslný nebo dokonce neúmyslný útok DOS, protože se spouštějí náročné evaluace a zamykají produkční instance MediaWiki.
• Je obtížné vyhodnocování v rámci rozšíření sandboxovat, protože vše je v jednom kódu PHP.
• Potřeba implementovat monitorování, časová a paměťová omezení v rámci MediaWiki.

Samostatná služba

Vyvíjíme samostatnou službu, kterou lze volat prostřednictvím REST a která umožňuje vyhodnocovat volání funkcí. Službu využívají externí i interní klienti.

Klady:

• Je možné vyvinout vše od začátku. Žádná omezení kvůli MediaWiki, služba může být tak úsporná, jak nám to umožní stack, na kterém stavíme.
• Služba může být uzavřena v sandboxu, monitorována a jako celek může mít časový a paměťový rozpočet.
• Dokáže vytvořit ucelený a jednotný přístup k ukládání do mezipaměti v rámci evaluačního mechanismu.
• Lze snadno rozšířit spuštěním více služeb ve více boxech. Dokonce umožňuje architekturu, kde se jeden server může rozhodnout zavolat další servery, a tak paralelizuje části volání, což je něco, co je obtížné implementovat v ostatních dvou zde diskutovaných přístupech.

Zápory:

• Je nutné vše vyvinout od začátku. Spousta potenciálu pro výměnu nástrojů, pokud jde o jazyk implementace, zásobník a přístup k nasazení.
• Znamená to také mnohem více příležitostí k zavedení nových chyb.
• Je třeba zjistit, jak spustit novou produkční službu pro spuštění (ale do té doby může běžet na WMFCloudu nebo jiné infrastruktuře).
• Je nutné číst hodně z DB, takže je důležité, aby to bylo možné rychle. Jedná se však o přístup pouze pro čtení.
• Vznikají náklady každému, kdo nasadí rozšíření a chce na něm pracovat, protože musí službu také nastavit.

Prohlížeč

Evaluace funkcí nemusí vůbec běžet na infrastruktuře Wikimedia, ale mohou být spuštěny v prohlížečích uživatelů.

Klady:

• Snadné nasazení.
• Těžko může mít nepříznivý vliv na obslužnou infrastrukturu.
• Není třeba omezovat zdroje pro čtenáře, protože se jedná o jejich vlastní zdroje.

Zápory:

• Je nutné si dávat velký pozor, aby nedošlo k útokům na čtenáře.
• Pravděpodobně povede k pomalému provozu u mnoha klientů, což povede k tomu, že bude přístupný pouze uživatelům s lepším vybavením, což je v rozporu s našimi cíli.
• Vyhodnocovací engine může potřebovat načíst hodně dat z DB, což může mít za následek dlouhé doby přístupu do wiki, protože prohlížeč musí přistupovat k databázi.
• Není možné volat kód na straně serveru (ledaže bychom jej vyvíjeli paralelně řekněme na uzlu, takže by mohl běžet v prohlížeči i v backendu, ale to je v podstatě vývoj a údržba dvou řešení, i když sdílejí část kódu).
• Možnosti ukládání do cache jsou značně omezené, zejména u uživatelů, u nichž se očekávají obrovské přínosy.
• Není přívětivé pro vyhledávače.
• Nelze dále zpracovat (například {{Str left|{{#lambda:xxx}}|123}}).

Architektura pro samostatnou službu

V současné době se přikláníme k vývoji prvního evaluačního engine jako samostatné služby. Nasazení jako součást MediaWiki je považováno za příliš mnoho potenciálních bezpečnostních a výkonnostních rizik, stejně jako spuštění v prohlížeči. Doufáme, že se k rozhodnutí o prohlížeči vrátíme později.

V ideálním případě může být evaluační engine mnohokrát spuštěn a orchestrován jako bezstavová služba. Služba je "pouze pro čtení", modulo caching a monitoring.

Evaluační engine zpřístupňuje rozhraní API přes protokol HTTP, které přijímá objekt ZObject jako vstup a vrací objekt ZObject jako výstup. Vrácený objekt ZObject je výsledkem vyhodnocení příchozího objektu ZObject, dokud není dosaženo pevného bodu. To je nejzajímavější pro volání funkcí.

Služba bude výrazně těžit z ukládání do cache. V souvislosti s vyhodnocovacím mechanismem existují (přinejmenším) tři úrovně ukládání do cache:

• Cache HTTP: ukládání celého volání API do cache evaluačnímu enginu na úrovni volání HTTP. Při stejném volání se vrátí stejný výsledek.
• cache mezivýsledků: když evaluační engine vyhodnocuje volání funkce, měl by zkontrolovat, zda má dané volání funkce ve své cache, a místo toho vrátit tento výsledek. Bylo by výhodné, kdyby všechny paralelně spuštěné evaluační enginy mohly používat stejnou cache.
• cache obsahu: reference jsou vyhledávány ve wiki. To by mohlo být také přesunuto z wiki, zejména pokud máme sdílenou cache. Může být součástí cache mezivýsledků.

Nakonec budeme muset umožnit volání REST na jiné služby Wikimedia a externí služby (např. Wikidata, předpověď počasí atd.), stejně jako změnu věcí, jako je aktuální čas, a také náhodné hodnoty.

Jak je to s podmínkami běhu, když se funkce upravují za běhu?

Byly by evaluační enginy homogenní, nebo různorodé? Tj. mohl by existovat evaluační engine, který může používat TPU, a jiné, které to nedělají, a jak směrovat dotazy? Jednoduchá myšlenka: musí všechny evaluační enginy rozumět všem programovacím jazykům, nebo je můžeme zjednodušit tím, že budeme mít specializované evaluační enginy, kde některé mohou spustit Python, jiné JavaScript atd.

Některé technologie, které je třeba zvážit:

• Kubernetes
• OpenWhisk
• Apache Ignite

Návrh kroků prvního evaluačního enginu

Pořadí následujících kroků nemusí nutně odpovídat uvedenému pořadí. Zabudované prvky jsou na prvním místě, ale většina ostatních je na sobě poměrně nezávislá.

Zabudované prvky

Viz phabricator:T260321.

• Velmi malé API - možná dokonce stačí začít s jedinou evaluační metodou a to je vše.
• Žádné kešování.
• Implementuje některé (nebo všechny) z první sady zabudovaných modulů popsaných v tasku phabricator:T261474.
• Vše, co není voláním funkce, se vrátí tak, jak je (možná kanonizované).
  Příklad: "Test" se vyhodnotí jako "Test".
• Vše, co je voláním funkce, se vyhodnocuje až do konečného výsledku.
  Příklad: if(true, "Yes", "No") se vyhodnotí jako "Yes".
• Pokud jsou argumenty voláními funkcí, vyhodnotí se také, až do konečného výsledku.
  Příklad: head(tail(["1", "2", "3"])) se vyhodnotí jako "2".

Všimněte si, že to vše již vyžaduje, aby byly reference řešeny na wiki. Funkce head je funkce ve wiki a je třeba ji vyhledat, shromáždit její implementace (zatím máme pouze vestavěné implementace), vybrat implementaci a vyhodnotit ji.

První verzí výběru implementace je výběr libovolný. To je třeba později upřesnit.

Sandboxing a monitorování

Proveďte všechny potřebné kroky pro sandboxing a monitorujte evaluační enginy (Phabricator:T261470).

Mnoho z toho by mělo být k dispozici prostřednictvím Kubernetes. Pravděpodobně bychom ale také chtěli vést statistiky, jako například "jak často byla funkce volána?", "jak často došlo k chybě cache" atd.

Cache mezivýsledků

Zavedení ukládání mezivýsledků do cache.

Před vyhodnocením volání funkce zjistěte, zda je tato funkce v cache, a vraťte ji místo ní.

Povolte obnovení mezipaměti.

Editace zneplatňuje cache

Editace existujícího objektu ZObject zneplatní celou cache. Toto chování se bude pomalu zlepšovat. (V ideálním případě se při editaci zneplatní pouze ty cache, které je třeba zneplatnit, ale to se rychle zkomplikuje. K tomu se dostaneme později.)

Vyžaduje přechodné ukládání do cache.

Skládání implementací

Povolit implementace, které jsou kompozicemi (Phabricator:T261468).

Implementace JavaScriptu

Umožňuje implementaci v jazyce JavaScript.

Wikidata

Možnost volat Wikidata.

Commons

Možnost vyvolat soubory ve službě Commons.

Další Wikimedia projekty

Možnost volat do jiných projektů Wikimedia.

Volání do webu

Možnost volat na obecný web.

Nefunkční funkce

Zejména "aktuální čas" a "náhoda".