Da bi lažje razumeli, o čem govori ta članek, začnimo s spremembo povprečne dnevne statistike Stack Overflow. Naslednje številke so iz statistike na dan 12. november 2013:
- Uravnoteževalnik obremenitve je sprejel 148.084.833 HTTP zahtevkov
- Od teh je bilo 36.095.312 naloženih strani
- Za pošiljanje se uporablja 833.992.982.627 bajtov (776 GB) HTTP prometa
- Skupno je bilo prejetih 286.574.644.032 bajtov (267 GB) podatkov
- Skupno je bilo poslanih 1.125.992.557.312 bajtov (1.048 GB) podatkov
- 334.572.103 SQL poizvedb (vključno samo iz HTTP zahtevkov)
- 412.865.051 zahtevkov za Redis
- 3.603.418 zahtevkov za Tag Engine
- SQL poizvedbe so potrebovale 558.224.585 ms (155 ur)
- Redis zahteve so zahtevale 99.346.916 ms (27 ur)
- Porabil sem 132.384.059 ms (36 ur) za zahtevo za oznako motorja
- Obdelava ASP.Net procesa je trajala 2.728.177.045 ms (757 ur)
Naslednji podatki prikazujejo spremembe v statistiki na dan 9. februar 2016, tako da lahko primerjate:
- HTTP zahteve, ki jih prejme Load Balancer: 209.420.973 (+61.336.090)
- 66.294.789 (+30.199.477), od tega se stran naloži
- Poslani HTTP podatki: 1.240.266.346.053 (+406.273.363.426) bajtov (1,24 TB)
- Skupna količina prejetih podatkov: 569.449.470.023 (+282.874.825.991) bajtov (569 GB)
- Skupna količina poslanih podatkov: 3.084.303.599.266 (+1.958.311.041.954) bajtov (3,08 TB)
- SQL poizvedbe (samo iz HTTP zahtevkov): 504.816.843 (+170.244.740)
- Redis Cache obiski: 5.831.683.114 (+5.418.818.063)
- Elastic Searches: 17.158.874 (neupoštevano v letu 2013)
- Zahteve za tag engine: 3.661.134 (+57.716)
- Skupni čas, porabljen za izvajanje SQL poizvedb: 607.073.066 (+48.848.481) ms (168 ur)
- Poraba časa dosega predpomnilnika v Redisu: 10.396.073 (-88.950.843) ms (2,8 ure)
- Čas, porabljen za zahteve Tag Engine: 147.018.571 (+14.634.512) ms (40,8 ur)
- Čas, porabljen za ASP.Net obdelavo: 1.609.944.301 (-1.118.232.744) ms (447 ur)
- 22,71 (-5,29) ms 49.180.275 strani številke povprečni čas upodabljanja (od tega 19,12 ms porabi ASP.Net)
- 11,80 (-53,2) ms 6.370.076 Povprečni čas upodabljanja prvih strani (od tega 8,81 ms porabi ASP.Net)
Morda se sprašujete, zakaj ASP.Net obdela 61 milijonov več zahtevkov na dan, hkrati pa zmanjšuje čas obdelave za 757 ur (v primerjavi z letom 2013). To je predvsem posledica nadgradenj, ki smo jih izvedli na naših strežnikih v začetku leta 2015, pa tudi številnih izboljšav zmogljivosti v aplikaciji. Ne pozabite: zmogljivost je še vedno prodajna točka. Če vas bolj zanimajo podrobnosti o strojni opremi, brez skrbi, podrobnosti o strojni opremi strežnikov, ki se uporabljajo za poganjanje teh strani, bom podal v obliki priloge v naslednjem članku (to povezavo bom posodobil, ko bo čas).
Kaj se je torej spremenilo v zadnjih dveh letih? Ne veliko, samo zamenjava nekaterih strežnikov in omrežne opreme. Tukaj je pregled strežnikov, ki danes uporabljajo vašo spletno stran (opazite, kako so se spremenili od leta 2013)
- 4 strežniki Microsoft SQL Server (2 od njih uporabljata novo strojno opremo)
- 11 IIS spletnih strežnikov (nova strojna oprema)
- 2 Redis strežnika (nova strojna oprema)
- 3 strežniki Tag Engine (2 od teh uporabljata novo strojno opremo)
- 3 Elasticsearch strežniki (enako kot zgoraj)
- 4 HAProxy strežniki za uravnoteženje obremenitve (2 dodana za podporo CloudFlare)
- 2 omrežni napravi (Nexus 5596 jedro + 2232TM Fabric Extender, vse naprave nadgrajene na 10Gbps pasovno širino)
- 2 x Fortinet 800C požarni zid (nadomešča Cisco 5525-X ASA)
- 2 usmerjevalnika Cisco ASR-1001 (nadomesti usmerjevalnike Cisco 3945)
- 2 Cisco ASR-1001-x usmerjevalnika (NOVO!) ）
Kaj potrebujemo, da Stack Overflow deluje? Od leta 2013 se ni veliko spremenilo, a zahvaljujoč optimizacijam in novi strojni opremi, omenjeni zgoraj, zdaj potrebujemo le en spletni strežnik. To situacijo smo že večkrat nehote preizkusili in bili uspešni. Prosimo, upoštevajte: pravkar sem rekel, da deluje, nisem rekel, da je dobra ideja. A vsakič, ko se to zgodi, je precej zanimivo.
Zdaj, ko imamo nekaj osnovnih podatkov o idejah za skaliranje strežnikov, poglejmo, kako smo ustvarili te kul spletne strani. Le malo sistemov obstaja povsem neodvisno (in naši niso izjema), in brez celostnega pogleda, ki povezuje te dele, je pomen načrtovanja arhitekture močno zmanjšan. Naš cilj je razumeti celotno situacijo. V prihodnosti bo veliko člankov, ki se bodo poglobili v vsako specifično področje. Ta članek je le povzetek logične strukture ključne strojne opreme, naslednji članek pa bo vseboval posebne podrobnosti o tej strojni opremi.
Če želite videti, kako ta strojna oprema izgleda danes, tukaj je nekaj fotografij, ki sem jih posnel omarice A (omara B je točno enaka kot ona), ko sem februarja 2015 nadgradil strežnik:
Zdaj pa se poglobimo v arhitekturno postavitev. Spodaj je povzetek logične arhitekture glavnih obstoječih sistemov:
Osnovna načela
Tukaj je nekaj pogostih načel, ki jih ni treba posebej uvajati:
- Vse ima odvečne varnostne kopije.
- Vsi strežniki in omrežne naprave imajo vsaj dve povezavi s pasovno širino 10Gbps.
- Vsi strežniki imajo dva vira energije, ki napajata preko dveh UPS enot, dva generatorja za njima in dva napajalna napajanja v omrežju.
- Vsi strežniki imajo odvečno varnostno kopijo, ki se nahaja v omari A in omari B.
- Vsi strežniki in storitve imajo dvojno redundantne varnostne kopije v ločenem podatkovnem centru (v Koloradu), čeprav večinoma pokrivam New York.
- Vse ima odvečne varnostne kopije.
internet
Najprej morate najti našo spletno stran, ki je stvar DNS. Iskanje spletnih strani je hitro, zato ga zdaj prepuščamo CloudFlare, ker imajo DNS strežnike v vsakem kotičku sveta. DNS zapise posodabljamo preko API-jev, ki so odgovorni za "upravljanje" DNS. Vendar pa v naših zlobnih mislih še vedno imamo svoje DNS strežnike zaradi globoko zakoreninjenih težav z zaupanjem. Ko je apokalipsa apokaliptična – morda zaradi težav z GPL, Punyon ali predpomnjenjem – in ljudje še vedno želijo programirati, da bi preusmerili njihovo pozornost, preklopimo na lastne DNS strežnike.
Ko vaš brskalnik najde naše skrivališče, HTTP promet naših štirih ponudnikov internetnih storitev (Level 3, Zayo, Cogent in Lightower v New Yorku) vstopi v enega od naših štirih naprednih usmerjevalnikov. Uporabljamo Border Gateway Protocol (BGP, zelo standarden protokol) za peer-to-peer promet med ponudniki omrežij, da ga nadzorujemo in zagotovimo najučinkovitejši način dostopa do naših storitev. Usmerjevalnika ASR-1001 in ASR-1001-X sta razdeljena v dve skupini, pri čemer naj bi vsaka uporabljala aktivni/aktivni način za upravljanje prometa obeh omrežnih ponudnikov – tukaj so odvečne varnostne kopije. Čeprav imajo vsi enako fizično pasovno širino 10Gbps, je promet od zunaj še vedno neodvisen od prometa iz zunanjega VLAN-a in je povezan z uravnoteženjem obremenitve ločeno. Ko promet preide skozi usmerjevalnik, prideš do uravnoteževalnika obremenitve.
Mislim, da je čas, da omenim, da imamo MPLS s pasovno širino 10Gbps med obema podatkovnima centroma, čeprav to ni neposredno povezano s storitvami spletnih strani. To tehnologijo uporabljamo za izvajanje replikacije na terenu in hitro obnovo podatkov za obvladovanje določenih izrednih razmer. "Ampak Nick, v tem ni nobene odvečnosti!" No, s tehničnega vidika imate prav (v pozitivnem smislu), gre za resnično eno samo točko odpovedi na tej ravni. Ampak počakaj! Preko omrežnega ponudnika imamo tudi dve dodatni poti za preklop OSPF (MPLS je prva možnost, to pa sta druga in tretja zaradi stroškov). Vsaka od prej omenjenih naprav bo ustrezno povezana s podatkovnim centrom v Koloradu, da se uravnoteži obremenitev omrežnega prometa v primeru preklopa. Seveda bi lahko povezali ti dve skupini naprav med seboj, tako da bi obstajale štiri poti, a pozabimo, pojdimo naprej.
Uravnoteženje obremenitve (HAProxy)
Uravnoteženje obremenitve je izvedeno s HAProxy 1.5.15, ki teče na CentOS 7 (naša najljubša različica Linuxa). In dodati TLS (SSL) protokol varnega prenosa na HAProxy. Prav tako spremljamo HAProxy 1.7, ki bo takoj zagotovil podporo za protokol HTTP/2.
Za razliko od drugih strežnikov z dvema 10Gbps LACP omrežjema ima vsak uravnoteževalnik obremenitve dve 10Gbps povezavi: eno za zunanje omrežje in drugo za DMZ. Ti strežniki imajo 64 GB ali več pomnilnika za učinkovitejšo obdelavo SSL protokolne plasti. Ko lahko v pomnilniku shranimo in ponovno uporabimo več TLS sej, porabimo manj računskih virov, ko se povezujemo z istim odjemalcem. To pomeni, da lahko seje obnovimo hitreje in ceneje. Pomnilnik je tako poceni, da je izbira enostavna.
Samo uravnavanje obremenitve je enostavno nastaviti. Poslušamo različne spletne strani na več različnih IP-jih (predvsem zaradi upravljanja certifikatov in DNS) ter nato usmerjamo promet na različne backende (predvsem na podlagi glav gostiteljev). Edino, kar tukaj naredimo, je, da omejimo hitrost in zberemo nekaj informacij iz glave (iz spletne plasti) za prijavo v sistemska sporočila HAProxy, na ta način lahko beležimo metrike zmogljivosti za vsako zahtevo. To bomo podrobneje omenili kasneje.
Spletna plast (IIS 8.5, ASP.Net MVC 5.2.3 in .Net 4.6.1)
Uravnoteženje obremenitve razdeli promet med 9 strežnikov, ki jih imenujemo primarni spletni strežnik (01-09) in 2 razvojna spletna strežnika (10-11, naše testno okolje). Glavni strežnik poganja Stack Overflow, Careers in vse strani Stack Exchange, medtem ko meta.stackoverflow.com in meta.stackexchange.com delujeta na dveh drugih strežnikih. Glavna Q&A aplikacija je večnajemniška, kar pomeni, da ena aplikacija obravnava vse zahteve s strani Q&A. Z drugimi besedami, celotno aplikacijo za vprašanja in odgovore lahko poganjamo v enem aplikacijskem bazenu na enem strežniku. Druge aplikacije, kot so Careers, API v2, Mobile API itd., so neodvisne. Tukaj je, kaj vidiš v IIS za master in dev strežnike:
Tukaj je razporeditev spletne plasti Stack Overflow, kot jo vidimo v Opserverju (naša notranja nadzorna plošča):
In tukaj je poraba virov teh spletnih strežnikov:
V nadaljevanju bom podrobneje razložil, zakaj ponujamo toliko virov, s poudarkom na tekoči gradnji, svobodi in redundanci.
Servisna plast (IIS, ASP.Net MVC 5.2.3, . NET 4.6.1 in HTTP. SYS)
Ob spletni plasti je servisna plast. Delujejo tudi na IIS 2012 v Windows 8.5R2. Ta plast izvaja nekatere notranje storitve, ki podpirajo spletno plast in druge notranje sisteme produkcijskega okolja. Glavni dve storitvi sta: "Stack Server", ki poganja tag engine in temelji na http.sys (ne na IIS); Providence API (temelji na IIS). Zanimivost: moral sem povezati oba procesa, da sem se povezal na različne sockete, ker je Stack Server zelo pogosto dostopal do L2 in L3 predpomnilnikov ob osveževanju seznama težav v dvominutnih intervalih.
Računalniki, ki izvajajo te storitve, so ključni za tag engine in backend API-je, zato morajo biti redundantni, a ne 9x redundantni. Na primer, vsakih n minut (trenutno 2 minuti) nalagamo vse članke in njihove oznake iz baze, kar ni malo. Ne želimo ponoviti te operacije nalaganja 9-krat na spletni plasti, trikrat je za nas dovolj varno. Uporabljamo tudi različne strojne konfiguracije za te strežnike, da bolje optimiziramo računalniške in podatkovne značilnosti tag motorja in elastičnih indeksnih nalog (ki prav tako tečejo v tej plasti). "Tag engine" sam po sebi je razmeroma zapletena tema, ki bo obravnavana v posebnem članku. Osnovno načelo je, da ko dostopate do naslova /questions/tagged/java, obiščete tag engine in dobite vprašanja, ki se ujemajo z njim. Iskalnik upravlja vse ujemanja oznak razen /search, tako da povsod, vključno z novo navigacijo, prejema podatke prek te storitve.
Predpomnjenje in objavljanje/naročanje (Redis)
Redis smo uporabljali na nekaterih mestih in ima trdno stabilnost. Čeprav je do 160 milijard operacij na mesec, CPU na instanco ne presega 2 %, kar je običajno nižje:
Uporabljamo Redis za sisteme predpomnjenja na ravni L1/L2. Raven "L1" je HTTP predpomnilnik, ki deluje na spletnem strežniku ali podobni aplikaciji. Raven "L2" je namenjena pridobivanju podatkov preko Redisa po odpovedi predpomnilnika prejšnje ravni. Naši podatki so shranjeni v formatu Protobuf, implementiranem preko protobuf-dot-net, ki ga je napisal Marc Gravel. Za odjemalca Redis smo uporabili knjižnico StackExchange.Redis, ki je odprtokodna knjižnica, razvita interno. Če spletni strežnik ne zadene tako L1 kot L2 predpomnilnika, pridobi podatke iz svojih podatkovnih virov (poizvedbe v bazi podatkov, API klici itd.) in rezultate shrani v lokalni predpomnilnik in Redis. Naslednji strežnik morda manjka v L1 predpomnilniku pri pridobivanju istih podatkov, vendar bo podatke pridobil v L2/Redis, kar odpravlja potrebo po poizvedbah v bazi podatkov ali klicih API-ja.
Prav tako izvajamo veliko Q&A strani, vsaka s svojim L1/L2 predpomnilnikom: ključ kot predpona v L1 predpomnilniku in ID baze podatkov v L2/Redis predpomnilniku. O tej temi se bomo poglobili v prihodnjih člankih.
Poleg dveh glavnih Redis strežnikov (enega glavnega in enega podrejenega), ki poganjata vse instance lokacije, smo vzpostavili tudi instanco za strojno učenje (predvsem zaradi pomnilnika) z uporabo dveh drugih namenskih podrejenih strežnikov. Ta skupina strežnikov se uporablja za zagotavljanje storitev, kot so priporočanje vprašanj na domači strani in boljše usklajevanje delovnih mest. Ta platforma se imenuje Providence, o kateri je pisal Kevin Montrose.
Glavni Redis strežnik ima 256 GB RAM-a (približno 90 GB porabljenega), strežnik Providence pa 384 GB pomnilnika (približno 125 GB porabljenega).
Redis ni namenjen le predpomnjenju, temveč ima tudi mehanizem za objavljanje in naročnino, kjer lahko en strežnik objavi sporočilo, drugi naročniki pa ga prejmejo (vključno z Redis od odjemalcev na strežniku). Ta mehanizem uporabljamo za čiščenje L1 predpomnilnika na drugih storitvah, da ohranimo doslednost predpomnilnika na spletnem strežniku. A ima še eno pomembno uporabo: websockete.
Websockets (NetGain)
Uporabljamo spletne vtičnice za pošiljanje posodobitev v realnem času uporabnikom, kot so obvestila v zgornji vrstici, glasovi, nova navigacija, novi odgovori, komentarji in še več.
Sam strežnik socketov teče na spletni plasti z uporabo nativnih sockets. To je zelo majhna aplikacija, ki temelji na naši odprtokodni implementaciji knjižnice: StackExchange.NetGain. V času največje konice smo imeli približno 500.000 sočasnih povezav prek websocketa, kar je veliko brskalnikov. Zanimivost: nekateri od teh brskalnikov so odprti že več kot 18 mesecev, zato boste morali najti nekoga, da preverite, ali so ti razvijalci še živi. Naslednji graf prikazuje vzorec sočasnosti websocketov ta teden:
Zakaj uporabljati spletne vtičnice? Na našem merilu je to veliko bolj učinkovito kot anketiranje. Na ta način lahko preprosto pošljemo več podatkov z manj viri in smo uporabnikom bolj v realnem času. Ta pristop pa ni brez težav: začasni porti, izčrpani ročaji datotek na uravnoteževalnikih obremenitve so zelo zanimivi problemi, o katerih bomo govorili kasneje.
Iskanje (Elasticsearch)
Spojler: Tukaj ni veliko razlogov za navdušenje. Spletna plast uporablja Elasticsearch 1.4 in implementira ultra-lahkega, zmogljivega StackExchange.Elastic odjemalca. Za razliko od večine stvari tega dela ne načrtujemo odprtokodnega, preprosto zato, ker razkriva zelo majhen podnabor API-jev, ki jih potrebujemo za uporabo. Prepričan sem, da bi javna objava pretehtala izgubo in bi razvijalce le zmedla. Na teh mestih uporabljamo elastic:/search za izračun povezanih vprašanj in dajemo predloge pri postavljanju vprašanj.
Vsak Elastic grozd (po en za vsak podatkovni center) vsebuje 3 vozlišča, vsako s svojim indeksom. Spletna stran Kariere ima tudi nekaj dodatnih indeksov. Malce manj standarden del naše konfiguracije v elastičnih krogih je, da je naša skupina treh strežnikov nekoliko zmogljivejša od običajne konfiguracije: vsak strežnik uporablja SSD pomnilnik, 192GB pomnilnika, dvojno omrežje s pasovno širino 10Gbps.
Ista aplikacijska domena kot Stack Server (ja, .Net Core nas je tukaj uporabljal) gosti tudi tag engine, ki prav tako uporablja Elasticsearch za neprekinjeno indeksiranje. Tukaj uporabimo majhen trik, na primer uporabo ROWVERSION v SQL Serverju (vir podatkov) za primerjavo z dokumentom "zadnje mesto" v Elasticu. Ker je očitno zaporedna, nam je enostavno brskati in indeksirati vsebino, če je bila po zadnjem obisku spremenjena.
Glavni razlog, da uporabljamo Elasticsearch namesto tehnologij, kot je SQL iskanje po celotnem besedilu, je njegova razširljivost in stroškovna učinkovitost. SQL je za procesorje razmeroma drag, medtem ko je Elastic precej cenejši in ima zadnje čase veliko novih funkcij. Zakaj ne uporabiš Solr? Moramo iskati po omrežju (z več indeksi hkrati), Solr pa tega scenarija v času naših odločitev ne podpira. Razlog, da še nismo uporabili 2.x, je, da so se tipi v 2.x precej spremenili, kar pomeni, da moramo vse ponovno indeksirati, če želimo nadgraditi. Preprosto nimam dovolj časa za načrtovanje sprememb zahtev in migracij.
Baza podatkov (SQL Server)
SQL Server uporabljamo kot edini vir resnice. Vsi podatki v Elastic in Redis prihajajo iz SQL Serverja. Imamo dva SQL Server grozda in smo konfigurirani z AlwaysOn skupinami razpoložljivosti. Vsak grozd ima primarni strežnik v New Yorku (ki prevzame skoraj vso obremenitev) in replika strežnik, poleg replika strežnika v Koloradu (naš podatkovni center za obnovo po nesrečah). Vse kopirne operacije so asinhrone.
Prva skupina je niz strežnikov Dell R720xd, vsak s 384 GB pomnilnika, PCIe SSD s 4 TB prostora in dvema 12-jedrnima procesorjema. Vključuje Stack Overflow, Sites (to je slabo ime, razložil bom kasneje), PRIZM in mobilno bazo podatkov.
Druga skupina je niz strežnikov Dell R730xd, vsak s 768GB pomnilnika, PCIe SSD s 6TB prostora in dvema 8-jedrnima procesorjema. Ta grozd vsebuje vse druge baze podatkov, vključno s Careers, Open ID, Chat, dnevniki izjem in drugimi Q&A stranmi (npr. Super User, Server Fault itd.).
Na podatkovni plasti želimo ohraniti izkoriščenost CPU na zelo nizki ravni, čeprav bo v praksi poraba procesorja nekoliko višja, ko pride do načrtovanih težav s predpomnjenjem (ki jih odpravljamo). Trenutno sta NY-SQL02 in 04 primarna strežnika, 01 in 03 pa replika strežnika, danes pa smo ju pravkar ponovno zagnali zaradi nadgradnje SSD-ja. Tako so se odrezali v zadnjih 24 urah:
Naša uporaba SQL je zelo preprosta. Preprosto pomeni hitro. Čeprav so nekateri stavki poizvedb lahko perverzni, je naša interakcija s SQL-jem precej naravna. Imamo nekaj starejših Linq2Sql, vendar vsi naši novi razvojni programi uporabljajo Dapper, naš odprtokodni mikro-ORM okvir, ki uporablja POCO. Naj razložim drugače: Stack Overflow ima v svoji bazi samo eno shranjeno proceduro, in to zadnjo preostalo shranjeno proceduro bom ukinil ter jo zamenjal s kodo.
Knjižnica
No, spremenimo mnenje, tukaj so stvari, ki vam lahko pomagajo bolj neposredno. Nekatere sem že omenil, a vam bom dal seznam številnih odprtokodnih .Net knjižnic, ki jih vzdržujemo in jih uporabljajo vsi. Odprto jih uporabljamo, ker nimajo temeljne poslovne vrednosti, lahko pa pomagajo razvijalcem po vsem svetu. Upam, da jih lahko zdaj uporabite:
- Dapper (.Net Core) – Visoko zmogljiv mikro-ORM okvir za ADO.Net
- StackExchange.Redis – Visokozmogljiv Redis odjemalec
- MiniProfiler – lahek profiler, ki ga uporabljamo na vsaki strani (podpira tudi Ruby, Go in Node)
- Izjemno – Za beleženje napak v SQL, JSON, MySQL itd
- Jil – Visokozmogljiva JSON serializacija in deserializacija
- Sigil – .Net CIL Generation Helper (uporabljen, ko C# ni dovolj hiter)
- NetGain – Visokozmogljiv websocket strežnik
- Opserver – nadzorna plošča, ki neposredno preverja večino sistemov in lahko pridobi informacije iz Oriona, Bosuna ali WMI
- Bosun – Nadzorni sistem v ozadju, napisan v jeziku Go
|
Objavljeno na 11. 04. 2018 17:33:18
|
|
|
|
