Feb 11, 2016

Datavirrat eivät ole rauhallisesti virtaavia jokia, ne virtaavat ryöppyinä

Simo_Roikonen_High_res_blog_image.jpg

Better_Tech_Blog_intro_banner.jpg

[in English below] Kerroin taannoin Landis+Gyrin blogissa työskentelemisestä Landis+Gyrillä ja totesin: "hyvien tyyppien kanssa on hienoa viettää aikaa". Kohdallani tämä pätee myös tekniikassa - hyvien teknologioiden parissa on hienoa viettää aikaa! Täällä Jyväskylässä suunnittelemamme älykkään energianmittauksen kokonaisratkaisut pohjautuvat luonnollisesti hajautettuihin järjestelmiin. Sähkö- vesi-, kaasu- ja kaukolämpömittarit sekä niihin liittyvät verkon järjestelmäkomponentit ovat merkittävä osa hajautettua järjestelmää, ja ne sisältävät omat monimuotoiset haastealueensa, kuten tiedonsiirron, tietoturvan ja yleisen sulautettujen järjestelmien problematiikan.

Vastaavasti järjestelmäkomponentteja, kuten mittareita ja datakeskittimiä, käsittelevillä keskusjärjestelmillä on omat haasteensa. Keskusjärjestelmien vastuulla on parhaimmillaan miljoonien järjestelmäkomponenttien hallinta, ylläpito ja kentälle vienti, eli niin sanottu roll-out. Eikä todellakaan vähäisimpänä mittaustiedon vastaanotto. Voidaan sanoa, että keskusjärjestelmien ja hajautettujen järjestelmäkomponenttien välinen tiedonvaihto tapahtuu pääasiassa viestein. Monimuotoinen viestintä suurilla mittarimäärillä tuottaa valtavan datamäärän, joka keskusjärjestelmien on kyettävä prosessoimaan tehokkaasti.

Want to know more about working for Landis+Gyr? Just click.

Vuodessa on 31 557 600 sekuntia. Jos hajauttamattoman "yksisäikeisen" keskusjärjestelmän vastuulla on miljoona sähkömittaria, yksittäisen mittarin tiedonkäsittelyyn jää aikaa karkeasti vain 30 sekuntia vuodessa. Mittarin tehtävänä on kommunikoida keskusjärjestelmän kanssa mm. ajan synkronointiin, järjestelmäpäivityksiin ja konfigurointiin liittyvissä asioissa sekä toimittaa mittarilukemia vähintään mittaussopimuksessa määritellyllä tiheydellä keskusjärjestelmään. Kuukaudessa näille kaikille tehtäville jää siis aikaa vain alle 3 sekuntia per mittari. Tästä on helppo päätellä, että hajauttamattomana keskusjärjestelmä muodostuu helposti pullonkaulaksi.

Järkevä skaalautuvuus mahdollistaa kustannustehokkaan kasvun

Jo pelkästään keskusjärjestelmä-sana antaa viitteitä siihen, että sen hajauttaminen on haastavaa. Keskityn nyt kuitenkin vain siihen, mitä hajautuksella voi saavuttaa. Puhutaan siis horisontaalisesta skaalautuvuudesta, joka tarkoittaa yksittäisen järjestelmän hajauttamista usean palvelimen varaan. Tämä lisää rinnakkaista prosessointitehoa järjestelmän käyttöön. Vettä myllyyn saadaan vetämällä hihasta vielä lineaarinen skaalautuvuus. Sillä tarkoitetaan horisontaalista skaalautuvuutta, jossa tiedon prosessointikyky kasvaa suoraan suhteessa järjestelmää pyörittävien palvelimien määrään. Lineaarisesti skaalautuva keskusjärjestelmä, jossa on vaikkapa viisi palvelinta, antaa vuodessa yhdelle mittarille 2,5 minuuttia tiedonkäsittelyaikaa 30 sekunnin sijaan. Tämä siksi, että yksi keskusjärjestelmän palvelin vastaa ainoastaan 200 000 mittarin tiedon prosessoinnista miljoonan sijaan.

Lineaarisen skaalautuvuuden saavuttaminen puhtaasti on mahdollista vain teoriassa. Tämän päivän teknologiat kuitenkin tarjoavat mahdollisuuden päästä niin lähelle sitä, että käytännön sovelluksissa erot todelliseen lineaariseen skaalautuvuuteen jäävät usein merkityksettömiksi. Telecom-alalta 80-luvun lopulla ponnistanut Erlang-ohjelmointikieli ja -ympäristö on esimerkki lähes lineaarisesti skaalautuvien järjestelmien rakentamisen pioneerityökaluista. Erlang mahdollistaa palvelut, joiden käyttäjämäärät ovat miljardeja - esimerkkinä WhatsApp-viestinvälityspalvelu, joka rikkoi miljardin aktiivisen käyttäjän rajan helmikuun alussa. Väitän, että Facebook ei vuonna 2014 ostanut WhatsAppia reilulla 11 miljardilla eurolla vain haaliakseen lisää käyttäjiä. Uskon reilun 10 000 työntekijän Facebookia kiinnostaneen aika tavalla, miten 32 hengen yritys oli viidessä vuodessa kyennyt luomaan käyttäjämäärissään samassa luokassa painivan tuotteen. Kauppoja ei varmasti olisi tehty, jos kiinnostuksen kohteena olisivat olleet pelkästään palvelussa käytetyt teknologiat. Se mistä Facebook maksoi, oli teknologinen osaaminen, yksittäisen WhatsApp-palvelimen tehokkuus ja palvelun lähes lineaarisesti skaalautuva arkkitehtuuri.

Asiakaskuntamme koostuu erikokoisista sähkönsiirtoyhtiöistä, joten tarjoamiimme ratkaisuihin on pystyttävä sisällyttämään järjestelmäalusta, joka on juuri sopivan kokoinen asiakkaan tarpeisiin ja jota voidaan helposti kasvattaa tarvittaessa. Näin pienen asiakkaan ei tarvitse ostaa miljoonille mittapisteille suunniteltua mammuttialustaa ennen kuin sille on tarvetta ja suuri asiakas voi jatkaa kasvuaan vielä senkin jälkeen, kun mammuttialusta alkaa vääntö loppua. Lineaarinen skaalautuvuus mahdollistaa järkevästi myös älykkäät lisensointimallit, kuten mittarimäärään tai datankeräysmäärään pohjautuvan hinnoittelun.

Elastisuus taltuttaa dataryöpyt

Datavirrat eivät ole rauhallisesti virtaavia jokia - ne virtaavat ryöppyinä. Näin ollen mammuttialustaa tarvitaan hetkinä, jolloin dataryöppyjä tapahtuu. Lineaarisen skaalautuvuuden ja data-analytiikan avulla ryöppyjen ajankohtia voidaan ennakoida. Myös datan vastaanottavaa järjestelmäalustaa voidaan ryöpyn ajaksi vahvistaa uusilla palvelimilla ja "ohentaa" rauhallisiin hetkiin. Tätä kutsutaan elastisuudeksi.

Datamäärien räjähdysmäisen kasvun myötä skaalautuvuuden merkitys on noussut vuosi vuodelta. Suuria datamassoja käsittelevät yritykset, kuten Twitter, Netflix ja Amazon ovat tehneet huomattavia investointeja pyrkiessään lähemmäs lineaarista skaalautuvuutta. Seurauksena on syntynyt pääasiassa vanhoihin hyviin ideoihin perustuvaa uutta tietoa ja uusia teknologioita, joista myös me voimme hyötyä. Tämän päivän teknologiatuulet puhaltavat mukanaan trendejä, kuten reaktiivisuus-termin alta löytyvät ja Typesafen buustaamat Akka ja Spark sekä NoSQL-kantojen haku- ja viestinvälitysteknologioiden tulokkaat Cassandra, ElasticSearch ja Kafka. Nämä teknologiat ovat pinnalla syystä, sillä ne mahdollistavat hajautetun arkkitehtuurin jalkauttamisen ja sitä kautta järjestelmän reaktiivisten ominaisuuksien kuten responsiivisuuden, virhesietoisuuden ja elastisuuden lisäämisen.

Meidän ideologiamme on rakentaa juuri tällaisia reaktiivisia järjestelmiä. Matkaa on jäljellä ja haasteita edessä, mutta nyt jos koskaan meillä on hieno mahdollisuus päästä mullistamaan älykkään sähköverkon järjestelmiä maailmanlaajuisesti. Kasvattaaksesi osaamistasi näihin asioihin liittyen suosittelen käymään Courseran ilmaiset kurssit Functional Programming Principles in Scala sekä jatkokurssin Principles of Reactive Programming. Jos taas haluat mukaan toteuttamaan reaktiivisia järjestelmiä kanssamme, kannattaa tutustua meihin paremmin: eu.landisgyr.com/betterfuture.

Lähteitä
http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired 
http://natishalom.typepad.com/nati_shaloms_blog/2007/07/the-true-meanin.html 
http://www.erlang.org/course/history.html 
http://blog.whatsapp.com/616/One-billion

___________________________________________________________________________________

Data streams are not serenely flowing rivers
- they arrive in waves


I recently wrote in Landis+Gyr’s Finnish blog about working at the company: “It’s wonderful spending time with great people”. For me, this also applies to technology – it’s wonderful spending time with great technology! The end-to-end solutions for smart energy metering that we design here in Jyväskylä are naturally based on distributed systems. Electricity, water, gas and district heat meters and the related network system components are a significant part of a distributed system, and they each come with their specific, complex challenges such as data transfer and data security issues, and general problems related to embedded systems.

Similarly central systems that process system components such as meters and data concentrators present their unique challenges.The central systems are responsible for managing, maintaining and rolling out up to millions of system components. And last, but by no means least, receiving measurement data. We can say that the data exchange between the central systems and distributed system components mainly takes place through messaging. Diverse communication with a large number of meters produces a huge volume of data that the central systems must be able to process efficiently.

Want to know more about working for Landis+Gyr? Just click.

There are 31,557,600 seconds in a year. If a centralised “single thread” central system is responsible for a million electric meters, this leaves approximately just 30 seconds each year for processing the data from a single meter. The meter’s task is to communicate with the central system concerning, among other things, the synchronisation of time, system updates and configuration-related issues and to send meter readings to the central system at least at the frequency specified in the metering agreement. This means less than 3 seconds per meter to carry out all of these tasks each month. This makes it easy to come to the conclusion that a central system that remains centralised can easily form a bottle neck.

Sensible scalability enables cost-effective growth

Even just the term “central” system gives us an inkling of the difficulty of decentralisation. Here, I will focus only on what can be achieved through decentralising a system. What we are talking about is horizontal scalability, which means the decentralisation of a single system so that it runs on a number of servers. This adds parallel process efficiency to the utilisation of the system. We can achieve a more effective system by adding linear scalability to the mix. Linear scalability means horizontal scalability where the data processing ability grows in direct relation to the number of servers running the system. A linearly scalable central system that has, let’s say, five servers, provides a single meter with 2.5 minutes of processing time instead of 30 seconds. This results from a single server in the central system being responsible for processing data for just 200,000 meters instead of a million.

Achieving true linear scalability is possible only in theory. However, today’s technology offers possibilities to come so close to achieving it that the differences between practical applications and true linear scalability are often insignificant. Erlang, the programming language and runtime system originating in the telecom sector of the 1980s, is an example of a pioneering tool in constructing linearly scalable systems. Erlang enables services that have billions of users, for example the WhatsApp messaging service that broke the billion-user mark at the beginning of February. I would like to make the claim that Facebook did not buy WhatsApp for more than EUR 11 billion in 2014 just to increase its user count. I believe that Facebook, which employs 10,000 people, was very much interested in how a company with just 32 employees has been able to create a product with similar user numbers in the space of just five years. The deal would surely never have happened if it had just been about the technologies used by the service. What Facebook paid for was technological expertise, the efficiency of a single WhatsApp server and the service’s virtually linearly scalable architecture.

Our customer base consists of transmission system operators of varying sizes, which means that the solutions we offer need to include a system platform that is precisely the right size to suit the customer’s needs and that can be easily scaled up if required. This means that a small customer does not have to purchase a mammoth platform designed for millions of metering points before it needs to, and a large customer can continue to grow even after its mammoth platform begins to run out of puff. Linear scalability also sensibly enables smart licensing models, such as pricing based on the number of meters or data collection volumes.

Elasticity keeps data waves in check

Data streams are not serenely flowing rivers – they arrive in waves.Thus mammoth platforms are needed when these data waves strike. The timing of the waves can be predicted using data analytics. Also the system platform that receives the data can be harden for the duration of the wave using new servers and graded down during calm periods. This is called elasticity.

Due to the explosive growth in data volumes, the significance of scalability has grown year-on-year. Companies that process huge volumes of data, such as Twitter, Netflix and Amazon, have made considerable investments in their bid to approach linear scalability. The result has been new information and novel technologies, mainly based on good existing ideas, which also benefit us. Today’s winds of technology bring with them trends such as Akka and Spark, which are filed under the term “reactivity” and powered by Typesafe, and the NoSQL database search and communications technology newcomers Cassandra, ElasticSearch and Kafka. These technologies are popular because they make it possible to cascade a dispersed architecture and thus increase the reactive characteristics of the system, such as responsiveness, error tolerance and elasticity.

Our ideology is to build precisely these types of reactive systems. We still have a way to go and challenges to face but now we have an excellent opportunity to revolutionise smart grid systems on a worldwide scale. In order to increase your expertise in these issues, I recommend taking Coursera’s free courses Functional Programming Principles in Scala and the follow-on course Principles of Reactive Programming. If you are interested in implementing reactive systems together with us, take a closer look at what we do at eu.landisgyr.com/betterfuture.

Sources:
http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired 
http://natishalom.typepad.com/nati_shaloms_blog/2007/07/the-true-meanin.html 
http://www.erlang.org/course/history.html 
http://blog.whatsapp.com/616/One-billion

 

Related articles:

No Free Lunch with Distributed Systems

Docker ja konttiteknologiat - ratkaisuja ja suorituskykyä

Kiperät haasteet motivoivat