Skaalautuvat arkkitehtuurit Miten suunnitellaan kymmenien miljoonien käyttäjien järjestelmä – Case TeamUp Kalle Launiala, ProtonIT, The Ball [email protected], +358445575665
Download
Report
Transcript Skaalautuvat arkkitehtuurit Miten suunnitellaan kymmenien miljoonien käyttäjien järjestelmä – Case TeamUp Kalle Launiala, ProtonIT, The Ball [email protected], +358445575665
Skaalautuvat
arkkitehtuurit
Miten suunnitellaan kymmenien miljoonien käyttäjien
järjestelmä – Case TeamUp
Kalle Launiala, ProtonIT, The Ball
[email protected], +358445575665
Esityksen rakenne
• Case: TeamUp esittely
• Digitaalinen palvelu ja käyttäjä – mitä tarkoitetaan?
• Migraatioskenaariot ASP.NET MVC:stä skaalautuvaksi
• DEMO – Miltä arkkitehtuuri näyttää käytännössä?
• Mobiiliappsin huomiointi skaalautuvuudessa
• Mobiiliekosysteemien maksuton osuus tiedonsiirrossa
• Digitaalisen palvelun kustannusrakenne
Case: TeamUp
Talenttien, fanien ja sponsorien yhdistäminen
Liiketoiminnan ansaintamalli
• Talenteille ilmainen
• Faneille ilmainen
• Talentit & fanit & fanituotteet - kauppa
• Ilmainen = 0% lisä
• Ei edes kustannusten kattamista
• Sponsorit perustaso ilmainen
• Selvästi osoitettavasta lisäarvosta hinta = hyötyperuste
Edellytykset & motiivit
• Talentit tarvitaan
• Motiivi: Tiedottaa faneille, yhteys omaan faniyhteisöön
• Fanit tarvitaan
• Motiivi: Talenttien seuraaminen ja tukeminen, yhteisö
• Sponsorit tarvitaan
• Motiivi: Näkyvyyttä oikeassa yhteydessä, talenttien itse
esilletuomana, fanien hyväksi ymmärtämänä
• Motiivi: Markkinointipanostuksen tehokas ja mitattava
realisointi
Tunnistetut haasteet kasvussa
• Talentit ja fanit tarvitaan ensin, sponsorit seuraavat
• Talentit ja fanit luovat kaikki kustannukset
• Sponsorit eli rahoittajat saattavat tulla perästäpäin
• Tavoiteskenaario: iso olemassaoleva fanikanta
• Esim. Jääkiekko- tai jalkapallojoukkue, miljoonia faneja
• Ottelua edeltävää aktiviteettia, selkeitä käyttäjäpiikkejä
Liiketoiminnan kysymyksiä...
• Voidaanko palvella miljoona yhtaikaista käyttäjää?
• Jos pitää miettiä, vastaus on ei voida
• Jos voidaan palvella, mitä maksaa?
• Mitä muutosvaihtoehtoja on, tekniikassa, tuotteessa?
• Mistä kustannus tulee, mitä se tarkoittaa?
• Tämä vastaus auttaa yhteistyöneuvotteluissa
• Mahdollista tunnistaa ”pay-per-click” perusteet ja
saattaa muutenkin linjaan nykyisen verkko-infran kanssa
Resurssikäyttö on ratkaisun avain
.json
MVC Controller
+ Handler
Prosessointiaika (h),
suorituskyky ja
skaalautuvuus
Partial View
SQL Server
As Master Data
& Indexing Storage
Ajax
Partial View
Combination
Razor View + MVC
Rendering
Webisivut, Ajax lähteet (JSON)
= Siirrettävä datamäärä
Web Page
Individual With
Private Data
Käyttäjäryhmien lukumäärät
= kerroin muuhun
Invidividual With
Private Data
Community / Shared Data
Datamäärä
(GB),
suorituskyky ja
skaalautuvuus
ProtonIT:n Edellytykset
luoda migraatio-skenaario
• ”The Ball on Azure”
• Avoimesti GitHubissa 2012• Tuotannossa keväästä 2013
• Hyvin ohut autorisoitu HTTS/WSS kerros
Blob Storagen päällä
= Kokemusta skaalaavasta
runkoteknologiasta käytännössä
+ Yhteistyö TeamUpin kanssa aidosta
skenaariosta
Lähtötilanne
• Huom - Hinnat muuttuneet – kevät-syksy 2014:
• Blob hinta puolittunut - AWS:n hinnantäsmäytyksiin...
• Metriikka lähtötasoksi:
•
•
•
•
Selaimen siirtotiedoista - cachen realisoituvat faktat
Palvelinpään diagnostiikka HTTP pyynnön läpimenossa
Arvioita mittakaavasta SQL tietokannasta per käyttäjä
Arvioita mittakaavasta käyttäjiä per aikayksikkö
• Ajatus-työkalut: arkkitehtuurilohko-kaaviot + Excel
Ennen – Jälkeen – 50-100k
Landing Page Uncached Loads / Landing Page Cached Loads / Month
Active Users Month / User
/ User
1 000 000
60
3000
Mbps Avg / Storage
Storage
Network Network Total Cost CPU
Constant Transactions /
Costs
(GB)
Costs
w/o CPU Hours CPU CostTotal
Load
second Avg
11 391 € 703 125 63 281 € 74 672 € 510 000 30 600 € 105 272 €
2 222
0
CPU 600ms => 60ms
Dataservice JSON =>
Cachettava BLOB
Onnistuuko?
Onnistuuko 10x?
Mbps Avg / Storage
Storage
Network Network Total Cost CPU
Constant Transactions /
Costs
(GB)
Costs
w/o CPU Hours CPU CostTotal
Load
second Avg
19 609 € 410 156 36 914 € 56 523 € 51 000 3 060 € 59 583 €
1 296
118 056
Digitaalinen palvelu
... Ja sen käyttäjä tämän esityksen kontekstissa
Digitaalinen palvelu
• Websovellus
• Mobiililaite-palvelu
• Avoimen datan palvelu
• Internet-of-anything palvelu
... Käyttäjä
• Yksittäinen ihminen
• Käyttäjäryhmä
• Yksittäisen omistajan laite
• ... Käyttäjäryhmän roolinen laite
• Mikälie-laite
• ... Toinen digitaalinen palvelu (= loputon ketju palveluita)
Laskennan perusteet: Käyttäjä?
Mikä määritellään käyttäjäksi?
• Ihminen vai laite?
• Onko käyttäjä eri viikonlopun ”matsin aikaan” kuin
työpisteellä statuspäivityksiä katsoessaan?
Montako per aikayksikkö, miten aktiivisia?
• Tunnistetaanko sama käyttäjä erilaiseksi, vai jaetaanko yksi
käyttäjä eri käyttäjätyyppeihin toiminnoista riippuen?
• ”Sivuja lukeva käyttäjä”, ”Päivitystä tekevä”, ”Ostosta tekevä”
Otetaanko huomioon käyttäjän poissaoloajat, vai onko
käyttäjä aktiivinen palvelussa oleva käyttäjä?
• Käyttäjän kokemus voidaan huomioida, jos tunnistetaan
Mitä väliä käyttäjästä on?
Kapasiteettilaskennan kannalta ei niin merkittävää,
kunhan ei mene sekaisin tunnit ja kuukaudet – Ei eroa
mittakaavassa 300B (cached 304) outbound vs 1 IOTR!
Liiketoiminnan ja sijoittajien kannalta on merkittävää,
joten parempi ettei mene sekaisin...
Esimerkki: 50%+ kustannuksista tulee m2m
palveluketjuista... Mikä on käyttäjä ja montako niitä on?
Tulokset voivat vaikuttaa palvelun tuotteistukseen ja
liiketoimintamalliin, mikä on hyvä asia !
Migraatioskenaariot
ASP.NET MVC ja mobiiliappsin arkkitehtuurit
Lähtötilanne
.json
MVC Controller
+ Handler
Partial View
SQL Server
As Master Data
& Indexing Storage
Ajax
Partial View
Combination
Razor View + MVC
Rendering
Web Page
Individual With
Private Data
Invidividual With
Private Data
Community / Shared Data
Resurssikäytön hahmottaminen
• Käyttäjäkohtaisuus vs. monen käyttäjän yhteinen
• Prosessointikapasiteetti, tallennus, verkko
• Konkretisointi: Data siirrettäviksi tiedostoiksi
• Etagit, expiroituminen, ”näkyvä/kosketeltava” data
• Tiedostot ovat cachejen ja CDN:n vakiokauraa
• Muutokset ja dynaamiset haut
• Murto-osa requesteista, ei tarvitse olla välitön
.html
.js = jQuery
.jpg
.json
=> Jo nyt...
Alkutavoite: CPU konsolidointi +
verkko-cache
Restructure
Storage
To Master JSON
Käyttäjäkohtaiset
”CPU + SQL queryt”
pois GET:stä
600ms => 60ms
JSON
Information
Dependencies
JSON
.json
Information Information
Dependencies Dependencies
.json JSON
SQL Server
As Master Data
& Indexing Storage
.json
Personal Data
jQuery & Browser
Rendering
HTML, jQuery,
Dust.js etc
Served Directly
as .json BLOB
JSON / REST
Served Directly
As .json BLOB
Individual With
Private Data
Invidividual With
Private Data
Community /
Shared Data
Muutokset ja vapaat haut
asynkronisina, tulokset JSON:ina
Libraries / Frameworks
To Support Submitting
Web Page(s)
Libraries / Frameworks
To Support Viewing
Libraries / Frameworks
To Support JSON Data
Management
HTTP POST
HTTP GET
Web Content Serving
GET Requests
Scalable Cloud Storage
Html/Javascript/Css/JSON
Web Operation Handling
POSTS Requests
Owner Separated
Storage & Operations
On jo: Entity Framework Mallit
On jo: URL (json)= EF + Dataservice
HTTPModule voi tallettaa responsen
.json fileksi URL:n nimellä
= Toimii blobin nimenä täysin
=> Blobiksi suoraan
Käyttäjäkohtainen
autorisointi luonteva
tehdä EF:ssä
+ T4 generaattorilla
+ .JSON customointi
tulee samalla
Mahdollista tehdä migraatio sideby-side pala kerrallaan...
Entity
MVC Controller
+ Handler
Framework
Restructure
Storage
To Master JSON
Partial View
ASP.NET
MVC +
.json
WCF Dataservice
+ html & jQuery
Partial View
Combination
Ajax
SQL Server
As Master Data
& Indexing Storage
Razor View + MVC
Rendering
User vs. Public community
data identification is best
done at database level. The
separation can then be
applied to further
processing chain with
simple rules.
Web Page
JSON
Information
Dependencies
.json
.json
.json filet
blobeista
”Browser Templates”
+ html & jQuery
JSON
JSON
Information Information
Dependencies Dependencies
JSON
Information
Dependencies
jQuery & Browser
Rendering
.json
JSON / REST
Served
Directly
Web Page
Individual user private data:
Browser cacheable
- Requires user specific blobcaching on server side
Individual With
Private Data
Invidividual With
Private Data
Community / Shared Data
Community wide
public content:
CDN Deliverable /
cacheable, browser
cacheable
- One blob-storage
cache applies to all
users
DEMO
Azure Blob Storage vs. Paikallinen Filesystem
Pelkistyminen – Asteittain
• Palvelin on autorisoiva HTTPS/WSS handler
• Palveltava data on HTML:ää, JavaScriptiä, binääriä ja
JSON:ia
• Salatut cookiet/tokenit hoitavat tilanhallinnan
• Pyynnön lähteet ja käsittelydata kokonaisuudessaan:
•
•
•
•
•
Pyynnön URL = mikä appsi/instanssi, mikä jakeluryhmä
Pyynnön cookie = kuka kysyy
Loput blob storagesta näiden pohjalta (joko auth tai suoraan)
Muisticachessa ainoastaan salausavaimet
Pyyntöjen statistiikka/logitus => blob storageen per request
Skaalautuminen
• Ryhmät datan omistajina = itsenäinen datavarasto
• Kuin tiedostokansio, johon pääsy vaatii ryhmäoikeudet
• GET pyynnöt palvellaan suoraan auth kerroksen läpi
• POST pyynnöt prosessoidaan ryhmäkohtaisilla
resursseilla/priorisoinnilla
• Yksittäiset blobit skaalaavat 500 IOPS & 60MB/s
• Ryhmäkohtaiset blob/Files skaalaavat 60MB/s
Cache-tasot
• Mobiiliappsin sovelluksen oma tietokanta
• Datan päivitys kuten HTTP-protokollassa
• HTTP cache tasot
•
•
•
•
•
•
Täysin julkinen = proxy cachettava, expire time
Täysin yksityinen = client cache, expire tai Etag/MD5
HTTPS/SSL = täysin yksityinen
200 OK, täysi download
304 Not Changed, headerit (alle 300B) + transaktiot
Expire hit = ei verkkoliikennettä lainkaan
Mobiiliappsit & kauppapaikat
• Erityispiirre: ilmainen datan jako paketin mukana
• Sovellusten maksimikoot gigatavuja
• Kannattaa hyödyntää staattisen tiedon päivityksissä
• Arkkitehtuuri yksinkertaistuu JSON tiedonsiirtoon
• Helppo muuttaa tukemaan offline-modea
• Voi mahdollisesti hyödyntää myös muita jakopalveluita
• OneDrive, Google Drive, DropBox...
Digitaalisen palvelun
kustannusrakenne
Mitä maksaa pitää palvelimet palvelemassa pyyntöjä..?
Azuren hinnoittelu = kustannukset
Mitä
Paljonko
Maksaa
Per yksikkö
1/x jaettu vCore + 768M
750h = 1kk 11,09€
0,015€/h
1 vCore + 1,75G (* kerrannaiset tästä
johtaen)
750h = 1kk 44,33€
0,06€/h
SQL Database (Web & Business) (RET)
150 GB
168,14€
1,12€/GB
Verkkokaista ulospäin
2000 GB
178,29€
0,09€/GB
Block Blob Storage (Locally Red.)
10000GB
178,73€
0,018€/GB
Block Blob Storage (Geo R. Read Acc.)
10000GB
681,67€
0,068€/GB
Page Blob (= Disk) Storage (LR)
10000GB
372,35€
0,037€/GB
Page Blob (= Disk) Storage (RA-GRS)
10000GB
759,96€
0,076€/GB
Files (SMB Share) (LR)
10000GB
297,88€
0,030€/GB
Files (SMB Share) (RA-GRS)
10000GB
968,11€
0,097€/GB
Storage Transactions (LR & RA-GRS)
1000M
26,81€
0,02681€/M
Content Delivery Network
2000GB
129,58€
0,06€/GB
”Omat palvelimet” vs Azure
• Huomattavasti halvempi CPU aika
• Ei skaalaa miljooniin käyttäjiin
• Huomattavasti halvempi outbound kaista
• Jos tasaisessa käytössä, ei skaalaa kuormituspiikkeihin
• ... Käytännön palvelu ei ikinä tasaisessa käytössä
• Luotettava ja skaalaava tallennus maksaa paljon
• Eikä kuitenkaan skaalaa miljooniin käyttäjiin
Lisätään redundanssi + PaaS-tason ylläpito...
Azuren hinnoittelu vs konesalipilvi
• Disclaimer: UpCloud vain esimerkkinä
• Ei suoraan verrattavissa, mutta onpa kuitenkin...
• UpCloud Hinnasto: Merkittävät kustannuserot HKI
& Lontoo – kannattaa tarkistaa myynniltä...
Azuren hinnoittelu vs UpCloud
• Tallennus: Azure (LR-3x) Blob Storage = 0,018€/GB
•
•
•
•
•
MaxIOPS = 0,20€/GB (~ 10x kalliimpaa)
HDD = 0,09€/GB (~ 5x kalliimpaa)
SSD = 0,36€/GB (~ 20x kalliimpaa)
Backup (lisä) = 0,05€/GB (+ 2,7x kalliimpaa – jos tarpeen)
IO Transaktio = 0€ (halvempaa, ei hinnoitteluperuste)
• Ulosmenevä verkkoliikenne
• Azure: 0,09€/GB (blob & prosessoitu), 0,06€/GB CDN
• UpCloud: 0,05€/GB
Todellinen ero? Kontrolli
• ”Mikä on moottoritien kapasiteetti autoa tunnissa?”
• Miten lasketaan kaupungin kapasiteetti, tiet, risteykset?
• Moottoritie voidaan rakentaa tarjottuna palveluna
• Primitiivi-tallennusjärjestelmä voidaan tarjota palveluna
Azure Storage Scalability and Performance Targets
http://msdn.microsoft.com/enus/library/azure/dn249410.aspx
Single Blob: ”Up to 60 MB per second, or up to 500
requests per second”
Kysymykset
Kysymyksiä / tarkennuksia..?