[LeopoldStuff]

#pytanie #programowanie #programista15k #cloud #webdev

Nie znam się na cloudzie i web-devie więc poradzę się jakie jest zalecane podejście do następującego problemu:
Załóżmy że jest sobie aplikacja typu monolit z bazą danych. Załóżmy że monolit jest w miarę dobrze napisany i jest wielowątkowy.
Załóżmy że mamy tysiące klientów którzy kupili naszą apkę, a każdy klient ma potencjalnie parę/paredziesiąt użytkowników korzystających z apki. Warto powiedzieć też, że baza danych ideowo jest per klient. Czyli wszyscy użytkownicy danego klienta mają dostęp do tych samych danych.

Pytanie 1 - ile instancji aplikacji (póki co nie rozważamy bazy danych) powinno być na serwerze:
a) jedna instancja dla wszystkich (aplikacja jest wielowątkowa więc potencjalnie poradzi sobie z wieloma użytkownikami na raz)? Ale jeżeli tak to jak ma się to do skalowania na cloudze? Czy jeżeli będziemy mieli tysiące użytkowników na raz to chmurka będzie przydzielała dodatkowe wątki dynamicznie w zależności od natężęnia?
b) będą tworzone instancje per klient albo nawet per użytkownik w zależności od zapotrzebowania?
c) może jeszcze inaczej?

Pytanie 2 - ile instancji baz danych powinno być na serwerze:
a) jedna baza dla wszystkich? Jeżeli tak to czy przy granicznej sytuacji gdzie mamy paredziesiąt tysięcy użytkowników na raz nie wystąpią duże lagi związane z dostępem do jednej baz? Jak realizowałoby się skalowanie takiej bazy?
b) jedna baza per klient ponieważ ideowo wszyscy użytkownicy danego klienta pracują na wspólnych danych więc baza per klient ma sens.
c) jeszcze inaczej?

[zibizz1]

@LeopoldStuff: zależy:)

[LeopoldStuff]

@zibizz1: wbrew pozorom to też jest odpowiedź bo myślałem że jest jakieś zalecane obecnie konkretne podejście a pewnie nie ma
( ͡° ʖ̯ ͡°)

[kimikini]

@LeopoldStuff: z baza to mozna tez podejsc tak ze jest schemat per client

[toshibaas]

@LeopoldStuff: wszystko zależy od aktualnego budżetu i tego jak jest napisana aplikacja.

1. W zależności od tego czy aplikacja ma jakieś lub będzie miała featury dla konkretnego klienta i jak jest wykonane np. zarządzanie połączeniami bo może się okazać, że aplikacja łącząc się do bazy będzie miała 300 aktywnych połączeń bo 30x10 klientów z osobnymi bazami. Przydzielanie zasobów będzie zależało od rozwiązania jakie będziecie wykorzystywać. IMHO. lepszym rozwiązaniem jest skalowalna instancja

[U.....t]

Czy jeżeli będziemy mieli tysiące użytkowników na raz to chmurka będzie przydzielała dodatkowe wątki dynamicznie w zależności od natężęnia?

@LeopoldStuff: ja wiem, że stary jestem i w chmurach widzę tylko linux servers (jak na tym komiksie-sucharze), ale zapytam z czystej ciekawości - możesz dokładniej rozwinąć co masz tutaj na myśli? I w jakiej technologii jest ta apka napisana?

[Saly]

a) jedna instancja dla wszystkich (aplikacja jest wielowątkowa więc potencjalnie poradzi sobie z wieloma użytkownikami na raz)? Ale jeżeli tak to jak ma się to do skalowania na cloudze? Czy jeżeli będziemy mieli tysiące użytkowników na raz to chmurka będzie przydzielała dodatkowe wątki dynamicznie w zależności od natężęnia?

@LeopoldStuff: to musisz sam ogarnać. Jak przykładowo używasz kubernetesa w jakiejś chmurze to w "definicji" twojej aplikacji mówisz ile procesorów ona wymaga. W

[y.....l]

@LeopoldStuff: 1. Zależy, ja bym postawił kilka instancji i load balancer przed nimi. Tylko Twoja aplikacja musi obsługiwać takie coś, że każdy request może iść do innej instancji. No i wtedy skalujesz ilość instancji w zależności od obciążenia.
2. To zależy. SQL to zawsze wąskie gardło. To zależy też jaki silnik bazy, czy to Oracle, MySQL, PostgreSQL czy jeszcze coś innego. To, że każdy klient powinien mieć indywidualną bazę to oczywiste.

[LeopoldStuff]

@UnderratedMoviesBot: jeżeli aplikacja jest wielowątkowa (przy okazji to .NET) to ma przydzielane wątki z puli wątków ale rozumiem że przy tysiącach użytkowniów na raz pula wątków może nie być wsytarczająco bo ma jakieś ograniczenia w zależności od użytego procesora i pamięci. Czy chmurki są w stanie dodawać procesory lub ogólnie moc obliczeniową plus pamięć dynamicznie tak żeby pula wątków mogła się powiekszać tyle ile potrzeba?

[LeopoldStuff]

@toshibaas: @Saly: @yggdrasil: dzięki za odpowiedzi, to mi już otworzyło kolejne punkty do rozważań.

[y.....l]

@LeopoldStuff: 1 cpu może obsługiwać więcej niż 1 wątek. Co do skalowania to tak możesz dodawać nowe serwery jak chcesz. Możesz też ustawić dynamiczne skalowanie w zależności np. od zużycia procesora.

[LeopoldStuff]

@yggdrasil: to wiem że więcej niż jeden wątek :) ale jeden cpu pewnie nie obsłuży powiedzmy 10 000 wątków albo odpowiednio więcej jeżeli będzie taka potrzeba. Pytałem czy chmurka dodaje dynamicznie procesry/moc obliczeniową jeżeli trzeba mocno zwiększyć liczbę wątków?

[y.....l]

@LeopoldStuff: Tak możesz dodawać sobie maszyny. Musisz tylko je skonfigurować w zależności od tego jak obsługujesz czy masz np. Kubernetesa czy nie masz itp. Jeżeli potrzebujesz więcej CPU albo ram to dodajesz sobie maszyn. Jeżeli chodzi o autoscaling to można się z tego doktoryzować. Ja w jednym projekcie od pół roku robię autoscaling tak, żeby działał dobrze.

[LeopoldStuff]

@yggdrasil: dzięki za wyjaśnienie

[Saly]

Czy chmurki są w stanie dodawać procesory lub ogólnie moc obliczeniową plus pamięć dynamicznie tak żeby pula wątków mogła się powiekszać tyle ile potrzeba?

@LeopoldStuff: używane podejście w chmurach to "wiecej instancji" a nie "grubsza instancja"

jeżeli aplikacja jest wielowątkowa (przy okazji to .NET) to ma przydzielane wątki z puli wątków ale rozumiem że przy tysiącach użytkowniów na raz pula wątków może nie być wsytarczająco bo ma jakieś ograniczenia w zależności

[LeopoldStuff]

@Saly: ok czyli jednak skalowanie jest przez nowe instancje a nie dokładanie zasobów do jednej instancji.
Co do puli wątków to się zgadza w .Necie w zależności od zapotrzebowania jest pewna startowa liczba wątków a następnie .net dodaje kolejne wątki w razie potrzeby według własnych wewnętrznych zasad.