Fra monolit til microservice: Sådan genbyggede Netflix sig selv i skyen

500 microservices styrer streaminggigantens infrastruktur efter syv års rejse til cloud.
Reportage15. december 2016 kl. 05:11
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

I august 2008 blev Netflix' datacenter ramt af et nedbrud, der fik virksomheden til at sende en besked til en lang række kunder om, at DVD'en de havde bestilt, ikke ville komme frem til tiden.

Den halvanden dag, som datacenteret var nede, blev en katalysator for Netflix-folket, der gik i gang med at overveje, hvordan it-infrastrukturen kunne blive bedre.

»Vi startede med at bygge et datacenter lige ved siden af det gamle,« fortæller Coburn Watson, der er chef for performance og reliability hos Netflix ved AWS-konferencen Re:Invent, der tidligere på måneden fandt sted i Las Vegas.

»Det var ikke det bedste træk i forhold til isolerede zoner,« erkender han.

Artiklen fortsætter efter annoncen

Netflix i tal

86.000.000 husstande betaler for et Netflix-abonnement.

Tilsammen giver de over 2 milliarder dollars i omsætning per kvartal.

I USA kan trafikken til Netflix om natten udgøre 35 procent af den samlede internettrafik i landet.

Netflix har 2500 ansatte.

Strategien passede heller ikke til Netflix' simple driftsambition for den dengang nystartede streamingforretning: Hvis du afspiller noget på Netflix, så virker det.

Med selskabets egne datacentre var det ikke altid tilfældet.

»Vi var ikke gode til at drive datacenter. Og det var vi heller ikke interesserede i at være. Vores speciale er indhold,« forklarer Coburn Watson.

Derfor valgte Netflix at droppe datacentret og entrere med Amazons sky (AWS), der ligesom Netflix havde planer om at være globale.

»Det var et sats. Men det betalte sig.«

Genopbygget fra bunden

Overgangen til skyen endte med at tage virksomheden syv år. Først i februar i år slukkede Netflix for den allersidste del af det lokale datacenter.

De syv år skyldes ikke blot, at Netflix' adskillige petabytes data skulle flyttes. Men nærmere at hele tjenestens software og arkitektur blev genopbygget på ny fra bunden.
>»Vi endte med store Oracle-databaser og store webapplikationer, der blev udviklet på af flere forskellige teams og ofte gik i stykker.«

»Da vi opbyggede de her datacentre, var der ikke meget automatisering, virtualisering og standardisering. Det var hårdt arbejde at sætte ting op og få det til at tale sammen.« indleder Coburn Watson.

Systemet var langsomt, og det krævede hardware at udvide kapaciteten. I uventede peakperioder måtte it-folk ud og sætte nye racks op i løbet af natten.

»Fordi det tog lang tid at udvide, så begyndte vi at bygge systemer, der skalerede horisontalt frem for vertikalt. Så vi endte med store Oracle-databaser og store webapplikationer, der blev udviklet på af flere forskellige teams og ofte gik i stykker,« siger Coburn Watson.

500 microservices

I den nye arkitektur er den store software monolit erstattet af i alt 500 microservices. Det vil sige 500 løst koblede elementer, der kommunikerer med hinanden efter behov og kan opdateres og ændres uafhængigt af hinanden.

Et udsnit af Netflix' microservice-arkitektur er illustreret i følgende GIF:

microservice

Hver cirkel repræsenterer en microservice, der varetager en specifik funktion. Prikkerne repræsenterer en vægtet mængde request gennem systemet. Den venstre tredjedel af systemet er, hvad Netflix kalder edge - de microservices, som er tættest på slutbrugerens klient.

I edge-delen findes fx en service, der giver en DRM-licens, når brugeren vil afspille indhold, og en service, der automatisk delegerer trafik mellem Netflix' tre zoner i AWS-skyen i tilfælde af nedbrud.

Hver enkelt microservice kan udvikles separat uden at forstyrre det øvrige system. Til gengæld kan en fejl i en microservice skabe en kædereaktion, hvis andre services er afhængig af den.

»Det er en af de opfattelser, folk ofte har, når de bygger en microservices arkitektur. At du jonglere med services, og hvis du taber en så stopper showet,« fortæller Coburn Watson.

Netflix' best practice til design af microservice arkitektur

Lav separat databank for hver service: Lad vær med at bruge den samme backend databank på tværs af flere microservices. I stedet så vælg den database, der bedst passer til tjenesten. Hvis services deler database, skal alle services opdateres, når den centrale database ændres.

Bland ikke ny og gammel kode: Hvis ny kode skal tilføjes en microservice, bør den skrives som en ny version af servicen. Først når den nye kode er testet og fejlfri kan den integreres i den originale service. Ofte vil man dog finde ud af, at de to funktioner er for store at samle.

Deploy microservices i containere: Hvis dine microservices er i containere er det altid nemt at rulle ud.

Servere skal være stateless: Servere skal være som kvæg - ikke som kæledyr. Undgå unikke servere, der udfører specialiserede funktioner. Det eneste hensyn bør være, at der er nok servere til den mængde arbejde, du vil have udført.

For flere detaljer se denne blog.

Nedbrud er uundgåelige

Ind imellem fejler microservices, erkender performance-chefen. Derfor har Netflix lavet et open source framework kaldet Hystrix, som sørger for at de øvrige services om muligt fortsætter som normalt.

»Lad os sige denne microservice har til opgave at give dig en liste over film personligt til dig,« forklarer Coburn Watson og fortsætter:

»Hvis den fejler har vi en failover, som giver dig en upersonlig liste over film - frem for at det hele stopper.«

Evnen til at overkomme fejl testes konstant med Netflix selvudviklede open source-værktøj Chaos Monkey, der løbende stopper microservices, database-noder mv. for at se, hvor godt systemet håndterer det.

Strategien er den del af det, Netflix kalder en failure driven architecture.

»Nedbrud er uundgåelige. Hver gang du pusher ny kode, så er der risiko for, at noget går i stykker. Hvis du ikke vil have et nedbrud, skal du aldrig ændre din kode,« siger Coburn Watson og tilføjer:

»Vi vil gerne sørge for, at vi ikke fejler på samme måde to gange.«

Kan sove gennem natten

Remote video URL

Visualisering af, hvordan trafik omdirigeres via proxy fra én Netflix-zone til de andre to.


Valget af database landede på Cassandra. Det passede Netflix godt, at databasen var Open Source. På den måde kunne streaminggiganten udvikle projektet med de funktioner, de havde brug for.

Fordi microservices-arkitekturen er stateless - og altså ikke gemmer på data om interaktion med brugeren - kræver det en stor mængde opslag til databasen. Cassandra alene kunne dog ikke levere den hastighed, som Netflix ønskede. Derfor udviklede virksomheden en cache-løsning kaldet EVCache.

Både database og cache er duplikeret over Netflix' tre såkaldte availability zones - US-west, US-East og EU. Skulle det ske, at en zone får problemer, omdirigeres trafikken gradvist fra den fejlramte zone til de andre zoner, som tilsvarende gradvist skalerer kapaciteten op. På 40 minutter kan en zone blive fuldstændig rømmet for trafik.

»Vi arbejder på at få det tal ned på 5 minutter,« fortæller Coburn Watson, der i januar fejrede den globale infrastruktur sammen med resten af Netflix-holdet.

»Vi behøver ikke at arbejde natten igennem for at fikse problemer. Arkitekturen giver os fleksibilitet til at løse problemerne, når vi har tid.«

Version2 blev inviteret til AWS Re:Invent af AWS.

Ingen kommentarer endnu.  Start debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger