Cześć wszystkim! Nazywam się Gołow Nikołaj. Wcześniej pracowałem w Avito i przez sześć lat zarządzałem Data Platform, czyli pracowałem na wszystkich bazach danych: analitycznych (Vertica, ClickHouse), streamingowych i OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). W tym czasie miałem do czynienia z dużą liczbą baz danych - bardzo różnych i nietypowych oraz z niestandardowymi przypadkami ich wykorzystania.
Obecnie pracuję w ManyChat. W istocie jest to startup – nowy, ambitny i szybko rozwijający się. A kiedy pierwszy raz dołączyłem do firmy, pojawiło się klasyczne pytanie: „Co młody startup powinien teraz zabrać z rynku DBMS i baz danych?”
W tym artykule, na podstawie mojego raportu o godz , odpowiem na to pytanie. Wersja wideo raportu jest dostępna pod adresem .
Powszechnie znane bazy danych 2020
Jest rok 2020, rozejrzałem się i zobaczyłem trzy typy baz danych.
Pierwszy typ - klasyczne bazy danych OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Zostały napisane dawno temu, ale nadal są aktualne, ponieważ są tak dobrze znane społeczności programistów.
Drugi typ to podstawy od „zera”. Próbowali odejść od klasycznych wzorców, porzucając SQL, tradycyjne struktury i ACID, dodając wbudowany sharding i inne atrakcyjne funkcje. Na przykład jest to Cassandra, MongoDB, Redis lub Tarantool. Wszystkie te rozwiązania chciały zaoferować rynkowi coś zasadniczo nowego i zajmowały swoją niszę, ponieważ okazały się niezwykle wygodne do określonych zadań. Oznaczę te bazy danych ogólnym terminem NOSQL.
Skończyły się „zera”, przyzwyczailiśmy się do baz NOSQL i świat moim zdaniem zrobił kolejny krok – zarządzane bazy danych. Bazy te mają ten sam rdzeń, co klasyczne bazy danych OLTP lub nowe bazy NoSQL. Ale nie potrzebują DBA i DevOps i działają na zarządzanym sprzęcie w chmurach. Dla programisty jest to „tylko baza”, która gdzieś działa, ale nikogo nie interesuje, jak jest zainstalowana na serwerze, kto skonfigurował serwer i kto go aktualizuje.
Przykłady takich baz danych:
- AWS RDS to zarządzane opakowanie dla PostgreSQL/MySQL.
- DynamoDB jest analogiem AWS bazy danych opartej na dokumentach, podobnej do Redis i MongoDB.
- Amazon Redshift to zarządzana analityczna baza danych.
Są to w zasadzie stare bazy danych, ale tworzone w zarządzanym środowisku, bez konieczności pracy ze sprzętem.
Notatka. Przykłady wzięte są dla środowiska AWS, ale ich odpowiedniki istnieją także w Microsoft Azure, Google Cloud czy Yandex.Cloud.
Co w tym nowego? W 2020 roku nic z tego.
Koncepcja bezserwerowa
Nowością na rynku w 2020 roku są rozwiązania bezserwerowe lub bezserwerowe.
Co to oznacza, postaram się wyjaśnić na przykładzie zwykłej usługi lub aplikacji backendowej.
Aby wdrożyć zwykłą aplikację backendową, kupujemy lub wynajmujemy serwer, kopiujemy na niego kod, publikujemy punkt końcowy na zewnątrz i regularnie płacimy za czynsz, prąd i usługi centrum danych. To jest standardowy schemat.
Czy jest jakiś inny sposób? Dzięki usługom bezserwerowym jest to możliwe.
Na czym skupia się to podejście: nie ma serwera, nie ma nawet wynajmu wirtualnej instancji w chmurze. Aby wdrożyć usługę, skopiuj kod (funkcje) do repozytorium i opublikuj go na punkcie końcowym. Wtedy po prostu płacimy za każde wywołanie tej funkcji, całkowicie ignorując sprzęt, na którym jest ona wykonywana.
Postaram się zilustrować to podejście zdjęciami.
Klasyczne wdrożenie. Mamy usługę z określonym obciążeniem. Podnosimy dwie instancje: serwery fizyczne lub instancje w AWS. Żądania zewnętrzne są wysyłane do tych instancji i tam przetwarzane.
Jak widać na obrazku, serwery nie są rozmieszczone równomiernie. Jeden jest wykorzystany w 100%, są dwa żądania, a jeden jest tylko w 50% - częściowo bezczynny. Jeśli nie pojawią się trzy żądania, ale 30, wówczas cały system nie będzie w stanie poradzić sobie z obciążeniem i zacznie zwalniać.
Wdrożenie bezserwerowe. W środowisku bezserwerowym taka usługa nie ma instancji ani serwerów. Istnieje pewna pula podgrzewanych zasobów - małe przygotowane kontenery Docker z wdrożonym kodem funkcji. System odbiera żądania zewnętrzne i dla każdego z nich framework bezserwerowy generuje mały kontener z kodem: przetwarza to konkretne żądanie i zabija kontener.
Jedno żądanie - podniesiony jeden kontener, 1000 żądań - 1000 kontenerów. Wdrożenie na serwerach sprzętowych jest już zadaniem dostawcy chmury. Jest całkowicie ukryty przez framework bezserwerowy. W tej koncepcji płacimy za każde połączenie. Np. jedno połączenie przyszło dziennie – zapłaciliśmy za jedno połączenie, milion przyszło za minutę – zapłaciliśmy za milion. Lub za sekundę to się również dzieje.
Koncepcja publikowania funkcji bezserwerowej jest odpowiednia w przypadku usługi bezstanowej. A jeśli potrzebujesz usługi (stanowej) z pełnym stanem, to dodajemy bazę danych do usługi. W tym przypadku, jeśli chodzi o pracę ze stanem, każda funkcja stanowa po prostu zapisuje i odczytuje z bazy danych. Ponadto z bazy dowolnego z trzech typów opisanych na początku artykułu.
Jakie jest wspólne ograniczenie wszystkich tych baz danych? Są to koszty stale używanego serwera chmurowego lub sprzętowego (lub kilku serwerów). Nie ma znaczenia, czy korzystamy z klasycznej czy zarządzanej bazy danych, czy mamy Devops i administratora, czy nie, i tak płacimy za sprzęt, prąd i wynajem centrum danych 24/7. Jeżeli mamy bazę klasyczną to płacimy za master i slave. Jeśli jest to mocno obciążona baza danych typu sharded, płacimy za 10, 20 lub 30 serwerów i płacimy stale.
Obecność serwerów zarezerwowanych na stałe w strukturze kosztów była dotychczas postrzegana jako zło konieczne. Konwencjonalne bazy danych mają również inne trudności, takie jak ograniczenia liczby połączeń, ograniczenia skalowania, konsensus rozproszony geograficznie - można je jakoś rozwiązać w niektórych bazach danych, ale nie wszystkie na raz i nie jest to idealne rozwiązanie.
Bezserwerowa baza danych - teoria
Pytanie roku 2020: czy możliwe jest utworzenie bazy danych bezserwerowej? Każdy słyszał o backendie bezserwerowym... spróbujmy uczynić bazę danych bezserwerową?
Brzmi to dziwnie, ponieważ baza danych jest usługą stanową, niezbyt odpowiednią dla infrastruktury bezserwerowej. Jednocześnie stan bazy danych jest bardzo duży: gigabajty, terabajty, a w bazach analitycznych nawet petabajty. Nie jest łatwo go podnieść w lekkich kontenerach Docker.
Z drugiej strony prawie wszystkie współczesne bazy danych zawierają ogromną ilość logiki i komponentów: transakcje, koordynację integralności, procedury, zależności relacyjne i mnóstwo logiki. W przypadku sporej części logiki bazy danych wystarczy mały stan. Gigabajty i terabajty są bezpośrednio wykorzystywane tylko przez niewielką część logiki bazy danych zaangażowaną w bezpośrednie wykonywanie zapytań.
W związku z tym pomysł jest następujący: jeśli część logiki pozwala na wykonanie bezstanowe, dlaczego nie podzielić bazy na części stanowe i bezstanowe.
Bezserwerowe dla rozwiązań OLAP
Zobaczmy, jak mogłoby wyglądać pocięcie bazy danych na części stanowe i bezstanowe, korzystając z praktycznych przykładów.
Mamy na przykład analityczną bazę danych: dane zewnętrzne (czerwony cylinder po lewej stronie), proces ETL ładujący dane do bazy danych oraz analityk wysyłający zapytania SQL do bazy danych. Jest to klasyczny schemat działania hurtowni danych.
W tym schemacie ETL jest warunkowo wykonywany jednorazowo. Trzeba wtedy stale płacić za serwery, na których działa baza danych z danymi wypełnionymi ETL, żeby było do czego wysyłać zapytania.
Przyjrzyjmy się alternatywnemu podejściu zaimplementowanemu w AWS Athena Serverless. Nie ma trwale dedykowanego sprzętu, na którym przechowywane są pobrane dane. Zamiast tego:
- Użytkownik przesyła zapytanie SQL do Atheny. Optymalizator Athena analizuje zapytanie SQL i przeszukuje magazyn metadanych (Metadane) pod kątem konkretnych danych potrzebnych do wykonania zapytania.
- Optymalizator na podstawie zebranych danych pobiera niezbędne dane ze źródeł zewnętrznych do pamięci tymczasowej (tymczasowa baza danych).
- Zapytanie SQL od użytkownika jest wykonywane w pamięci tymczasowej, a wynik jest zwracany użytkownikowi.
- Pamięć tymczasowa zostanie wyczyszczona i zasoby zostaną zwolnione.
W tej architekturze płacimy jedynie za proces realizacji żądania. Żadnych żądań - żadnych kosztów.
Jest to działające podejście i zostało zaimplementowane nie tylko w Athena Serverless, ale także w Redshift Spectrum (w AWS).
Przykład Atheny pokazuje, że baza danych Serverless działa na rzeczywistych zapytaniach obejmujących dziesiątki i setki terabajtów danych. Setki terabajtów będą wymagały setek serwerów, ale nie musimy za nie płacić - płacimy za żądania. Szybkość każdego żądania jest (bardzo) niska w porównaniu do specjalistycznych analitycznych baz danych, takich jak Vertica, ale nie płacimy za okresy przestojów.
Taka baza danych ma zastosowanie w przypadku rzadkich zapytań analitycznych ad hoc. Na przykład, gdy spontanicznie decydujemy się przetestować jakąś hipotezę na gigantycznej ilości danych. Atena jest idealna w takich przypadkach. W przypadku regularnych żądań taki system jest drogi. W takim przypadku należy buforować dane w jakimś specjalistycznym rozwiązaniu.
Bezserwerowe dla rozwiązań OLTP
Poprzedni przykład dotyczył zadań OLAP (analitycznych). Przyjrzyjmy się teraz zadaniom OLTP.
Wyobraźmy sobie skalowalny PostgreSQL lub MySQL. Stwórzmy zwykłą instancję zarządzaną PostgreSQL lub MySQL przy minimalnych zasobach. Gdy instancja otrzyma większe obciążenie, podłączymy dodatkowe repliki, do których rozdzielimy część obciążenia odczytu. Jeśli nie ma żądań ani obciążenia, wyłączamy repliki. Pierwsza instancja to master, a pozostałe to repliki.
Pomysł ten został zaimplementowany w bazie danych o nazwie Aurora Serverless AWS. Zasada jest prosta: żądania z aplikacji zewnętrznych są akceptowane przez flotę proxy. Widząc wzrost obciążenia, przydziela zasoby obliczeniowe z wygrzanych minimalnych instancji - połączenie zostaje nawiązane tak szybko, jak to możliwe. Wyłączenie instancji odbywa się w ten sam sposób.
W Aurorze istnieje koncepcja jednostki pojemnościowej Aurora, ACU. Jest to (warunkowo) instancja (serwer). Każda konkretna jednostka ACU może być jednostką nadrzędną lub podrzędną. Każda jednostka pojemności ma własną pamięć RAM, procesor i dysk minimalny. W związku z tym jeden jest głównym, reszta to repliki tylko do odczytu.
Liczba działających jednostek wydajności Aurora jest parametrem konfigurowalnym. Minimalna ilość może wynosić jeden lub zero (w tym przypadku baza danych nie będzie działać w przypadku braku zapytań).
Kiedy baza otrzymuje żądania, flota proxy zwiększa pojemność jednostek Aurora, zwiększając zasoby wydajności systemu. Możliwość zwiększania i zmniejszania zasobów pozwala systemowi „żonglować” zasobami: automatycznie wyświetlać poszczególne ACU (zastępując je nowymi) i wdrażać wszystkie aktualne aktualizacje pobranych zasobów.
Baza Aurora Serverless może skalować obciążenie odczytem. Ale dokumentacja nie mówi tego bezpośrednio. Może się wydawać, że są w stanie podnieść multimastera. Nie ma magii.
Ta baza danych doskonale pozwala uniknąć wydawania ogromnych sum pieniędzy na systemy o nieprzewidywalnym dostępie. Przykładowo tworząc strony MVP czy wizytówki marketingowe zazwyczaj nie oczekujemy stabilnego obciążenia. W związku z tym, jeśli nie ma dostępu, nie płacimy za instancje. Gdy nastąpi nieoczekiwane obciążenie, np. po konferencji czy kampanii reklamowej, witrynę odwiedzają tłumy ludzi i obciążenie gwałtownie wzrasta, Aurora Serverless automatycznie przejmuje to obciążenie i szybko łączy brakujące zasoby (ACU). Potem konferencja mija, wszyscy zapominają o prototypie, serwery (ACU) gasną, a koszty spadają do zera – wygodne.
To rozwiązanie nie nadaje się do stabilnego dużego obciążenia, ponieważ nie skaluje obciążenia przy zapisie. Wszystkie te połączenia i rozłączenia zasobów występują w tzw. „punkcie skali” – momencie, w którym baza danych nie jest obsługiwana przez transakcję lub tabele tymczasowe. Na przykład w ciągu tygodnia punkt skali może nie nastąpić, a baza działa na tych samych zasobach i po prostu nie może się rozszerzać ani kurczyć.
Nie ma żadnej magii - to zwykły PostgreSQL. Jednak proces dodawania i odłączania maszyn jest częściowo zautomatyzowany.
Z założenia bezserwerowy
Aurora Serverless to stara baza danych przepisana na potrzeby chmury, aby wykorzystać niektóre zalety Serverless. A teraz opowiem Wam o bazie, która oryginalnie została napisana dla chmury, dla podejścia bezserwerowego – Serverless-by-design. Powstał od razu, bez założenia, że będzie działać na serwerach fizycznych.
Ta baza nazywa się Płatek Śniegu. Zawiera trzy kluczowe bloki.
Pierwszy to blok metadanych. Jest to szybka usługa in-memory, która rozwiązuje problemy z bezpieczeństwem, metadanymi, transakcjami i optymalizacją zapytań (pokazane na ilustracji po lewej stronie).
Drugi blok to zestaw wirtualnych klastrów obliczeniowych do obliczeń (na ilustracji zestaw niebieskich kółek).
Trzeci blok to system przechowywania danych oparty na S3. S3 to bezwymiarowa pamięć obiektów w AWS, coś w rodzaju bezwymiarowego Dropbox dla firm.
Zobaczmy, jak działa Snowflake, zakładając zimny start. Oznacza to, że istnieje baza danych, dane są do niej ładowane, nie ma uruchomionych zapytań. Odpowiednio, jeśli nie ma żadnych żądań do bazy danych, uruchomiliśmy szybką usługę metadanych w pamięci (pierwszy blok). I mamy pamięć S3, w której przechowywane są dane tabelaryczne, podzielone na tzw. mikropartycje. Dla uproszczenia: jeśli tabela zawiera transakcje, to mikropartycje są dniami transakcji. Każdy dzień to osobna mikropartycja, osobny plik. A gdy baza danych działa w tym trybie, płacisz tylko za miejsce zajmowane przez dane. Ponadto stawka za jedno miejsce jest bardzo niska (zwłaszcza biorąc pod uwagę znaczną kompresję). Usługa metadanych również działa stale, ale do optymalizacji zapytań nie potrzeba dużo zasobów, a usługę można uznać za shareware.
Wyobraźmy sobie teraz, że do naszej bazy danych przyszedł użytkownik i wysłał zapytanie SQL. Zapytanie SQL jest natychmiast wysyłane do usługi Metadata w celu przetworzenia. W związku z tym po otrzymaniu wniosku usługa ta analizuje żądanie, dostępne dane, uprawnienia użytkownika i, jeśli wszystko jest w porządku, opracowuje plan rozpatrzenia wniosku.
Następnie usługa inicjuje uruchomienie klastra obliczeniowego. Klaster obliczeniowy to klaster serwerów wykonujących obliczenia. Oznacza to, że jest to klaster, który może zawierać 1 serwer, 2 serwery, 4, 8, 16, 32 - tyle, ile chcesz. Wysyłasz żądanie i natychmiast rozpoczyna się uruchamianie tego klastra. To naprawdę zajmuje sekundy.
Następnie, po uruchomieniu klastra, mikropartycje potrzebne do przetworzenia żądania zaczynają być kopiowane do klastra z S3. Oznacza to, że wyobraźmy sobie, że do wykonania zapytania SQL potrzebne są dwie partycje z jednej tabeli i jedna z drugiej. W takim przypadku do klastra zostaną skopiowane tylko trzy niezbędne partycje, a nie wszystkie tabele w całości. Właśnie dlatego i właśnie dlatego, że wszystko znajduje się w jednym centrum danych i jest połączone bardzo szybkimi kanałami, cały proces transferu przebiega bardzo szybko: w ciągu kilku sekund, bardzo rzadko w minutach, chyba że mówimy o jakichś monstrualnych żądaniach. W związku z tym mikropartycje są kopiowane do klastra obliczeniowego, a po zakończeniu w tym klastrze obliczeniowym wykonywane jest zapytanie SQL. Wynikiem tego żądania może być jedna linia, kilka linii lub tabela - są one wysyłane na zewnątrz do użytkownika, aby mógł je pobrać, wyświetlić w swoim narzędziu BI lub wykorzystać w inny sposób.
Każde zapytanie SQL może nie tylko odczytać agregaty z wcześniej załadowanych danych, ale także załadować/wygenerować nowe dane w bazie danych. Oznacza to, że może to być zapytanie, które np. wstawi nowe rekordy do innej tabeli, co doprowadzi do pojawienia się nowej partycji na klastrze obliczeniowym, która z kolei zostanie automatycznie zapisana w pojedynczej pamięci S3.
Opisany powyżej scenariusz od przybycia użytkownika do podniesienia klastra, załadowania danych, wykonania zapytań, uzyskania wyników, płatny jest według stawki za minuty korzystania z podniesionego wirtualnego klastra obliczeniowego, wirtualnego magazynu. Stawka różni się w zależności od strefy AWS i wielkości klastra, ale średnio wynosi kilka dolarów za godzinę. Klaster czterech maszyn jest dwukrotnie droższy niż klaster dwóch maszyn, a klaster ośmiu maszyn jest nadal dwukrotnie droższy. Dostępne są opcje 16, 32 maszyn, w zależności od złożoności zamówień. Ale płacisz tylko za te minuty, kiedy klaster faktycznie działa, bo gdy nie ma żądań, to tak jakby odrywasz ręce i po 5-10 minutach oczekiwania (parametr konfigurowalny) sam zgaśnie, uwolnij zasoby i stań się wolny.
Całkowicie realistyczny scenariusz jest taki, że kiedy wysyłasz żądanie, klaster pojawia się, mówiąc relatywnie, za minutę, odlicza kolejną minutę, potem pięć minut do zamknięcia, a ty płacisz za siedem minut działania tego klastra, i nie miesiącami i latami.
Pierwszy scenariusz opisuje użycie Snowflake w ustawieniu pojedynczego użytkownika. Teraz wyobraźmy sobie, że użytkowników jest wielu, co jest bliższe rzeczywistemu scenariuszowi.
Załóżmy, że mamy wielu analityków i raportów Tableau, którzy nieustannie bombardują naszą bazę danych dużą liczbą prostych analitycznych zapytań SQL.
Ponadto, powiedzmy, że mamy pomysłowych badaczy danych, którzy próbują robić potworne rzeczy z danymi, operują na dziesiątkach terabajtów, analizują miliardy i biliony wierszy danych.
Dla dwóch opisanych powyżej typów obciążeń Snowflake umożliwia utworzenie kilku niezależnych klastrów obliczeniowych o różnej pojemności. Co więcej, te klastry obliczeniowe działają niezależnie, ale ze wspólnymi, spójnymi danymi.
W przypadku dużej liczby lekkich zapytań można utworzyć 2–3 małe klastry, każdy po około 2 komputerach. Takie zachowanie można wdrożyć między innymi za pomocą ustawień automatycznych. Mówisz więc: „Płatek śniegu, wznieś małą gromadkę. Jeśli obciążenie na nim wzrośnie powyżej określonego parametru, podnieś podobny drugi, trzeci. Kiedy ładunek zacznie opadać, zgaś nadmiar.” Dzięki temu niezależnie od tego, ilu analityków przyjdzie i zacznie przeglądać raporty, każdy będzie miał wystarczające zasoby.
Jednocześnie, jeśli analitycy śpią i nikt nie zagląda do raportów, klastry mogą całkowicie zniknąć, a Ty przestaniesz za nie płacić.
Jednocześnie w przypadku ciężkich zapytań (od badaczy danych) można utworzyć jeden bardzo duży klaster na 32 maszyny. Ten klaster będzie również opłacany tylko za te minuty i godziny, w których działa Twoje gigantyczne żądanie.
Możliwość opisana powyżej pozwala na podzielenie nie tylko 2, ale także większej liczby rodzajów zadań na klastry (ETL, monitorowanie, materializacja raportów,...).
Podsumujmy Płatek Śniegu. Baza łączy w sobie piękny pomysł i wykonalną realizację. W ManyChat używamy Snowflake do analizy wszystkich posiadanych danych. Nie mamy trzech skupień, jak w przykładzie, ale od 5 do 9, o różnej wielkości. Do niektórych zadań posiadamy konwencjonalne 16-masowe, 2-masowe, a także supermałe 1-masowe. Skutecznie rozkładają obciążenie i pozwalają nam sporo zaoszczędzić.
Baza danych skutecznie skaluje obciążenie odczytem i zapisem. To ogromna różnica i ogromny przełom w porównaniu do tej samej „Aurory”, która dźwigała jedynie ładunek czytelniczy. Snowflake umożliwia skalowanie obciążenia związanego z pisaniem za pomocą tych klastrów obliczeniowych. Oznacza to, że jak wspomniałem, w ManyChat używamy kilku klastrów, małe i bardzo małe klastry są używane głównie do ETL, do ładowania danych. A analitycy już żyją na średnich klastrach, na które obciążenie ETL absolutnie nie ma wpływu, więc działają bardzo szybko.
W związku z tym baza danych dobrze nadaje się do zadań OLAP. Niestety, nie ma to jeszcze zastosowania w przypadku obciążeń OLTP. Po pierwsze, ta baza danych jest kolumnowa, co pociąga za sobą wszystkie konsekwencje. Po drugie, samo podejście, kiedy dla każdego żądania, jeśli zajdzie taka potrzeba, podnosi się klaster obliczeniowy i zasypuje go danymi, niestety nie jest jeszcze wystarczająco szybkie dla obciążeń OLTP. Oczekiwanie sekund na zadania OLAP jest normalne, ale w przypadku zadań OLTP jest niedopuszczalne; 100 ms byłoby lepsze, a 10 ms byłoby jeszcze lepsze.
Łączny
Bezserwerowa baza danych jest możliwa poprzez podzielenie bazy danych na części bezstanowe i stanowe. Być może zauważyłeś, że we wszystkich powyższych przykładach część Stateful to, mówiąc relatywnie, przechowywanie mikro-partycji w S3, a Stateless to optymalizator, pracujący z metadanymi i zajmujący się kwestiami bezpieczeństwa, które można zgłosić jako niezależne, lekkie usługi Stateless.
Wykonywanie zapytań SQL można również postrzegać jako usługi stanu lekkiego, które mogą pojawiać się w trybie bezserwerowym, np. klastry obliczeniowe Snowflake, pobierać tylko niezbędne dane, wykonywać zapytanie i „wychodzić”.
Bezserwerowe bazy danych na poziomie produkcyjnym są już dostępne do użytku i działają. Te bezserwerowe bazy danych są już gotowe do obsługi zadań OLAP. Niestety, do zadań OLTP używa się ich... z pewnymi niuansami, gdyż istnieją pewne ograniczenia. Z jednej strony jest to minus. Ale z drugiej strony jest to szansa. Być może któryś z czytelników znajdzie sposób, aby baza danych OLTP była całkowicie bezserwerowa, bez ograniczeń Aurory.
Mam nadzieję, że uznałeś to za interesujące. Bezserwerowe to przyszłość :)
Źródło: www.habr.com