Ang mga ulap ay parang magic box - tatanungin mo kung ano ang kailangan mo, at ang mga mapagkukunan ay lilitaw nang wala saan. Mga virtual machine, database, network - lahat ng ito ay sa iyo lamang. Mayroong iba pang mga nangungupahan sa ulap, ngunit sa iyong Uniberso ikaw ang nag-iisang pinuno. Sigurado ka na palagi kang makakatanggap ng mga kinakailangang mapagkukunan, hindi mo isinasaalang-alang ang sinuman at independyente mong tinutukoy kung ano ang magiging network. Paano gumagana ang mahika na ito na ginagawang ang cloud ay elastic na maglaan ng mga mapagkukunan at ganap na ihiwalay ang mga nangungupahan sa isa't isa?
Ang AWS cloud ay isang mega-super complex na sistema na ebolusyonaryong umuunlad mula noong 2006. Bahagi ng pag-unlad na ito ang naganap Vasily Pantyukhin - Arkitekto ng Mga Serbisyo sa Web ng Amazon. Bilang isang arkitekto, nakakakuha siya ng panloob na pagtingin hindi lamang sa resulta, kundi pati na rin sa mga hamon na napapagtagumpayan ng AWS. Kung mas malaki ang pag-unawa sa kung paano gumagana ang system, mas malaki ang tiwala. Samakatuwid, ibabahagi ni Vasily ang mga lihim ng mga serbisyo sa cloud ng AWS. Nasa ibaba ang disenyo ng mga pisikal na AWS server, elastic database scalability, isang custom na database ng Amazon at mga pamamaraan para sa pagpapataas ng performance ng mga virtual machine habang sabay na binabawasan ang kanilang presyo. Ang kaalaman sa mga diskarte sa arkitektura ng Amazon ay makakatulong sa iyong gamitin ang mga serbisyo ng AWS nang mas epektibo at maaaring magbigay sa iyo ng mga bagong ideya para sa pagbuo ng sarili mong mga solusyon.
Tungkol sa tagapagsalita: Vasily Pantyukhin () nagsimula bilang isang Unix admin sa mga kumpanyang .ru, nagtrabaho sa malalaking Sun Microsystem hardware sa loob ng 6 na taon, at nangaral ng isang data-centric na mundo sa EMC sa loob ng 11 taon. Ito ay natural na nagbago sa mga pribadong ulap, at noong 2017 ay lumipat sa mga pampublikong ulap. Ngayon ay nagbibigay siya ng teknikal na payo upang makatulong na mabuhay at umunlad sa AWS cloud.
Disclaimer: lahat ng nasa ibaba ay personal na opinyon ni Vasily at maaaring hindi tumugma sa posisyon ng Amazon Web Services. Ang ulat kung saan nakabatay ang artikulo ay available sa aming channel sa YouTube.
Bakit ko pinag-uusapan ang Amazon device?
Ang una kong sasakyan ay may manual transmission. Napakasarap dahil sa pakiramdam na kaya kong magmaneho ng kotse at magkaroon ng ganap na kontrol dito. Nagustuhan ko rin na hindi bababa sa halos naiintindihan ko ang prinsipyo ng pagpapatakbo nito. Naturally, naisip ko na ang istraktura ng kahon ay medyo primitive - isang bagay tulad ng isang gearbox sa isang bisikleta.
Ang lahat ay mahusay, maliban sa isang bagay - natigil sa mga jam ng trapiko. Tila nakaupo ka at walang ginagawa, ngunit patuloy kang nagbabago ng mga gear, pagpindot sa clutch, gas, preno - talagang nakakapagod ito. Ang problema sa traffic jam ay bahagyang nalutas nang ang pamilya ay nakakuha ng awtomatikong sasakyan. Habang nagmamaneho, nagkaroon ako ng oras para mag-isip tungkol sa isang bagay at makinig sa isang audiobook.
Ang isa pang misteryo ay lumitaw sa aking buhay, dahil ako ay ganap na tumigil sa pag-unawa kung paano gumagana ang aking sasakyan. Ang isang modernong kotse ay isang kumplikadong aparato. Ang kotse ay umaangkop nang sabay-sabay sa dose-dosenang iba't ibang mga parameter: pagpindot sa gas, preno, istilo ng pagmamaneho, kalidad ng kalsada. Hindi ko na maintindihan kung paano ito gumagana.
Noong nagsimula akong magtrabaho sa Amazon cloud, ito rin ay isang misteryo sa akin. Tanging ang misteryong ito ay isang order ng magnitude na mas malaki, dahil mayroong isang driver sa kotse, at sa AWS mayroong milyun-milyon sa kanila. Ang lahat ng mga gumagamit ay sabay-sabay na umiiwas, pinindot ang gas at preno. Nakapagtataka na pumunta sila kung saan nila gusto - ito ay isang himala para sa akin! Awtomatikong nag-aangkop, nagsusukat at nababanat ang sistema sa bawat gumagamit upang tila sa kanya ay nag-iisa siya sa Uniberso na ito.
Medyo nawala ang magic nang maglaon akong magtrabaho bilang arkitekto sa Amazon. Nakita ko kung anong mga problema ang kinakaharap namin, kung paano namin malulutas ang mga ito, at kung paano kami bumuo ng mga serbisyo. Sa pagtaas ng pag-unawa sa kung paano gumagana ang system, lumilitaw ang higit na kumpiyansa sa serbisyo. Kaya gusto kong magbahagi ng larawan ng kung ano ang nasa ilalim ng hood ng AWS cloud.
Ano ang pag-uusapan natin
Pinili ko ang isang sari-saring diskarte - Pumili ako ng 4 na kawili-wiling serbisyo na dapat pag-usapan.
Pag-optimize ng server. Ephemeral cloud na may pisikal na embodiment: mga pisikal na data center kung saan may mga pisikal na server na umuugong, umiinit at kumukurap na may mga ilaw.
Mga function na walang server (Lambda) ay marahil ang pinakanasusukat na serbisyo sa cloud.
Pag-scale ng database. Sasabihin ko sa iyo kung paano tayo bumuo ng sarili nating mga scalable database.
Pag-scale ng network. Ang huling bahagi kung saan bubuksan ko ang aparato ng aming network. Ito ay isang kahanga-hangang bagay - bawat gumagamit ng ulap ay naniniwala na siya ay nag-iisa sa ulap at hindi nakikita ang iba pang mga nangungupahan.
Tandaan. Tatalakayin ng artikulong ito ang pag-optimize ng server at pag-scale ng database. Isasaalang-alang namin ang pag-scale ng network sa susunod na artikulo. Nasaan ang mga serverless function? Ang isang hiwalay na transcript ay nai-publish tungkol sa kanila "" Pinag-uusapan nito ang tungkol sa ilang iba't ibang paraan ng pag-scale, at tinatalakay nang detalyado ang solusyon sa Firecracker - isang symbiosis ng mga pinakamahusay na katangian ng isang virtual machine at mga lalagyan.
Mga server
Ang ulap ay panandalian. Ngunit ang ephemerality na ito ay mayroon pa ring pisikal na sagisag - mga server. Sa una, ang kanilang arkitektura ay klasiko. Karaniwang x86 chipset, network card, Linux, Xen hypervisor kung saan pinapatakbo ang mga virtual machine.
Noong 2012, ang arkitektura na ito ay nakayanan nang maayos ang mga gawain nito. Ang Xen ay isang mahusay na hypervisor, ngunit mayroon itong isang pangunahing disbentaha. Sapat na siya mataas na overhead para sa emulation ng device. Habang nagiging available ang mga bago, mas mabilis na network card o SSD drive, nagiging masyadong mataas ang overhead na ito. Paano haharapin ang problemang ito? Nagpasya kaming magtrabaho sa dalawang larangan nang sabay-sabay - i-optimize ang parehong hardware at hypervisor. Napakaseryoso ng gawain.
Pag-optimize ng hardware at hypervisor
Ang paggawa ng lahat nang sabay-sabay at ang paggawa nito ng maayos ay hindi gagana. Kung ano ang "mabuti" ay hindi rin malinaw sa simula.
Nagpasya kaming gumawa ng ebolusyonaryong diskarte - binago namin ang isang mahalagang elemento ng arkitektura at itinapon ito sa produksyon.
Tinatapakan namin ang bawat kalaykay, nakikinig sa mga reklamo at mungkahi. Pagkatapos ay binago namin ang isa pang bahagi. Kaya, sa maliliit na pagdaragdag, radikal naming binabago ang buong arkitektura batay sa feedback mula sa mga user at suporta.
Nagsimula ang pagbabago noong 2013 sa pinakakomplikadong bagay - ang network. SA C3 mga pagkakataon, isang espesyal na Network Accelerator card ang idinagdag sa karaniwang network card. Ito ay literal na konektado sa isang maikling loopback cable sa front panel. Hindi ito maganda, ngunit hindi ito nakikita sa ulap. Ngunit ang direktang pakikipag-ugnayan sa hardware sa panimula ay nagpabuti ng jitter at network throughput.
Susunod, nagpasya kaming pahusayin ang pag-access upang harangan ang storage ng data EBS - Elastic Block Storage. Ito ay isang kumbinasyon ng network at storage. Ang kahirapan ay habang ang mga Network Accelerator card ay umiral sa merkado, walang opsyon na bumili lang ng Storage Accelerator hardware. Kaya napunta kami sa isang startup Annapurna Labs, na bumuo ng mga espesyal na ASIC chip para sa amin. Pinayagan nila ang mga malayuang volume ng EBS na mai-mount bilang mga NVMe device.
Sa mga pagkakataon C4 nalutas namin ang dalawang problema. Ang una ay ipinatupad namin ang isang pundasyon para sa hinaharap ng pag-asa, ngunit bago sa panahong iyon, ang teknolohiya ng NVMe. Pangalawa, makabuluhang na-unload namin ang gitnang processor sa pamamagitan ng paglilipat ng pagproseso ng mga kahilingan sa EBS sa isang bagong card. Ito ay naging maganda, kaya ngayon ang Annapurna Labs ay bahagi ng Amazon.
Noong Nobyembre 2017, napagtanto namin na oras na para baguhin ang hypervisor mismo.
Ang bagong hypervisor ay binuo batay sa binagong KVM kernel modules.
Ginawa nitong posible na bawasan ang overhead ng emulation ng device at direktang gumana sa mga bagong ASIC. Mga pagkakataon C5 ay ang mga unang virtual machine na may bagong hypervisor na tumatakbo sa ilalim ng hood. Pinangalanan namin siya Nitro.
Ebolusyon ng mga pagkakataon sa timeline.
Ang lahat ng mga bagong uri ng virtual machine na lumitaw mula noong Nobyembre 2017 ay tumatakbo sa hypervisor na ito. Walang hypervisor ang mga Bare Metal instance, ngunit tinatawag din silang Nitro, dahil gumagamit sila ng mga espesyal na Nitro card.
Sa susunod na dalawang taon, ang bilang ng mga uri ng Nitro instance ay lumampas sa ilang dosenang: A1, C5, M5, T3 at iba pa.
Mga uri ng instance.
Paano gumagana ang mga makabagong Nitro machine
Mayroon silang tatlong pangunahing bahagi: ang Nitro hypervisor (tinalakay sa itaas), ang security chip at ang Nitro card.
Security chip direktang isinama sa motherboard. Kinokontrol nito ang maraming mahahalagang function, tulad ng pagkontrol sa paglo-load ng host OS.
Nitro card - Mayroong apat na uri ng mga ito. Lahat ng mga ito ay binuo ng Annapurna Labs at batay sa mga karaniwang ASIC. Ang ilan sa kanilang firmware ay karaniwan din.
Apat na uri ng Nitro card.
Ang isa sa mga card ay idinisenyo upang magamit networkVPC. Ito ang nakikita sa mga virtual machine bilang isang network card ENA - Elastic Network Adapter. Sinasaklaw din nito ang trapiko kapag ipinapadala ito sa pamamagitan ng isang pisikal na network (pag-uusapan natin ito sa ikalawang bahagi ng artikulo), kinokontrol ang firewall ng Security Groups, at responsable para sa pagruruta at iba pang mga bagay sa network.
Gumagana ang mga piling card sa block storage EBS at mga disk na binuo sa server. Lumilitaw ang mga ito sa guest virtual machine bilang Mga adaptor ng NVMe. Responsable din sila para sa pag-encrypt ng data at pagsubaybay sa disk.
Ang sistema ng mga Nitro card, hypervisor at security chip ay isinama sa isang network ng SDN o Network na Tinukoy ng Software. Responsable sa pamamahala sa network na ito (Control Plane) card ng controller.
Siyempre, patuloy kaming bumuo ng mga bagong ASIC. Halimbawa, sa pagtatapos ng 2018 inilabas nila ang Inferentia chip, na nagbibigay-daan sa iyong magtrabaho nang mas mahusay sa mga gawain sa pag-aaral ng makina.
Inferentia Machine Learning Processor chip.
Nasusukat na Database
Ang isang tradisyunal na database ay may layered na istraktura. Upang lubos na gawing simple, ang mga sumusunod na antas ay nakikilala.
- SQL — ang kliyente at mga dispatser ng kahilingan ay nagtatrabaho dito.
- Mga probisyon mga transaksyon - malinaw ang lahat dito, ACID at lahat ng iyon.
- pag-cache, na ibinibigay ng mga buffer pool.
- Pagtotroso — nagbibigay ng trabaho sa mga redo log. Sa MySQL sila ay tinatawag na Bin Logs, sa PosgreSQL - Write Ahead Logs (WAL).
- Imbakan – direktang pag-record sa disk.
Layered na istraktura ng database.
Mayroong iba't ibang paraan upang sukatin ang mga database: sharding, Shared Nothing architecture, shared disks.
Gayunpaman, ang lahat ng mga pamamaraang ito ay nagpapanatili ng parehong monolitikong istraktura ng database. Lubos nitong nililimitahan ang pag-scale. Upang malutas ang problemang ito, bumuo kami ng sarili naming database − Amazon Aurora. Ito ay katugma sa MySQL at PostgreSQL.
Amazon Aurora
Ang pangunahing ideya sa arkitektura ay ang paghiwalayin ang mga antas ng imbakan at pag-log mula sa pangunahing database.
Sa hinaharap, sasabihin ko na ginawa rin naming independyente ang antas ng pag-cache. Ang arkitektura ay tumigil sa pagiging isang monolith, at nakakakuha kami ng mga karagdagang antas ng kalayaan sa pag-scale ng mga indibidwal na bloke.
Ang mga antas ng pag-log at imbakan ay hiwalay sa database.
Ang isang tradisyunal na DBMS ay nagsusulat ng data sa isang storage system sa anyo ng mga bloke. Sa Amazon Aurora, gumawa kami ng matalinong storage na nakakapagsalita ng wika redo-logs. Sa loob, ginagawa ng storage ang mga log sa mga bloke ng data, sinusubaybayan ang kanilang integridad at awtomatikong nagba-back up.
Ang diskarte na ito ay nagpapahintulot sa iyo na ipatupad ang mga kagiliw-giliw na bagay tulad ng pag-clone. Gumagana ito sa panimula nang mas mabilis at mas matipid dahil sa katotohanang hindi ito nangangailangan ng paglikha ng kumpletong kopya ng lahat ng data.
Ang storage layer ay ipinatupad bilang isang distributed system. Binubuo ito ng napakalaking bilang ng mga pisikal na server. Ang bawat redo log ay pinoproseso at nai-save nang sabay-sabay anim na buhol. Tinitiyak nito ang proteksyon ng data at pagbabalanse ng load.
Maaaring makamit ang read scaling gamit ang naaangkop na mga replika. Tinatanggal ng ibinahagi na imbakan ang pangangailangan para sa pag-synchronize sa pagitan ng pangunahing halimbawa ng database, kung saan kami nagsusulat ng data, at ang natitirang mga replika. Ang up-to-date na data ay ginagarantiyahan na magagamit sa lahat ng mga replika.
Ang tanging problema ay ang pag-cache ng lumang data sa mga nabasang replika. Ngunit ang problemang ito ay nalulutas paglipat ng lahat ng redo logs sa mga replika sa panloob na network. Kung ang log ay nasa cache, ito ay minarkahan bilang hindi tama at na-overwrite. Kung wala ito sa cache, ito ay itatapon lamang.
Inayos namin ang imbakan.
Paano sukatin ang mga tier ng DBMS
Dito, ang pahalang na pag-scale ay mas mahirap. Kaya't pumunta tayo sa matapang na landas klasikong vertical scaling.
Ipagpalagay natin na mayroon tayong application na nakikipag-ugnayan sa DBMS sa pamamagitan ng master node.
Kapag patayo ang pag-scale, naglalaan kami ng bagong node na magkakaroon ng mas maraming processor at memory.
Susunod, inililipat namin ang application mula sa lumang master node patungo sa bago. Ang mga problema ay lumitaw.
- Mangangailangan ito ng makabuluhang downtime ng aplikasyon.
- Ang bagong master node ay magkakaroon ng malamig na cache. Ang pagganap ng database ay magiging maximum lamang pagkatapos ng pag-init ng cache.
Paano pagbutihin ang sitwasyon? Mag-set up ng proxy sa pagitan ng application at ng master node.
Ano ang ibibigay nito sa atin? Ngayon ang lahat ng mga application ay hindi kailangang manu-manong i-redirect sa bagong node. Ang paglipat ay maaaring gawin sa ilalim ng isang proxy at sa panimula ay mas mabilis.
Mukhang naayos na ang problema. Ngunit hindi, nagdurusa pa rin kami sa pangangailangang painitin ang cache. Bilang karagdagan, isang bagong problema ang lumitaw - ngayon ang proxy ay isang potensyal na punto ng pagkabigo.
Panghuling solusyon sa Amazon Aurora na walang server
Paano natin nalutas ang mga problemang ito?
Nag-iwan ng proxy. Ito ay hindi isang hiwalay na pagkakataon, ngunit isang buong ipinamahagi na fleet ng mga proxy kung saan kumokonekta ang mga application sa database. Sa kaso ng pagkabigo, ang alinman sa mga node ay maaaring palitan halos kaagad.
Nagdagdag ng pool ng mga mainit na node na may iba't ibang laki. Samakatuwid, kung kinakailangan upang maglaan ng isang bagong node ng isang mas malaki o mas maliit na sukat, ito ay magagamit kaagad. Hindi na kailangang maghintay para mag-load ito.
Ang buong proseso ng scaling ay kinokontrol ng isang espesyal na sistema ng pagsubaybay. Patuloy na sinusubaybayan ng pagsubaybay ang estado ng kasalukuyang master node. Kung nakita nito, halimbawa, na ang pag-load ng processor ay umabot sa isang kritikal na halaga, inaabisuhan nito ang pool ng mga maiinit na pagkakataon tungkol sa pangangailangang maglaan ng bagong node.
Ibinahagi ang mga proxy, mainit na pagkakataon at pagsubaybay.
Available ang isang node na may kinakailangang kapangyarihan. Ang mga buffer pool ay kinopya dito, at ang system ay nagsisimulang maghintay para sa isang ligtas na sandali upang lumipat.
Kadalasan ang sandali ng paglipat ay mabilis na dumarating. Pagkatapos ang komunikasyon sa pagitan ng proxy at ang lumang master node ay nasuspinde, ang lahat ng mga session ay inililipat sa bagong node.
Makipagtulungan sa mga resume ng database.
Ipinapakita ng graph na talagang napakaikli ng pagsususpinde. Ipinapakita ng asul na graph ang pagkarga, at ang mga pulang hakbang ay nagpapakita ng mga scaling moments. Ang mga panandaliang pagbaba sa asul na graph ay eksaktong maikling pagkaantala.
Sa pamamagitan ng paraan, pinapayagan ka ng Amazon Aurora na ganap na makatipid ng pera at i-off ang database kapag hindi ito ginagamit, halimbawa, sa katapusan ng linggo. Matapos ihinto ang pagkarga, unti-unting binabawasan ng DB ang kapangyarihan nito at nag-off nang ilang oras. Kapag bumalik ang load, ito ay tataas muli ng maayos.
Sa susunod na bahagi ng kuwento tungkol sa Amazon device, pag-uusapan natin ang tungkol sa network scaling. Mag-subscribe at manatiling nakatutok upang hindi mo makaligtaan ang artikulo.
Sa Si Vasily Pantyukhin ay magbibigay ng ulat "" Anong mga pattern ng disenyo para sa mga distributed system ang ginagamit ng mga developer ng Amazon, ano ang mga dahilan para sa mga pagkabigo sa serbisyo, ano ang arkitektura na nakabatay sa Cell, Constant Work, Shuffle Sharding - ito ay magiging kawili-wili. Wala pang isang buwan bago ang kumperensya - . Oktubre 24 huling pagtaas ng presyo.
Pinagmulan: www.habr.com