Vytváření platformy služeb OCI — Unified API Conductor

V tomto článku se budu zabývat naším přístupem k řešení behaviorální konzistence prostřednictvím služby pro konzistenci platformy. Také se ponoříme do výzev spojených s architekturou této centralizované platformy a prozkoumám „zlaté cesty", které pomáhají urychlit poskytování služeb zákazníkům a aplikovat efektivní dodržování předpisů pro bezpečnost zákazníků. Sdílením našich zkušeností a poznatků se také snažíme poskytnout cenný zdroj organizacím, které se potýkají s konzistencí ve své architektuře mikroslužeb.

Pozadí

V počátcích Oracle Cloud Infrastructure (OCI) měli omezený počet cloudových služeb, které přímo interagovaly s platformovými službami, jako jsou Identity a Audit. Servisní týmy také spravovaly platformu API spolu se svými službami. Platforma API nabízí funkce směrování a omezování. Jak je znázorněno na obrázku 1, služby Infrastructure-as-a-Service (IaaS), jako jsou Compute, Block Storage a Virtual Cloud network, byly hostovány za instancí služby platformy Public API. Podobně se sada databázových služeb nacházela za jinou instancí služby platformy Public API atd. Tato jednoduchá architektura nám umožňovala spravovat a udržovat naše služby relativně snadno.

Obrázek 1: Pohled na platformu služeb Public API z ptačí perspektivy.

Ve skutečnosti vypadaly interakce mezi navazujícími službami a službami platformy podobně jako v části „kde jsme byli" na obrázku 2. Interakce mezi službami jsou složité a není snadné je řešit. Jakékoli změny v platformové službě vyžadují změny ve více navazujících službách. Naším cílem je zjednodušit interakce, které jsou znázorněny v části „kde chceme být" na obrázku 2.

Obrázek 2: Tok požadavků mezi službami

Platforma API se spoléhá na konfigurační soubory pro správu směrování API a jeho chování. Jak je vidět, níže uvedený snímek obsahuje ukázkovou konfiguraci pro konfiguraci API Matcher. Obsahuje seznam cest regulárních výrazů používaných pro porovnávání cest příchozích požadavků. Jakmile je API identifikováno, použije se k určení koncového bodu API a jeho chování další konfigurační soubor zdroje.

Ukázková konfigurace porovnávače API

Tato architektura funguje dobře pro malou sadu služeb. S růstem naší nabídky cloudových služeb jsme se setkali s následujícími problémy.

• Nedostatečná znalost funkcí platformy by mohla vést k výpadkům nebo bezpečnostním mezerám, zejména v oblasti ověřování a autorizace.
• Veškeré aktualizace nebo opravy sady SDK platformy vyžadují provedení změn v každé službě, což má za následek náklady na údržbu úměrné počtu služeb.
• Mezi týmy platformy a servisními týmy probíhala značná komunikace, což bylo časově náročné a neefektivní.

V jednom z našich největších regionů jsme zaznamenali konzistentní 15% čtvrtletní nárůst míry požadavků. Po přezkoumání naší architektury se ukázalo, že funkce platformy, které zahrnují více služeb, výrazně zvyšují celkovou složitost služby. Tyto funkce napříč službami zavádějí další závislosti, interakce a potenciální body selhání, což ztěžuje údržbu, aktualizaci a škálování platformy.

Architektura servisní platformy

Kromě výzev, které byly uvedeny ve výše uvedené architektuře, jsme chtěli službu, která by dokázala směrovat provoz přes 400 cloudových služeb. Služba by musela být bezstavová, flexibilní, škálovatelná a super spolehlivá. Musela by zohledňovat scénáře hlučných sousedů a mít nízkou latenci pro funkce platformy. To by pomohlo zajistit, aby provoz do navazujících služeb byl vysoce předvídatelný.

Proxy služba hraje v naší architektuře klíčovou roli tím, že funguje jako brána pro všechny příchozí požadavky. Aplikuje klíčové funkce založené na požadavcích, což pomáhá zajistit bezpečný a kontrolovaný přístup k navazujícím službám. Pro přesné použití těchto funkcí však proxy vyžaduje od vlastníků služeb podrobné informace o funkcích specifických pro platformu a souvisejících vstupech. Zde vstupují do hry specifikace Swagger, které nabízejí standardizovaný způsob dokumentace RESTful API. Využitím těchto specifikací pomáháme zajistit přímočarý proces konfigurace a snižujeme potřebu složitých konfiguračních souborů. Registrátor služeb je ústřední komponentou, která tento proces usnadňuje a poskytuje platformu pro vlastníky služeb k nahrávání a nasazování jejich specifikací Swagger, což umožňuje proxy službě bezproblémově aplikovat potřebné funkce na úrovni API.

Obrázek 3: Architektura platformy služeb na vysoké úrovni

Vzhledem k tomu, že jsme v proxy vrstvě řešili funkce založené na požadavcích, rozhodli jsme se posunout naši platformu služeb na další úroveň a zaměřit se na další sadu funkcí platformy, které jsou založeny na zdrojích. Za tímto účelem jsme zavedli službu metadat zdrojů. Jak je znázorněno na obrázku 3, proxy volá tuto službu metadat pro použití funkcí založených na zdrojích, jako je vynucování limitů zdrojů, indexování zdrojů atd.

Proxy také načítá specifikace služeb z registrátora a ukládá je do mezipaměti na disk. Specifikace se pravidelně aktualizují na pozadí. Díky tomu je registrátor měkkou závislostí. Co nejméně závislostí zvyšuje odolnost. Proxy se integruje s dalšími službami platformy, aby umožnil funkce platformy. Jakmile jsou funkce povoleny prostřednictvím proxy, není nutné, aby navazující služby, jako je Compute, komunikovaly s Identity.

Cesta požadavku na cloudovou službu

V současné době služba Proxy směruje více než 65 tisíc různých API a dokáže zpracovat několik stovek tisíc požadavků za sekundu. Vzhledem k tomu, že máme obecný přehled komponent Platformy služeb, podívejme se na cestu požadavku.

Obrázek 4: Tok požadavků v Platformě služeb. 

Když je požadavek odeslán na jakoukoli cloudovou službu, je směrován na hostitele proxy služby. Platforma služeb podporuje pouze připojení HTTPS, což nabízí bezpečnou komunikaci mezi klienty a službami. Správa DNS a certifikátů pro více služeb může být složitá a mnoho organizací se potýká s výpadky souvisejícími s certifikáty. Naproti tomu náš přístup na vrstvě platformy služeb zahrnuje pravidelné monitorování certifikátů pro upstream i downstream. Tento proaktivní přístup nám umožňuje detekovat a řešit potenciální problémy dříve, než ovlivní naše služby.

Jak je znázorněno na obrázku 4, sekvenční diagram ukazuje příklad toho, jak platforma služeb zpracovává funkci založenou na požadavcích a funkci založenou na zdrojích. Následující kroky poskytují podrobnější pohled na proces zpracování požadavků.

Proxy služba je jako dirigent v orchestru, který využívá jiné platformové služby k poskytování nezbytných funkcí platformy pro následné služby.

Zjednodušení architektury servisní platformy prostřednictvím standardizace

Strávil jsem roky prací na jednotné implementaci pro všechny funkce platformy a mohu potvrdit, že dosažení tohoto cíle je složitější, než se zdá. Z mých zkušeností vyplývá, že různé služby napsané v různých jazycích a zveřejňující svou funkcionalitu různými metodami, jako jsou API, SOAP a RPC, nám mohou ztížit jejich podporu a zkomplikovat architekturu naší servisní platformy. Vzpomínám si na nespočet hodin strávených řešením problémů, které vznikly při snaze integrovat společné funkce napříč různými platformami, a věděl jsem, že potřebujeme lepší přístup.

Abychom se s tímto problémem vypořádali, zavedli jsme technické postupy a proces vydávání, které podporují standardizaci. Doporučujeme, aby nové služby byly klonovány z klasické služby. Také pomáháme zajistit, aby naše veřejná API splňovala oborové standardy. V důsledku toho se nyní přibližně 80 % našich služeb řídí standardními pokyny, což výrazně zlepšilo architekturu naší servisní platformy a organizační efektivitu.

Ve společnosti Oracle upřednostňujeme potřeby našich zákazníků. Postupem času jsem zjistil, že nejúspěšnější produkty jsou ty, které řeší specifické problematické body. Například nastavení ověřování pro API je zcela odlišné od auditu volání API a požádat týmy, aby pro tyto funkce provedly různé kroky, může být skutečnou otravou. Proto potřebujeme platformu, která poskytuje konzistentní způsob, jak tyto funkce zvládat.

Dovolte mi ukázat vám příklad, jak to děláme. Používáme vlastní rozšíření v definici API s názvem x-platform. Vypadá to takto:

Spuštění instance API

/instances:

  post:

    x-platform:

       audit:

         mode: enabled

         additionalFields: 

            ipAddress: response.body.IpAddress

       authentication:

         mode: oci-signature

Každá služba se může trochu lišit, takže musíme být schopni tyto rozdíly zohlednit. A právě zde přichází na řadu Groovy – dynamický skriptovací jazyk, který nám umožňuje reprezentovat logiku velmi stručným způsobem. Ve výše uvedeném příkladu mohl Compute přidat další atributy k auditním událostem. To nám dalo spoustu flexibility a pomohlo nám to vyhnout se vlastnímu kódu pro konkrétní služby.

Služba metadat zdrojů

Pojďme se trochu hlouběji ponořit do architektury služby Resource Metadata.

Když služba metadat obdrží požadavek od služby proxy, zkontroluje, zda je požadavek v rámci limitů služby, aby se zajistila spravedlivost mezi zákazníky. Metadata sledují využití na úrovni zdrojů/účtů a ukládají tato data do relačních databází.

Pokud je požadavek v rámci limitů, Metadata vytvoří požadavek na sladění pro sledování stavu zdroje. Pokud zpracování selže, Metadata vrátí stav zdroje do původního stavu pomocí protokolu dvoufázového potvrzení, aby se zajistila konzistence. Služba poté dotazuje stav zdroje pomocí exponenciálního algoritmu zpětného odečtu, dokud nedosáhne svého konečného stavu, načež se použijí další funkce založené na zdrojích.

Abyste si udělali představu o tom, jak velký tento systém je, v jednom z našich největších regionů spravuje služba metadat přes 200 milionů zdrojů. Data jsou na aplikační úrovni segmentována na základě tenancí. Tenancí je izolované prostředí pro správu cloudových zdrojů. To znamená, že všechny požadavky zákazníka jsou obsluhovány z jediné segmentace. Díky segmentaci dat dosahujeme vysoké propustnosti a snižujeme dopad výpadků databáze.

Máme také záložní databáze připravené k přepnutí v případě selhání nebo údržby a pravidelně zálohujeme data pro obnovu. Všimli jsme si, že některé shardy se mohou kvůli alokaci aktivních tenancí „zahřát". Abychom vyvážili provoz a objem požadavků, implementovali jsme živé reshardování na úrovni aplikace. To nám umožňuje migrovat data o zdrojích z aktivních shardů do méně aktivních shardů bez jakýchkoli prostojů.

Jakmile jsme pro platformu integrovali naše klíčové služby, jako jsou výpočetní výkon, virtuální sítě a blokové úložiště, začali jsme pozorovat skutečná zlepšení. Prováděli jsme interní testy se společností Gartner pro spuštění instancí a výsledky byly konzistentně skvělé. Problém byl v tom, že existovala všechna tato dodatečná volání úložiště, která vše zpomalovala – a ani nesouvisela s vytvářením samotného zdroje. Mluvíme o věcech, jako je aktualizace záznamů o využití a ukládání dat pro zpracování na pozadí za účelem indexování zdrojů. Ale s implementací funkcí platformy jsme byli schopni proces zefektivnit a API výrazně zefektivnit.

Škálování servisní platformy

Nyní, když jsme hovořili o architektuře služby metadat zdrojů, pojďme se o krok vrátit a podívat se na širší souvislosti. Abychom zajistili škálovatelnost a spolehlivost, nasadili jsme naše služby v několika regionech. Při budování platformy služeb jsme věděli, že potřebujeme způsob, jak zajistit větší izolaci mezi službami. Nechtěli jsme, aby prudký nárůst požadavků v jedné službě způsobil výpadek celé platformy. A právě zde přichází na řadu naše buňková architektura.

Představte si buňku jako samostatnou jednotku, která má svůj vlastní DNS, vyrovnávač zátěže a hostitele. Je dostatečně izolovaná, takže pokud se v jedné buňce něco pokazí, nebude to mít vliv na ostatní. Používáme DNS k mapování požadavků na IP adresu vyrovnávače zátěže konkrétní buňky a poté je požadavek směrován do správné buňky. Proxy buňky rozdělujeme na základě služeb. Každá downstreamová služba je registrována do konkrétní proxy buňky. Jak je znázorněno na obrázku 5, veškerý provoz do konkrétní služby směřuje do konkrétní buňky. Narazili jsme na incident, kdy jedna ze služeb měla přerušovaný provoz. Díky této celulární architektuře jsme byli schopni migrovat službu do nové buňky, takže ostatní služby zůstaly nedotčeny.

Obrázek 5: Celulární architektura servisní platformy. 

Možná vás zajímá, jak do toho všeho zapadá služba Resource Metadata. I ta používá buňky – ale trochu jinak. U služby Metadata se buňka skládá z nástroje pro vyrovnávání zátěže, hostitelů a databází. Buňky nemůžeme rozdělit podle služeb, jako to děláme u služby Proxy, protože služba metadat nabízí funkce, které zahrnují více služeb. Místo toho každá buňka metadat zpracovává určité procento tenancí. Abychom zajistili hladký chod, máme v Proxy modul pro překlad buněk, který vyhledává správný koncový bod služby metadat na základě tenancí, a validátor buněk ve službě Metadata, který kontroluje, zda je požadavek směrován do správné buňky. Pokud vše vypadá v pořádku, buňka provoz přijme.

V jedné z větších oblastí máme více buněk pro zpracování provozu. S rostoucím objemem požadavků můžeme jednoduše přidávat další buňky pro zpracování provozu.

Jak platforma služeb pomáhá se zabezpečením API?

Než tento blog zakončíme, pojďme si povědět něco opravdu důležitého: zabezpečení. V Oraclu se zavázali k tomu, že každé cloudové API, které zpřístupňujeme, bude co nejbezpečnější. Chceme zajistit, aby každý přicházející požadavek byl důkladně prověřen, než se dostane k našim následným službám. Za tímto účelem jsme zavedli řadu bezpečných kontrol přístupu, kterými musí každý požadavek projít. Patří sem například ověřování, autorizace, kontrola založená na přístupu k síti, zóny maximálního zabezpečení atd.

Většina API používá jako mechanismus ověřování oci-signature. Víme však také, že univerzální řešení neexistuje. Proto nabízíme řadu mechanismů, včetně základních tokenů, tokenů na nosiče, OpenID Connect atd. V některých případech jsou naše API pro downstreamové služby povoleny s více režimy ověřování. Chceme zajistit, aby vlastníci služeb měli flexibilitu zvolit si metodu ověřování, která jim nejlépe vyhovuje.

Autorizace je pro nás také nejvyšší prioritou. Vlastníci našich služeb specifikují, jaká oprávnění jsou potřebná pro přístup k určitému zdroji, a naše platforma provádí potřebné kontroly voláním naší služby identity. Jde o to, aby správní lidé měli přístup ke správným zdrojům.

Řekněme například, že chcete vytvořit vyrovnávač zátěže. Potřebujete mít správná oprávnění k podsíti. Co když ale podsíť vlastní jiná služba? Naše platforma je dostatečně robustní, aby si s těmito případy poradila. Můžeme specifikovat oprávnění požadovaná pro konkrétní zdroj a naše platforma se postará o zbytek. Zde je příklad, jak to funguje:

Definice API Loadbalanceru

/loadbalancers:

   post:

      x-platform:

        resources:

          Subnet:

            forEachInArrayExpression: subnetIds

            targetCompartmentId: service.invoke('VirtualNetworkService','GetSubnet', each).compartmentId

            permissions: ["SUBNET_ATTACH"]

        authorization:

            check: resourceList["MyResource"].every 

Jak vidíte, naše platforma usnadňuje správu složitých autorizačních scénářů bez velkého množství šablonovitého kódu. Jde nám o to, aby byly věci jednoduché a bezpečné, aby se naši vlastníci služeb mohli soustředit na to nejdůležitější – tvorbu skvělých služeb.

Závěrem

Platforma služeb je páteří naší cloudové infrastruktury a v současné době nabízí více než 15 funkcí platformy. Naše centralizovaná architektura nám umožnila snížit náklady na infrastrukturu a úsilí vývojářů, protože jsme se již nemuseli učit a integrovat každou službu jednotlivě.

Zde jsou některé klíčové poznatky:

1. Rychlejší zavádění funkcí v celé organizaci eliminací nutnosti, aby všechny služby měnily kód, testovaly a nasazovaly jej.
2. Centralizovaná platforma pomáhá zajistit, aby všechny služby splňovaly bezpečnostní standardy, a poskytuje tak další vrstvu ochrany a jistoty.
3. Vynucování standardů a jednotná implementace pro funkce platformy zlepšuje produktivitu organizace.

Podobné podrobné ponory do inženýrství OCI naleznete v rámci  série V zákulisí inženýrství OCI, která představuje talentované inženýry pracující v oblasti infrastruktury Oracle Cloud. Pro více informací nás neváhejte kontaktovat.

Zdroj: Oracle