Vyskytly se problémy s křížovým odesíláním kvůli dialektu markdown v původním příspěvku. Zejména nejsou zobrazeny diagramy, které existují v původním příspěvku. Takže pokud máte zájem, podívejte se také na originál. Myslím, že ten původní je srozumitelnější

Upgrade HBase nad architekturou Event Sourcing a CQRS za 3 týdny

TL;DR

• Pro upgrade verze HBase jsme použili modrozelenou strategii nasazení nad systémem Event Sourcing a CQRS.
• Přístup nasazení fungoval docela dobře a dosažení cíle projektu trvalo celkem jen 3 týdny. Tato zkušenost byla pro nás nová a vzrušující. Tak se o to chci podělit :)

O upgradu databáze

Upgrade databáze je vždy problematický a kdykoli se potýkáte s takovými okolnostmi v produkčních scénářích, budete velmi nervózní (řekl bych 100krát ve srovnání s jinými produkčními operacemi, se kterými máte co do činění) .

Tento pocit je těžké sdílet s lidmi, kteří nemají zkušenosti nebo zkušenosti s provozováním prostředí databáze. A myslím, že 99,9 % lidí by souhlasilo, pokud máte zkušenosti a prošli jste si těžkými časy při řešení operací souvisejících s databází. Je to riskantní a stojí to hodně, ale upgrade sám o sobě neznamená, že poskytuje produktu novou hodnotu, a přestože není v mnoha případech upřednostňován, pokud neexistuje naléhavý důvod.

Zároveň je obrovským skrytým rizikem, pokud se databáze stane „nedotknutelnou“ a jak se s tímto problémem vypořádat bylo téma napříč, s takovými situacemi se potýkalo mnoho vývojářů a operátorů

Postup upgradu

Obecně byste měli dvě možnosti.

průběžný upgrade

Jedním z nich je průběžný upgrade. Upgrade verze databáze jeden po druhém sekvenčním způsobem.
Našel jsem zde dobré vysvětlení. Pokud toto slovo neznáte, přečtěte si toto.

Co znamená průběžný upgrade ve vývoji softwaru?

• Klady

  • Data jsou na jednom místě. Nemusíte tedy přemýšlet o tom, jak synchronizovat data mezi různými clustery a jak zaručit, že synchronizace bude perfektně fungovat.

• Nevýhody

  • Po dokončení upgradu neexistuje snadný způsob, jak se vrátit. Pokud tedy upgrade nějakým způsobem způsobí problém s výkonem, měli byste velké potíže.
  • Dlouho běžící databáze má nějaký neočekávaný stav, který nemůžete reprodukovat v testovacím prostředí. Někdy se musíte vypořádat s problémem, pokud jde o výrobu. A tato možnost vás opravdu znervózňuje.

modro-zelené nasazení

Druhým je modro-zelené rozmístění. V tomto případě musíte upgradovaný databázový cluster zřídit samostatně a v určitém okamžiku přepnout aplikaci, aby používala novou.
Pokud neznáte slovo „modro-zelené nasazení“, přečtěte si prosím tento příspěvek na blogu.

BlueGreenDeployment

Myslím, že tento přístup je rozšířený v nasazení webových aplikací, ale pokud nahradíte slovo „router“ slovem „aplikace“ a „webový server“ slovem „databáze“, stejný přístup lze použít i pro upgrade databáze.

• Klady

  • Během upgradu se nedotýkáte běžící produkční databáze. Díky tomu je váš život mnohem jednodušší ve srovnání s přístupem postupného upgradu.
  • Pokud dojde k neočekávanému problému, můžete se snadno vrátit ke starému clusteru. A také můžete požadavky distribuovat postupně, abyste mohli minimalizovat rozsah v případě, že máte nějaký problém (Abyste to udělali, stejně jako v "Nevýhody", musíte synchronizovat data z nového clusteru do starého clusteru)
  • Vzhledem k výše uvedenému faktoru můžete o něco zkrátit zátěžové testování v testovacím prostředí a můžete rychle pokračovat v projektu.

• Nevýhody

  • Musíte se ujistit, že data jsou synchronizována mezi oběma databázovými clustery. Nejen ze starého clusteru do nového clusteru, ale také z nového clusteru do starého clusteru, pokud chcete mít snadný způsob, jak se po upgradu vrátit. Vzájemná replikace dat je ale v mnoha případech značně obtížná. Při každé operaci může být možné zapisovat do dvou klastrů, ale musíte se připravit, když je mimo provoz pouze jeden klastr a operace pouze s tímto klastrem selže. Ta manipulace by byla opravdu složitá.
  • Při provozu obou clusterů musíte mít servery dvojnásobné velikosti. To bude stát nějaké peníze a může to být těžké, pokud váš systém nepoužívá cloudovou infrastrukturu.

Náš přístup

Náš přístup je v zásadě modro-zelené nasazení. A protože máme Kafku vpředu jako sběrnici událostí, bylo mnohem snazší vypořádat se s problémem synchronizace dat v části „Nevýhody“ uvedené výše.

Aktuální architektura

Nejprve mi dovolte představit základní architekturu. Btw, celý podsystém chatových zpráv nazýváme "Falcon". Proto je v diagramu ikona sokola.

1. když koncový uživatel odešle chatovou zprávu, write-api vloží data zprávy do Kafky
2. read-model-updater (zkráceně "rmu") stahuje data z Kafky, převádí je na read-model a vkládá je do HBase
3. když koncový uživatel čte zprávy chatu, read-api vytáhne data zpráv z HBase

V tomto příspěvku nevysvětluji, proč volíme CQRS. Pokud se tedy chcete dozvědět podrobnosti nebo pokud nejste obeznámeni s konceptem CQRS, podívejte se prosím na níže uvedené snímky.
Kafka Summit SF 2017 – celosvětově škálovatelné a odolné služby zasílání zpráv s Kafka a Kafka Streams
Celosvětové škálovatelné a odolné služby zasílání zpráv prostřednictvím CQRS a Event Sourcing pomocí Akka, Kafka Streams a HBase

Postup aktualizace databáze

Nyní vysvětlím, jak jsme provedli upgrade databáze na této architektuře

Krok 1: Připravte nové clustery a proveďte počáteční obnovení ze zálohy.

Krok 2: Připravte dalšího spotřebitele (rmu2 v tomto diagramu) na synchronizaci dat z Kafky do nového databázového clusteru. Znovu si přehrajete staré Kafkovy události počínaje před počátečním obnovením. Ujistěte se, že u svého spotřebitele implementujete idempotenci. Chci říct, že systém musí správně fungovat, i když je stejná událost spotřebována více než jednou.

Krok 3: Když nový spotřebitel (rmu2) dohoní nejnovější zprávy Kafka, připravte další read-api stahování dat z nového databázového clusteru. A postupně posílejte požadavky na nové read-api.

Mezi starým a novým clusterem by byl určitý stavový rozdíl, i když synchronizace dat skončí během několika milisekund. Kvůli tomuto rozdílu jsme měli malý problém, takže musíte předem potvrdit a spustit kontrolu hodnocení, abyste viděli, jaký druh problému může být způsoben rozdílem mezi clustery a vaší aplikační logikou. Nebo pokud máte nějaké dobré vrstvy před read-api pro distribuci požadavku podle uživatelského atributu nebo tak něco (např. směrování přes Nginx nebo Envoy jako proxy), stačí tam nastavit správné pravidlo a rozdíl lze efektivně zvládnout a nebude to problém.

A v retrospektivě tohoto projektu jsme si všimli, že pokud dokážete zrcadlit požadavky ze stávajícího rozhraní API na nové rozhraní API, můžete provádět zátěžové testování pomocí produkčního provozu, aniž byste ovlivnili koncové uživatele.

Krok 4: Přepněte na 100% nové read-api a vypněte staré clustery a aplikace, když jste si jisti, že vše funguje perfektně.

Proč si myslím, že je tento přístup lepší

Dovolte mi vysvětlit rozdíl oproti normálnímu modro-zelenému přístupu. Jeden problém v normální modro-zelené je, že se musíte ujistit, že data jsou synchronizována na obou clusterech, ideálně nejen před upgradem, ale i po upgradu. V tomto přístupu se namísto použití replikační funkce, kterou databáze poskytuje, aktualizace databáze aplikují samostatně prostřednictvím aplikace, kterou napíšeme a připravíme. Tento přístup nám přináší mnoho výhod.

Za prvé, protože pracují samostatně, nemusíte se starat o to, jak jsou data synchronizována v každé fázi. Zejména budete potřebovat nějaké další (a ve většině případů docela náročné) úsilí při synchronizaci dat z nového clusteru do starého clusteru, pokud chcete mít snadný způsob, jak se vrátit po upgradu. Ale v tomto přístupu prostě pracují nezávisle. Takže se můžete vrátit k používání starých v případě, že se po upgradu objeví nějaký neočekávaný problém.

Za druhé, nemusíte si dělat starosti s kompatibilitou verzí mezi starými a novými clustery. Pokud používáte funkci synchronizace dat clusteru, kterou databáze poskytuje, může docházet k určitému omezení verzí a problémům s kompatibilitou, ke kterým může v některých okrajových případech dojít. Ale v tomto přístupu vše, co musíte udělat, je připravit nezávislou aplikaci, která vloží data do každé databáze. Myslím, že je to problém, který můžete ve většině případů vyřešit mnohem snadněji. A teoreticky můžete nejen aktualizovat verzi databáze, ale také můžete přepnout nový cluster na úplně jiný (např. DynamoDB) pomocí stejného přístupu. V takovém případě nemůžete použít zálohovaná data pro počáteční nastavení a musíte připravit program počáteční migrace dat. Bude to chvíli trvat, ale myslím, že je to rozumné řešení.

Závěr

V softwarové architektuře se často diskutuje o tématech CQRS a event sourcingu. Z provozního hlediska další vrstva jako sběrnice událostí zvyšuje složitost infrastruktury a provozní náklady. Upřímně řečeno, dříve se mi tento přístup z tohoto pohledu tolik nelíbil. Ale všimli jsme si, že to také mění způsob, jakým provozujeme infrastrukturu, a přináší nám klid v provozu databáze. A ano, CQRS a sourcing událostí mě teď velmi baví :)

Další výzva

Možná by vás zajímalo, co bychom upgradovali Kafka (bus sourcingu událostí)? Jo, to bude naše další výzva. Doufám, že existuje lepší přístup než normální postupný upgrade a modrozelené nasazení. Život inženýra jde dál!