Kepiye AWS masak layanan elastis. Scaling server lan database

Awan kaya kothak ajaib - sampeyan takon apa sing sampeyan butuhake, lan sumber daya mung katon ora ana. Mesin virtual, database, jaringan - kabeh iki mung sampeyan. Ana panyewa awan liyane, nanging ing Semesta sampeyan minangka panguwasa tunggal. Sampeyan yakin manawa sampeyan bakal nampa sumber daya sing dibutuhake, sampeyan ora nganggep sapa wae lan sampeyan nemtokake kanthi mandiri apa jaringan kasebut. Kepiye carane sihir iki bisa nggawe awan kanthi elastis nyedhiyakake sumber daya lan ngisolasi panyewan saka saben liyane?

AWS cloud minangka sistem mega-super kompleks sing wis berkembang kanthi evolusi wiwit taun 2006. Bagéyan saka pangembangan iki dumadi Vasily Pantyukhin - Arsitek Layanan Web Amazon. Minangka arsitek, dheweke ora mung ndeleng asil pungkasan, nanging uga tantangan sing ditindakake AWS. Sing luwih gedhe pangerten babagan cara kerja sistem, luwih akeh kapercayan. Mula, Vasily bakal nuduhake rahasia layanan awan AWS. Ing ngisor iki desain server AWS fisik, skalabilitas database elastis, basis data Amazon khusus lan metode kanggo nambah kinerja mesin virtual nalika nyuda rega. Kawruh babagan pendekatan arsitektur Amazon bakal mbantu sampeyan nggunakake layanan AWS kanthi luwih efektif lan bisa menehi ide anyar kanggo mbangun solusi sampeyan dhewe.

Babagan pembicara: Vasily Pantyukhin (Hen) diwiwiti minangka admin Unix ing perusahaan .ru, nggarap hardware Sun Microsystem gedhe sajrone 6 taun, lan martakake jagad data-sentris ing EMC sajrone 11 taun. Secara alami berkembang dadi awan pribadi, lan ing taun 2017 pindhah menyang awan umum. Saiki dheweke menehi saran teknis kanggo mbantu urip lan berkembang ing awan AWS.

Penafian: kabeh ing ngisor iki minangka pendapat pribadi Vasily lan bisa uga ora cocog karo posisi Layanan Web Amazon. Rekaman video Laporan sing adhedhasar artikel kasebut kasedhiya ing saluran YouTube kita.

Napa aku ngomong babagan piranti Amazon?

Mobil pisananku duwe transmisi manual. Iku apik amarga saka koyo sing aku bisa drive mobil lan duwe kontrol lengkap liwat. Aku uga seneng yen aku paling ora ngerti prinsip operasi kasebut. Alami, aku mbayangno struktur kothak kasebut cukup primitif - kaya gearbox ing sepedha.

Kabeh apik, kajaba mung siji - macet ing macet. Kayane sampeyan lagi lungguh lan ora nindakake apa-apa, nanging sampeyan terus-terusan ganti gear, menet kopling, gas, rem - pancen nggawe sampeyan kesel. Masalah macet sebagian ditanggulangi nalika kulawarga entuk mobil otomatis. Nalika nyopir, aku duwe wektu kanggo mikir babagan lan ngrungokake buku audio.

Misteri liyane muncul ing uripku, amarga aku mandheg ngerti cara kerja mobilku. Mobil modern minangka piranti rumit. Mobil adapts bebarengan kanggo Welasan paramèter beda: mencet gas, brake, gaya nyopir, kualitas dalan. Aku ora ngerti cara kerjane maneh.

Nalika aku miwiti nggarap maya Amazon, iku uga dadi misteri kanggo aku. Mung misteri iki minangka urutan gedhene, amarga ana siji pembalap ing mobil, lan ing AWS ana mayuta-yuta wong. Kabeh pangguna bebarengan setir, pencet gas lan rem. Pancen nggumunake yen dheweke lunga menyang ngendi wae - iku mukjijat kanggo aku! Sistem kasebut kanthi otomatis adaptasi, timbangan lan elastis nyetel saben pangguna supaya bisa dirasakake yen dheweke mung ana ing Semesta iki.

Piandel rada ilang nalika aku banjur kerja dadi arsitek ing Amazon. Aku weruh masalah apa sing diadhepi, carane ngatasi, lan carane ngembangake layanan. Kanthi nambah pangerten babagan cara kerja sistem, luwih yakin ing layanan kasebut. Dadi aku pengin nuduhake gambar apa sing ana ing sangisore awan AWS.

Apa sing bakal kita guneman

Aku milih pendekatan macem - Aku milih 4 layanan menarik sing worth ngomong bab.

Optimization server. Awan ephemeral kanthi pawujudan fisik: pusat data fisik ing ngendi ana server fisik sing hum, panas lan kedhip karo lampu.

Fungsi tanpa server (Lambda) bisa uga minangka layanan paling skalabel ing méga.

Skala database. Aku bakal menehi pitutur marang kowe babagan carane nggawe database sing bisa diukur dhewe.

Skala jaringan. Bagian pungkasan sing bakal mbukak piranti jaringan kita. Iki pancen apik banget - saben pangguna awan percaya yen dheweke mung ana ing awan lan ora ndeleng panyewan liyane.

Cathetan. Artikel iki bakal ngrembug optimasi server lan skala database. Kita bakal nimbang skala jaringan ing artikel sabanjure. Ing endi fungsi tanpa server? Transkrip kapisah diterbitake babagan dheweke "Cilik, nanging pinter. Unboxing Firecracker microvirtual" Dhiskusi bab sawetara cara njongko beda, lan ngrembug rinci ing solusi Firecracker - simbiosis saka kuwalitas paling saka mesin virtual lan kontaner.

Server

Awan iku ephemeral. Nanging ephemerality iki isih nduweni pawujudan fisik - server. Kaping pisanan, arsitektur kasebut klasik. Chipset x86 standar, kertu jaringan, Linux, hypervisor Xen sing digunakake mesin virtual.

Ing taun 2012, arsitektur iki ngrampungake tugas kanthi apik. Xen minangka hypervisor sing apik, nanging duwe kekurangan utama. Dheweke wis cukup overhead dhuwur kanggo emulasi piranti. Minangka anyar, kertu jaringan luwih cepet utawa drive SSD kasedhiya, overhead iki dadi dhuwur banget. Kepiye cara ngatasi masalah iki? Kita mutusake kanggo nggarap rong bidang sekaligus - ngoptimalake hardware lan hypervisor. Tugas kasebut serius banget.

Ngoptimalake hardware lan hypervisor

Nindakake kabeh bebarengan lan nindakake kanthi becik ora bakal bisa. Apa sing "apik" uga ora jelas ing wiwitan.

Kita mutusake kanggo njupuk pendekatan evolusi - kita ngganti siji unsur penting arsitektur lan mbuwang menyang produksi.

We langkah ing saben rake, ngrungokake keluhan lan saran. Banjur kita ngganti komponen liyane. Dadi, kanthi tambahan cilik, kita ngganti kabeh arsitektur kanthi radikal adhedhasar umpan balik saka pangguna lan dhukungan.

Transformasi kasebut diwiwiti ing 2013 kanthi perkara sing paling rumit - jaringan. ING C3 kedadean, kertu Network Accelerator khusus ditambahake menyang kertu jaringan standar. Iki disambungake kanthi harfiah karo kabel loopback cendhak ing panel ngarep. Ora ayu, nanging ora katon ing méga. Nanging interaksi langsung karo hardware dhasar nambah jitter lan throughput jaringan.

Sabanjure kita mutusake kanggo nambah akses kanggo mblokir panyimpenan data EBS - Elastic Block Storage. Iku kombinasi jaringan lan panyimpenan. Kangelan iku nalika kertu Network Accelerator ana ing pasar, ora ana pilihan kanggo mung tuku hardware Storage Accelerator. Dadi kita nguripake kanggo wiwitan Annapurna Labs, sing dikembangaké Kripik ASIC khusus kanggo kita. Dheweke ngidini volume EBS remot dipasang minangka piranti NVMe.

Ing kasus C4 kita ngrampungake rong masalah. Pisanan yaiku kita ngetrapake dhasar kanggo masa depan sing janji, nanging anyar ing wektu kasebut, teknologi NVMe. Kapindho, kita Ngartekno unloaded prosesor tengah dening nransfer Processing saka panjalukan kanggo EBS kanggo kertu anyar. Ternyata apik, mula saiki Annapurna Labs dadi bagean saka Amazon.

Ing November 2017, kita nyadari yen wis wektune kanggo ngganti hypervisor kasebut dhewe.

Hypervisor anyar dikembangake adhedhasar modul kernel KVM sing diowahi.

Iku ndadekake iku bisa kanggo dhasar nyuda nduwur sirah emulation piranti lan bisa langsung karo ASICs anyar. Kedadeyan C5 padha mesin virtual pisanan karo hypervisor anyar mlaku ing hood. We jenenge nitro.

Evolusi kedadean ing timeline.

Kabeh jinis mesin virtual anyar sing wis muncul wiwit November 2017 nganggo hypervisor iki. Instance Bare Metal ora duwe hypervisor, nanging uga disebut Nitro, amarga padha nggunakake kertu Nitro specialized.

Sajrone rong taun sabanjure, jumlah jinis kasus Nitro ngluwihi sawetara rolas: A1, C5, M5, T3 lan liya-liyane.

Tipe Instance.

Carane mesin Nitro modern bisa

Padha duwe telung komponen utama: Nitro hypervisor (rembugan ndhuwur), chip keamanan lan kertu Nitro.

Chip keamanan Integrasi langsung menyang motherboard. Ngontrol akeh fungsi penting, kayata ngontrol loading OS host.

kertu Nitro - Ana papat jinis mau. Kabeh mau dikembangake dening Annapurna Labs lan adhedhasar ASIC umum. Sawetara perangkat kukuh sing uga umum.

Papat jinis kertu Nitro.

Salah sawijining kertu dirancang kanggo nggarap jaringanVPC. Iki sing katon ing mesin virtual minangka kertu jaringan ENA - Adaptor Jaringan Elastis. Iku uga encapsulates lalu lintas nalika ngirim liwat jaringan fisik (kita bakal pirembagan bab iki ing bagean liya saka artikel), kontrol firewall Keamanan Groups, lan tanggung jawab kanggo nuntun lan jaringan liyane.

Pilih kertu bisa digunakake karo panyimpenan pemblokiran EBS lan disk sing dibangun ing server. Padha katon kanggo mesin virtual tamu minangka adaptor NVMe. Dheweke uga tanggung jawab kanggo enkripsi data lan ngawasi disk.

Sistem kertu Nitro, hypervisor lan chip keamanan Integrasi menyang jaringan SDN utawa Jaringan sing Ditetepake Piranti Lunak. Tanggung jawab kanggo ngatur jaringan iki (Control Plane) kertu controller.

Mesthi, kita terus ngembangake ASIC anyar. Contone, ing pungkasan taun 2018, dheweke ngeculake chip Inferentia, sing ngidini sampeyan bisa luwih efisien karo tugas sinau mesin.

Inferentia Machine Learning Processor chip.

Database Scalable

Basis data tradisional nduweni struktur berlapis. Kanggo nyederhanakake banget, tingkat ing ngisor iki dibedakake.

• SQL - klien lan panyuwunan dispatcher nggarap.
• pranata transaksi - kabeh wis jelas ing kene, ASAM lan liya-liyane.
• Caching, sing diwenehake dening buffer pools.
• logging - nyedhiyakake karya karo log maneh. Ing MySQL diarani Bin Log, ing PosgreSQL - Tulis Ahead Log (WAL).
• Panyimpenan – ngrekam langsung menyang disk.

Struktur database berlapis.

Ana macem-macem cara kanggo skala database: sharding, arsitektur Shared Nothing, disk sing dienggo bareng.

Nanging, kabeh cara iki njaga struktur database monolitik sing padha. Iki sacara signifikan mbatesi skala. Kanggo ngatasi masalah iki, kita ngembangake database kita dhewe - Amazon Aurora. Iku kompatibel karo MySQL lan PostgreSQL.

Amazon Aurora

Ide arsitektur utama yaiku misahake tingkat panyimpenan lan logging saka database utama.

Ing ngarep, aku bakal ujar manawa kita uga nggawe level caching mandiri. Arsitèktur mandhek monolith a, lan kita gain derajat tambahan saka kamardikan ing njongko pamblokiran individu.

Tingkat logging lan panyimpenan kapisah saka database.

DBMS tradisional nulis data menyang sistem panyimpenan ing wangun blok. Ing Amazon Aurora, kita nggawe panyimpenan cerdas sing bisa nganggo basa redo-log. Ing njero, panyimpenan ngowahi log dadi pamblokiran data, ngawasi integritas lan kanthi otomatis gawe serep.

Pendekatan iki ngidini sampeyan ngleksanakake perkara sing menarik kaya kloning. Kerjane dhasar luwih cepet lan luwih ekonomis amarga ora mbutuhake nggawe salinan lengkap kabeh data.

Lapisan panyimpenan dileksanakake minangka sistem sing disebarake. Iku kasusun saka nomer akeh banget saka server fisik. Saben log redo diproses lan disimpen bebarengan enem knots. Iki njamin pangayoman data lan imbangan beban.

Maca skala bisa digayuh nggunakake replika cocok. Panyimpenan sing disebarake ngilangi kabutuhan sinkronisasi ing antarane conto database utama, sing kita tulis data, lan replika sing isih ana. Data up-to-date dijamin kasedhiya kanggo kabeh replika.

Masalah mung cache data lawas ing replika diwaca. Nanging masalah iki lagi ditanggulangi transfer kabeh log redo kanggo replika liwat jaringan internal. Yen log ana ing cache, ditandhani minangka salah lan ditindhes. Yen ora ana ing cache, mung dibuwang.

We diurutake metu panyimpenan.

Cara ngukur tingkat DBMS

Ing kene, skala horisontal luwih angel. Dadi ayo padha mudhun ing dalan sing diantemi skala vertikal klasik.

Ayo nganggep yen kita duwe aplikasi sing komunikasi karo DBMS liwat simpul master.

Nalika skala vertikal, kita nyedhiyakake simpul anyar sing bakal duwe prosesor lan memori luwih akeh.

Sabanjure, kita ngalih aplikasi saka simpul master lawas menyang sing anyar. Masalah muncul.

• Iki mbutuhake downtime aplikasi sing signifikan.
• Node master anyar bakal duwe cache kadhemen. Kinerja database bakal maksimal mung sawise cache wis digawe panas.

Carane nambah kahanan? Nggawe proxy ing antarane aplikasi lan simpul master.

Apa iki bakal menehi kita? Saiki kabeh aplikasi ora perlu dialihake kanthi manual menyang simpul anyar. Ngalih bisa rampung ing proxy lan dhasar luwih cepet.

Iku misale jek sing masalah wis ditanggulangi. Nanging ora, kita isih nandhang sangsara marga saka perlu kanggo anget munggah cache. Kajaba iku, masalah anyar wis muncul - saiki proxy minangka titik potensial kegagalan.

Solusi pungkasan karo Amazon Aurora tanpa server

Kepiye carane ngatasi masalah kasebut?

Ninggalake proxy. Iki dudu conto sing kapisah, nanging kabeh armada proksi sing disebarake liwat aplikasi sing nyambung menyang database. Yen gagal, samubarang node bisa diganti meh langsung.

Nambahake blumbang kelenjar sing anget saka macem-macem ukuran. Mulane, yen perlu kanggo nyedhiakke simpul anyar saka ukuran luwih gedhe utawa cilik, iku langsung kasedhiya. Ora perlu ngenteni kanggo mbukak.

Proses skala kabeh dikontrol dening sistem pemantauan khusus. Ngawasi terus-terusan ngawasi kahanan simpul master saiki. Yen ndeteksi, contone, sing mbukak prosesor wis tekan nilai kritis, iku ngabari blumbang kedadean anget bab perlu kanggo nyedhiakke simpul anyar.

Proksi sing disebarake, kedadeyan sing anget lan ngawasi.

A simpul karo daya sing dibutuhake kasedhiya. Buffer pools disalin menyang, lan sistem wiwit ngenteni wayahe aman kanggo ngalih.

Biasane wayahe kanggo ngalih teka cukup cepet. Banjur komunikasi antarane proxy lan simpul master lawas ditundha, kabeh sesi diuripake menyang simpul anyar.

Bisa nganggo resume database.

Grafik kasebut nuduhake manawa suspensi kasebut pancen cendhak banget. Grafik biru nuduhake beban, lan langkah abang nuduhake momen skala. Penurunan jangka pendek ing grafik biru yaiku wektu tundha sing cendhak.

Miturut cara, Amazon Aurora ngidini sampeyan ngirit dhuwit lan mateni database nalika ora digunakake, contone, ing akhir minggu. Sawise mungkasi mbukak, DB mboko sithik nyuda daya lan mateni sawetara wektu. Nalika beban bali, bakal munggah lancar maneh.

Ing bagean sabanjure crita babagan piranti Amazon, kita bakal ngomong babagan skala jaringan. Langganan layang lan tetep dirungokake supaya sampeyan ora kantun artikel kasebut.

Ing HighLoad++ Vasily Pantyukhin bakal menehi laporan "Houston, kita duwe masalah. Desain sistem kanggo kegagalan, pola pangembangan kanggo layanan awan Amazon internal" Apa pola desain kanggo sistem sing disebarake sing digunakake dening pangembang Amazon, apa sebabe kegagalan layanan, apa arsitektur basis Cell, Kerja Konstan, Shuffle Sharding - bakal menarik. Kurang saka sasi nganti konferensi - pesen tiket. 24 Oktober mundhak rega final.

Source: www.habr.com