Awan adalah seperti kotak ajaib - anda bertanya apa yang anda perlukan, dan sumber itu muncul entah dari mana. Mesin maya, pangkalan data, rangkaian - semua ini hanya milik anda. Terdapat penyewa awan lain, tetapi di Alam Semesta anda, anda adalah penguasa tunggal. Anda pasti bahawa anda akan sentiasa menerima sumber yang diperlukan, anda tidak mengambil kira sesiapa pun dan anda secara bebas menentukan seperti apa rangkaian itu. Bagaimanakah keajaiban ini berfungsi yang menjadikan awan memperuntukkan sumber secara elastik dan mengasingkan penyewa sepenuhnya daripada satu sama lain?
Awan AWS ialah sistem mega-super kompleks yang telah berkembang secara evolusi sejak 2006. Sebahagian daripada perkembangan ini berlaku Vasily Pantyukhin - Arkitek Perkhidmatan Web Amazon. Sebagai seorang arkitek, dia mendapat pandangan dalaman bukan sahaja pada hasil akhir, tetapi juga pada cabaran yang diatasi oleh AWS. Semakin besar pemahaman tentang cara sistem berfungsi, semakin besar kepercayaannya. Oleh itu, Vasily akan berkongsi rahsia perkhidmatan awan AWS. Di bawah ialah reka bentuk pelayan AWS fizikal, kebolehskalaan pangkalan data elastik, pangkalan data Amazon tersuai dan kaedah untuk meningkatkan prestasi mesin maya sambil mengurangkan harganya pada masa yang sama. Pengetahuan tentang pendekatan seni bina Amazon akan membantu anda menggunakan perkhidmatan AWS dengan lebih berkesan dan mungkin memberi anda idea baharu untuk membina penyelesaian anda sendiri.
Mengenai penceramah: Vasily Pantyukhin () bermula sebagai pentadbir Unix di syarikat .ru, bekerja pada perkakasan Sun Microsystem yang besar selama 6 tahun, dan mengkhutbahkan dunia tertumpu data di EMC selama 11 tahun. Ia secara semula jadi berkembang menjadi awan peribadi, dan pada 2017 beralih kepada awan awam. Kini dia memberikan nasihat teknikal untuk membantu hidup dan berkembang dalam awan AWS.
Penafian: semua di bawah adalah pendapat peribadi Vasily dan mungkin tidak bertepatan dengan kedudukan Perkhidmatan Web Amazon. Laporan yang berdasarkan artikel itu tersedia di saluran YouTube kami.
Mengapa saya bercakap tentang peranti Amazon?
Kereta pertama saya mempunyai transmisi manual. Ia sangat bagus kerana perasaan bahawa saya boleh memandu kereta dan mempunyai kawalan sepenuhnya ke atasnya. Saya juga suka bahawa saya sekurang-kurangnya secara kasar memahami prinsip operasinya. Sememangnya, saya membayangkan struktur kotak itu agak primitif - seperti kotak gear pada basikal.
Semuanya hebat, kecuali satu perkara - terperangkap dalam kesesakan lalu lintas. Nampaknya anda sedang duduk dan tidak melakukan apa-apa, tetapi anda sentiasa menukar gear, menekan klac, gas, brek - ia benar-benar membuatkan anda letih. Masalah kesesakan lalu lintas sebahagiannya diselesaikan apabila keluarga itu mendapat kereta automatik. Semasa memandu, saya sempat memikirkan sesuatu dan mendengar buku audio.
Satu lagi misteri muncul dalam hidup saya, kerana saya berhenti memahami cara kereta saya berfungsi. Kereta moden adalah peranti yang kompleks. Kereta itu menyesuaikan secara serentak dengan berpuluh-puluh parameter yang berbeza: menekan gas, brek, gaya pemanduan, kualiti jalan. Saya tidak faham bagaimana ia berfungsi lagi.
Apabila saya mula bekerja di awan Amazon, ia juga menjadi misteri kepada saya. Hanya misteri ini adalah urutan magnitud yang lebih besar, kerana terdapat seorang pemandu di dalam kereta, dan dalam AWS terdapat berjuta-juta daripada mereka. Semua pengguna mengemudi, menekan gas dan brek serentak. Sungguh menakjubkan bahawa mereka pergi ke mana-mana yang mereka mahu - itu satu keajaiban kepada saya! Sistem ini secara automatik menyesuaikan, menskala dan menyesuaikan secara elastik kepada setiap pengguna supaya nampaknya dia bersendirian di Alam Semesta ini.
Keajaiban itu hilang sedikit apabila saya kemudiannya bekerja sebagai arkitek di Amazon. Saya melihat masalah yang kami hadapi, cara kami menyelesaikannya, dan cara kami membangunkan perkhidmatan. Dengan peningkatan pemahaman tentang cara sistem berfungsi, lebih keyakinan dalam perkhidmatan muncul. Jadi saya ingin berkongsi gambar apa yang ada di bawah hud awan AWS.
Apa yang akan kita bincangkan
Saya memilih pendekatan yang pelbagai - saya memilih 4 perkhidmatan menarik yang patut dibincangkan.
Pengoptimuman pelayan. Awan fana dengan penjelmaan fizikal: pusat data fizikal di mana terdapat pelayan fizikal yang bersenandung, memanaskan dan berkelip dengan lampu.
Fungsi tanpa pelayan (Lambda) mungkin merupakan perkhidmatan yang paling berskala dalam awan.
Penskalaan pangkalan data. Saya akan memberitahu anda tentang cara kami membina pangkalan data boleh skala kami sendiri.
Penskalaan rangkaian. Bahagian terakhir di mana saya akan membuka peranti rangkaian kami. Ini adalah perkara yang menarik - setiap pengguna awan percaya bahawa dia bersendirian di awan dan tidak melihat penyewa lain sama sekali.
Catatan. Artikel ini akan membincangkan pengoptimuman pelayan dan penskalaan pangkalan data. Kami akan mempertimbangkan penskalaan rangkaian dalam artikel seterusnya. Di manakah fungsi tanpa pelayan? Transkrip berasingan telah diterbitkan mengenai mereka "" Ia membincangkan beberapa kaedah penskalaan yang berbeza, dan membincangkan secara terperinci penyelesaian Mercun - simbiosis kualiti terbaik mesin dan bekas maya.
Pelayan
Awan tidak kekal. Tetapi kefanaan ini masih mempunyai penjelmaan fizikal - pelayan. Pada mulanya, seni bina mereka adalah klasik. Set cip x86 standard, kad rangkaian, Linux, hipervisor Xen di mana mesin maya dijalankan.
Pada tahun 2012, seni bina ini mengatasi tugasnya dengan baik. Xen ialah hypervisor yang hebat, tetapi ia mempunyai satu kelemahan utama. Dia sudah cukup overhed tinggi untuk emulasi peranti. Apabila kad rangkaian atau pemacu SSD baharu yang lebih pantas tersedia, overhed ini menjadi terlalu tinggi. Bagaimana untuk menangani masalah ini? Kami memutuskan untuk bekerja pada dua bidang sekaligus - mengoptimumkan kedua-dua perkakasan dan hipervisor. Tugas itu sangat serius.
Mengoptimumkan perkakasan dan hipervisor
Melakukan semuanya sekaligus dan melakukannya dengan baik tidak akan berhasil. Apa yang "baik" itu juga tidak jelas pada mulanya.
Kami memutuskan untuk mengambil pendekatan evolusi - kami menukar satu elemen penting seni bina dan membuangnya ke dalam pengeluaran.
Kami memijak setiap garu, mendengar keluhan dan cadangan. Kemudian kita menukar komponen lain. Jadi, dalam kenaikan kecil, kami mengubah keseluruhan seni bina secara radikal berdasarkan maklum balas daripada pengguna dan sokongan.
Transformasi bermula pada tahun 2013 dengan perkara yang paling kompleks - rangkaian. DALAM C3 contoh, kad Pemecut Rangkaian khas telah ditambahkan pada kad rangkaian standard. Ia disambungkan secara literal dengan kabel gelung belakang pendek pada panel hadapan. Ia tidak cantik, tetapi ia tidak kelihatan di awan. Tetapi interaksi langsung dengan perkakasan secara asasnya meningkatkan jitter dan daya pemprosesan rangkaian.
Seterusnya kami memutuskan untuk menambah baik akses kepada menyekat storan data EBS - Elastic Block Storage. Ia adalah gabungan rangkaian dan storan. Kesukarannya ialah walaupun kad Pemecut Rangkaian wujud di pasaran, tidak ada pilihan untuk membeli perkakasan Pemecut Storan. Jadi kami beralih kepada permulaan Makmal Annapurna, yang membangunkan cip ASIC khas untuk kami. Mereka membenarkan volum EBS jauh untuk dipasang sebagai peranti NVMe.
Dalam keadaan C4 kami menyelesaikan dua masalah. Yang pertama ialah kami melaksanakan asas untuk masa depan yang menjanjikan, tetapi baru pada masa itu, teknologi NVMe. Kedua, kami memunggah pemproses pusat dengan ketara dengan memindahkan pemprosesan permintaan kepada EBS ke kad baharu. Ia ternyata baik, jadi kini Annapurna Labs adalah sebahagian daripada Amazon.
Menjelang November 2017, kami menyedari bahawa sudah tiba masanya untuk menukar hipervisor itu sendiri.
Hipervisor baharu telah dibangunkan berdasarkan modul kernel KVM yang diubah suai.
Ia membolehkan untuk mengurangkan overhed emulasi peranti secara asas dan berfungsi secara langsung dengan ASIC baharu. Contoh C5 ialah mesin maya pertama dengan hypervisor baharu yang berjalan di bawah hud. Kami namakan dia Nitro.
Evolusi kejadian pada garis masa.
Semua jenis mesin maya baharu yang telah muncul sejak November 2017 dijalankan pada hipervisor ini. Contoh Bare Metal tidak mempunyai hypervisor, tetapi mereka juga dipanggil Nitro, kerana mereka menggunakan kad Nitro khusus.
Dalam tempoh dua tahun akan datang, bilangan jenis kejadian Nitro melebihi beberapa dozen: A1, C5, M5, T3 dan lain-lain.
Jenis contoh.
Cara mesin Nitro moden berfungsi
Mereka mempunyai tiga komponen utama: hipervisor Nitro (dibincangkan di atas), cip keselamatan dan kad Nitro.
Cip keselamatan disepadukan terus ke dalam papan induk. Ia mengawal banyak fungsi penting, seperti mengawal pemuatan OS hos.
Kad Nitro - Terdapat empat jenis daripadanya. Kesemuanya dibangunkan oleh Annapurna Labs dan berdasarkan ASIC biasa. Sesetengah perisian tegar mereka juga biasa.
Empat jenis kad Nitro.
Salah satu kad direka bentuk untuk digunakan rangkaianVPC. Inilah yang boleh dilihat dalam mesin maya sebagai kad rangkaian ENA - Penyesuai Rangkaian Anjal. Ia juga merangkum trafik apabila menghantarnya melalui rangkaian fizikal (kita akan membincangkan perkara ini dalam bahagian kedua artikel), mengawal tembok api Kumpulan Keselamatan dan bertanggungjawab untuk penghalaan dan perkara rangkaian lain.
Pilih kad berfungsi dengan storan blok EBS dan cakera yang dibina ke dalam pelayan. Mereka kelihatan kepada mesin maya tetamu sebagai Penyesuai NVMe. Mereka juga bertanggungjawab untuk penyulitan data dan pemantauan cakera.
Sistem kad Nitro, hipervisor dan cip keselamatan disepadukan ke dalam rangkaian SDN atau Rangkaian Ditakrifkan Perisian. Bertanggungjawab untuk menguruskan rangkaian ini (Pesawat Kawalan) kad pengawal.
Sudah tentu, kami terus membangunkan ASIC baharu. Sebagai contoh, pada penghujung tahun 2018 mereka mengeluarkan cip Inferentia, yang membolehkan anda bekerja dengan lebih cekap dengan tugasan pembelajaran mesin.
Cip Pemproses Pembelajaran Mesin Inferentia.
Pangkalan Data Berskala
Pangkalan data tradisional mempunyai struktur berlapis. Untuk memudahkan, tahap berikut dibezakan.
- SQL — pelanggan dan penghantar permintaan bekerja padanya.
- Peruntukan urus niaga - semuanya jelas di sini, ASID dan semua itu.
- Caching, yang disediakan oleh kolam penampan.
- Pembalakan — menyediakan kerja dengan log buat semula. Dalam MySQL mereka dipanggil Log Bin, dalam PosgreSQL - Tulis Log Ahead (WAL).
- Penyimpanan – rakaman terus ke cakera.
Struktur pangkalan data berlapis.
Terdapat pelbagai cara untuk menskala pangkalan data: sharding, seni bina Tiada Kongsi, cakera kongsi.
Walau bagaimanapun, semua kaedah ini mengekalkan struktur pangkalan data monolitik yang sama. Ini mengehadkan penskalaan dengan ketara. Untuk menyelesaikan masalah ini, kami membangunkan pangkalan data kami sendiri − Amazon Aurora. Ia serasi dengan MySQL dan PostgreSQL.
Amazon Aurora
Idea seni bina utama adalah untuk memisahkan tahap penyimpanan dan pembalakan daripada pangkalan data utama.
Memandang ke hadapan, saya akan mengatakan bahawa kami juga menjadikan tahap caching bebas. Seni bina tidak lagi menjadi monolit, dan kami memperoleh darjah kebebasan tambahan dalam menskala blok individu.
Tahap pembalakan dan penyimpanan adalah berasingan daripada pangkalan data.
DBMS tradisional menulis data ke sistem storan dalam bentuk blok. Di Amazon Aurora, kami mencipta storan pintar yang boleh bercakap bahasa buat semula log. Di dalam, storan menukar log menjadi blok data, memantau integritinya dan membuat sandaran secara automatik.
Pendekatan ini membolehkan anda melaksanakan perkara yang menarik seperti pengklonan. Ia berfungsi secara asasnya lebih pantas dan lebih menjimatkan kerana fakta bahawa ia tidak memerlukan membuat salinan lengkap semua data.
Lapisan storan dilaksanakan sebagai sistem teragih. Ia terdiri daripada bilangan pelayan fizikal yang sangat besar. Setiap log buat semula diproses dan disimpan serentak enam simpulan. Ini memastikan perlindungan data dan pengimbangan beban.
Penskalaan bacaan boleh dicapai menggunakan replika yang sesuai. Storan teragih menghapuskan keperluan untuk penyegerakan antara contoh pangkalan data utama, yang melaluinya kami menulis data, dan replika yang tinggal. Data terkini dijamin tersedia untuk semua replika.
Satu-satunya masalah ialah menyimpan data lama pada replika yang dibaca. Tetapi masalah ini sedang diselesaikan pemindahan semua log buat semula kepada replika melalui rangkaian dalaman. Jika log berada dalam cache, ia ditandakan sebagai tidak betul dan ditulis ganti. Jika ia tiada dalam cache, ia dibuang begitu sahaja.
Kami menyusun storan.
Bagaimana untuk menskalakan peringkat DBMS
Di sini, penskalaan mendatar adalah lebih sukar. Jadi mari kita pergi ke jalan yang dipukul penskalaan menegak klasik.
Mari kita anggap bahawa kita mempunyai aplikasi yang berkomunikasi dengan DBMS melalui nod induk.
Apabila menskala secara menegak, kami memperuntukkan nod baharu yang akan mempunyai lebih banyak pemproses dan memori.
Seterusnya, kami menukar aplikasi daripada nod induk lama kepada yang baharu. Masalah timbul.
- Ini memerlukan masa henti aplikasi yang ketara.
- Nod induk baharu akan mempunyai cache sejuk. Prestasi pangkalan data akan menjadi maksimum hanya selepas cache dipanaskan.
Bagaimana untuk memperbaiki keadaan? Sediakan proksi antara aplikasi dan nod induk.
Apakah ini akan memberi kita? Kini semua aplikasi tidak perlu diubah hala secara manual ke nod baharu. Suis boleh dilakukan di bawah proksi dan pada asasnya lebih pantas.
Nampaknya masalah itu telah selesai. Tetapi tidak, kami masih mengalami keperluan untuk memanaskan cache. Di samping itu, masalah baru telah muncul - kini proksi adalah titik kegagalan yang berpotensi.
Penyelesaian akhir dengan Amazon Aurora tanpa pelayan
Bagaimanakah kami menyelesaikan masalah ini?
Meninggalkan proksi. Ini bukan contoh yang berasingan, tetapi keseluruhan kumpulan proksi yang diedarkan melalui mana aplikasi menyambung ke pangkalan data. Sekiranya berlaku kegagalan, mana-mana nod boleh diganti hampir serta-merta.
Menambah kumpulan nod hangat pelbagai saiz. Oleh itu, jika perlu untuk memperuntukkan nod baharu dengan saiz yang lebih besar atau lebih kecil, ia boleh didapati dengan serta-merta. Tidak perlu menunggu untuk dimuatkan.
Keseluruhan proses penskalaan dikawal oleh sistem pemantauan khas. Pemantauan sentiasa memantau keadaan nod induk semasa. Jika ia mengesan, sebagai contoh, bahawa beban pemproses telah mencapai nilai kritikal, ia memberitahu kumpulan kejadian hangat tentang keperluan untuk memperuntukkan nod baharu.
Proksi yang diedarkan, contoh hangat dan pemantauan.
Nod dengan kuasa yang diperlukan tersedia. Kolam penimbal disalin kepadanya, dan sistem mula menunggu masa yang selamat untuk bertukar.
Biasanya masa untuk bertukar datang agak cepat. Kemudian komunikasi antara proksi dan nod induk lama digantung, semua sesi ditukar kepada nod baharu.
Bekerja dengan resume pangkalan data.
Graf menunjukkan bahawa penggantungan itu sememangnya sangat pendek. Graf biru menunjukkan beban, dan langkah merah menunjukkan momen penskalaan. Penurunan jangka pendek dalam graf biru adalah tepat pada kelewatan yang singkat itu.
Dengan cara ini, Amazon Aurora membolehkan anda menjimatkan wang sepenuhnya dan mematikan pangkalan data apabila ia tidak digunakan, contohnya, pada hujung minggu. Selepas menghentikan beban, DB secara beransur-ansur mengurangkan kuasanya dan dimatikan untuk beberapa lama. Apabila beban kembali, ia akan naik semula dengan lancar.
Dalam bahagian seterusnya cerita tentang peranti Amazon, kita akan bercakap tentang penskalaan rangkaian. Langgan dan teruskan menonton supaya anda tidak terlepas artikel.
Pada Vasily Pantyukhin akan memberikan laporan "" Apakah corak reka bentuk untuk sistem teragih yang digunakan oleh pemaju Amazon, apakah sebab kegagalan perkhidmatan, apakah seni bina berasaskan Sel, Kerja Malar, Shuffle Sharding - ia akan menjadi menarik. Kurang daripada sebulan sehingga persidangan - . 24 Oktober kenaikan harga akhir.
Sumber: www.habr.com