Et selle artikli sisu oleks lihtsam mõista, alustame Stack Overflow' keskmise päevase statistika muutusest. Järgnevad andmed pärinevad statistikast seisuga 12. november 2013:
- Koormuse tasakaalustaja võttis vastu 148 084 833 HTTP päringut
- Nendest 36 095 312 olid leheküljelaadimised
- 833 992 982 627 baiti (776 GB) HTTP liiklust kasutatakse saatmiseks
- Kokku saadi 286 574 644 032 baiti (267 GB) andmeid
- Kokku saadeti 1 125 992 557 312 baiti (1 048 GB) andmeid
- 334,572,103 SQL-päringut (sh ainult HTTP-päringutest)
- 412 865 051 Redis taotlust
- 3 603 418 Tag Engine'i taotlust
- SQL-päringutega kulus 558 224 585 ms (155 tundi)
- Redis'i päringute täitmisel kulus 99 346 916 ms (27 tundi)
- Kulutas 132 384 059 ms (36 tundi) märgistusmootori päringule
- ASP.Net protsessi töötlemine võttis 2 728 177 045 ms (757 tundi)
Järgnevad andmed näitavad statistika muutusi seisuga 9. veebruar 2016, seega saate võrrelda:
- Koormuse tasakaalustaja poolt vastu võetud HTTP-päringud: 209,420,973 (+61,336,090)
- 66 294 789 (+30 199 477), millest leht laaditakse
- HTTP andmed saadetud: 1,240,266,346,053 (+406,273,363,426) baiti (1,24 TB)
- Kogukogutud andmete hulk: 569 449 470 023 (+282 874 825 991) baiti (569 GB)
- Saadetud andmete koguarv: 3 084 303 599 266 (+1 958 311 041 954) baiti (3,08 TB)
- SQL-päringud (ainult HTTP-päringutest): 504,816,843 (+170,244,740)
- Redis vahemälu tabamused: 5 831 683 114 (+5 418 818 063)
- Elastsed otsingud: 17 158 874 (2013. aastal ei jälgitud)
- Siltmootori taotlused: 3 661 134 (+57 716)
- SQL-päringute käivitamiseks kuluv kumulatiivne aeg: 607,073,066 (+48,848,481) ms (168 tundi)
- Redis vahemälu tabamisaeg: 10,396,073 (-88,950,843) ms (2,8 tundi)
- Sildimootori päringute aeg: 147 018 571 (+14 634 512) ms (40,8 tundi)
- Töötlemise ASP.Net kulutatud aeg: 1 609 944 301 (-1 118 232 744) ms (447 tundi)
- 22,71 (-5,29) ms 49 180 275 numbri lehekülge keskmine renderdamisaeg (millest 19,12 ms kulub ASP.Net)
- 11,80 (-53,2) ms 6 370 076 esimest lehte keskmine renderdamisaeg (millest 8,81 ms kulub ASP.Net)
Võite mõelda, miks ASP.Net töötleb päevas 61 miljonit rohkem päringut, kuid vähendab töötlemisaega 757 tunni võrra (võrreldes 2013. aastaga). See on peamiselt tingitud serverite uuendustest 2015. aasta alguses ning paljudest rakendusesisesest jõudluse optimeerimise tööst. Ära unusta: jõudlus on endiselt müügiargument. Kui oled rohkem uudishimulik konkreetsete riistvaraliste detailide vastu, ära muretse, ma annan järgmise artikli lisas serverite riistvaraandmed lisana (uuendan seda linki, kui aeg kätte jõuab).
Mis on viimase kahe aasta jooksul muutunud? Mitte palju, lihtsalt vahetan mõned serverid ja võrguseadmed. Siin on ülevaade serveritest, millega teie veebisaiti täna juhitakse (pane tähele, kuidas need on alates 2013. aastast muutunud)
- 4 Microsoft SQL Server serverit (2 neist kasutavad uut riistvara)
- 11 IIS veebiserverit (uus riistvara)
- 2 Redis serverit (uus riistvara)
- 3 Tag Engine serverit (2 neist kasutavad uut riistvara)
- 3 Elasticsearch serverit (nagu eelpool)
- 4 HAProxy koormuse tasakaalustamise serverit (2 lisatud CloudFlare'i toetamiseks)
- 2 võrguseadet (Nexus 5596 tuum + 2232TM Fabric Extender, kõik seadmed uuendatud 10Gbps ribalaiusele)
- 2 x Fortinet 800C tulemüür (asendab Cisco 5525-X ASA-sid)
- 2 Cisco ASR-1001 ruuterit (asendab Cisco 3945 ruutereid)
- 2 Cisco ASR-1001-x ruuterit (UUS!) ）
Mida on vaja, et Stack Overflow toimiks? Alates 2013. aastast pole palju muutunud, kuid tänu eelmainitud optimeerimistele ja uuele riistvarale vajame nüüd vaid ühte veebiserverit. Oleme seda olukorda juba kogemata katsetanud, edukalt mitmel korral. Palun pange tähele: ma just ütlesin, et see töötab, ma ei öelnud, et see on hea mõte. Aga iga kord, kui see juhtub, on see üsna huvitav.
Nüüd, kui meil on mõned baasnumbrid serveri skaleerimise ideede kohta, vaatame, kuidas me need ägedad veebilehed tegime. Vähe on süsteeme, mis eksisteerivad täiesti iseseisvalt (ja meie oma pole erand) ning ilma tervikliku vaateta, mis neid osi integreerib, väheneb arhitektuuri planeerimise tähendus märkimisväärselt. Meie eesmärk on mõista üldist olukorda. Tulevikus tuleb palju artikleid, mis käsitlevad iga konkreetset valdkonda põhjalikult. See artikkel on lihtsalt võtmeseadme loogilise struktuuri kokkuvõte ning järgmine artikkel sisaldab konkreetseid detaile nende riistvara kohta.
Kui tahad näha, milline see riistvara täna välja näeb, siis siin on mõned fotod, mille tegin kapist A (kapp B on täpselt sama), kui uuendasin serverit 2015. aasta veebruaris:
Nüüd sukeldume arhitektuuri paigutusse. Järgnevalt on kokkuvõte peamiste olemasolevate süsteemide loogilisest arhitektuurist:
Põhiprintsiibid
Siin on mõned levinud põhimõtted, mida ei pea eraldi sisse viima:
- Kõigel on varukoopiad.
- Kõigil serveritel ja võrguseadmetel on vähemalt kaks 10Gbps ribalaiusega ühendust.
- Kõigil serveritel on kaks toiteallikat, mis annavad energiat kahe UPS-seadme komplekti, kahe generaatori taga ja kahe võrgu pinge suuna kaudu.
- Kõigil serveritel on varukoopia, mis asub Rack A ja Rack B-s.
- Kõigil serveritel ja teenustel on kahekordsed varukoopiad eraldi andmekeskuses (Colorados), kuigi mina kajastan peamiselt New Yorki.
- Kõigel on varukoopiad.
Internet
Kõigepealt pead leidma meie veebilehe, mis on DNS-i asi. Veebilehtede leidmine on kiire, seega anname selle nüüd CloudFlare'ile, sest neil on DNS-serverid igas maailma nurgas. Me uuendame DNS-i kirjeid API-de kaudu ning nemad vastutavad DNS-i "haldamise" eest. Kuid meie kurjategijate mõtetes on meil endiselt oma DNS-serverid sügavalt juurdunud usaldusprobleemide tõttu. Kui apokalüpsis on apokalüptiline – võib-olla GPL-i, Punyoni või vahemällu salvestamise probleemide tõttu – ja inimesed tahavad ikka programmeerida, et tähelepanu kõrvale juhtida, lülitume omaenda DNS-serveritele.
Kui teie brauser leiab meie peidukoha, siseneb HTTP-liiklus meie neljast internetiteenuse pakkujast (Level 3, Zayo, Cogent ja Lightower New Yorgis) ühte meie neljast arenenud ruuterist. Kasutame Border Gateway Protocoli (BGP, väga tavaline protokoll), et võrguteenuse pakkujatelt peer-to-peer liiklust juhtida, et seda kontrollida ja pakkuda kõige tõhusamat viisi teenustele ligipääsuks. ASR-1001 ja ASR-1001-X ruuterid jagunevad kaheks rühmaks, millest kumbki peaks kasutama aktiivset/aktiivset režiimi, et hallata liiklust mõlemalt võrgupakkujalt – siin on olemas varukoopiad. Kuigi kõigil on sama füüsiline ribalaius 10Gbps, on väljastpoolt tulev liiklus siiski sõltumatu välise VLAN-i liiklusest ja on eraldi ühendatud koormuse tasakaalustamisega. Pärast seda, kui liiklus läbib ruuteri, jõuad koormuse tasakaalustajani.
Arvan, et on aeg mainida, et meil on MPLS 10Gbps ribalaiusega kahe andmekeskuse vahel, kuigi see pole otseselt seotud veebiteenustega. Kasutame seda tehnoloogiat väljaspool asukohta replikatsiooniks ja kiireks andmete taastamiseks teatud hädaolukordade lahendamiseks. "Aga Nick, selles pole mingit kordust!" Tehnilisest vaatenurgast on sul õigus (positiivses mõttes), tegelikult on sellel tasemel üks ebaõnnestumise punkt. Aga oota! Võrguteenuse pakkuja kaudu on meil ka kaks täiendavat OSPF varukanalit (MPLS on esimene valik ning need on kulude tõttu teine ja kolmas valik). Kõik eelmainitud seadmed ühendatakse Colorado andmekeskusega vastavalt koormuse tasakaalustamisele võrguliiklusele juhul, kui tekib ülekanne. Muidugi oleksime võinud need kaks seadmekomplekti omavahel ühendada, nii et oleks neli radade komplekti, aga unusta see, liigume edasi.
Koormuse tasakaalustamine (HAProxy)
Koormuse tasakaalustamine on rakendatud HAProxy 1.5.15-ga, mis töötab CentOS 7-l (meie lemmik Linuxi versioon). Ja lisa TLS (SSL) turvaline edastusprotokoll HAProxy'sse. Jälgime ka HAProxy 1.7, mis toetab HTTP/2 protokolli kohe.
Erinevalt teistest serveritest, millel on kaks 10Gbps LACP võrguühendust, on igal koormuse tasakaalustajal kaks 10Gbps ühendust: üks välisvõrgule ja teine DMZ jaoks. Nendel serveritel on 64GB või rohkem mälu, et SSL protokollikihiga tõhusamalt toime tulla. Kui saame mälus rohkem TLS-sessioone vahemällu salvestada ja taaskasutada, tarbime sama kliendiga ühendudes vähem arvutusressursse. See tähendab, et saame sessioone taastada kiiremini ja odavamalt. Mälu on nii odav, et see on lihtne valik.
Koormuse tasakaalustamine ise on lihtne seadistada. Kuulame erinevaid veebisaite mitmel erineval IP-aadressil (peamiselt sertifikaatide ja DNS-i halduse eesmärgil) ning suuname liikluse erinevatesse taustsüsteemidesse (peamiselt hosti päiste põhjal). Ainus, mida me siin teeme, on kiiruse piiramine ja päise info (veebikihilt) kraapimine, et logida HAProxy süsteemilogi sõnumitesse, nii saame salvestada iga päringu jõudlusmõõdikuid. Räägime sellest hiljem üksikasjalikult.
Veebikiht (IIS 8.5, ASP.Net MVC 5.2.3 ja .Net 4.6.1)
Koormuse tasakaalustamine jaotab liikluse 9 peamise veebiserveri (01-09) ja kahe arendusveebiserveri (10-11, meie testkeskkond) vahel. Peamine server töötab Stack Overflow's, Careers ja kõigis Stack Exchange'i saitides, samas kui meta.stackoverflow.com ja meta.stackexchange.com töötavad kahel teisel serveril. Peamine K&A rakendus ise on mitme rentnikuga, mis tähendab, et üks rakendus haldab kõiki küsimuste ja vastuste saidilt pärinevaid päringuid. Teisisõnu, me saame käivitada kogu Q&A rakenduse ühes rakenduste basseinis ühes serveris. Teised rakendused nagu Careers, API v2, Mobile API jne on iseseisvad. Siin on, mida näete IIS-is master- ja arendusserverite jaoks:
Siin on Stack Overflow veebitaseme jaotus, nagu seda näeb Opserveris (meie sisemine jälgimisjuhtpaneel):
Ja siin on nende veebiserverite ressursitarbi:
Järgmises artiklis selgitan täpsemalt, miks me nii palju ressursse ülepakume, keskendudes pidevale ehitusele, paindlikkusele ja varundusele.
Teeninduskiht (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 ja HTTP. SYS)
Veebikihi kõrval on teeninduskiht. Need töötavad ka IIS 2012 peal Windows 8.5R2-s. See kiht haldab mõningaid sisemisi teenuseid, mis toetavad veebikihti ja teisi tootmiskeskkonna sisemisi süsteeme. Kaks peamist teenust on: "Stack Server", mis käitab sildimootorit ja põhineb http.sys-l (mitte IIS-il); Providence API (põhineb IIS-il). Huvitav fakt: pidin need kaks protsessi korreleerima, et ühendada erinevatesse sokleid, sest Stack Server pääses L2 ja L3 vahemäludele väga sageli ligi, kui probleemide nimekirja kaheminutiliste vahedega värskendas.
Masinad, mis neid teenuseid jooksutavad, on kriitilised siltimootori ja taustapõhiste API-de jaoks, seega peavad need olema redundantsed, kuid mitte 9x redundantsed. Näiteks laadime kõik artiklid ja nende sildid andmebaasist iga n minuti tagant (praegu 2 minutit), mis ei ole väike. Me ei taha seda laadimisoperatsiooni veebikihil 9 korda korrata, 3 korda on meie jaoks piisavalt ohutu. Kasutame ka erinevaid riistvarakonfiguratsioone nende serverite jaoks, et paremini optimeerida sildimootori ja elastse indeksi tööde arvutus- ja andmelaadimise omadusi (samuti selles kihis). "Siltimootor" ise on suhteliselt keeruline teema, mida käsitletakse eraldi artiklis. Põhipõhimõte on see, et kui sa pääsed aadressile /questions/tagged/java, külastad sildistamise mootorit, et leida vastavad küsimused. Mootor haldab kõiki siltide sobitamist peale /search, nii et kõikjal, sealhulgas uus navigatsioon, saavad andmed selle teenuse kaudu.
Vahemällu salvestamine ja kirjastamine/tellimine (Redis)
Mõnes kohas kasutasime Redis'i ja sellel on kivikõva stabiilsus. Kuigi kuus toimub kuni 160 miljardit operatsiooni, ei ületa CPU instantsi kohta 2%, mis on tavaliselt väiksem:
Me kasutame Redist L1/L2 taseme vahemälusüsteemide jaoks. "L1" tase on HTTP-vahemälu, mis töötab veebiserveris või mõnes sarnases rakenduses. "L2" tase on andmete hankimine Redis'i kaudu pärast eelmise taseme vahemälu ebaõnnestumist. Meie andmed salvestatakse Protobufi formaadis, mis on teostatud protobuf-dot-net kaudu, mille on kirjutanud Marc Gravel. Redis kliendi jaoks kasutasime StackExchange.Redis teeki, mis on avatud lähtekoodiga teek, mis on arendatud kohapeal. Kui veebiserver ei taba nii L1 kui L2 vahemälu, siis ta toob andmed oma andmeallikatest (andmebaasi päringud, API kutsed jne) ja salvestab tulemused kohalikku vahemälu ja Redis'i. Järgmine server võib L1 vahemälust puududa, kui sama andmeid kätte saada, kuid see toob andmed L2/Redis'is, kõrvaldades vajaduse andmebaasipäringute või API kutsete järele.
Meil on ka palju küsimuste ja vastuste lehti, millest igaühel on oma L1/L2 vahemälu: võti L1 vahemälus eesliitena ja andmebaasi ID L2/Redis vahemälus. Me käsitleme seda teemat tulevastes artiklites.
Lisaks kahele peamisele Redis serverile (üks master ja üks slave), mis käitavad kõiki saidi instantsere, seadistasime ka masinõppe instantsi (peamiselt mälu tõttu) kahe teise pühendatud slave-serveriga. Seda serverite gruppi kasutatakse teenuste pakkumiseks, näiteks küsimuste soovitamiseks avalehel ja paremate töökohtade sobitamiseks. See platvorm kannab nime Providence ja Kevin Montrose kirjutas sellest.
Peamine Redis server omab 256GB RAM-i (umbes 90GB kasutatud) ja Providence'i serveril 384GB mälu (umbes 125GB kasutatud).
Redis ei ole mõeldud ainult vahemällu salvestamiseks, vaid sellel on ka avaldamis- ja tellimismehhanism, kus üks server saab sõnumi avaldada ja teised tellijad saavad sõnumi vastu võtta (sh Redis serveri allavoolu klientidelt). Kasutame seda mehhanismi L1 vahemälu puhastamiseks teistes teenustes, et säilitada veebiserveri vahemälu järjepidevus. Aga sellel on veel üks oluline kasutus: veebipesad.
Websockets (NetGain)
Kasutame websockete, et edastada kasutajatele reaalajas uuendusi, näiteks teavitused ülemisel ribal, hääled, uued navigeerimisvõimalused, uued vastused, kommentaarid ja palju muud.
Socket-server ise töötab veebikihil, kasutades natiivseid sokleid. See on väga väike rakendus, mis põhineb meie avatud lähtekoodiga teegi rakendusel: StackExchange.NetGain. Tipptundidel oli meil umbes 500 000 samaaegset websocket-ühendust, mis on palju brausereid. Lõbus fakt: mõned neist brauseritest on olnud avatud üle 18 kuu ja pead leidma kellegi, et näha, kas need arendajad on veel elus. Järgmine graafik näitab sel nädalal websocketi samaaegsuse mustrit:
Miks kasutada websockete? Meie skaalal on see palju tõhusam kui küsitlus. Nii saame lihtsalt rohkem andmeid edastada vähemate ressurssidega ja olla kasutajatele reaalajas rohkem kättesaadavad. See lähenemine pole siiski probleemideta: ajutised portid, koormuse tasakaalustajate failikäepidemed on väga huvitavad probleemid, millest räägime hiljem.
Otsing (Elasticsearch)
Spoiler: Siin pole eriti midagi põnevat. Veebikiht kasutab Elasticsearch 1.4 ja rakendab ülikerget, kõrge jõudlusega StackExchange.Elastic klienti. Erinevalt enamikust asjadest ei plaani me seda osa avatud lähtekoodiga kasutada, sest see avab väga väikese osa API-dest, mida peame kasutama. Olen kindel, et selle avalikustamine kaalub üles kaotuse ja ajab arendajad segadusse. Nendes kohtades kasutame elastik:/otsingut, et arvutada seotud küsimusi ja anda soovitusi küsimuste esitamisel.
Iga elastne klaster (üks iga andmekeskuse kohta) sisaldab 3 sõlme, millest igaühel on oma indeks. Karjääride lehel on ka täiendavaid indekseid. Veidi vähem standardne osa meie konfiguratsioonist elastsetes ringides on see, et meie kolme serveri klaster on tavapärasest võimsam: iga server kasutab SSD salvestusruumi, 192GB mälu, topeltvõrgu 10Gbps ribalaiusega.
Sama rakendusdomeen nagu Stack Server (jah, meid viskas ringi .Net Core siin) majutab ka siltide mootorit, mis kasutab samuti Elasticsearchi pidevaks indekseerimiseks. Siin kasutame väikest nippi, näiteks ROWVERSIONi kasutamist SQL Serveris (andmeallikas), et võrrelda Elasticu "viimase koha" dokumendiga. Kuna see on ilmselt järjestikune, on meil lihtne sisu indekseerida ja indekseerida, kui see on pärast viimast külastust muudetud.
Peamine põhjus, miks kasutame Elasticsearchi selliste tehnoloogiate asemel nagu SQL täistekst otsing, on selle skaleeritavus ja kulutõhusus. SQL on protsessoritel suhteliselt kallis, samas kui Elastic on palju odavam ja viimasel ajal on seal palju uusi funktsioone. Miks mitte kasutada Solr'i? Peame otsima üle kogu võrgu (mitme indeksiga korraga) ja Solr ei toeta seda stsenaariumi meie otsuste tegemise hetkel. Põhjus, miks me pole veel 2.x kasutanud, on see, et tüübid on 2.x versioonis palju muutunud, mis tähendab, et peame kõik uuesti indekseerima, kui tahame uuendada. Mul lihtsalt pole piisavalt aega, et planeerida nõuete muutusi ja migratsioone.
Andmebaas (SQL Server)
Me kasutame SQL Serverit kui ühtset tõeallikat. Kõik andmed Elasticus ja Redis pärinevad SQL Serverist. Meil on kaks SQL Serveri klastrit ja oleme konfigureeritud AlwaysOn saadavuse gruppidega. Igal klastril on New Yorgis põhiserver (mis võtab peaaegu kogu koormuse) ja replikaserver, lisaks replikaserverile Colorados (meie katastroofitaaste andmekeskus). Kõik kopeerimisoperatsioonid on asünkroonsed.
Esimene klaster koosneb Dell R720xd serveritest, millest igaühel on 384GB mälu, PCIe SSD 4TB ruumiga ja kaks 12-tuumalist protsessorit. See sisaldab Stack Overflow'd, Sites (see on halb nimi, selgitan seda hiljem), PRIZM-i ja Mobile'i andmebaasi.
Teine klaster koosneb Dell R730xd serveritest, millest igaühel on 768GB mälu, PCIe SSD 6TB ruumiga ja kaks 8-tuumalist protsessorit. See klaster sisaldab kõiki teisi andmebaase, sealhulgas karjääri, avatud ID, vestlus, erandlogid ja muud küsimuste-vastuste lehed (nt superkasutaja, serveri rike jne).
Andmebaasi tasandil tahame hoida CPU kasutuse väga madalal tasemel, kuigi praktikas on CPU kasutus veidi kõrgem, kui tekivad planeeritud vahemäluprobleemid (mida me praegu lahendame). Praegu on NY-SQL02 ja 04 peamised serverid ning 01 ja 03 replikaserverid ning me taaskäivitasime need täna SSD uuenduse tõttu. Siin on, kuidas nad viimase 24 tunni jooksul esinesid:
Meie SQL-i kasutus on väga lihtne. Lihtne tähendab kiiret. Kuigi mõned päringulaused võivad olla moonutatud, toimub meie suhtlus SQL-iga üsna natiivsel viisil. Meil on mõned pärandlikud Linq2Sql-id, kuid kõik meie uued arendused kasutavad Dapperit, meie avatud lähtekoodiga mikro-ORM raamistikku, mis kasutab POCO-d. Las ma selgitan seda teisiti: Stack Overflow'l on andmebaasis ainult üks salvestatud protseduur ja ma lõpetan selle viimase salvestatud protseduuri ning asendan selle koodiga.
Raamatukogu
Noh, muudame meelt, siin on asjad, mis võivad sind otsesemalt aidata. Olen mõnda neist varem maininud, aga annan teile nimekirja paljudest avatud lähtekoodiga .Net teekidest, mida me hooldame ja mida kõik kasutavad. Me avame neid lähtekoodiga, sest neil puudub põhiäriline väärtus, kuid nad saavad aidata arendajaid üle kogu maailma. Loodan, et saad neid nüüd kasutada:
- Dapper (.Net Core) – Kõrge jõudlusega mikro-ORM raamistik ADO.Net
- StackExchange.Redis – Kõrge jõudlusega Redis klient
- MiniProfiler – kerge profiilija, mida kasutame igal lehel (toetab ka Ruby, Go ja Node)
- Erakordne – Vigade logimiseks SQL-is, JSON-is, MySQL-is jne
- Jil – Kõrge jõudlusega JSON-i serialiseerimine ja deserialiseerija
- Sigil – .Net CIL generatsiooni abiline (kasutatakse, kui C# pole piisavalt kiire)
- NetGain – Kõrge jõudlusega websocket server
- Opserver – Jälgimisjuhtpaneel, mis küsitleb enamiku süsteeme otse ja suudab tuua infot Orionist, Bosunist või WMI-st
- Bosun – taustal olev jälgimissüsteem, kirjutatud Go keeles
|
Postitatud 11.04.2018 17:33:18
|
|
|
|
