Na czym umieścić serwis pokroju ebay ?

Muszę napisać projekt taki jak ebay, prosty system aukcyjny. Tylko że ma być skalowalny żeby mógł obsłużyć miliony osób. Czego użyć do takiego projektu ?

Jeszcze nie obsługuje nawet jednej, a Ty myślisz już o milionach? Nie widze w tym sensu.

Amazon śmiga na AWSie więc AWS powinien ogarnąć ;)

@Shalom: No i właśnie rozkminiałem temat i myślę tak czy starczy S3, E3, Scale i Load balancer czy uzyc serverless i zrobic to na AWS Lambda ?

Mi się wydaje, że tutaj nie chodzi o samą 'chmurę' ale bardziej o architekturę rozwiązania.

@.andy: chodzi o to jak by to zrobic, sama aplikacja np umiesczona na instancji E3 podpiety load balancer i uruchamia on kolejna instancje gdy ruch jest wiekszy lub ja wylacza gdy mniejszy. natomiast baza danych z sesjami powinna byc key-value zeby byla szybka, no i druga baza z produktami i aukcjami. ale nie wiem czy to co mysle jest ok.

@masterc:
Podam Ci przykład ejabberd (implementacja serwera protokołu XMPP). Skubańce ponoć na jednym nodzie obrobili 2+ mln użytkowników ;)

Both ejabberd and the test platform were running on Amazon EC2 instances. ejabberd was running on a single node of instance type m4.10xlarge (40 vCPU, 160 GiB). Tsung instance was identical.

Samo zaplecze sprzętowe to jedno ale bardziej liczy się architektura rozwiązania. Bo jak architektura będzie źle pomyślana, to zapchasz całego Amazona a aplikacja dalej nie obsłuży 1mln userów ;)

@masterc: ja bym zaczął od odpowiedniej abstrakcji, oddzielenia logiki biznesowej i modelu domonowego od szczegółów infrastrukturalnych (bazy danych, chmura etc). Wtedy jak juz będzie większe zapotrzebowanie to podmienisz implementację tych infrastrukturalnych detali. Oczywiście jesli dobrze zrozumialem Twoje posty.

Musisz sobie zawęzić wymagania żeby to miało sens. Skalowanie nie zadziała ci dla wszystkich user caseów jednakowo, wyświetlenie aktualnych (albo aktualnawych) aukcji dla milionów userów jest stosunkowo proste o ile nie personalizujesz tego widoku i o ile boty ci nie nabiją w cholerę sesji jak będą ci scrapeować oferty :), wystawienie nowego bidu w aukcji już jest bardziej skomplikowane (musi być atomowe), tak samo wystawienie aukcji (musisz tą aukcję jakoś zindeksować w szukajkach i wywalić cache dla danych kategorii).

Rzygnięcie sobie technologiami jak Cloudfront ALB ASG EC2 ElastiCache i RDS nie rozwiąże tych problemów.

masterc napisał(a):

Muszę napisać projekt taki jak ebay, prosty system aukcyjny. Tylko że ma być skalowalny żeby mógł obsłużyć miliony osób. Czego użyć do takiego projektu ?

Ja bym do takiego projektu użył jakiegoś software house'u, żeby mi to napisali, skoro to na miliony klientów to inwestor musi wyskoczyć z grubego hajsu. Nie ma rady.

@PanamaJoe: Nie no, takie pitu pitu jak formularze i dodawanie aukcji to ja napisze, to nie trzeba aż softhaousu. Chodzi mi tylko ze do przemyslenia jest baza, sesje i skalowanie instancji. Musze te odpowiedzi tutaj dobrze przeanalizowac i pogrzebac

NoSQL jest mniej elastyczne? Chyba wręcz przeciwnie.

pragmaticdev napisał(a):

NoSQL jest mniej elastyczne? Chyba wręcz przeciwnie.

Zależy od której strony patrzysz. Przy pracy ReadOnly (np robienie raportów) SQL jest bardziej elastyczny bo możesz złączyć wszystko ze wszystkim (i zabić bazę dla dużych zbiorów danych). Przy NoSQLu często musisz sobie wcześniej zaplanować jakie złączenia będą ci potrzebne w przyszłości

BTW w osobnym wątku znów jest dyskusja PostgreSQL z JSONB kontra klasyczne NoSQLe. Ja wolę PostgreSQL z JSONB bo to już znam i używałem

@pragmaticdev: W NoSQL nie masz możliwości łatwego wygenerowania raportu przekrojowego. Właściwie już na etapie projektowania zbioru danych musisz wiedzieć po czym będziesz te dane wyszukiwał. W przypadku SQL, masz jakąś strukturę typu OLTP, ale jak potrzebujesz raportowania, to nic wielkiego się nie stanie, poza potencjalnym zabiciem serwera, jeżeli zapytanie będzie mocno suboptymalne.

@piotrpo:

piotrpo napisał(a):

1. Jak ma się naprawdę skalować, to użycie mikroserwisów może być bardzo zasadne.

1. Sesje bardzo utrudniają skalowanie. Dlatego warto dane sesji trzymać po stronie użytkownika. Wtedy wszystkie dane przychodzą z każdym żądaniem.
2. Skalowanie instancji - zarządzalny k8s. Popatrz na GCP. Skalowanie node pool działa tam daleko lepiej niż w takim Azure (gdzie nie działa).
3. Skalowanie podów - im mniejsze i lżejsze pody, tym szybciej się uruchamiają i tym mniejszy zapas instancji będziesz musiał mieć.
4. Komunikacja pomiędzy usługami - warto pomyśleć o asynchroniczności z użyciem kolejek (tam gdzie to możliwe). Ktoś wrzuca nową aukcję, dane lądują w kolejce, następnie są przetwarzane przez osobną usługę/usługi i zapisywane na poziomie mikroserwisu.
5. Szybki cache zapewni ci Redis. Mam na myśli scenariusz typu kilka instancji usługi do rejestrowania ofert potrzebuje wiedzieć, czy w danej aukcji została wrzucona jakaś nie przetworzona oferta. Używanie Redis do komunikacji pomiędzy różnymi typami usług jest błędem.
6. Bazy danych dobieraj na poziomie mikroserwisów. Bazy NoSQL są mniej elastyczne, ale skalują się dużo bardziej niż jakieś postgresy, czy msql. Trzeba się zmierzyć z eventual consistency, ale skoro ma się skalować, to ciężko będzie od tego uciec.
7. Wszystkie statyczne rzeczy powinny iść z CDNa

Wrzucasz trochę mało danych, żeby doradzać cos naprawdę szczegółowego. Nie piszesz nic o wymaganiach jakościowych, bezpieczeństwie, kosztach. Warto poczytać https://aws.amazon.com/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/

1. Sesje trzymane po stronie użytkownika odpadają bo są niebezpieczne to raz, a dwa zawsze pozostaje element pamiętania czy to sekwencji czy tokena po stronie serwera prawda ? Już nie mówię o wszelkich algorytmach szyfrujących dane sesyjne trzymane u klienta ale chociażby problem z powtórnym wysyłaniem danych. I sposobności na atak crypto validation prone to reply attack. Dlatego sesje będą w Redis.
2. Tutaj redis bedzie na oddzielnym klastrze więc z utrzymaniem sesji i skalowaniem nie będzie problemu bo każda instancja będzie uzywać tej samej bazy
3. Obadam tematy, bo każdy pisze co innego i każdy poleca akurat tę metodę, którą zna co nie znaczy że jest ona lepsza czy najlepsza
4. Co to są pody ? iPody ?
5. Kolejki sa obowiązkowe. Ponieważ baza z danymi będzie na kolejnej instancji tam będzie też właśnie kolejka, która będzie odciążać pewne procesy, jak na przykład dodawanie aukcji, wysyłki wiadomości, maili, generowanie dokumentów itd.
6. Tak jak w sesjach Redis jest idealny do trzymania sesji i do obslugi cache
7. Do aplikacji musze uzyc mysql czy tam oracle . NoSQL to baza typu klucz wartosc wiec nie nadaje sie do niczego relacyjnego.
8. CDN zgadzam sie :)

Co do wymagań jakościowych czy bezpieczeństwa to ma to być serwer jak z lat 90. Lista przedmiotów, formularz dodawania / edycji, opcja podbij cene i to wszystko. Żadnych wodotrysków, żadnych cudów. Bezpieczeństwo na poziomie autentykaci więc zależne od użytkownika. Od mojej strony jak dam to na chmure to nie będe się martwił o aktualizacje serwerów, wszystko będzie po ich stronie także tutaj się nie martwię jakby. Dzięks za ciekawe punkty, dają do myslenia i trzeba jeszcze posiedzieć w papierach i poprojektować.

Lepiej żeby się jak najmniej skalował serwis, chyba że chcesz szybko zbankrutować.

masterc napisał(a):

1. Sesje trzymane po stronie użytkownika odpadają bo są niebezpieczne to raz, a dwa zawsze pozostaje element pamiętania czy to sekwencji czy tokena po stronie serwera prawda ? Już nie mówię o wszelkich algorytmach szyfrujących dane sesyjne trzymane u klienta ale chociażby problem z powtórnym wysyłaniem danych. I sposobności na atak crypto validation prone to reply attack. Dlatego sesje będą w Redis.

Twoja decyzja, nie manie sesji znacznie ułatwia skalowanie. Serwer nie musi trzymać tokenu, żeby go potwierdzić - JWT

1. Tutaj redis bedzie na oddzielnym klastrze więc z utrzymaniem sesji i skalowaniem nie będzie problemu bo każda instancja będzie uzywać tej samej bazy

Redis występuje jako usługa zarządzalna w każdej chmurze. Bez sensu stawiać własny klaster

1. Co to są pody ? iPody ?

Instancja usługi w k8s. Pakujesz wszystkie usługi do kontenerów dockerowych, wrzucasz do zarządzalnego Kubernetesa w chmurze, ustawiasz limity budżetów i leci.

1. Do aplikacji musze uzyc mysql czy tam oracle . NoSQL to baza typu klucz wartosc wiec nie nadaje sie do niczego relacyjnego.

Nie, klicz-wartość to tylko jedna z form NoSQL. Zobacz sobie co chmury oferują.

Co do wymagań jakościowych czy bezpieczeństwa to ma to być serwer jak z lat 90. Lista przedmiotów, formularz dodawania / edycji, opcja podbij cene i to wszystko. Żadnych wodotrysków, żadnych cudów. Bezpieczeństwo na poziomie autentykaci więc zależne od użytkownika. Od mojej strony jak dam to na chmure to nie będe się martwił o aktualizacje serwerów, wszystko będzie po ich stronie także tutaj się nie martwię jakby. Dzięks za ciekawe punkty, dają do myslenia i trzeba jeszcze posiedzieć w papierach i poprojektować.

No nie - co z HA, DR, jakie jest SLA, jakie masz RPO? Serwerami nie musisz się przejmować, o ile sam ich nie postawiłeś. Czyli dalej warto iść w usługi zarządzalne i nie stawiać żadnej własnej VM.

NoSQL to też bazy dokumentowe, a nie jedynie klucz-wartość. Spokojnie mogą przechowywać dane z relacjami. Tylko, że całą warstwa pilnowania relacji i spójności danych jest po stronie mikroserwisu. Bazy dokumentowe mają zaletę i wadę, że nie mają struktury - czyli wszystko przyjmą, nie wymagają migracji, ale zawsze może wpaść jakaś stara wybrakowana encją i wtedy serwis musi potrafić coś z tym zrobić.

No i dalej - dlaczego wy czepiacie się tak tych raportów? To nie lata 80-siąte, żeby trzymać jedną monolityczną i relacyjną bazę ;) Bazy serwisowe są małymi lekkimi bazkami dokumentowymi. Różne mechanizmu rzucania eventową propagują operacje z tych baz na inne bazy - np. jakąś relacyjną bazę, która spaja dane ze wszystkich mikroserwisów i służy do raportów. Potem analogicznie raz na jakiś czas eksportuje się bazy do hurtowni, gdzie liczą się agregaty na potrzeby analityki oraz kopania w danych. Ma to wiele zalet - można wprowadzać zmiany w serwisach, nie martwiąc się o migracje danych. Na raz możemy przechowywać różne typy dokumentów w kolekcji. Eksport do baz raportowych jest narzutem, ale przynajmniej żadne zapytanie nie zabije bazy produkcyjnej ;) Podobnie jest z bazami do hurtowni. Nie jest powiedziane, że jeden system ma mieć 1 bazę i to tylko jednego typu. Tym bardziej rozwiązania chmurowe mają wiele baz dla różnych zastosowań.

@pragmaticdev: Problem w tym, że mając wszystkie dane w jakimś MySQL jak przyjdzie ci zrobić zestawienie typu "wszystkie aktywne aukcje w kategorii x, otwarte w ciągu ostatnich 3 dni, o cenie wywoławczej powyżej y", to zrobisz to w 5 minut. Może zajedziesz serwer, ale zrobisz. W przypadku baz NoSQL już masz pod górkę, bo musisz mieć jakiś indeks, po którym wyciągniesz dokumenty, później musisz te dokumenty ręcznie przefiltrować i zagregować. Możesz też przygotować jakieś rozwiązanie pod analitykę, ale też trzeba to zrobić. I nie twierdzę, że NoSQL to zło. To w większości przypadków bardzo fajne i naturalne rozwiązanie, tylko tez ma swoje ograniczenia. Oprócz baz dokumentowych i KV, masz też bazy obiektowe - wrzucasz sobie obiekt w JSON, definiujesz na których polach chcesz indeksy i zapis, wyszukanie i pobranie pojedynczego obiektu chodzi lepiej niż w jakiejkolwiek relacyjnej bazie. We wspomnianym GCP był np. Google Cloud Datastore. Teraz jest to któreś z rozwiązań brandowanych jako Firebase. Oczywiście to co piszesz jest prawdą - jak masz system działający w sieci, to celem podstawowym jest, żeby działał, więc eksport (czy podwójny zapis) do bazy analitycznej ma sens.

@piotrpo:

Twoja decyzja, nie manie sesji znacznie ułatwia skalowanie. Serwer nie musi trzymać tokenu, żeby go potwierdzić - JWT

A jak poradzic sobie z powtornym wyslaniem danych ?

@masterc: napiszę ponownie - to jest jakiś nowy produkt, kolejna "genialna idea", jesteś jakims architektem w polskim software house który takie coś tworzy czy co? No bo jednak najpierw wypada miec jakiś klientów, jakąś logike biznesową i pod to dobierać bazy danych (a nie odwrotnie).

Tak jeszcze abstrahując od problemu - warto zwrócić uwagę że np taki StackOverflow wcale nie potrzebuje pod spodem niczego zbyt fancy (w kwestii architektury), taki klasyczny CDN + LB + web tier + RDBMS na dane, elastic do searcha, redis jako cache/pub-sub. W sumie robi prawie to samo co taki serwis aukcyjny:

• wystawienie pytania to aukcja
• łapka w górę/dół to prawie jak bid
• tagi to kategorie

Wszystko mieści się w kilku rackach (albo mieściło się): https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Bez przesady jak post zakręci się na synchronizacji lub baza przymuli to nic sienie stanie. Jak aukcje wygrają dwie osoby to już tak. Tracimy energię- bez założeń biznesowych i analizy domeny można powiedzieć - to zależy i to będzie najmniej kłamliwa odpowiedz.

Muszę napisać projekt taki jak ebay, prosty system aukcyjny. Tylko że ma być skalowalny żeby mógł obsłużyć miliony osób. Czego użyć do takiego projektu ?

Jakiś frontend, jakiś backend, baza danych i lecisz

Biore sie za robote, powroce jak bede mial dzialajaca lokalnie apliakcje

Aleksander32 napisał(a):

@masterc: napiszę ponownie - to jest jakiś nowy produkt, kolejna "genialna idea", jesteś jakims architektem w polskim software house który takie coś tworzy czy co? No bo jednak najpierw wypada miec jakiś klientów, jakąś logike biznesową i pod to dobierać bazy danych (a nie odwrotnie).

Tak tylko piszą ludzie, którzy maja pomysl ale nigdy go nie zrealizuja, ja nie mysle o biznesie , logice czy klientach. Kocham tworzyc i chce to stworzyc. Co sie stanie ? 1. projekt nauczy mnie doswiadczenia. Ta dyskusja juz mi wiele dala do nauki kolejnych rzeczy, 2. zyskam wiedze na temat jak mozna zrealziwoac tak duze serwisy. 3. program moze zaskoczyc i bedzie milion klientow a wtedy go sprzedam.
Nie ma tu miejsca na przegraną, no chyba ze sie poddam to wtedy przegram.

Jak będziesz interesował się chmurami to pomyśl o podejściu Cloud agnostic - czyli system chmurowy rozproszony, ale tak zrobiony, żeby uniezależnić się od platformy. Czyli zamiast cloudformation inwestować w Terraformę, zamiast SQS dać RabbitMQ etc. etc. Oczywiście pewnie coś tam zawsze będzie platform specyfic ale warto jak najwięcej rzeczy robić na pewnej wyższej formie abstrakcji. Dodatkowo warto dbać by całość była łatwa do postawienia na lokalu, bo praca wspólna jest czasem upierdliwą, a z czasem okazuje się, że bez devopa nie zdebuggujesz lokalnie pewnych scenariuszy systemu.

@masterc:

No do ceny to tak ale mowie o dowolnym blokowaniu tego samego requesta. Jak to zablokujesz ? obojetne np edycja danych jak zablokujesz powtorne wysylanie danych jesli sesja jest po stronie klienta ?

Musisz sobie stworzyć sekwencję requestów, która zabezpieczy cię przed biznesowo błędnym przebiegiem wydarzeń. Czyli np.

-> GET ./documents/123/lock-code
<- lock
-> POST /document/123
{
"lock-code" = "lock"
"document"="....."
}

Jak dokument jest już zablokowany, to na pierwsze żądanie zwracasz błąd, jak ktoś próbuje wysłać dokument bez wcześniejszego lock / z błędnym lock-code, to też odrzucasz.

Zobacz sobie Spryker marketplace
https://spryker.com/en/
Ma większość rzeczy jakie potrzebujesz dostęp do kodu jest i możesz przejrzeć tam implementację elastic, redisa itd.