Hej wszystkim!

Mam problem z czasami dostępu do serwisu, szukam rozwiązania który go skróci - najpierw opiszę jaki jest obecny stan portalu.

Każdy user może zakładać konta, dodawać prezentacje. Prezentacja składa się z obrazków, po klatkowych zdjęć lub rozbitych filmów na ramki. Userzy mogą te filmy udostępniać innym albo przez plugin w js animujący obrazki, albo poprzez wygenerowanie gif/video. Obecnie portal ma ok 500gb plików userów z całego świata, a transfer wychodzący jest na poziomie ok. 1tb miesięcznie.

Niestety pojawiają się problemy z wydajnością łącza, klient chce rozproszyć servery/dodać cdn'y. Tak by klienci nie musieli łączyć się z serverem przez pół świata do polski gdzie obecnie stoi 1 server.

Rozwiązania jakie udało mi się znaleźć to routing DNS, który wydaje się bardzo kosztowny lub Amazon S3 - tutaj lepiej z kosztami.

Problem jest taki, że user musi od razu uploadować pliki na najbliższy S3. Potem server jakiś musi go pobrać, utworzyć video, gify itd i oddać tym razem do kilku regionów S3. Cała procedura jest dość zawiła i szukam innych rozwiązań tego problemu.

Obecny szacunkowy koszt przy 3 regionach w amazonie tworzy koszt ok. 300$ miesięcznie + server bazowy do operacji na plikach, mysql'a itd. za ok 500zł/miesiąc. Te koszta są jak najbardziej akceptowalne.

Możecie doradzić jakieś rozwiązanie ew. utwierdzić mnie że S3 to dobry wybór?

za mało danych, muszę gdybać. transfer 1TB to bardzo mało, a ty piszesz, że są problemy z wydajnością łącza. ale JAKIE konkretnie przy tak małym transferze?
Poza tym zrozumiałem, że to jakieś duże pliki - tutaj regionalizacja chyba nie powinna być tak istotna, będzie to miało marginalne znaczenie.

Serwis niedawno wystartował więc to są same początki. Pliki w prezentacjach mogą mieć 5mb przy ilości 100 sztuk, a mogą mieć 100kb przy 1000 sztuk. User ma możliwość wgrywania ich przez www jak i dedykowany problem. Przez www można wgrać pojedyncze pliki jak i całe zip, a program automatycznie pakuje całość przed wysyłką.

Transfer przychodzący do servera jest darmowy, a wychodzący to właśnie 1tb - wszystkie obrazki są bardzo mocno kompresowane przed wysyłką. Problem polega na ich ilości i opóźnieniach niż na samej wadze - tak mi się wydaje.

Server jest w Polsce (e24cloud), klienci z 2 końca ziemi narzekają iż pliki wgrywają się bardzo wolny (szczególnie pojedynczo), gdzie ja w Polsce nie odczuwam tego problemu. Przy oglądaniu prezentacji problem jest identyczny - konsola pokazuje że nie tyle czas pobierania a czas pomiędzy requestami jest znaczący - myślę że winnych częściach świata opóźnienia są jeszcze większe.

Jeśli miał byś jakieś pytania mogące pomóc rozwiązać problem - zadaj je odpowiem.

Jakiś czas temu widziałem biuletyn ovh z ich ofertą cdn'ów rozmieszczonych na całym świecie. Zerknij czy to by nie rozwiązało twojego problemu: http://www.ovh.pl/cdn/

podstawowe pytanie: dane lokalne czy globalne? - czy klient ze stanow wrzucajac plik spodziewa sie ze odrazu cala europa go obejzy czy wrzuca plik w stanach dla odbiorcow w stanach?

ogolnie, masz conajmniej kilka sposobow na rozwiazanie twojego problemu, zeby przerzucic ruch do lokalnego serwera mozesz uzyc route 53, mozesz skonfigurowac bind z geoip, lub robic zwykly redirect

jak wrzucasz dane to mozesz je odrazu replikowac na drugi koniec swiata uzywajac np: glusterfs czy drbd, wszystko zalezy od skali, ilosci danych i ilosci plikow, a przy duzej pozostaje consistent hashing i cachowanie

co do S3 to zalezy jakie operacje chcesz robic na tych plikach, dlatego ze S3 dziala jako straming, rownie dobrze mozesz postawic hadoopowy HDFS u tanszych prowiderow i uzyskasz to samo co S3, jezeli jednak potrzebujesz mielic pliki jakimis programami, lub skakac po nich (fseek) to S3 sie nie sprawdzi bo bedziesz musial buforowac plik na maszynie ktora przetwarza dane czyli po prostu skopiowac plik lokalnie, jak danych masz duzo to bedzie to duzy narzut

klienci z daleka zawsze beda narzekac na transfer chociazby dlatego ze na laczach miedzy kontynentami jest capping, jak usluga ma byc szybsza to musi byc dla nich lokalna, kolejna sprawa jak duzo ludzi ma miec dostep do danych i w jakim czasie, kontent ma sie pojawic na drugim koncu odrazu, czy oglada go tysiace ludzi itp?

Prezentacje wgrane w Polsce mają być jak najszybciej widoczne na całym świecie.

Aktualny pomysł był taki:
1. User wgrywa obrazki lub zip na swój region w S3
2. Server "obsługujący prezentacje" pobiera je do siebie
3. Na serwerze renderujemy filmy, jeśli jest to zip to rozpakowujemy obrazki - jednym słowem przygotowujemy całą prezentację
4. Tworzymy pliki jsona z plikami (tak by user pobrał isona z obrazkami w ilości 10 sztuk po 100 obrazków, a nie 1000 requestów)
5. Uploadujemy na lokalny S3 (Server jest w Polsce więc uploadujemy na region Europa)
6. Serwer requestuje prośbę o rozpropagowanie danych na inne S3 (do innych regionów, na start 3)
7. User dostaje info o gotowości prezentacji

Niby realne, tylko spore koszta utrzymania - przynajmniej backupów plików robić nie trzeba! ;P

Edycja prezentacji niestety będzie polegać na podobnym procesie. Można utrzymywać pliki również na serwerze głównym przez co nie trzeba ich po każdej edycji pobejrać, niestety rozsyłanie będzie polegać na tym samym. Najpierw lokalny S3 następnie kopia pomiędzy S3'kami.

Kolejnym pomysłem był właśnie routing DNS i kopia servera 1:1 do kilku lokalizacji, wszystkie pliki jak i kod serwisu. Jedna baza danych dla ich wszystkich.

Nie mam doświadczenia by podjąć taką decyzję samemu bez doradztwa. Oba rozwiązania działały by poprawnie - tylko kwestią jest które z nich jest lepsze lub czy istnieją inne zmniejszające koszta.

Widly z igły osobiście gdybym miał taki problem to podszedł bym tak:

- mam conajmniej dwie identyczne strefy z aplikacja (moze byc oczywiscie wiecej)
- dns routuje do najblizszego serwera po latency, lub geoip i zwykly redirect
- klient robi zwykly upload do najblizszej strefy, plik laduje normalnie na serwerze - odpada upload do S3
- plik z automatu jest dodawany do kolejki, dane sa przetwarzane lokalnie - odpada download z S3
- po udanym przetwarzaniu plik wynikowy laduje na podmontowanym glusterze, gluster sam zadba o replikacje danych do innych stref i dziala to jak zwykly mount jak nfs
- kontent prezentacji jest dostepny poprzez niewielkie nody cache, moga to byc nawet malenkie vps, na hostach stoi cached reverse proxy - dzieki temu dane beda ciagniente doslownie z lokalnego dysku, co do odswierzania cache, zalezy od ciebie

kolejka:
polecam python + celery, sprawdzi sie doskonale a uzycie jest trywialne

baza danych:
osobiscie uzylbym apache cassandra, ma jezyk CQL bardzo zblizony do SQL no i przedewszystkim masz replikacje i klastrowanie z bani
druga opcja to shardowanie mysql i consisten hashing, nie uzywalbym replikacji sql ze wzgledu na opoznienia miedzy strefami

skalowanie up:
- tworzysz nowa strefe, stawiasz wszystkie elementy na niej
- podpinasz kolejny node glustera do klastra
- podpinasz kolejny node cassandry do klastra
- dodajesz informacje o kolejnej strefie do dns
- pijesz browar zwyciestwa

Edit:
ewentualnie zamiast glustera wykorzystaj S3 ale tylko do wynikow, dane przetwarzaj lokalnie