Bohužel, tento termín nemá dobrý český ekvivalent. "Wikipedia" uvádí "multi-tenantnost, vícenásobný pronájem". Někdy se tomu říká "víceroční vlastnictví". Tyto termíny mohou být poněkud matoucí, protože se podstatně netýkají ani pronájmu, ani vlastnictví. Je to otázka architektury softwaru a organizace jeho provozu. A to poslední je neméně důležité.
Naše porozumění multitenancy jsme začali formovat současně s tím, jak jsme začali navrhovat přístup k cloudovému (servisnímu) modelu práce "1C:Enterprise". To bylo před několika lety. A od té doby se naše chápání neustále rozšiřuje. Neustále objevujeme nové a nové aspekty tohoto tématu (výhody, nevýhody, složitosti, zvláštnosti atd.).
Někdy vývojáři chápou pod multitenancy zcela jednoduchou věc: "aby data několika organizací byla uložena v jedné databázi, je třeba do všech tabulek přidat sloupec s identifikátorem organizace a nastavit filtr podle něj". My jsme samozřejmě také začali naše zpracování otázky z tohoto bodu. Ale dost rychle jsme pochopili, že to je jen jedna "loukka" (také, mimochodem, ne jednoduchá). A vůbec je to "celá země".
Hlavní myšlenku multitenancy lze popsat přibližně takto. Běžná aplikace je jako rodinný dům, určený pro bydlení jedné rodiny, která využívá jeho infrastrukturu (stěny, střecha, vodovod, topení atd.). Naopak multitenancy aplikace je jako bytový dům. V něm každá rodina používá stejnou infrastrukturu, ale samotná infrastruktura je realizována pro celý dům jako celek.
A je přístup multitenancy dobrý, nebo špatný? Na to lze najít velmi různé názory. Zdá se, že neexistuje "dobré nebo špatné" vůbec. Je třeba porovnávat výhody a nevýhody v kontextu konkrétních řešených úkolů. Ale to je samostatné téma…
V nejjednodušším chápání je cílem multitenancy snížit náklady na údržbu aplikace prostřednictvím "sdílení" nákladů na infrastrukturu. Je to stejné hnutí, jako je snižování nákladů na aplikaci použitím sériového řešení (možná s úpravou a přizpůsobením), a ne vytvářením "na míru". Jen v jednom případě se sdílí vývoj, a v druhém – provoz.
A opakujeme, zde není přímá vazba na způsob prodeje. Architektura multitenancy může velmi dobře fungovat i v korporátní nebo vládní IT infrastruktuře pro automatizaci velkého množství homogeních poboček, podniků holdingu.
Lze říci, že multitenancy není jen otázkou organizace ukládání dat. Je to model práce aplikace jako celku (včetně podstatné části aspektů její architektury, modelu nasazení a organizace údržby).
Nejdůležitější a nejzajímavější na modelu multitenancy, jak se nám zdá, je, že podstata aplikace se "rozděluje". Část funkcionality pracuje s konkrétními oblastmi dat (byty) a "nezajímá se" o to, co se děje s nájemníky v jiných bytech. A část vnímá dům jako celek a pracuje okamžitě pro všechny nájemníky. Přitom posledně jmenovaná nemůže abstrahovat od toho, že přece jen jde o jednotlivé byty, a je třeba zajistit nezbytnou úroveň granularity a bezpečnosti.
V "1C:Podnikání" je model multitenancy realizován na úrovni několika technologií. Jsou to mechanismy platformy "1C:Podnikání", mechanismy "“ a „", mechanismy (knihovny standardních subsystémů).
Každý z těchto prvků přispívá k budování celkové infrastruktury bytového domu. Proč je to realizováno v několika technologiích a ne pouze v jedné, například v platformě? Především proto, že část mechanismů, podle našeho názoru, je zcela oprávněně modifikovat při konkrétním způsobu nasazení. Ale obecně je to složitá otázka a neustále jsme postaveni před volbu – na které úrovni je nejlepší realizovat ten či onen aspekt multitenancy.
Je zřejmé, že základní část mechanismů bylo třeba realizovat v platformě. Například samotné oddělení dat. To, čím obvykle začíná rozhovor o multitenancy. Ale nakonec model multitenancy "projížděl" podstatnou část mechanismů platformy a vyžádal si jejich úpravy, a v některých případech i přepracování.
Na úrovni platformy jsme implementovali základní mechanismy. Ty umožňují vytvářet aplikace, které fungují na modelu multitenancy. Aby však aplikace mohly „žít a fungovat“ v tomto modelu, je potřeba mít systém pro správu jejich „životnosti“. Za to jsou zodpovědné technologie 1cFresh a unifikovaná vrstvy obchodní logiky na úrovni BSP. Stejně jako v bytovém domě infrastruktura zajišťuje obyvatelům vše potřebné, tak i technologie 1cFresh zajišťují aplikacím potřebné zdroje pro fungování v modelu multitenancy. Aby aplikace mohly komunikovat s touto infrastrukturou (bez podstatných úprav), jsou do nich vloženy odpovídající „zástrčky“ ve formě subsystémů BSP.
Z pohledu mechanismů platformy je snadno patrné, že s narůstajícími zkušenostmi a rozvojem cloudové varianty používání „1C:Enterprise“ rozšiřujeme soubor mechanismů, které jsou zapojeny do této architektury. Uveďme jeden příklad. V modelu multitenancy se podstatně mění rozložení rolí účastníků údržby aplikací. Zásadně se zvyšuje úloha (úroveň odpovědnosti) těch, kteří odpovídají za provoz aplikací. Ti nyní potřebují mít silnější nástroje pro kontrolu aplikací. Protože uživatelé aplikací (obyvatelé) důvěřují především poskytovateli, se kterým spolupracují. K tomu jsme v verzi 8.3 implementovali nový . Tento mechanismus umožňuje administrátorům poskytovatele omezit volnost vývojářů aplikací na potřebnou úroveň bezpečnosti – v podstatě izolovat práci aplikace pro každého obyvatele v určitých mezích „pískoviště“ (sandbox).
Architektura pro správu aplikací, které fungují v režimu multitenancy (tak, jak to realizují technologie 1cFresh a BSP), představuje zajímavý aspekt. Ve srovnání s tradičními modely nasazení se zde výrazně zvyšují požadavky na automatizaci procesů správy. Takových procesů je desítky: vytváření nových datových oblastí („bytů“), aktualizace aplikací, aktualizace normativních informací, zálohování atd. A samozřejmě se zvyšují požadavky na úroveň spolehlivosti a dostupnosti. Například pro zajištění spolehlivé interakce aplikací s komponenty systému řízení jsme implementovali technologii asynchronního volacího systému s garantovaným doručením.
Velmi citlivým momentem je způsob sdílení dat a procesů. Na první pohled se to může zdát jednoduché (pokud to někomu připadá). Největší obtíž představuje rovnováha mezi centralizací dat a procesů a decentralizací. Na jedné straně umožňuje centralizace snížit náklady (diskový prostor, výkon procesoru, úsilí administrátorů…). Na druhé straně omezuje svobodu „obyvatel“. To je jeden z aspektů „rozdělení“ aplikace, kdy se vývojář musí zamýšlet nad aplikací v úzkém smyslu (sloužící jedné „bytové jednotce“) a v širším smyslu (sloužící všem „obyvatelům“).
Jako příklad této „dilema“ lze uvést normativně-informační údaje. Je jasné, že existuje silné pokušení učinit je společnými pro všechny „obyvatele“ domu. To umožňuje uchovávat je v jednom exempláři a okamžitě aktualizovat pro všechny. Ale někdy se stává, že jednotlivý obyvatel potřebuje specifické úpravy. Jak paradoxní to může znít, v praxi to nastává i pro informace, které jsou specifikovány regulátory (vládními orgány). Dochází k nelehkému problému: sdílet nebo nesdílet? Je lákavé udělat společné informace pro všechny a soukromé pro vyžadující. To však vede k přinejmenším složité realizaci. Ale na tom pracujeme…
Dalším příkladem je návrh implementace pravidelných procesů (prováděných podle plánu, zahajovaných řídicím systémem atd.). Na jedné straně je možné je implementovat pro každou oblast dat zvlášť. Je to jednodušší a pohodlnější. Na druhé straně však taková drobnost vytváří velkou zátěž na systém. Aby se zátěž snížila, je třeba implementovat sdílené procesy. Ty však vyžadují pečlivější zpracování.
Samozřejmě vyvstává velmi významná otázka. Jak mohou vývojáři aplikací zajistit funkčnost v režimu multitenancy? Co pro to musí udělat? Určitě se snažíme o to, aby tíha technologických a infrastrukturních otázek maximálně ležela na bedrech dodávané technologie, zatímco vývojář aplikace by se měl zabývat pouze úkoly obchodní logiky. Ale jako u dalších důležitých architektonických otázek, nějaké povědomí o práci v modelu multitenancy musí mít i vývojáři aplikací a nějaké úsilí během vývoje aplikací bude zapotřebí. Proč? Protože existují momenty, které technologie nemůže automaticky zajistit bez ohledu na sémantiku dat. Například definice hranic sdílení informací. Ale snažíme se, aby tyto složitosti byly co nejmenší. Příklady implementace takových aplikací už existují.
Důležitým momentem v kontextu implementace multitenancy v „1C:Enterprise“ je, že vytváříme hybridní model, ve kterém jedna aplikace může fungovat jak v režimu multitenancy, tak i v normálním režimu. To je velmi složitý úkol a téma pro samostatnou diskusi.
Zdroj: habr.com
