1 / 58

Case Wensus

Case Wensus.com. Mikael Koskinen | 6.3.2013. #td2013fi. Agenda. Azure resurssien hyödyntäminen kustannustehokkaasti Node.js Azuressa Table Storage & optimointi MongoDB Azuressa = Lessons Learned : Case Wensus.com. Esittely. Mikael Koskinen @ MikaelKoskinen http://mikaelkoskinen.net

chesna
Download Presentation

Case Wensus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Case Wensus.com Mikael Koskinen | 6.3.2013 #td2013fi

  2. Agenda • Azureresurssien hyödyntäminen kustannustehokkaasti • Node.js Azuressa • Table Storage & optimointi • MongoDB Azuressa • = LessonsLearned: Case Wensus.com

  3. Esittely • Mikael Koskinen • @MikaelKoskinen • http://mikaelkoskinen.net • Adafy Oy • Jyväskyläläinen it-startup • Perustettu 2012 kesäkuussa • BizSpark Plus • http://www.adafy.com

  4. Wensus.com • Windows sovelluskehittäjän analyysipalvelu: • Virheraportit • Käyttäjien arvostelut • Yleistä tietoa: latausmäärät, käyttäjien aktiivisuus • Tuetut alustat: • Windows Phone • Windows 8 (beta)

  5. Virheraportit

  6. Käyttäjien arvostelut

  7. Yleistä tietoa

  8. Lähtökohta Jatkuvien kustannusten minimointi: 2. Skaalautuvuuden maksimointi: Startupin perustajan mielessä:

  9. Kustannusten minimointi • Arvio kustannuksista: • Kalleinta: Laskenta-aika (compute) • Halvinta: Tiedon tallennus (storage) = Tavoite: Maksimoidaan storage-palvelujen käyttö • Tietojen tallentaminen halpaa (esim. 165Gt = 13€ / kk) • Azure huolehtii skaalaamisesta käyttäjämäärän kasvaessa

  10. Kustannusten minimointi • Mutta: Jossain vaiheessa tarvitaan myös laskenta-aikaa… • Api • Webbisivut • Raporttien muodostaminen • Azure tarjoaa selvän hinnoittelumallin laskenta-ajalle: • Hidas = halpaa (Extrasmall: 11€ /kk) • Nopea = kallista (Extralarge: 514€ /kk) • Kuinka pitää laskenta-ajan kustannukset maltillisena: • Minimoidaan nopean laskenta-ajan (”highpriority”) tarve • Maksimoidaan taustalla tapahtuva hidas laskenta

  11. Kustannusten minimointi • Tarve nopealla laskenta-ajalle: • API • Käyttäjän webbisivut • Kaikki muu: • Hidasta ja halpaa taustalaskentaa hyödyntäen • Lopputulokset tallennetaan Azure Storageen

  12. Skaalautuvuus • Worker-farmi: • Nippu extrasmall -palvelimia • Maksimoidaan taustalla tapahtuva hidas laskenta • Kaikki laskenta, jonka hitaus ei haittaa käyttökokemusta

  13. Lähtökohta Jatkuvien kustannusten minimointi: 2. Skaalautuvuuden maksimointi: Startupin perustajan mielessä:

  14. Välineet • Jatkuvien kustannusten minimointi: • Azure Storagen käyttö • Nopean laskenta-ajan käyttäminen vain välttämättömissä kohdissa. • 2. Skaalautuvuuden maksimointi: • Siirretään kaikki laskentaa vaativat operaatiot Azure Service Bussin välityksellä ”worker-farmiin” Ratkaisut ensimmäiseen versioon:

  15. LessonsLearned Suunnittele etukäteen palvelun resurssien käyttö: Minimoi ”highpriority” laskenta, maksimoi taustalla tapahtuva halvempi laskenta.

  16. Palvelun rakenne WensusPortal Customer.wensus.com Käyttäjä Kehittäjä Raportit Raporttien muodostus WensusApi Api.wensus.com

  17. Palvelun rakenne WensusPortal Customer.wensus.com Käyttäjä Kehittäjä Raportit Raporttien muodostus WensusApi Api.wensus.com

  18. API WensusApi Api.wensus.com • Skaalautuvuus: • Kuinka varmistaa, että sovellusten määrän kasvaessa API ei muodostu pullonkaulaksi? = Minimoidaan APIn vastuut. • Vastuut: • Vastaanottaa sovelluksen lähettämä viesti • Tehdä viestille jotain mahdollisimman nopeasti

  19. API toteutus • Toteutus: • Viestin vastaanotto • Välitys eteenpäin Azure Service Bus –palveluun • Paluuarvo sovellukseen: Viesti vastaanotettu onnistuneesti • Teknologia: Node.js

  20. Node.js • Miksi Node, eikä ASP.NET Web API? • Suorituskyky & Kustannukset • Enemmän tehoja per euro • Mahdollisuus vaihtaa Linux-pohjaiseen hostaukseen • Myös Node.js on ensimmäisen luokan Azure-kansalainen.

  21. Node.js suorituskyky Palvelinkustannusten näkökulma (tavoite 5000 req/s): ASP.NET MVC:llä toteutettu rajapinta maksaisi 66% enemmän.

  22. Node.js Azuressa Virallinen Node.js Azure –kirjasto: https://github.com/WindowsAzure/azure-sdk-for-node Azure toimintojen käyttäminen kirjaston avulla suoraviivaista:

  23. Node.js palvelun hostaaminenAzuressa • Azure Web Role • Azure Web Site • Azure Virtual Machine: • Linux • Windows

  24. Node.js Azurenvirtuaalipalvelimessa • Linux: • Forever (https://github.com/nodejitsu/forever) • Windows: • IISNode

  25. LessonsLearned Suunnittele etukäteen palvelun resurssien käyttö: Minimoi ”highpriority” laskenta, maksimoi taustalla tapahtuva halvempi laskenta. Maksimoi kalliimpien resurssien hyödyt: Oikea teknologia + kevyt rajapinta -> enemmän req/s

  26. Palvelun rakenne WensusPortal Customer.wensus.com Käyttäjä Kehittäjä Raportit Raporttien muodostus WensusApi Api.wensus.com

  27. Raporttien muodostus • ”Map & reduce” –raportointi • Massaraportointia • ”Pre-aggregated” –raportointi • Raportointia reaaliajassa • Palvelun ensimmäinen versio: • Massaraportointi

  28. Datan säilytys • Worker lukee Azure Service Bussista viestin ja tallentaa sen Azure Table Storageen raportointia varten. • Azure Table storage • Nimestään huolimatta enemmän sukua NoSQL- kuin SQL-kantoihin.

  29. Table storage Partitio: 6 Partitio: 4 Partitio: 2 ID: 19 App: 2 Action: install Time: 4.5.2012 ... ID: 9 App: 4 Action: install Time: 3.4.2012 ... ID: 110 App: 6 Action: install Time: 9.1.2012 ... ID: 35 App: 2 Action: launch Time: 3.8.2012 ... ID: 35 App: 4 Action: launch Time: 2.7.2012 ... ID: 35 App: 6 Action: launch Time: 1.8.2012 ... ID: 840 App: 2 Action: install Time: 6.6.2012 ... ID: 1121 App: 4 Action: install Time: 5.5.2012 ... ID: 751 App: 6 Action: install Time: 4.4.2012 ... ID: 4541 App: 2 Action: install Time: 5.8.2012 ... ID: 4541 App: 4 Action: install Time: 4.7.2012 ... ID: 4541 App: 6 Action: install Time: 3.6.2012 ...

  30. Table storage ja datan hakeminen Partitio: 4 ID: 9 App: 4 Action: install Time: 3.4.2012 ... ID: 35 App: 4 Action: launch Time: 2.7.2012 ... ID: 1121 App: 4 Action: install Time: 5.5.2012 ... ID: 4541 App: 4 Action: install Time: 4.7.2012 ... • Objektin yksilöivä tunniste: • partitio (PartitionKey) + id (RowKey). • Haku esimerkkejä: • HaeObjekti(partitio:4, id:9) • HaeObjektit(partitio:4, päivämäärä > x, action:install)

  31. Table storagen käyttö 1.versiossa: Partitio: 4 ID: 9 App: 4 Action: install Time: 3.4.2012 ... ID: 35 App: 4 Action: launch Time: 2.7.2012 ... ID: 1121 App: 4 Action: install Time: 5.5.2012 ... ID: 4541 App: 4 Action: install Time: 4.7.2012 ... • Partition key: Sovelluksen ID • Haut: Tietystä partitiosta, pääasiassa kahdella hakukriteerillä (action, pvm) • Tuloksena joukko rivejä • Massaraportointia eräajoina.

  32. Table storage ja suorituskyky

  33. Table storage ja suorituskyky

  34. Table storage ja suorituskyky Esimerkki hausta, kun partiossa on 10 miljoona riviä: ”Hae partitiosta ’install’ tyyppiset objektit aikaväliltä ’kesäkuu 2012’. Tulos: n. 1000 riviä Hakuaika: n. 1h 20min.

  35. Table storage ja suorituskyky • Indeksi ainoastaan Partition Key + Row Key –yhdistelmällä. • Ei mahdollisuutta omien indeksien määrittämiseen • Jos haku jotain muuta kuin Partition Key + Row Key –yhdistelmä, Table Storage joutuu käymään partition kaikki rivit läpi. Haut hidastuvat partition koon kasvaessa

  36. Table storagen optimointi Partitio: 4_2012_06_01 ID: 9 App: 4 Action: install Time: 1.6.2012 ... ID: 35 App: 4 Action: launch Time: 1.6.2012 ... ID: 1121 App: 4 Action: install Time: 1.6.2012 ... ID: 4541 App: 4 Action: install Time: 1.6.2012 ... Avain suorituskyvyn parantamiseen: Partitioiden pienentäminen. Uusi malli: Partitio: Sovelluksen id + päivämäärä

  37. 10x parempi suorituskyky uudella partitionnilla Uudessa mallissa Table Storage joutuu käymään läpi 10x vähemmän rivejä.

  38. Hakujen lisäoptimointi Haku rinnakkain: Koodimuutos: Alkuperäinen: Uusi:

  39. Usean säikeen käytön vaikutus suorituskykyyn Neljällä säikeellä jopa 3x nopeammat hakuajat.

  40. LessonsLearned Suunnittele etukäteen palvelun resurssien käyttö: Minimoi ”highpriority” laskenta, maksimoi taustalla tapahtuva halvempi laskenta. Maksimoi kalliimpien resurssien hyödyt: Oikea teknologia + kevyt rajapinta -> enemmän req/s Varmista, että Table Storagen partition koko kasvaa hallitusti ja rajoitetusti.

  41. Raportointidatan kolmas malli • Ensimmäinen malli: • Table Storage: Partitio = sovellus • Toinen malli: • Table Storage: Partitio = sovellus + päivämäärä • Idea kolmannen mallin takana: • ”Onko tarve hakea Table Storagesta vanhoja, jopa puoli vuotta vanhoja rivejä?” • Kolmas malli: • Yli viikon vanha data tallennetaan blob storageen

  42. Azure Blob Storage raportointidatan säilönä • Eräajona: • Haetaan yhden sovelluksen yhden päivät data • Muunnetaan json-formaattiin • Zipataan • Tallennetaan Azure Blob Storageen • Raporttien muodostuksessa voidaan haut tehdä Blob Storagesta haettuun dataan, ei Table Storageen. • Suorituskyky kymmeniä kertoja parempia. Vie myös muistia enemmän.

  43. Raporttien muodostus • ”Map & reduce” –raportointi • Massaraportointia • ”Pre-aggregated” –raportointi • Raportointia reaaliajassa • Palvelun ensimmäinen versio: • Massaraportointi • Palvelun toinen versio: • Kohti pre-aggregated raportointia

  44. Raportit dokumenteista • Uudessa mallissa: • Raakadata = Table Storage • Raportointidata = Valmiiksi lasketut dokumentit • Esimerkkidokumentti:

  45. MongoDB Raporttidokumentit MongoDB NoSQL –kannassa. MongoDB:ssä useita datan analysointiin sopivia ominaisuuksia: ”Atomiset operaatiot” ja aggregation framework

  46. MongoDB ja atomiset operaatiot Hakukriteerit, joilla dokumenttiä etsitään Atominen operaatio, joka dokumentille tehdään Jos dokumenttia ei löydy hakukriitereillä, luodaan se automaattisesti. Esimerkki

  47. MongoDB ja atomiset operaatiot Esimerkki Dokumentti:

  48. Muita MongoDB:n hyödyllisiä ominaisuuksia • Capped collection • ”Tähän kokoelmaan mahtuu vain 500 dokumenttia” • TTL-kokoelmat • ”Poista automaattisesti yli kuukauden vanhat dokumentit tästä kokoelmasta”

  49. MongoDB Azuressa • http://docs.mongodb.org/ecosystem/platforms/windows-azure/ • MongoDB virallinen Azure-asennusohjelma: • Asentaa MongoDB:n Worker Role –palveluina • Omat kokemukset viime vuoden puolelta huonoja • Azure Virtual Machine • Linux tai Windows • Azure VM Depot: http://vmdepot.msopentech.com

  50. Lessons Learned • Suunnittele etukäteen palvelun resurssien käyttö: Minimoi ”highpriority” laskenta, maksimoi taustalla tapahtuva halvempi laskenta. • Maksimoi kalliimpien resurssien hyödyt: Oikea teknologia + kevyt rajapinta -> enemmän req/s • Varmista, että Table Storagen partition koko kasvaa hallitusti ja rajoitetusti. • Tee hakuja Table Storageen ilman Partition key + Row key yhdistelmää vain jos on pakko. Hyödynnä datan hakemisessa muita ratkaisuja (blog storage, MongoDB jne)

More Related