Architektúra mikroslužieb: Úvahy o bránach rozhrania API

Úvod

V súčasnom extrémne konkurenčnom prostredí, kde sú nároky zákazníkov vyššie než kedykoľvek predtým, klienti neváhajú zmeniť dodávateľa, ktorý nedokáže na ich požiadavky reagovať dostatočne rýchlo. IT odvetvie sa preto musí neustále vyrovnávať s bremenom spočívajúcim v nutnosti ponúkať svojim zákazníkom holistickú a jednotnú skúsenosť všetkými dostupnými spôsobmi. A práve architektúra mikroslužieb dokáže na túto výzvu odpovedať. Jej cieľom je totiž poskytovať rýchle a bezpečné riešenia aplikovateľné aj vo veľkom rozsahu a zároveň poskytovať flexibilitu v oblasti výberu technológie na implementáciu zvoleného riešenia. Vďaka tomuto prístupu sa IT firmy menia z dodávateľov s tradične podpornou úlohou na obchodných partnerov.

Architektúru mikroslužieb tvorí systém nezávislých, jednoduchých, modulárnych a vzájomne kombinovateľných služieb. Každá z týchto služieb realizuje jedinečný proces a komunikuje s ostatnými službami prostredníctvom vhodne zadefinovaného mechanizmu v prospech konkrétneho cieľa. Systém v súlade s cieľom reaguje na zmeny agilným spôsobom, kombinuje zmeny a agilné odpovede na ne a ponúka decentralizované riešenia. Brány rozhrania API a ostatné riešenia dopĺňajú modulárne služby a sú nedeliteľnou súčasťou architektúry mikroslužieb (viď obrázok nižšie).

Obr. 1: Brány rozhrania API a ostatné riešenia dopĺňajú modulárne služby a sú nedeliteľnou súčasťou architektúry mikroslužieb

Čo a prečo v bránach rozhraní API

Programové rozhranie API je v podstate reverzná proxy pre mikroslužby a funguje ako jediný vstupný bod do systému. Podobá sa na dizajnový vzor pre objektovo-orientované programovanie Facade a má podobný charakter ako „Anti-Corruption Layer“ v dizajne Domain Driven Design. Zjednodušuje proces návrhu, implementácie a manažmentu rozhrania API a zároveň ho robí konzistentnejším. Toto rozhranie rieši niektoré kľúčové otázky, napr.:

• Ako riešiť bezpečnosť, reguláciu, kešovanie a monitoring z jedného miesta?
• Ako sa vyhnúť príliš rozsiahlej komunikácii medzi klientom a mikroslužbami?
• Ako uspokojiť potreby heterogénnych klientov?
• Ako routovať požiadavky na back-end klientov?
• Ako zistiť, ktoré mikroslužby sú funkčné?
• Ako odhaliť, že nejaká inštancia mikroslužby nefunguje?

Jediný prístupový bod do systému umožňuje ľahké (a ľahko zvládnuteľné) runtime riadenie, ako sú napr. bežné bezpečnostné požiadavky, spoločné vzorové rozhodnutia (napr. že každý príjemca služby má mať hlavičku „X-Correlation-ID“) či real-time politiky ako monitoring, meranie využívania rozhrania API alebo jeho regulácia.

Brána rozhrania abstrahuje mikroslužby od spotrebiteľov, vďaka čomu je zaistená flexibilita a voľné dopĺňanie alebo odoberanie inštancií služieb tak, aby sa prispôsobili záťaži resp. požiadavkám zo strany mikroslužieb. Môže sa stať, že rôzni klienti služby požadujú odlišné dáta, ktoré môžu zároveň potrebovať v špecifických formátoch. Napríklad:

• Komerčná mobilná aplikácia na obrazovke s detailmi produktu zobrazuje informácie o produkte a jeho dostupnosť, no desktop verzia danej komerčnej stránky okrem spomínaných informácií o produkte a dostupnosti zároveň zobrazuje aj recenzie užívateľov.
• Existujú mobilné aplikácie, kde si jedna skupina klientov vymieňa údaje vo formáte XML payload, kým iná skupina vo formáte JSON.

Brána rozhrania API je najvhodnejším miestom na riešenie spomínaných transformačných požiadaviek. Tieto môžu byť naplnené pomocou využitia špecifických rozhraní API pre rovnaký business prvok na úrovni brány. Univerzálny prístup by minimálne skomplikoval rozširovanie funkcionality, s ktorým sa zvyšuje aj stupeň diverzity prvkov.

Brána zároveň pomáha pri zaznamenávaní dát pre potreby analýzy a auditu, ale aj pre vyrovnávanie zaťaženia, kešovanie či statické spracovanie údajov. Nasledujúca schéma znázorňuje zvyčajný spôsob zakomponovania brány do celkovej architektúry mikroslužieb.

Obr. 2: Ukážka zvyčajného spôsobu zakomponovania brány do celkovej architektúry mikroslužieb

Zabezpečenie

Zabezpečenie predstavuje dôležitú požiadavku pre akékoľvek firemné riešenie. V istom bode budovania architektúry je preto nutné zvoliť najvhodnejšiu z dostupných alternatív autentifikácie, autorizácie, ochrany pred hrozbami, ochrany správ, a pod.

Autentizácia a autorizácia

Združená identita (federated identity) je preferovaným riešením pri implementácii funkcionalít ako autentizácia alebo autorizácia v rámci architektúry mikroslužieb. Nie je nevyhnutné, aby si každá mikroslužba musela na autentizáciu klientskych prístupov vyžiadať a uložiť užívateľské oprávnenia. Mikroslužby môžu namiesto toho na autentizáciu užívateľa využiť systém manažmentu identít, v ktorom je už užívateľská identita uložená. Takýto prístup umožňuje oddelenie autentizácie a autorizácie a zároveň uľahčuje centralizáciu týchto dvoch funkcionalít, aby sa predišlo situácii, keď si každá služba musí pre každého užívateľa spravovať osobitný súbor oprávnení na prístup.

Existujú tri hlavné protokoly pre združenú identitu: OpenID, SAML a OAuth. Nasledujúca schéma znázorňuje bezpečnostnú architektúru využívajúcu protokol OAuth2.0.

Každá žiadosť rozhrania API je autentizovaná na vrstve brány rozhrania. Klient aplikácie v mene koncového užívateľa na základe prístupových poverení získa po predložení poverení prístupový token, ktorý sa potom využíva pri každej žiadosti rozhrania API ako súčasť autorizačnej hlavičky HTTP. Brána rozhrania API potom overí prístupový token s autorizačným serverom. Token JWT, ktorý obsahuje deklarácie pre používateľa, sa potom posunie backendovým mikroslužbám, ktoré použijú informácie obsiahnuté v tokene JWT na autorizáciu. Rovnaký token JWT sa využíva aj pri komunikácii samotných mikroslužieb navzájom medzi sebou.

Keďže každá z mikroslužieb sa pri autentizácii spolieha na bránu rozhrania API, vyššie opísaný sled krokov môže potenciálne viesť k vzniku tzv. „confused deputy problem“. V ideálnom prípade by mala každá mikroslužba autentizovať token tak, ako ho obdrží od svojho klienta (brány alebo mikroslužby). Dôjde k voľbe medzi bezpečnosťou a výkonom. Vyššie spomenutá architektúra sa prikláňa k výkonu, pretože na zmiernenie bezpečnostného rizika má iné mechanizmy.

Obr. 3: Bezpečnostná architektúra využívajúca OAuth2.0

Architektúra mikroslužieb je súčasťou podnikovej IT infraštruktúry ako celku, preto ak firma využíva cloudové IT riešenia, mala by si zvoliť aj niektoré zo známych cloudových autorizačných serverov ako sú napr. Azure Active Directory alebo AWS IAM, ktoré môžu byť integrované v on-premise úložisku identít ako active directory. Open source server ako IdentityServer4 tak umožnuje implementáciu vašich vlastných autorizačných serverov ako aj integráciu s existujúcimi úložiskami identít.

Ochrana pred hrozbami z DDoS

Brány rozhraní API zväčša ponúkajú (v rámci základnej ponuky alebo ako doplnky) prvky, ktoré dokážu zvládnuť DDoS útoky pomocou regulácie a kontroly toku informácií smerujúcich k back-endovým mikroslužbám. Zvážte konfiguráciu nasledujúcich regulačných parametrov pre brány rozhraní API:

• Obmedzenie počtu požiadaviek: Maximálny počet požiadaviek, ktoré môže rozhranie API prijať v danom časovom rámci, vychádzajúc z prístupu obmedzenia ich počtu. Niektoré prístupy môžu mať formu Authenticated User alebo Request Origin alebo Authenticated User aj Request Origin. Môžete sa napríklad rozhodnúť, že na rozhranie API povolíte prístup autentizovanému užívateľovi zo špecifickej mobilnej aplikácie len raz denne.
• Obmedzenie počtu spojení: Maximálny počet spojení, ktoré môže konkrétny klient s rozhraním API otvoriť
• Uzatvorenie pomalých spojení: Doba, po uplynutí ktorej sa ukončí spojenie s klientom píšucim dáta veľmi zriedka, čo môže znamenať pokus o udržanie otvoreného spojenia čo najdlhší čas
• Zapíšte IP adresy na Black list / White list, ak môžete s určitosťou identifikovať platných a neplaných užívateľov svojich rozhraní API
• Obmedzenie spojení s back-endovými mikroslužbami
• Blokovanie požiadaviek:
  • pri ktorých sa zdá, že sa zameriavajú na špecifické rozhrania API;
  • ktoré majú hlavičku User – Agent nastavenú na hodnotu, ktorá nekorešponduje s bežným prenosom dát pre danú sieťovú prevádzku;
  • ktoré majú hlavičku referrer nastavenú na hodnotu, ktorá môže byť spájaná s útokom;
  • ktoré majú ďalšie hlavičky nastavené na hodnoty, ktoré môžu byť spájané s útokom.

Bezpečná komunikácia

Odporúča sa, aby brána rozhraní API aj vrstva mikroslužieb mali koncové body v súlade s protokolmi SSL/TLS, aby sa zabezpečila ochrana pred útokmi typu man-in-the-middle, ako aj obojsmerné šifrovanie správ, aby sa zabránilo neoprávnenej manipulácii s nimi.

Ak pracujete s viacerými certifikátmi, ich správa sa stáva veľkou administratívnou záťažou. Pomocou riešení ako AWS certificate manager letsencrypt.org je však možné certifikáty transparentným spôsobom vydávať i odoberať.

Nasadenie

Všetky mikroslužby by mali byť kvôli zvýšeniu bezpečnosti hostené na privátnej podsieti a IP adresa brány by mala byť zaradená do white listu na vrstve mikroslužieb. Ak nie je možné, aby mikroslužby boli na privátnej podsieti, je potrebné autorizačným serverom validovať každý token pri každej požiadavke, čo však bude mať vplyv na výkonnosť systému.

Service Registry a Service Discovery

Ľahká škálovateľnosť je jednou z hlavných výhod architektúry mikroslužieb. Neustále pridávanie či odoberanie inštancií mikroslužieb umožňuje ľahkú adaptáciu na prichádzajúce zaťaženie siete. Navyše, vaše tímy môžu pridávať nové alebo refaktorovať už existujúce mikroslužby na viacnásobné súpravy (najmä pri prechode z monolitického modelu na mikroslužby). Inštancie služieb si dynamicky priradia sieťové umiestnenie.

Service Registry

Register služieb (Service Register) pomáha pri sledovaní spomínaných inštancií. Ide o databázu, ktorá zahŕňa sieť lokalít, na ktorých sú jednotlivé inštancie umiestnené. Každá z inštancií služieb sa pri spustení zaregistruje a pri vypnutí sa odhlási. Brána rozhrania API túto informáciu využíva pri jej „objavovaní“ (discovery). Nasledujúci obrázok zobrazuje proces registrácie a objavenia služby.

Na kontrolu stavu služby sa používajú dva modely: pull a push. Aj keď niektoré registre podporujú model pull, neodporúča sa to, pretože to predstavuje extra záťaž pre register. Navyše, samotná služba je zodpovedná za to, aby registru podala aktuálnu informáciu o tom, či konkrétnu požiadavku môže alebo nemôže realizovať (či je dostupná alebo nedostupná).

Register služieb ako jeden z kľúčových komponentov musí byť vždy dostupný. Odporúča sa preto naplánovať si klaster registrov, ktorý na zabezpečenie konzistentnosti využíva replikáciu. Naopak, neodporúča sa kešovať sieťové body z registra klienta, pretože takáto informácia sa časom stane neaktuálnou a spôsobí, že klientské programy nebudú schopné objaviť inštancie služieb.

Obr. 4: Registrácia a objavovanie služieb

Service Discovery

Počet a umiestnenie inštancií jednotlivých služieb je dynamické, v dôsledku čoho je nevyhnutné, aby váš klientský kód využíval prepracovanejšie mechanizmy objavovania služieb (service discovery). Existujú dva hlavné vzory objavovania: na strane klienta a na strane servera (viď obrázok nižšie).

Objavovanie na strane servera je preferovaným vzorom z viacerých dôvodov:

• nezaťažuje klienta objavovaním, takže tento sa môže zamerať na business funkcie;
• ak máte viac klientov, musíte kódovať i udržiavať kód objavovania pre každého klienta;
• znižuje počet internetových volaní.

Obr. 5: Existujú dva hlavné vzory objavovania: na strane klienta a na strane servera

Orchestrácia

Na realizáciu business prípadu použitia (business use case) je často potrebné, aby sa orchestrovala celá škála jemných mikroslužieb. Ako je vidieť na nasledujúcom obrázku, existujú dve možnosti takejto orchestrácie: spôsob, pri ktorom brána rozhrania API slúži ako orchestračná vrstva, alebo zakódovanie orchestrácie do osobitnej mikroslužby.

Orchestrácia by nemala prebiehať na vrstve brány, pretože porušuje princíp jednej zodpovednosti (single responsibility principle) a v prípade, že by došlo k škálovaniu rozhrania API, bude nutné škálovať aj bránu a orchestrované mikroslužby. Niektoré z brán rozhrania API majú veľmi malú, prípadne nulovú schopnosť orchestrácie.

Aj keď sa neodporúča orchestráciu využívať na vrstve brány, ak ju z nejakého dôvodu aj tak chcete takto použiť, v procese jej implementácie by nemala byť zapojená žiadna business logika.

Transformácia

Mikroslužby musia na front-ende často komunikovať s rôznymi klientmi. Títo majú rôzne potreby z pohľadu protokolu (SOAP, REST, JSON a XML) i dát. Navyše, pri prechode z monolitu k mikroslužbám, back-endové služby môžu využívať rôzne protokoly (SOAP, REST, AMQP a pod.).

Brána rozhrania API poskytuje priestor na transformáciu dát, kde je možný preklad jednotlivých správ medzi back-endom a rozhraním API na jednej strane a rôznymi formátmi aplikácií a protokolmi na strane druhej. Brána slúži ako centrálny bod dátovej transformácie, cez ktorý prechádzajú všetky dáta:

• vyžiadané zmeny payload-u,
• zmeny hlavičiek,
• zmeny protokolov.

Je vhodné, aby ste si vytvorili transformačné adaptéry ako opakovane použiteľné komponenty. Okrem toho sa neodporúča, aby ste potreby všetkých svojich klientov kódovali v jednom rozhraní API. Mali by ste si vytvoriť rôzne rozhrania API špecifické pre klienta s transformačnou logikou.

Obr. 6: Existujú dve možnosti takejto orchestrácie: spôsob, pri ktorom brána rozhrania API slúži ako orchestračná vrstva, alebo zakódovanie orchestrácie do osobitnej mikroslužby.

Monitoring

Nakoľko brána rozhrania API predstavuje jediný prístupový bod do systému, všetky dáta prúdiace do alebo zo systému ním musia prejsť, a preto je jeho monitorovanie kľúčové. Dáva nám to možnosť zachytiť informácie týkajúce sa toku dát, ktoré môžeme použiť ako vstup pre IT administráciu a tvorbu IP politík.

Monitoring kondície

Úlohou monitoringu kondície systému je uistiť sa, že brána funguje správne. Monitoring zdravia by mal zaznamenávať tieto údaje:

• Stav a zdravie systému (CPU, pamäť, využitie vláken)
• Sieťová konektivita
• Bezpečnostné upozornenia
• Zálohovanie a obnova dát
• Správa logov

Monitoring sieťovej prevádzky a dát

Analýza dát o prevádzke a zaťažení siete vám pomôže prijať proaktívne opatrenia na zabezpečenie bezproblémového fungovania softvérových systémov a nastavenie IT pravidiel. Mali by ste zvážiť monitoring nasledujúcich základných metrík:

• Počet požiadaviek na rozhranie API
• Kategorizácia požiadaviek podľa kritérií (napr. vzdialený server)
• Štatistika výkonnosti
• Správy o úspešnom priebehu a chybách
• Zablokované správy porušujúce politiky brány

Odporúča sa tiež pravidelne analyzovať sieťovú prevádzku z dlhodobého hľadiska, aby ste vedeli predvídať úrovne prevádzky a boli pripravení na prípady preťaženia.

Vyrovnávanie záťaže a škálovanie

Analýza sieťovej prevádzky a dátová analýza umožňujú pochopiť a predvídať záťaž systému. To zas pomôže nastaviť primeranú veľkosť brány a rozsah príslušných služieb. Veľkosť brány sa dá nastaviť horizontálne i vertikálne. Rovnomerne zaťažená brána rozhrania API využíva na virtualizáciu rovnakých rozhraní API rovnakú konfiguráciu a realizuje rovnaké pravidlá. Pri nasadení viacnásobných brán rozhraní API má vyrovnávanie záťaže prebiehať naprieč skupinami.

Brána rozhrania API nekladie na tzv. vyrovnávače záťaže (load balancers) žiadne špeciálne požiadavky. Záťaž sa vyrovnáva na základe rôznych charakteristík, ako napr. reakčný čas alebo systémová záťaž. Výkon pravidiel brány rozhrania API je bezstavový, pričom dráha, ktorou správa preberá konkrétny systém, nemá na jeho spracovanie žiadny vplyv. Položky ako caches a počítadlá, ktoré sú umiestnené na distribuovanom cache, sa aktualizujú po každej správe, čo prispieva k úspešnej prevádzke brány rozhrania API tak v sticky ako aj v non-sticky móde.

Distribuovaný stav so sebou prináša určité obmedzenia spojené s klastrovaním active/active a active/passive. Napr. ak je dôležitý stav počítadla a cache, systém by mal byť navrhnutý tak, aby zaručoval, že aspoň jedna z jeho brán rozhrania API bude v prevádzke nepretržite. Znamená to, že pri odolných vysoko dostupných systémoch je potrebné zapojiť aspoň dve brány rozhrania API, ktoré budú aktívne kedykoľvek, najmä však v pasívnom móde.

Brána rozhrania API tiež pomocou nasadenia konfigurácie ako rolling fashion zabezpečuje dostupnosť počítača. Znamená to, že aj keď každá inštancia brány rozhrania API v klastri alebo v skupine potrebuje na aktualizáciu svojej konfigurácie niekoľko sekúnd, počas ktorých nereaguje na nové požiadavky, všetky prebiehajúce a prichádzajúce požiadavky sú spracované. Postará sa o to zvyšok klastra alebo skupiny, ktorý môže nové požiadavky prijímať aj v čase spomínanej aktualizácie. Vyrovnávač záťaže zabezpečí, že požiadavky sú smerované do uzlov, ktoré ich vedia prijať.

Obr. 7: Vyrovnávanie záťaže a škálovanie

High Availability a Failover

Brána rozhrania API je kritickým komponentom a JEDINÝM vstupným bodom v architektúre mikroslužieb, a preto má byť nasadená v režime High Availability (HA). Jednotlivé inštancie brány rozhrania API sú zvyčajne nasadzované za štandardné vyrovnávače záťaže, ktoré si pravidelne overujú stav brány rozhrania API. Ak nastane problém, vyrovnávač prevádzku presmeruje na najbližší dostupný uzol.

Udalosti/upozornenia sú nakonfigurované tak, aby vedeli prijať notifikácie v prípade, ak sa vyskytne nejaký problém. Ak sa spustí udalosť alebo upozornenie, problém môže byť pomocou analytiky brán rozhrania API identifikovaný a aktívna brána rozhrania API môže byť následne opravená.

Inštancie brány rozhrania API sú v podstate bezstavové. Nevytvárajú sa žiadne session data, preto ani nevzniká potreba replikovať stav relácie naprieč bránami rozhrania API. Môžu však uchovávať kešované dáta, pričom tieto môžu byť replikované pomocou vzťahu peer-to-peer naprieč klastrom brán rozhraní API.

Stav High Availability sa dá udržať pomocou ktorejkoľvek z nasledujúcich možností: systémy Active/Active, Active/Standby alebo Active/Passive. Tieto sa opisujú nasledovne:

• Active/Standby: systém je vypnutý
• Active/Passive: systém je v prevádzke a neaktívny
• Active/Active: systém je v plnej prevádzke a aktívny

Usmernenia pre HA a Failover

• Na dosiahnutie maximálnej dostupnosti je dôležité, aby bola brána rozhrania API v móde Active/Active v prípade každej produkčnej brány rozhrania API
• Riadna analýza prevádzky, aby sa obmedzila premávka smerom k back-end službám a zamedzilo sa zahlteniu správami. Toto je zvlášť dôležité pri legacy systémoch, ktoré boli nedávno transformované na systémové, pretože legacy systémy nemuseli byť navrhnuté pre prevádzkové vzory, s ktorými teraz pracujú.
• Detailný monitoring sieťovej infraštruktúry, aby sa prípadné problémy identifikovali zavčasu. Pomôcť vám pri tom môžu nástroje API Gateway Manager a API Gateway Analytics. Štandardné monitorovacie nástroje tiež využívajú rozhrania ako syslog alebo Simple Network Management Protocol (SNMP).

Spravovanie

So zvyšujúcim sa počtom rozhraní API je dôležité zaviesť príslušné politiky a monitoring. Politiky môžu byť vo všeobecnosti rozdelené na spravovanie design-time a spravovanie runtime. Na politiky majú veľký vplyv najmä IT (business) ciele.

Zvoľte a nakonfigurujte si také pravidlá brány API, ktoré vám pomôžu implementovať systém runtime spravovania, ako napr.:

Sledovanie životného cyklu rozhraní API:

• Riadenie smerovania, blokovania a spracovania prístupov
• Poznanie využitia rozhrania API a aktivovanie hlásení/upozornení v prípade, že využitie prekročí stanovený prah
• Regulácia, uľahčovanie prevádzky a vyvažovanie záťaže
• Obmedzovanie počtu použití na rozhranie API
• Vývoj nových verzií rozhrania API
• Vývoj nových schém pre nastavenie parametrov vstupných/výstupných požiadaviek

Spravovanie Design-time zahŕňa:

• Definovanie štandardov pre definície rozhrania API (príklad: Swagger)
• Tagy pre kľúčové slová využívané na kategorizáciu rozhraní API
• Súlad s pravidlami navrhovania REST API

Záver

Brána rozhrania API predstavuje základný komponent architektúry mikroslužieb. Pomáha:

• Oddeliť spotrebiteľov služieb od back-endových služieb
• Implementovať relevantné politiky na jednom mieste
• Zabezpečovať opakovanú použiteľnosť
• Monitorovať celkové fungovanie technologickej platformy
• Zabezpečiť ľahkú škálovateľnosť služieb

Referencie

• Pattern: API Gateway / Backend for Front-End (Microservices.io)
• Building Microservices: Using an API Gateway (NGINX)
• Enabling Microservice Architecture with Middleware (WSO2 Blog)
• Welcome to IdentityServer4 (IdentityServer4)
• Oracle® Fusion Middleware Part 1. API Gateway administration (Oracle)

Úplnú verziu si môžete stiahnuť tu. Podklad je v anglickom jazyku.