Twitter zet bittorrent in voor uitrollen serverupdates

Twitter heeft zijn serverupdateproces tot 12 seconden weten te verkorten. De systeembeheerders konden deze verbetering treffen door gebruik te maken van bittorrent. Voorheen duurde het uitrollen van een update 40 minuten.

Twitter heeft met de zelfgeschreven bittorrentsoftware een tijdsbesparing van 99,5% gerealiseerd. Door de groei in de afgelopen jaren kampte het sociale netwerk met schalingsproblemen bij serverupdates. Met behulp van een enkele Git-server werden de duizenden servers van updates voorzien. Elke server moest apart de update van de Git-server downloaden en installeren, een tijdrovende bezigheid omdat de server zeer zwaar werd belast. Het bedrijf uit San Francisco vond de oplossing in de opensource-wereld in de vorm van bittorrent.

Ze ontwikkelden Murder, vernoemd naar het poëtische woord voor een groep kraaien. Murder is een tool, geschreven in de programmeertalen Python en Ruby, waarmee de updates worden aangestuurd. Als client is een gemodificeerde versie van BitTornado gebruikt die onder andere lagere toegangstijden kent, een hogere bandbreedte en geen nat-problemen heeft. Elke server downloadt van één peer en dient zelf ook als één peer voor een andere server. Als de eerste server in de 'ketting' het eerste datapakketje van de update heeft ontvangen, begint de tweede server dat pakketje te downloaden. Zo ontstaat er een ketting van data waarmee de nieuwste software snel verspreid kan worden. De Murder-software is opensource en voor iedereen te downloaden.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (97)

[analog_]

Ik snap niet goed waarom er wordt geredeneerd dat een 1-op-1 ketting beter werkt dan een één-op-veel. (peer download maar bij één seed tegelijkertijd maar één seed kan wel meerdere peers behelpen). Ik neem aan dat we het hier over minstens een paar hondertal servers hebben dus lijkt mij één 12 seconden update met een ketting constructie eigenlijk een beetje ongeloofwaardig aangezien het verbinden, downloaden, sluiten van een connectie waarschijnlijk op z'n minst toch 200ms duurt. (12sec ~= 60 clients)

[Reactie gewijzigd door analog_ op 1 augustus 2024 05:18]

[Kser]

Alle peers werken op 10MB/sec om een netwerkoverload te voorkomen. De eerste peer kan beginnen aan zijn upload op het moment dat zijn eerste pakket voltooid is.
Men heeft het over een update van ongeveer 100MB, deel dat door 10MB/sec en je krijgt 10 seconden dat nodig is voor de transfer.

Tegen de tijd dat de originele seed klaar is met zijn complete transfer, is de laatste server allang begonnen met zijn download van de op een na laatste server. En vanwege de 10MB/s cap is het niet nodig om te downloaden van meer dan 1 peer.

Elke server gebruikt slechts enkele milliseconden (niet honderden) om te communiceren met de tracker en om vervolgens een connectie te maken met de server waarvan deze de update binnen haalt. Daarna volgt de secondenlange transfer. Je kunt er op rekenen dat na de eerste twee seconden alle duizenden servers begonnen zijn met de download van de update.

[Verwijderd]

De updatetijd is 12 seconden. Misschien kan jij er nog 2-3 seconden vanaf doen, maar dan maak je het nodeloos complex, niet?

[Rob Coops]

Het is een leuk idee marr ik vraag me af at we gebeurt als machine 3 halverwege een upload *poof* doet en het even allemaal niet meer trekt om welke reden dan ook... als het dan nog steeds als een ketting werkt dan is twitter nog steeds totaal nutteloos omdat deze software dan totaal nutteloos is.

Ik neem aan dat er dus ook een manier is voor andere machines om de positie van server 3 in de ketting over te nemen. Hoe ze dat dan geregeld hebben en hoe ze het voor elkaar gekregen hebben dat alle servers schijnbaar constant met elkaar aan het kletsen zijn om uit te vinden of hun peer al een nieuwe update heeft is me nog niet helemaal duidelijk. Het lijkt me namelijk een enorme bandwidth verspilling als je alle servers constant met elkaar moet laten kletsen zeker als je meerdere datacenters hebt die als het even kan ook nog eens in meerdere locaties te vinden zijn.

Het klinkt nog het meest naar een bittorrent aanpassing die alleen van een peer download en een peer toestaat van hun te downloaden. Maar hoe ze het constant vragen aan de andere peers hebben opgelost...

[TheGhostInc]

Het blijft gewoon een torrent, met waarschijnlijk een maximum concurrent downloads van 1, met een max. ratio van 1 en nog wat van die tweaks.

Dus bij het uitvallen pakt gewoon de volgende het over, no big deal. En uiteindelijk zal de tracker alleen wat extra load krijgen. Hoewel natuurlijk gebruik kan worden gemaakt van peer exchange.

Overigens is het heel stom om steeds meer downloads simultaan toe te staan, dat is namelijk hèt recept om je hele backbone om zeep te helpen. Immers binnen een paar seconden zijn er zoveel servers tegelijkertijd aan het downloaden dat je tientallen Gbit's aan het verstoken bent. En over het algemeen is dat exact het moment waarop er iets stuk gaat, en dat alles om een paar seconden sneller klaar te zijn....

[thegve]

Er zit een cap op van 10Mbit begrijp ik, dus die traffic zal wel wat meevallen.

[Icekiller2k6]

Bittorrent heeft een tracker.. je kunt meerdere trackers erbij houden..
je zegt nu als 3 machines opeens "poof" weg gaan.. want als je ene "server" waar je (als je 1 op 1 afhaalt) vanaf haalt opeens weg is? dan is je download ook incomplete en moet je een seintje sturen v an "oh ow" ..

De download controleer je naderhand mbv MD5 Hash..
en als het verkeerd is ga mbv het feit dat torrent per stukje een hash heeft van de main server afhalen voor te completen..

Torrent is redelijk "goed" ontwikkelt.. 't is enkel het gebruik wat correct gedaan moet worden.. als je 1 hoofdserver hebt waar de files en hoofdtracker opstaat en dan 10 kleine backup servers (imho met 10mbit lijntjes..) die enkel lijst bijhoudt van wie wat aan het afhalen is en wie complete heeft gaat het bijna nooit fout.. en als het fout gaat is de md5 hash om het op te vangen kun je het alsof manueel afhalen.

[ultimasnake]

Raar, want opzich is dit niet zozeer het idee achter bitorrent.. Normaal zou 1 persoon seeden, waarna een 2de begint met downloaden en seeden and so on waardoor de laatste twitter server dan het bestand geserveerd zou moeten krijgen van b.v. 50 andere servers..

In dit geval is het een push-push ketting (van server 1 -> naar 2 -> naar 3) via toevallig de bittorrent netwerkinterface.

De nieuwe opzet likt me dan ook gevaarlijker dan de vroegere situatie gezien het stopt bij een falende server waar normaal 1 server voor outroll bedoeld was....

Helaas geen geluid hier anders even het filmpje bekeken voor meer helderheid

[Kser]

Raar, want opzich is dit niet zozeer het idee achter bitorrent.. Normaal zou 1 persoon seeden, waarna een 2de begint met downloaden en seeden and so on waardoor de laatste twitter server dan het bestand geserveerd zou moeten krijgen van b.v. 50 andere servers..

Dat klopt, maar in het geval van twitter is de download en upload gecapped om een overload te voorkomen. Je hebt dan ook geen tweede peer nodig omdat de eerste al voldoende snelheid biedt.

Alle servers krijgen vrijwel gelijktijdig de opdracht om een update binnen te halen.
Via de tracker krijgen ze een nummer waarmee de "ketting" wordt gevormd.
Ik zie geen groot probleem met falende servers. Een reeds gefaalde server zal zich niet melden bij de tracker. Mocht er iets mis gaan tijdens de transfer dan zal de volgende schakel in de ketting al snel een timeout krijgen en zich melden bij de tracker. De details weet ik niet, maar je kunt je voorstellen dat de tracker de gefaalde schakel "overslaat" waarbij de rest van de ketting een korte delay krijgt vanwege de gefaalde server. Maar het kan ook zo zijn dat de rest van de ketting zich allemaal opnieuw meldt bij de tracker vanwege een timeout en de tracker zorgt ervoor dat ze "opnieuw" genummerd worden. Hoe het ook wordt opgelost, het is een kwestie van een korte communicatie met de tracker die slechts enkele milliseconden nodig heeft.

Het belangrijkste van deze applicatie is dat het in plaats van via het internet, deze update binnen een lokale netwerk wordt doorgevoerd. Alles (behalve de data transfer) gebeurt in enkele milliseconden. Binnen een halve seconde van de update zullen enkele honderden of duizenden servers al begonnen zijn met het binnenhalen van de update, en een gefaalde server zal binnen "enkele" milliseconden worden overgeslagen.

Van de twaalf seconden die er nodig zijn, zijn er waarschijnlijk 10 voor de daadwerkelijke overdracht van de data (er werd 100MB genoemd voor de update met een transfer snelheid van 10MB/s). De overige twee seconden zijn voor het starten van de update op de duizenden servers en eventuele problemen die zich voordoen.

[Skinkie]

Multicast? Zeker als je servers in hetzelfde data centrum hangen...

[Sorcerer8472]

Niet handig, want dan moet je alsnog rekening houden met servers die niet in hetzelfde DC hangen. En dan is het de vraag hoe handig multicast voor een proces als updating is, als je ook al dit p2p-systeem hebt...

[silentsnake]

Multicast gaat leuk als je alles in 1 plat netwerk heb, wat me sterk lijkt met 1000en servers. Anders moet je multicast gaan routeren, leuke manier om je switches op hun gat te krijgen. (en nee, da's geen router maar een layer 3 switch) Sowieso is multicasten naar 1000en servers redelijk heavy voor net netwerk backbone, ongeacht of je wel of geen plat netwerk heb.

[Reactie gewijzigd door silentsnake op 1 augustus 2024 05:18]

[Ramoonus]

dat zou te slim zijn

[Freeaqingme]

Hoe stel je je dat voor je? Multicast is leuk bij dingen als streams, maar hierbij niet echt praktisch?

[Skinkie]

Ooit van Norton Ghost gehoord?

[DJFreestyler]

Begrijp ik nu goed dat ze een systeem hebben geschreven om een DVCS distributed te distribueren? Hadden ze niet beter de ditributed kwaliteiten van git kunnen gebruiken? Dus in plaats van al die duizend servers van 1 git server te laten downloaden laat je tien servers van die ene server downloaden waarna er weer tien servers van die tien servers kunnen downloaden en zo voort. Ik snap in ieder geval de redenatie niet helemaal hier achter...

[88Weighed]

Zo vreemd is de huidige oplossing nog niet. Op de manier die ze nu hebben geimplementeerd, duurt het uploadproces per server korter. Ze hoeven nu namelijk maar 1 keer te uploaden wat ze gedownload hebben.
Als je dit op de "klassieke" bittorrent manier doet, krijg je alsnog servers met een hoog bandbreedteverbruik. En laten we eerlijk zijn, Twitter heeft het al druk genoeg.

[Prototype666]

dit is in een dag te bouwen, het werkt super simpel en er kan weinig fout gaan, het is gratis / open source, en je kan het bijna unlimited scalen.

De simpelste oplossingen zijn meestal de beste .

[Archiebald]

Als je het filmpje gezien hebt, dan weet je waarom ze geen treedist gebruiken

[Bosmonster]

Elke server downloadt van één peer en dient zelf ook als één peer voor een andere server.

Dan vraag ik me af of het niet nog sneller kan als ze die limiet van 1 opschroeven naar 2 of 3.

[Eppo ©]

Ik vraag me eerder af het niet veel betrouwbaarder wordt als je het opschroeft naar 2 of 3. Als nu een server onderuit gaat, dan ligt heel je ketting stil...

[Scorpion1984]

De betrouwbaarheid gaat niet omlaag, hij zoekt gewoon een nieuwe peer die niet aan het uploaden is. Dus als er midden in de chain 1tje uitvalt, gaat degene zonder download link op zoek naar een nieuwe peer, wat degene is vóór(in de chain) diegene die uit is gevallen, het blijft gewoon torrent, alleen met een heel laag peer limit per client.

[Reactie gewijzigd door Scorpion1984 op 1 augustus 2024 05:18]

[ZpAz]

Dat is iets wat ik me ook afvraag, waarom van één naar éen? Heb het filmpje vluchtig doorgekeken dus heb niet zo snel gevolgd waarom (als het er al in staat).

[Leftblank]

Dat vertellen ze op ongeveer 10:40: Doordat de servers met gigabitlinks aan elkaar hangen is de extra tijd die nodig is om het bestand tussen meerdere mensen te versturen verwaarloosbaar. Daarnaast vertelt hij ook nog dat ze de snelheid en connecties limiteren om het overige verkeer niet te hinderen.

[ath92]

Omdat het bittorrent is. Alle bestanden die worden verzonden worden opgedeeld in kleine packages, dus je hebt niet het hele bestand nodig om verder te kunnen seeden. Bovendien werkt het via een tracker dus als er een seeder uitvalt kan de tracker de server die nog niets heeft ontvangen vertellen dat het moet verbinden met een andere server.

[Verwijderd]

In het filmpje zegt hij dat het rapper gaat in een simpele ketting: 1-1-1-1 dan in een complex systeem waarbij 1 server naar meerdere servers zendt bv: 3-3-3-3...

[bigoldie]

Niet alleen doet Twitter het op deze manier, ook de mensen van Facebook doen het op deze manier, check:
Velocity 2010: Tom Cook, "A Day in the Life of Facebook Operations"

[The Lord]

Lijtk erop dat veel meer bedrijven bittorrent hiervoor gaan gebruiken. INHolland al iets eerder:
nieuws: Hogeschool Inholland gebruikt bittorrent voor verspreiding software-updates

[Soultaker]

Wat een overkill. Git is al decentraal (of peer-to-peer zo je wilt): iedere server heeft een volledige kopie van de repository, en je kunt van een willekeurige server pullen. Het lijkt me dus dat ze net zo goed een hiërarchie hadden kunnen definiëren van servers (zeg, elke server bedient tien anderen) en dan kun je in een paar iteraties alle servers updaten zonder één server maximaal te belasten.

Iets soortgelijks kun je met rsync doen in het algemeen. Dat is ook niet echt nieuws natuurlijk. Mirror sites zijn bijna zo oud als het internet.

[Reactie gewijzigd door Soultaker op 1 augustus 2024 05:18]

[Togusa]

Ja, Git is decentraal, maar de data van een Git repo moet ook eerst op al die servers gezet worden. Het staat niet opeens magisch op alle servers. Het is niet zo dat als er wat naar de Git server geupload word dat het ook gelijk op alle andere servers staat.

Ze gebruiken BitTorrent om die data naar alle servers te verspreiden.

[Roland684]

Het lijkt er op dat de server die de update moet doen nu na 12 seconden klaar is, niet het hele process.
Een beetje in de trand van "vroeger moest ik iedereen persoonlijk uitnodigen voor mijn feestje, nu bel ik 1 persoon en zet de telefoonketting in werking en ben ik in 10 seconden klaar."

En hoe er hier nog sprake is van bittorrent is mij even onduidelijk. Een ketting is niet bepaald een p2p netwerk. Het is wel p2p, maar geen netwerk.

En ik zie nu duizenden single-point-of failure. 1 server dood, dan krijgt alles achter die server in de ketting geen updates meer. Maar daar hebben ze vast wel wat op bedacht, zoals niet een vaste ketting gebruiken, maar alleen de eerste peer die zich meldt toestaan.

[- peter -]

Raar, dit lijkt me nu niet echt een bittorrent implementatie, daar heb je juist het idee van een swarm. Dit is een rare ketting, die zo zwak is als de zwakste schakel.