For at gøre det lettere at forstå, hvad denne artikel handler om, lad os starte med ændringen i Stack Overflows gennemsnitlige daglige statistik. Følgende tal er fra statistikkerne pr. 12. november 2013:
- Load balanceren accepterede 148.084.833 HTTP-forespørgsler
- Af disse var 36.095.312 sideindlæsninger
- 833.992.982.627 bytes (776 GB) HTTP-trafik bruges til at sende
- I alt blev der modtaget 286.574.644.032 bytes (267 GB) data
- I alt blev der sendt 1.125.992.557.312 bytes (1.048 GB) data
- 334.572.103 SQL-forespørgsler (inklusive kun fra HTTP-forespørgsler)
- 412.865.051 Redis-anmodninger
- 3.603.418 Tag Engine-anmodninger
- Det tog 558.224.585 ms (155 timer) på SQL-forespørgsler
- Det tog 99.346.916 ms (27 timer) på Redis-anmodninger
- Brugte 132.384.059 ms (36 timer) på tagmotor-anmodningen
- Det tog 2.728.177.045 ms (757 timer) på ASP.Net procesbehandling
Følgende data viser ændringer i statistikkerne pr. 9. februar 2016, så du kan sammenligne:
- HTTP-anmodninger modtaget af load balancer: 209.420.973 (+61.336.090)
- 66.294.789 (+30.199.477) hvoraf sider indlæses
- HTTP-data sendt: 1.240.266.346.053 (+406.273.363.426) bytes (1,24 TB)
- Samlet mængde modtaget data: 569.449.470.023 (+282.874.825.991) bytes (569 GB)
- Samlet mængde sendt data: 3.084.303.599.266 (+1.958.311.041.954) bytes (3,08 TB)
- SQL-forespørgsler (kun fra HTTP-forespørgsler): 504.816.843 (+170.244.740)
- Redis Cache-hits: 5.831.683.114 (+5.418.818.063)
- Elastiske søgninger: 17.158.874 (ikke registreret i 2013)
- Tag Engine-anmodninger: 3.661.134 (+57.716)
- Samlet tid brugt til at køre SQL-forespørgsler: 607.073.066 (+48.848.481) ms (168 timer)
- Redis cache-hittid forbrugt: 10.396.073 (-88.950.843) ms (2,8 timer)
- Tid brugt af tag engine-anmodninger: 147.018.571 (+14.634.512) ms (40,8 timer)
- Tid brugt i ASP.Net behandling: 1.609.944.301 (-1.118.232.744) ms (447 timer)
- 22,71 (-5,29) ms 49.180.275 udgavesider gennemsnitlig rendertid (hvoraf 19,12 ms bruges i ASP.Net)
- 11,80 (-53,2) ms 6.370.076 første sider gennemsnitlig rendertid (hvoraf 8,81 ms bruges i ASP.Net)
Du undrer dig måske over, hvorfor ASP.Net behandler 61 millioner flere forespørgsler om dagen, men reducerer behandlingstiden med 757 timer (sammenlignet med 2013). Dette skyldes hovedsageligt de opgraderinger, vi lavede på vores servere i begyndelsen af 2015, samt en masse arbejde med optimering af ydeevnen i appen. Glem ikke: ydeevne er stadig et salgsargument. Hvis du er mere nysgerrig på de specifikke hardwaredetaljer, så bare rolig, jeg vil give de specifikke hardwaredetaljer for de servere, der bruges til at køre disse sider, i form af et appendiks i næste artikel (jeg opdaterer dette link, når tiden er inde).
Så hvad er der ændret de sidste to år? Ikke meget, bare udskiftning af nogle servere og netværksudstyr. Her er en oversigt over de servere, der bruges til at køre din hjemmeside i dag (bemerk, hvordan de har ændret sig siden 2013)
- 4 Microsoft SQL Server-servere (hvoraf 2 bruger nyt hardware)
- 11 IIS Webservere (Nyt Hardware)
- 2 Redis-servere (nyt hardware)
- 3 Tag Engine-servere (hvoraf 2 bruger nyt hardware)
- 3 Elasticsearch-servere (samme som ovenfor)
- 4 HAProxy load balancing-servere (2 tilføjet for at understøtte CloudFlare)
- 2 netværksenheder (Nexus 5596 kerne + 2232TM Fabric Extender, alle enheder opgraderet til 10Gbps båndbredde)
- 2 x Fortinet 800C firewall (erstatter Cisco 5525-X ASA'er)
- 2 Cisco ASR-1001 routere (erstatter Cisco 3945 routere)
- 2 Cisco ASR-1001-x routere (NYE!) ）
Hvad har vi brug for for at få Stack Overflow til at fungere? Der er ikke sket meget siden 2013, men takket være optimeringerne og det nye hardware nævnt ovenfor, har vi nu kun brug for én webserver. Vi har allerede testet denne situation utilsigtet, med succes flere gange. Bemærk venligst: Jeg sagde lige, at det virker, jeg sagde ikke, at det er en god idé. Men hver gang det sker, er det ret interessant.
Nu hvor vi har nogle grundlæggende tal for idéer til serverskalering, lad os se, hvordan vi lavede disse seje websider. Få systemer eksisterer fuldstændig uafhængigt (og vores er ingen undtagelse), og uden et helhedsorienteret syn, der integrerer disse dele, reduceres betydningen af arkitektonisk planlægning betydeligt. Vores mål er at forstå den overordnede situation. Der vil komme mange artikler, der går i dybden med hvert specifikt felt i fremtiden. Denne artikel er blot et resumé af den logiske struktur af nøglehardwaren, og den næste artikel vil indeholde specifikke detaljer om denne hardware.
Hvis du vil se, hvordan dette hardware ser ud i dag, er her et par billeder, jeg tog af skab A (skab B er præcis det samme som det), da jeg opgraderede serveren i februar 2015:
Lad os nu dykke ned i arkitekturens layout. Følgende er et resumé af den logiske arkitektur for de vigtigste eksisterende systemer:
Grundlæggende principper
Her er nogle almindelige principper, som ikke behøver at blive introduceret én gang:
- Alt har redundante backups.
- Alle servere og netværksenheder har mindst to 10 Gbps båndbreddeforbindelser.
- Alle servere har to strømkilder, der leverer strøm gennem to UPS-enheder, to generatorer bagved og to netspændingsfremsendelser.
- Alle servere har en redundant backup placeret i Rack A og Rack B.
- Alle servere og tjenester har dobbelte redundante backups i et separat datacenter (i Colorado), selvom jeg primært dækker New York.
- Alt har redundante backups.
internet
Først skal du finde vores hjemmeside, som er en DNS-ting. At finde hjemmesider går hurtigt, så nu giver vi det til Cloudflare, fordi de har DNS-servere overalt i verden. Vi opdaterer DNS-poster via API'er, og de er ansvarlige for at "administrere" DNS. Men i vores skurkagtige sind har vi stadig vores egne DNS-servere på grund af de dybt rodfæstede tillidsproblemer. Når apokalypsen er apokalyptisk – måske på grund af GPL, Punyon eller caching-problemer – og folk stadig vil programmere for at aflede deres opmærksomhed, skifter vi til vores egne DNS-servere.
Når din browser finder vores skjulested, kommer HTTP-trafik fra vores fire internetudbydere (Level 3, Zayo, Cogent og Lightower i New York) ind i en af vores fire avancerede routere. Vi bruger Border Gateway Protocol (BGP, en meget standard protokol) til peer-to-peer trafik fra netværksudbydere for at kontrollere det og levere den mest effektive måde at få adgang til vores tjenester på. ASR-1001 og ASR-1001-X routerne er opdelt i to grupper, som hver skal bruge aktiv/aktiv tilstand til at håndtere trafik fra begge netværksudbydere – her findes redundante backups. Selvom de alle har samme fysiske båndbredde på 10 Gbps, er trafikken udefra stadig uafhængig af trafikken fra det eksterne VLAN og er tilsluttet load balancing separat. Når trafikken passerer gennem routeren, kommer du til load balanceren.
Jeg tror, det er tid til at nævne, at vi har MPLS med 10 Gbps båndbredde mellem de to datacentre, selvom det ikke rigtig er direkte relateret til webservices. Vi bruger denne teknologi til at udføre ekstern replikation og hurtig gendannelse af data for at håndtere visse nødsituationer. "Men Nick, der er ingen redundans i det her!" Nå, fra et teknisk synspunkt har du ret (i positiv forstand), det er virkelig et enkelt fejlpunkt på dette niveau. Men vent! Gennem netværksudbyderen har vi også to yderligere OSPF failover-ruter (MPLS er det første valg, og disse er det andet og tredje valg af omkostningsmæssige årsager). Hver af de førnævnte sæt enheder vil blive forbundet til Colorados datacenter i overensstemmelse med belastningsbalancen i forbindelse med en failover. Selvfølgelig kunne vi have forbundet disse to sæt enheder med hinanden, så der er fire sæt af veje, men glem det, lad os gå videre.
Lastfordeling (HAProxy)
Load balancing er implementeret med HAProxy 1.5.15, som kører på CentOS 7 (vores yndlingsversion af Linux). Og tilføj TLS (SSL) sikker transmissionsprotokol på HAProxy. Vi holder også øje med HAProxy 1.7, som straks vil understøtte HTTP/2-protokollen.
I modsætning til andre servere med dobbelte 10Gbps LACP-netværksforbindelser har hver load balancer to 10Gbps-forbindelser: én til det eksterne netværk og én til DMZ. Disse servere har 64GB eller mere hukommelse for at håndtere SSL-protokollaget mere effektivt. Når vi kan cache og genbruge flere TLS-sessioner i hukommelsen, bruger vi færre beregningsressourcer, når vi forbinder til den samme klient. Det betyder, at vi kan gendanne sessioner hurtigere og billigere. Hukommelse er så billigt, at det er et nemt valg.
Load balancing er i sig selv nemt at sætte op. Vi lytter til forskellige hjemmesider på flere forskellige IP-adresser (primært af hensyn til certifikat- og DNS-administration) og dirigerer derefter trafikken til forskellige backends (primært baseret på hostheaders). Det eneste, vi gør her, er at begrænse hastigheden og skrabe noget headerinformation (fra weblaget) for at logge ind på HAProxys systemlogbeskeder, på den måde kan vi registrere performance-metrikker for hver anmodning. Vi vil nævne dette i detaljer senere.
Weblag (IIS 8.5, ASP.Net MVC 5.2.3 og .Net 4.6.1)
Load balancing fordeler trafikken mellem 9 af det, vi kalder den primære webserver (01-09) og 2 udviklingswebservere (10-11, vores testmiljø). Hovedserveren kører Stack Overflow, Careers og alle Stack Exchange-siderne, mens meta.stackoverflow.com og meta.stackexchange.com kører på to andre servere. Selve Q&A-appen er multi-tenant, hvilket betyder, at en enkelt app håndterer alle forespørgsler fra Q&A-siden. Med andre ord kan vi køre hele Q&A-appen på én applikationspulje på én server. Andre apps som Careers, API v2, Mobile API osv. er uafhængige. Her er, hvad du ser i IIS for master- og dev-serverne:
Her er fordelingen af Stack Overflows web-tier, som set i Opserver (vores interne overvågningsdashboard):
Og her er ressourceforbruget for disse webservere:
Jeg vil gå mere i detaljer i en senere artikel om, hvorfor vi overleverer så mange ressourcer, med fokus på rullende build, spillerum og redundans.
Servicelag (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 og HTTP. SYS)
Ved siden af weblaget ligger servicelaget. De kører også oven på IIS 2012 i Windows 8.5R2. Dette lag kører nogle interne tjenester, der understøtter weblaget og andre interne systemer i produktionsmiljøet. De to hovedtjenester er: "Stack Server", som kører en tag-motor og er baseret på http.sys (ikke IIS); Providence API (baseret på IIS). En interessant kendsgerning: Jeg måtte korrelere de to processer for at forbinde til forskellige sockets, fordi Stack Serveren meget ofte tilgik L2- og L3-caches, når listen over problemer blev opdateret med to minutters mellemrum.
Maskinerne, der kører disse tjenester, er kritiske for tagmotoren og backend-API'erne, så de skal være redundante, men ikke 9 gange redundante. For eksempel indlæser vi alle artikler og deres tags fra databasen hvert n minut (i øjeblikket 2 minutter), hvilket ikke er lavt. Vi ønsker ikke at gentage denne load-operation 9 gange på weblaget, 3 gange er sikkert nok for os. Vi bruger også forskellige hardwarekonfigurationer til disse servere for bedre at optimere til de beregningsmæssige og dataindlæsningskarakteristika for tag-motoren og elastic index-jobs (som også kører i dette lag). "Tag engine" er i sig selv et relativt komplekst emne, som vil blive dækket i en dedikeret artikel. Det grundlæggende princip er, at når du tilgår adressen /questions/tagged/java, besøger du tagging-motoren for at få de spørgsmål, der matcher den. Motoren håndterer al tag-matching undtagen /search, så overalt, inklusive den nye navigation, får data gennem denne tjeneste.
Caching & Publicering/Abonnement (Redis)
Vi brugte Redis nogle steder, og den har en stenfast stabilitet. Selvom der er op til 160 milliarder operationer om måneden, overstiger CPU'en pr. instans ikke 2%, hvilket normalt er lavere:
Vi bruger Redis til Caching-systemer på L1/L2-niveau. "L1"-niveauet er HTTP-cachen, der fungerer i en webserver eller en lignende applikation. "L2"-niveauet er til at hente data gennem Redis efter at det forrige niveau cache fejler. Vores data gemmes i Protobuf-formatet, implementeret via protobuf-dot-net skrevet af Marc Gravel. Til Redis-klienten brugte vi StackExchange.Redis-biblioteket, som er et open source-bibliotek udviklet internt. Hvis en webserver ikke rammer i både L1- og L2-cachen, henter den data fra sine datakilder (databaseforespørgsler, API-kald osv.) og gemmer resultaterne i den lokale cache og Redis. Den næste server kan mangle i L1-cachen, når den henter de samme data, men den henter dataene i L2/Redis, hvilket eliminerer behovet for databaseforespørgsler eller API-kald.
Vi kører også mange Q&A-sites, hver med sin egen L1/L2-cache: nøgle som præfiks i L1-cachen og database-ID i L2/Redis-cachen. Vi vil dykke ned i dette emne i fremtidige artikler.
Ud over de to hovedservere i Redis (en master og en slave), der kører alle site-instanser, oprettede vi også en instans til maskinlæring (primært af hukommelsesårsager) ved brug af to andre dedikerede slaveservere. Denne gruppe af servere bruges til at tilbyde tjenester som at anbefale spørgsmål på forsiden og lave bedre jobmatching. Denne platform hedder Providence, og Kevin Montrose skrev om den.
Hovedserveren til Redis har 256GB RAM (ca. 90GB brugt), og Providence-serveren har 384GB hukommelse (ca. 125GB brugt).
Redis er ikke kun til caching, det har også en publicerings- og abonnementsmekanisme, hvor én server kan udgive en besked, og andre abonnenter kan modtage beskeden (inklusive Redis fra nedstrøms klienter på serveren). Vi bruger denne mekanisme til at rydde L1-cachen på andre tjenester for at opretholde cachekonsistens på webserveren. Men det har en anden vigtig anvendelse: websockets.
Websockets (NetGain)
Vi bruger websockets til at sende realtidsopdateringer til brugerne, såsom notifikationer i øverste bjælke, stemmer, ny navigation, nye svar, kommentarer og mere.
Socket-serveren kører på weblaget og bruger native sockets. Dette er en meget lille applikation baseret på vores open source-biblioteksimplementering: StackExchange.NetGain. I spidsbelastningstider havde vi omkring 500.000 samtidige websocket-forbindelser, hvilket er mange browsere. Sjov fakta: nogle af disse browsere har været åbne i over 18 måneder, og du bliver nødt til at finde nogen for at se, om de udviklere stadig er i live. Følgende diagram viser mønstret for websocket-samtidighed denne uge:
Hvorfor bruge websockets? På vores niveau er det meget mere effektivt end meningsmålinger. På den måde kan vi simpelthen sende mere data med færre ressourcer og være mere realtidsorienterede for brugerne. Denne tilgang er dog ikke uden problemer: midlertidige porte, udtømte filhåndteringer på load balancere er meget interessante problemer, og vi vil tale om dem senere.
Søgning (Elasticsearch)
Spoiler: Der er ikke meget at blive begejstret for her. Weblaget bruger Elasticsearch 1.4 og implementerer en ultra-let, højtydende StackExchange.Elastic-klient. I modsætning til det meste planlægger vi ikke at open source denne del, simpelthen fordi den eksponerer et meget lille udvalg af de API'er, vi skal bruge. Jeg er sikker på, at det at gøre det offentligt opvejer tabet og kun vil forvirre udviklerne. Vi bruger elastic:/search på disse steder til at beregne relaterede spørgsmål og give forslag, når vi stiller spørgsmål.
Hver elastisk klynge (én for hvert datacenter) indeholder 3 noder, hver med sit eget indeks. Karrieresiden har også nogle ekstra indekser. En lidt mindre standard del af vores konfiguration i elastiske cirkler er, at vores klynge på 3 servere er lidt mere kraftfuld end den sædvanlige konfiguration: hver server bruger SSD-lager, 192GB hukommelse, dobbelt netværk med 10 Gbps båndbredde.
Det samme applikationsdomæne som Stack Server (ja, vi blev kastet rundt af .Net Core her) huser også en tag-motor, som også bruger Elasticsearch til kontinuerlig indeksering. Her bruger vi et lille trick, såsom at bruge ROWVERSION i SQL Server (datakilden) til at sammenligne med "sidste plads"-dokumentet i Elastic. Da det tilsyneladende er sekventielt, er det nemt for os at crawle og indeksere indhold, hvis det ændres efter sidste besøg.
Hovedårsagen til, at vi bruger Elasticsearch i stedet for teknologier som SQL fuldtekstsøgning, er dets skalerbarhed og omkostningseffektivitet. SQL er relativt dyrt på CPU'er, mens Elastic er meget billigere og har mange nye funktioner for tiden. Hvorfor ikke bruge Solr? Vi skal søge på tværs af netværket (med flere indekser på samme tid), og Solr understøtter ikke dette scenarie på tidspunktet for vores beslutninger. Grunden til, at vi endnu ikke har brugt 2.x, er, at typerne har ændret sig meget i 2.x, hvilket betyder, at vi skal re-indeksere alt, hvis vi vil opgradere. Jeg har bare ikke tid nok til at planlægge ændringer i kravene og migrationer.
Database (SQL Server)
Vi bruger SQL Server som en enkelt sandhedskilde. Alle data i Elastic og Redis kommer fra SQL Server. Vi har to SQL Server-klynger og er konfigureret med AlwaysOn-tilgængelighedsgrupper. Hver klynge har en primær server i New York (som tager næsten al belastningen) og en replika-server, ud over en replika-server i Colorado (vores katastrofeberedskabsdatacenter). Alle kopioperationer er asynkrone.
Den første klynge er et sæt Dell R720xd-servere, hver med 384 GB hukommelse, en PCIe SSD med 4 TB plads og to 12-core CPU'er. Det inkluderer Stack Overflow, Sites (det er et dårligt navn, det forklarer jeg senere), PRIZM og Mobiles database.
Den anden klynge er et sæt Dell R730xd-servere, hver med 768 GB hukommelse, en PCIe SSD med 6 TB plads og to 8-core CPU'er. Denne klynge indeholder alle andre databaser, herunder Careers, Open ID, Chat, undtagelseslogge og andre Q&A-sider (f.eks. Super User, Server Fault osv.).
På database-niveauet ønsker vi at holde CPU-udnyttelsen på et meget lavt niveau, selvom CPU-forbruget i praksis vil være lidt højere, når der opstår nogle planlagte caching-problemer (som vi fejlfinder). I øjeblikket er NY-SQL02 og 04 de primære servere, og 01 og 03 er replikaserverne, og vi genstartede dem lige i dag på grund af SSD-opgraderingen. Sådan har de præsteret inden for de sidste 24 timer:
Vores brug af SQL er meget enkel. Simpelt betyder hurtigt. Selvom nogle forespørgselssætninger kan være forvrængede, foregår vores interaktion med SQL på en ret naturlig måde. Vi har noget ældre Linq2SQL, men alle vores nye udviklinger bruger Dapper, vores open source mikro-ORM-rammeværk, der bruger POCO. Lad mig forklare det på en anden måde: Stack Overflow har kun én lagret procedure i sin database, og jeg vil dræbe denne sidste lagrede procedure og erstatte den med kode.
Bibliotek
Lad os ændre mening, her er ting, der kan hjælpe dig mere direkte. Jeg har nævnt nogle af dem før, men jeg vil give dig en liste over de mange open source .Net-biblioteker, som vi vedligeholder, og som alle bruger. Vi open sourcer dem, fordi de ikke har kerneværdi i deres forretning, men de kan hjælpe udviklere over hele verden. Jeg håber, du kan bruge dem nu:
- Dapper (.Net Core) – Et højtydende mikro-ORM-framework til ADO.Net
- StackExchange.Redis – En højtydende Redis-klient
- MiniProfiler – en letvægtsprofiler, som vi bruger på hver side (understøtter også Ruby, Go og Node)
- Exceptionelt – Til fejllogning i SQL, JSON, MySQL osv
- Jil – Højtydende JSON-serialisering og deserializer
- Sigil – .Net CIL Generation Helper (bruges når C# ikke er hurtigt nok)
- NetGain – Højtydende websocket-server
- Opserver – Overvågningsdashboard, der direkte spørger de fleste systemer og kan hente information fra Orion, Bosun eller WMI
- Bosun – Overvågningssystem i baggrunden, skrevet i Go
|
Opslået på 11/04/2018 17.33.18
|
|
|
|
