Urobiť Gentlent rýchlejším a spoľahlivejším

Ach áno, komplexný svet serverovej a cloudovej infraštruktúry. Aké úžasné miesto na míňanie ťažko zarobených peňazí a času, ktorého je už aj tak príliš málo.

G-Core je to, čo nazývame obludným kódom Gentlent, ktorý obsahuje doménové meno servery (DNS), SMTP (pre emaily), nástroje na oznámenie našich anycast a unicast IP rozsahov prostredníctvom border gateway protocol (BGP) do routerov našich dátových centier, alebo len základné Geo IP API, ktoré by ste mohli použiť vo vašom ďalšom projekte. Beží na ňom dokonca aj viac služieb, ktoré tu nie sú uvedené a škáluje sa dobre, naozaj dobre. Ale ako všetky skvelé veci, má významnú chybu. Chybu, ktorú sme zatiaľ ešte neriešili:

Je to o diskách? Je to o energii? Ide o reštartovanie služieb. Aby sme našu infraštruktúru urobili spoľahlivou ako skala - a dúfam, že ste všetci pochopili odkaz - potrebovali sme ju vylepšiť tak, aby podporovala nulové prestávky pre väčšinu, ak nie všetky, našich budúcich aktualizácií a preto reštartov.

Aktualizácie základného systému Gentlent sa dejú niekoľkokrát denne, či už ide o malú úpravu, opravu alebo veľké vydanie funkcie. Každá aktualizácia začína rovnakým procesom postupného zatvárania otvorených pripojení, zastavenia ohlasovania IP do klastru, stiahnutia nového obrazu a spätného spustenia nového kontajneru so všetkými jeho službami, poslucháčmi a oznamovaniami. Aktualizácie sú už vykonávané ako „Rolling updates“, čo znamená, že neaktualizujeme všetky servery súčasne. Napriek tomu časti hostujeme naše vlastné servery doménových mien a spúšťanie týchto kontajnerových obrazov chvíľu trvá. Aspoň toľko, aby to bolo zistené našimi rôznymi internými a externými monitorovacími službami. Tiež sme pozorovali časové výnimky a odmietnutie pripojenia počas aktualizácií.

Čo máme:

• Naše rolling updates vyžadujú reštarty, ktoré znižujú DNS a BGP.
• Aj keď BGP automaticky presmeruje používateľov do najbližšieho dátového centra, zlyhá, až kým sa nepropaguje a zabráni vynechaniu cache pri správnom rozpoznávaní našich verejných a interných domén.

Na riešenie týchto problémov sme sa rozhodli nasadiť ďalšiu službu, ktorá je určená na celoživotnú prevádzku počas aktualizácií a je schopná vyvažovať záťaž na iné servery v prípade, že sa core služby na stroji aktualizujú alebo reštartujú. Ako software load balancer (LB), ktorý je v tomto prípade reverzný proxy, musí držať krok s našou súčasnou úrovňou výkonu a bezpečnosti, rozhodli sme sa pre open source softvér, ktorý je optimalizovaný práve na to.

Tieto reverzné proxy typy LB prišli s výhodou, že boli značne optimalizované a boli založené na jazykoch ako C++, ktoré obvykle prinášajú veľké zlepšenie výkonu, ktoré by mohlo kompenzovať pridanú latenciu.

Rýchlo po implementácii prvého prototypu nového systému sme si tiež všimli, že môžeme odľahčiť dve z najťažších a najviac CPU náročných úloh na LB: SSL/TLS ukončovanie a kompresiu. Tým sme celkový čas načítania znížili o viac ako 50% a výrazne zvýšili dostupnosť a spoľahlivosť našej infraštruktúry.

Ďalšie zlepšenia DNS

Ako si viete predstaviť, trvalo nám mnoho hodín skúšok a omylov a ako ste si prečítali vyššie, konečne sme túto migráciu dokončili. Využili sme príležitosť na ďalšie vylepšenie nášho vlastného DNS tým, že sme aktívne načítali všetky zóny do lokálnej pamäte, čím sa zrýchľoval čas načítania a znižovala latencia. Použili sme nástroje od KeyCDN na meranie výkonu nášho DNS so dosť zlými výsledkami:

Výkonový test

Napriek tomu, že naše databázové servery sú dosť rýchle, server v Tokiu zareagoval na jeden DNS dotaz takmer tretinou sekundy. Stalo sa to len za určitých okolností, keď bola požiadavka alebo odpoveď urobená na akomkoľvek danom serveri prvýkrát, a teda bola poskytnutá neuložená v pamäti. Trvalo to až niekoľko stoviek milisekúnd, aby sa všetky údaje načítali z ľadu, čo pridávalo masívne špičky latencie k požiadavke.

Bolo to dôsledkom toho, že server urobil úplnú spiatočnú cestu cez oceán do Ázie, potom Európy a do nášho core databázového servera. Aktívnym načítaním a ukladním do pamäte všetkých zón sme preskočili a odložili do priepasti procesov na pozadí 4 asynchrónne databázové dotazy vrátane ich latencie.

Dostali sme to z čohokoľvek nad 100 milisekúnd na priemerne len pod 6ms pri aktívne zdravotne kontrolovaných lokálnych požiadavkách.

Ďalšie masívne vylepšenie urobené, nasadené a dokončené. Ale tu nekončíme.