Awan sapertos kotak ajaib - anjeun naroskeun naon anu anjeun peryogikeun, sareng sumber dayana muncul teu kamana-mana. Mesin virtual, pangkalan data, jaringan - sadayana ieu ngan ukur anjeun. Aya panyewa awan anu sanés, tapi di Alam Semesta anjeun mangrupikeun pangawasa tunggal. Anjeun yakin yén anjeun bakal salawasna nampa sumberdaya diperlukeun, anjeun teu nganggap saha wae jeung anjeun bebas nangtukeun naon jaringan bakal jadi. Kumaha karya sihir ieu anu ngajantenkeun awan sacara elastis nyayogikeun sumber daya sareng ngasingkeun panyewa sacara lengkep?
Awan AWS mangrupikeun sistem mega-super kompleks anu parantos mekar sacara évolusionér saprak 2006. Bagian tina pangwangunan ieu lumangsung Vasily Pantyukhin - Arsiték Layanan Wéb Amazon. Salaku hiji arsiték, anjeunna meunang katingal jero teu ukur dina hasil ahir, tapi ogé dina tantangan AWS overcomes. Langkung ageung pamahaman kumaha sistem jalanna, langkung ageung kapercayaan. Ku alatan éta, Vasily bakal babagi Rahasia jasa awan AWS. Di handap ieu desain server AWS fisik, scalability database elastis, database Amazon custom jeung métode pikeun ngaronjatkeun kinerja mesin virtual bari sakaligus ngurangan harga maranéhanana. Pangaweruh ngeunaan pendekatan arsitéktur Amazon bakal ngabantosan anjeun ngagunakeun jasa AWS sacara langkung efektif sareng tiasa masihan ideu énggal pikeun ngawangun solusi anjeun nyalira.
Ngeunaan panyatur: Vasily Pantyukhin () dimimitian salaku admin Unix di pausahaan .ru, digawé dina hardware Sun Microsystem badag pikeun 6 taun, sarta ngahutbah dunya data-centric di EMC pikeun 11 taun. Éta sacara alami mekar janten awan pribadi, sareng dina taun 2017 ngalih ka awan umum. Ayeuna anjeunna nyayogikeun nasihat téknis pikeun ngabantosan hirup sareng ngembangkeun dina awan AWS.
Bantahan: sadayana di handap ieu mangrupikeun pendapat pribadi Vasily sareng panginten henteu saluyu sareng posisi Amazon Web Services. Laporan anu dumasar kana tulisan éta sayogi dina saluran YouTube kami.
Naha kuring ngawangkong ngeunaan alat Amazon?
Mobil munggaran kuring ngagaduhan transmisi manual. Éta hébat kusabab rarasaan yén kuring tiasa nyetir mobil sareng gaduh kontrol lengkep. Kuring ogé resep yén kuring sahenteuna kasarna ngartos prinsip operasi na. Alami, kuring ngabayangkeun struktur kotakna rada primitif - sapertos kotak gear dina sapédah.
Sagalana éta hébat, iwal hiji hal - nyangkut dina jams lalulintas. Sigana anjeun calik sareng teu ngalakukeun nanaon, tapi anjeun terus-terusan ngarobih gear, mencét clutch, gas, rem - éta leres-leres ngajantenkeun anjeun capé. Masalah macet sawaréh direngsekeun nalika kulawarga ngagaduhan mobil otomatis. Nalika nyetir, kuring ngagaduhan waktos mikir ngeunaan hiji hal sareng ngadangukeun buku audio.
Misteri anu sanés muncul dina kahirupan kuring, sabab kuring lirén ngartos kumaha mobil kuring jalan. Mobil modern mangrupikeun alat anu kompleks. Mobil diluyukeun sakaligus ka puluhan parameter béda: mencét gas, rem, gaya nyetir, kualitas jalan. Kuring teu ngarti kumaha gawéna deui.
Nalika kuring mimiti damel dina awan Amazon, éta ogé misteri pikeun kuring. Ngan misteri ieu mangrupa urutan gedena, sabab aya hiji supir dina mobil, sarta dina AWS aya jutaan aranjeunna. Kabéh pamaké sakaligus steering, pencét gas jeung rem. Éta endah pisan yén aranjeunna nuju ka tempat anu dipikahoyong - éta mujijat pikeun kuring! Sistem sacara otomatis nyaluyukeun, skala sareng nyaluyukeun sacara elastis ka unggal pangguna supados sigana anjeunna nyalira di Alam Semesta ieu.
Sihirna rada leungit nalika kuring engké damel salaku arsiték di Amazon. Kuring ningali naon masalah anu urang hadapi, kumaha urang ngabéréskeunana, sareng kumaha urang ngembangkeun jasa. Kalawan ngaronjatkeun pamahaman kumaha sistem jalan, beuki kapercayaan dina layanan nu mucunghul. Janten abdi hoyong bagikeun gambar naon anu aya dina tiung awan AWS.
Naon anu bakal urang bahas
Kuring milih pendekatan anu rupa-rupa - kuring milih 4 jasa anu pikaresepeun anu patut diomongkeun.
optimasi server. Awan ephemeral kalayan perwujudan fisik: pusat data fisik dimana aya server fisik anu hum, panas sareng ngacieupan ku lampu.
fungsi serverless (Lambda) sigana mangrupikeun jasa anu paling skalabel dina méga.
Skala database. Kuring gé ngabejaan Anjeun tentang kumaha urang ngawangun database scalable urang sorangan.
Skala jaringan. Bagian anu terakhir dimana kuring bakal muka alat jaringan urang. Ieu mangrupikeun hal anu saé - unggal pangguna awan percaya yén anjeunna nyalira dina méga sareng henteu ningali panyewa sanés.
Catetan. Artikel ieu bakal ngabahas optimasi server sareng skala database. Urang bakal mertimbangkeun skala jaringan dina artikel salajengna. Dimana fungsi serverless? Transkrip anu misah diterbitkeun ngeunaan aranjeunna "" Ieu Talks About sababaraha métode skala béda, sarta ngabahas di jéntré solusi Firecracker - a simbiosis sahiji kualitas pangalusna tina mesin virtual jeung wadahna.
Palayan
Méga téh ephemeral. Tapi ephemerality ieu masih ngabogaan perwujudan fisik - server. Dina awalna, arsitéktur maranéhanana éta klasik. Chipset x86 standar, kartu jaringan, Linux, Xen hypervisor dimana mesin virtual dijalankeun.
Dina 2012, arsitéktur ieu coped kalawan tugas na cukup alus. Xen mangrupakeun hypervisor hébat, tapi boga hiji aral utama. Anjeunna ngagaduhan cukup overhead tinggi pikeun emulation alat. Salaku anyar, kartu jaringan gancang atawa drive SSD sadia, overhead ieu jadi luhur teuing. Kumaha carana nungkulan masalah ieu? Urang mutuskeun pikeun dianggo dina dua fronts sakaligus - ngaoptimalkeun duanana hardware na hypervisor. Tugasna serius pisan.
Optimizing hardware na hypervisor
Ngalakukeun sadayana sakaligus sareng ngalakukeun éta ogé moal jalan. Naon "saé" éta ogé teu jelas mimitina.
Kami mutuskeun nyandak pendekatan évolusionér - urang ngarobih hiji unsur penting dina arsitéktur sareng ngalungkeun kana produksi.
Urang lengkah dina unggal rake, ngadangukeun keluhan jeung saran. Teras we ngarobah komponén séjén. Ku kituna, dina increments leutik, urang radikal ngarobah sakabéh arsitéktur dumasar kana eupan balik ti pamaké sarta rojongan.
Transformasi dimimitian dina 2013 kalawan hal paling kompléks - jaringan. DI S3 instance, kartu Network Accelerator husus ditambahkeun kana kartu jaringan baku. Ieu disambungkeun sacara harfiah ku kabel loopback pondok dina panel hareup. Teu geulis, tapi teu katingali dina awan. Tapi interaksi langsung jeung hardware fundamentally ningkat jitter sarta throughput jaringan.
Salajengna urang mutuskeun pikeun ngaronjatkeun aksés ka meungpeuk gudang data EBS - Elastis Blok Panyimpenan. Éta mangrupikeun kombinasi jaringan sareng panyimpenan. Kasusahna nyaéta nalika kartu Network Accelerator aya di pasar, teu aya pilihan pikeun ngan ukur mésér hardware Storage Accelerator. Janten urang tos ka ngamimitian Annapurna Labs, Anu ngembangkeun chip ASIC husus pikeun urang. Aranjeunna ngamungkinkeun volume EBS jauh dipasang salaku alat NVMe.
Dina instansi C4 urang direngsekeun dua masalah. Anu kahiji nyaéta yén kami ngalaksanakeun yayasan pikeun masa depan anu ngajangjikeun, tapi énggal dina waktos éta, téknologi NVMe. Kadua, urang nyata unloaded processor sentral ku mindahkeun ngolah requests ka EBS ka kartu anyar. Tétéla saé, janten ayeuna Annapurna Labs mangrupikeun bagian tina Amazon.
Ku Nopémber 2017, urang sadar yén éta waktuna pikeun ngarobah hypervisor sorangan.
Hypervisor anyar dikembangkeun dumasar kana modul kernel KVM anu dirobih.
Hal ieu ngamungkinkeun pikeun dasarna ngirangan overhead emulation alat sareng damel langsung sareng ASIC énggal. instansi S5 éta mesin virtual munggaran kalayan hypervisor anyar ngajalankeun handapeun tiung. Urang ngaranna Nitro.
Évolusi instansi dina timeline.
Sadaya jinis mesin virtual énggal anu muncul saprak Nopémber 2017 dijalankeun dina hypervisor ieu. instansi Metal bulistir teu boga hypervisor a, Tapi maranéhna disebut ogé Nitro, saprak aranjeunna ngagunakeun kartu Nitro husus.
Dina dua taun ka hareup, jumlah jenis instan Nitro ngaleuwihan sababaraha belasan: A1, C5, M5, T3 jeung sajabana.
Jenis conto.
Kumaha mesin Nitro modern jalan
Aranjeunna gaduh tilu komponén utama: hypervisor Nitro (dibahas di luhur), chip kaamanan sareng kartu Nitro.
Chip kaamanan terpadu langsung kana motherboard nu. Ngadalikeun seueur fungsi penting, sapertos ngadalikeun beban OS host.
Kartu Nitro - Aya opat rupa di antarana. Sadayana dikembangkeun ku Annapurna Labs sareng didasarkeun kana ASIC umum. Sababaraha firmware maranéhanana ogé umum.
Opat jenis kartu Nitro.
Salah sahiji kartu dirancang pikeun digawekeun ku jaringanVPC. Ieu anu katingali dina mesin virtual salaku kartu jaringan ENA - Elastis Network adaptor. Éta ogé encapsulates lalulintas nalika ngirimkeunana ngaliwatan jaringan fisik (urang bakal ngobrol ngeunaan ieu dina bagian kadua artikel), ngadalikeun firewall Grup Kaamanan, sarta tanggung jawab routing sarta hal jaringan séjén.
Pilih kartu dianggo sareng panyimpen blok EBS jeung disk nu diwangun kana server. Aranjeunna muncul ka mesin virtual tamu salaku adaptor NVMe. Éta ogé tanggung jawab enkripsi data sareng ngawaskeun disk.
Sistem kartu Nitro, hypervisor sarta chip kaamanan terpadu kana jaringan SDN atawa Software Diartikeun Network. Tanggung jawab pikeun ngatur jaringan ieu (Control Plane) kartu controller.
Tangtu, urang neruskeun ngamekarkeun ASICs anyar. Salaku conto, dina ahir 2018 aranjeunna ngaluarkeun chip Inferentia, anu ngamungkinkeun anjeun damel langkung éfisién sareng tugas diajar mesin.
Inferentia Machine Learning Processor chip.
Database Scalable
Database tradisional ngagaduhan struktur berlapis. Pikeun nyederhanakeun pisan, tingkat di handap ieu dibédakeun.
- SQL - klien tur pamundut dispatchers dianggo dina eta.
- katangtuan transaksi - sadayana jelas di dieu, ASAM sareng sadayana.
- Caching, nu disadiakeun ku pools panyangga.
- logging - nyadiakeun gawé kalawan redo log. Dina MySQL aranjeunna disebut Bin Log, dina PosgreSQL - Tulis Ahead Log (WAL).
- neundeun - ngarékam langsung kana disk.
Struktur database berlapis.
Aya sababaraha cara pikeun skala database: sharding, arsitéktur Shared Euweuh, disk dibagikeun.
Sanajan kitu, sakabéh métode ieu ngajaga struktur database monolithic sarua. Ieu sacara signifikan ngawatesan skala. Pikeun ngajawab masalah ieu, urang ngembangkeun database urang sorangan - Amazon Aurora. Éta cocog sareng MySQL sareng PostgreSQL.
Amazon Aurora
Gagasan arsitéktur utama nyaéta pikeun misahkeun tingkat panyimpenan sareng logging tina pangkalan data utama.
Ningali payun, kuring bakal nyarios yén urang ogé ngadamel tingkat caching mandiri. Arsitéktur ceases jadi monolith a, sarta kami meunang gelar tambahan kabebasan dina skala blok individu.
Tingkat logging sareng neundeun dipisahkeun tina pangkalan data.
DBMS tradisional nyerat data kana sistem panyimpen dina bentuk blok. Di Amazon Aurora, kami nyiptakeun gudang pinter anu tiasa nyarios basa redo-logs. Di jero, panyimpen ngarobih log kana blok data, ngawas integritasna sareng otomatis nyadangkeun.
pendekatan ieu ngidinan Anjeun pikeun nerapkeun hal metot kayaning kloning. Gawéna fundamentally gancang sarta leuwih ékonomis alatan kanyataan yén teu merlukeun nyieun salinan lengkep sadaya data.
Lapisan gudang dilaksanakeun salaku sistem anu disebarkeun. Ieu diwangun ku angka nu gede ngarupakeun server fisik. Unggal log redo diolah sareng disimpen sakaligus genep knots. Ieu mastikeun panyalindungan data sareng kasaimbangan beban.
Skala bacaan tiasa dihontal nganggo réplika anu cocog. Panyimpenan anu disebarkeun ngaleungitkeun kabutuhan sinkronisasi antara conto pangkalan data utama, dimana urang nyerat data, sareng réplika sésana. Data up-to-date dijamin sadia ka sadaya réplika.
Hiji-hijina masalah nyaéta cache data heubeul dina réplika dibaca. Tapi masalah ieu keur direngsekeun mindahkeun sadaya log redo pikeun réplika ngaliwatan jaringan internal. Upami log aya dina cache, éta ditandaan salaku salah sareng ditimpa. Upami teu aya dina cache, éta ngan saukur dipiceun.
Urang nyortir kaluar gudang.
Kumaha skala tiers DBMS
Di dieu, skala horizontal leuwih hese. Ku kituna hayu urang turun jalur keok skala nangtung Palasik.
Anggap urang gaduh aplikasi anu komunikasi sareng DBMS ngalangkungan master node.
Nalika skala vertikal, kami alokasi titik anyar anu bakal gaduh langkung seueur prosesor sareng mémori.
Salajengna, urang ngalihkeun aplikasi tina titik master anu lami ka anu énggal. Masalah timbul.
- Ieu bakal merlukeun downtime aplikasi signifikan.
- The master node anyar bakal boga cache tiis. Kinerja database bakal maksimal ngan saatos cache parantos dipanaskeun.
Kumaha carana ningkatkeun kaayaan? Nyetél proxy antara aplikasi sareng master node.
Naon anu bakal masihan urang? Ayeuna sadaya aplikasi henteu kedah dialihkeun sacara manual ka titik énggal. Saklar tiasa dilakukeun dina proxy sareng dasarna langkung gancang.
Sigana masalahna parantos direngsekeun. Tapi henteu, urang masih kakurangan tina kabutuhan pikeun haneut nepi cache. Salaku tambahan, masalah anyar parantos muncul - ayeuna proxy mangrupikeun titik poténsial gagal.
Solusi ahir sareng Amazon Aurora tanpa server
Kumaha urang ngajawab masalah ieu?
Ninggalkeun proxy. Ieu sanés conto anu misah, tapi sakumpulan proksi anu disebarkeun ku aplikasi anu nyambung ka pangkalan data. Dina hal gagal, salah sahiji titik bisa diganti ampir instan.
Ditambahkeun kolam renang tina titik haneut tina ukuran anu béda. Ku alatan éta, lamun perlu pikeun allocate titik anyar tina ukuran nu leuwih gede atawa leuwih leutik, éta langsung sadia. Henteu kedah ngantosan éta dimuat.
Sakabéh prosés skala dikawasa ku sistem ngawaskeun khusus. Ngawaskeun terus-terusan ngawas kaayaan titik master ayeuna. Upami éta ngadeteksi, contona, yén beban prosesor parantos ngahontal nilai kritis, éta ngabéjaan kolam renang instansi anu haneut ngeunaan kabutuhan pikeun ngalokasikeun titik énggal.
Proxies disebarkeun, instansi haneut tur monitoring.
Hiji titik kalawan kakuatan diperlukeun sadia. pools panyangga disalin ka dinya, sarta sistem dimimitian ngadagoan momen aman switch.
Biasana momen pikeun pindah datang rada gancang. Teras komunikasi antara proxy sareng node master lami ditunda, sadaya sesi dialihkeun ka node énggal.
Gawe sareng database neruskeun.
Grafik nunjukkeun yén gantungna memang pondok pisan. Grafik biru nunjukkeun beban, sareng léngkah beureum nunjukkeun momen skala. Dips jangka pondok dina grafik biru persis nu reureuh pondok.
Ku jalan kitu, Amazon Aurora ngamungkinkeun anjeun pikeun ngahémat artos sareng mareuman pangkalan data nalika henteu dianggo, contona, dina sabtu minggu. Saatos ngeureunkeun beban, DB laun-laun ngirangan kakuatanana sareng mareuman sababaraha waktos. Nalika beban balik, éta bakal naek lancar deui.
Dina bagian salajengna carita ngeunaan alat Amazon, urang bakal ngobrol ngeunaan skala jaringan. Ngalanggan sarta tetep katala sangkan anjeun teu sono artikel.
on Vasily Pantyukhin bakal masihan laporan "" Naon pola desain pikeun sistem anu disebarkeun anu dianggo ku pamekar Amazon, naon alesan pikeun gagal jasa, naon arsitéktur basis sél, Gawé Konstan, Shuffle Sharding - éta bakal pikaresepeun. Kurang leuwih sabulan nepi ka konferensi - . 24 Oktober kanaékan harga ahir.
sumber: www.habr.com