Awan seperti kotak ajaib - Anda bertanya apa yang Anda butuhkan, dan sumber daya muncul begitu saja. Mesin virtual, basis data, jaringan - semua ini hanya milik Anda. Ada penyewa lain dari awan, tetapi di alam semesta Anda, Anda adalah satu-satunya penguasa. Anda yakin bahwa Anda akan selalu menerima sumber daya yang diperlukan, Anda tidak memperhitungkan siapa pun dan secara independen menentukan apa jaringannya. Bagaimana keajaiban ini yang membuat cloud mengalokasikan sumber daya secara elastis dan benar-benar mengisolasi penyewa dari satu sama lain?
AWS Cloud adalah sistem mega-canggih yang telah berkembang sejak 2006. Bagian dari perkembangan ini ditemukan oleh
Vasily Pantyukhin , arsitek Amazon Web Services. Sebagai seorang arsitek, dia melihat dari dalam bukan hanya hasil akhir, tetapi juga tantangan yang AWS atasi. Semakin banyak pemahaman tentang sistem, semakin percaya diri. Karenanya, Vasily akan berbagi rahasia layanan cloud AWS. Di bawah potongan adalah perangkat untuk server fisik AWS, skalabilitas basis data yang fleksibel, basis data Amazon kustom dan metode untuk meningkatkan kinerja mesin virtual sekaligus mengurangi harga mereka. Pengetahuan tentang pendekatan arsitektur Amazon akan membantu Anda memanfaatkan layanan AWS dengan lebih baik dan dapat memberikan ide-ide baru untuk membangun solusi Anda sendiri.
Tentang Pembicara: Vasily Pantyukhin ( Hen ) dimulai sebagai perusahaan admin inix Unix, menghabiskan 6 tahun bekerja di kelenjar Sun Microsystem yang besar, dan selama 11 tahun ia mengkhotbahkan data-sentrisitas dunia di EMC. Secara alami berkembang menjadi awan pribadi, dan pada 2017 berubah menjadi awan publik. Sekarang dengan tips teknis, ia membantu untuk hidup dan berkembang di cloud AWS.
Penafian: Segala sesuatu di bawah ini adalah pendapat pribadi Vasily, dan itu mungkin tidak sesuai dengan posisi Amazon Web Services. Video laporan berdasarkan artikel yang dibuat tersedia di saluran YouTube kami.Mengapa saya berbicara tentang perangkat Amazon
Mobil pertama saya dengan "pegangan" - pada gearbox manual. Itu hebat karena perasaan bahwa saya bisa mengendalikan mesin dan sepenuhnya mengendalikannya. Saya juga suka bahwa setidaknya saya secara kasar memahami prinsip pekerjaannya. Secara alami, saya membayangkan perangkat kotak cukup primitif - kira-kira seperti gearbox pada sepeda.
Semuanya indah, kecuali satu hal - berdiri di tengah kemacetan. Sepertinya Anda sedang duduk dan tidak melakukan apa-apa, tetapi Anda terus-menerus menggeser persneling, menekan kopling, gas, rem - Anda benar-benar bosan. Masalah kemacetan lalu lintas sebagian diselesaikan ketika sebuah mesin muncul di mesin dalam keluarga. Di belakang kemudi ada waktu untuk memikirkan sesuatu, mendengarkan buku audio.
Sebuah misteri muncul dalam hidup saya, karena saya biasanya tidak lagi mengerti cara kerja mobil saya. Mobil modern adalah perangkat yang kompleks. Mobil menyesuaikan secara bersamaan dengan puluhan parameter yang berbeda: menekan gas, rem, gaya mengemudi, kualitas jalan. Saya tidak lagi mengerti cara kerjanya.
Ketika saya mulai melakukan Amazon Cloud, itu juga merupakan misteri bagi saya. Hanya rahasia ini yang urutan besarnya lebih tinggi, karena ada satu pengemudi di mobil, dan ada jutaan AWS. Semua pengguna secara bersamaan menyetir, tekan gas dan rem. Sungguh menakjubkan mereka pergi ke mana pun mereka inginkan - bagi saya itu adalah keajaiban! Sistem secara otomatis beradaptasi, berskala, dan secara fleksibel menyesuaikan diri dengan setiap pengguna sehingga ia merasa sendirian di alam semesta ini.
Keajaiban menghilang sedikit ketika saya kemudian datang untuk bekerja sebagai arsitek di Amazon. Saya melihat masalah apa yang kita hadapi, bagaimana kita menyelesaikannya, bagaimana kita mengembangkan layanan. Dengan meningkatnya pemahaman tentang sistem, ada lebih banyak kepercayaan dalam layanan. Jadi saya ingin berbagi gambar apa yang ada di bawah awan AWS.
Apa yang akan kita bicarakan?
Saya memilih pendekatan yang beragam - saya memilih 4 layanan menarik yang layak dibicarakan.
Optimasi server . Awan Ephemeral dengan perwujudan fisik: pusat data fisik, di mana ada server fisik yang berdengung, pemanasan dan lampu berkedip.
Fungsi serverless (Lambda) mungkin adalah layanan yang paling scalable di cloud.
Penskalaan basis data . Saya akan berbicara tentang bagaimana kita membangun basis data yang dapat diskalakan sendiri.
Penskalaan jaringan . Bagian terakhir di mana saya akan membuka perangkat jaringan kami. Ini adalah hal yang luar biasa - setiap pengguna cloud percaya bahwa ia sendirian di cloud dan tidak melihat penyewa lain sama sekali.
Catatan Artikel ini akan fokus pada pengoptimalan server dan penskalaan basis data. Penskalaan jaringan akan dibahas pada artikel selanjutnya. Di mana fungsi tanpa server? Transkrip terpisah keluar tentang mereka: “ Mal, ya berani. Anboxing microvirtuals Petasan . " Ini berbicara tentang beberapa cara penskalaan, dan solusi Petasan dianalisis secara rinci - simbiosis kualitas terbaik dari mesin dan wadah virtual.
Server
Awan itu fana. Tetapi kesementaraan ini masih memiliki perwujudan fisik - server. Awalnya, arsitektur mereka klasik. Chipset x86 standar, kartu jaringan, Linux, Xen hypervisor, yang menjalankan mesin virtual.
Pada 2012, arsitektur seperti itu melakukan tugasnya dengan baik. Xen adalah hypervisor yang hebat, tetapi dengan satu kelemahan utama. Dia memiliki
overhead yang cukup
tinggi untuk meniru perangkat . Dengan munculnya kartu jaringan atau SSD baru yang lebih cepat, overhead ini menjadi terlalu tinggi. Bagaimana cara mengatasi masalah ini? Kami memutuskan untuk bekerja di dua bidang sekaligus - untuk
mengoptimalkan perangkat keras dan hypervisor . Tugasnya sangat serius.
Optimalisasi zat besi dan hypervisor
Melakukan semuanya sekaligus dan baik tidak akan berhasil. Apa yang "baik" pada awalnya tidak bisa dipahami.
Kami memutuskan untuk menerapkan pendekatan evolusi - kami mengubah satu elemen penting arsitektur dan membuangnya ke dalam produksi.
Kami menginjak semua garu, mendengarkan keluhan dan saran. Lalu kami mengubah komponen lain. Jadi, sedikit demi sedikit, kami mengubah seluruh arsitektur secara radikal berdasarkan umpan balik dan dukungan pengguna.
Transformasi dimulai pada 2013 dengan hal yang paling sulit - jaringan. Dalam kasus
C3 , kartu Network Accelerator khusus ditambahkan ke kartu jaringan standar. Itu terhubung dengan kabel loopback pendek harfiah di panel depan. Jelek, tapi tidak terlihat di awan. Tetapi interaksi langsung dengan perangkat keras secara fundamental meningkatkan jitter dan bandwidth jaringan.
Kemudian kami memutuskan untuk fokus pada peningkatan akses ke penyimpanan blok EBS - Elastic Block Storage. Ini adalah kombinasi dari jaringan dan penyimpanan. Kesulitannya adalah bahwa jika kartu Network Accelerator ada di pasaran, tidak ada cara untuk hanya membeli perangkat keras Storage Accelerator. Karena itu, kami beralih ke startup
Annapurna Labs , yang mengembangkan chip ASIC khusus untuk kami. Mereka memungkinkan Anda untuk menghubungkan volume EBS jarak jauh sebagai perangkat NVMe.
Dalam kasus
C4 , kami memecahkan dua masalah. Pertama, kami mengimplementasikan landasan untuk masa depan dengan teknologi NVMe yang menjanjikan, tetapi baru pada saat itu. Yang kedua - secara signifikan menurunkan prosesor pusat dengan mentransfer pemrosesan permintaan ke EBS ke kartu baru. Ternyata dengan baik, jadi sekarang Annapurna Labs adalah bagian dari Amazon.
Pada November 2017, kami menyadari bahwa sudah waktunya untuk mengubah hypervisor itu sendiri.
Hypervisor baru dikembangkan berdasarkan modul kernel KVM yang dimodifikasi.
Ini memungkinkan untuk secara fundamental mengurangi biaya overhead perangkat meniru dan bekerja secara langsung dengan ASIC baru. Mesin virtual
C5 adalah mesin virtual pertama di bawah kap mesin yang menjalankan hypervisor baru. Kami menyebutnya
Nitro .
Evolusi instance pada timeline.Semua jenis mesin virtual baru yang muncul sejak November 2017 berfungsi pada hypervisor ini.
Contoh Iron Bare Metal tidak memiliki hypervisor , tetapi mereka juga disebut Nitro, karena mereka menggunakan kartu Nitro khusus.
Selama dua tahun berikutnya, jumlah jenis contoh Nitro melebihi beberapa lusin: A1, C5, M5, T3, dan lainnya.
Jenis Instances.Cara kerja mobil nitro modern
Mereka memiliki tiga komponen utama: Nitro hypervisor (dibahas di atas), sebuah chip keamanan, dan kartu Nitro.
Chip keamanan terintegrasi langsung ke motherboard. Ini mengontrol banyak fungsi penting, misalnya, mengendalikan pemuatan OS host.
Kartu Nitro - ada empat jenis
kartu . Semua dikembangkan oleh Annapurna Labs dan didasarkan pada ASIC umum. Bagian dari firmware mereka juga umum.
Empat jenis kartu nitro.Salah satu kartu dirancang untuk bekerja dengan
jaringan VPC . Dialah yang terlihat di
mesin virtual sebagai kartu jaringan
ENA - Elastic Network Adapter . Itu juga merangkum lalu lintas ketika ditransmisikan melalui jaringan fisik (kita akan membicarakan hal ini di bagian kedua artikel), mengontrol firewall Grup Keamanan, bertanggung jawab untuk perutean dan hal-hal jaringan lainnya.
Kartu terpisah berfungsi dengan penyimpanan blok
EBS dan disk yang dibangun ke dalam server. Mereka disajikan ke mesin virtual tamu sebagai
adapter NVMe . Mereka juga bertanggung jawab untuk enkripsi data dan pemantauan disk.
Sistem kartu Nitro, hypervisor, dan chip keamanan terintegrasi ke dalam SDN atau
Software Defined Network .
Kartu kontrol bertanggung jawab untuk mengelola jaringan ini (Control Plane).
Tentu saja, kami terus mengembangkan ASIC baru. Sebagai contoh, pada akhir 2018, mereka merilis chip Inferentia, yang memungkinkan pekerjaan yang lebih efisien dengan tugas pembelajaran mesin.
Chip Prosesor Pembelajaran Mesin Inferentia.Database yang dapat diukur
Basis data tradisional memiliki struktur berlapis. Jika sangat disederhanakan, level berikut dibedakan.
- SQL - client dan dispatcher kueri mengerjakannya.
- Mengamankan transaksi - semuanya jelas di sini, ACID dan semua itu.
- Caching disediakan oleh buffer pool.
- Logging - menyediakan pekerjaan dengan redo-log. Di MySQL mereka disebut Bin Log, di PosgreSQL mereka disebut Write Ahead Logs (WAL).
- Penyimpanan - langsung menulis ke disk.
Struktur basis data berlapis.Ada berbagai cara untuk skala basis data: sharding, arsitektur Shared Nothing, shared drive.
Namun, semua metode ini mempertahankan struktur database monolitik yang sama. Ini secara signifikan membatasi penskalaan. Untuk mengatasi masalah ini, kami mengembangkan basis data kami sendiri -
Amazon Aurora . Ini kompatibel dengan MySQL dan PostgreSQL.
Amazon aurora
Gagasan arsitektur utama adalah untuk membagi tingkat penyimpanan dan pencatatan dari basis data utama.
Ke depan, saya akan mengatakan bahwa kami juga membuat level cache independen. Arsitektur berhenti menjadi monolit, dan kami mendapatkan derajat kebebasan tambahan dalam menentukan skala blok individu.
Level logging dan penyimpanan terpisah dari database.DBMS tradisional menulis data ke sistem penyimpanan dalam bentuk blok. Di Amazon Aurora, kami menciptakan repositori “pintar” yang dapat berbicara bahasa
redo-log . Di dalam, repositori mengubah log menjadi blok data, memonitor integritasnya dan secara otomatis membuat cadangan.
Pendekatan ini memungkinkan Anda untuk menerapkan hal-hal menarik seperti
kloning . Ini bekerja secara fundamental lebih cepat dan lebih ekonomis karena fakta bahwa itu tidak memerlukan pembuatan salinan lengkap dari semua data.
Tingkat penyimpanan diimplementasikan sebagai sistem terdistribusi. Ini terdiri dari sejumlah besar server fisik. Setiap redo-log diproses dan disimpan secara bersamaan oleh
enam node . Ini memberikan perlindungan data dan keseimbangan beban.
Pembacaan skala dapat dicapai menggunakan replika yang sesuai. Penyimpanan terdistribusi menghilangkan kebutuhan untuk sinkronisasi antara instance DB utama di mana kita menulis data dan replika lainnya. Data saat ini dijamin akan tersedia untuk semua replika.
Satu-satunya masalah adalah caching data lama pada replika baca. Tetapi masalah ini diselesaikan dengan
mentransfer semua redo-log ke replika di jaringan internal. Jika log ada dalam cache, maka itu ditandai sebagai tidak valid dan ditimpa. Jika tidak ada dalam cache, maka itu hanya dibuang.
Kami menemukan penyimpanannya.
Bagaimana skala tingkat DBMS
Di sini penskalaan horizontal jauh lebih sulit dilakukan. Oleh karena itu, mari kita mulai jalur
skala vertikal klasik .
Misalkan kita memiliki aplikasi yang berkomunikasi dengan DBMS melalui master node.
Dengan penskalaan vertikal, kami memilih simpul baru yang akan memiliki lebih banyak prosesor dan memori.
Selanjutnya, alihkan aplikasi dari node master lama ke yang baru. Ada masalah.
- Ini akan membutuhkan waktu henti aplikasi yang nyata.
- Node master baru akan memiliki cache dingin. Kinerja basis data akan maksimal hanya setelah cache memanas.
Bagaimana cara memperbaiki situasi? Letakkan proksi antara aplikasi dan master node.
Apa yang akan memberi kita? Sekarang semua aplikasi tidak perlu diarahkan secara manual ke node baru. Perpindahan dapat dilakukan di bawah proxy dan pada saat yang sama secara fundamental lebih cepat.
Masalahnya tampaknya diselesaikan. Tapi tidak, kami masih menderita karena harus memanaskan cache. Selain itu, masalah baru telah muncul - sekarang proksi adalah titik kegagalan potensial.
Solusi Akhir dengan Amazon Aurora Serverless
Bagaimana kita mengatasi masalah ini?
Meninggalkan proxy . Ini bukan contoh terpisah, tetapi seluruh armada proxy yang didistribusikan di mana aplikasi terhubung ke database. Jika terjadi kegagalan, salah satu node dapat diganti hampir secara instan.
Kami menambahkan kumpulan node hangat dengan berbagai ukuran . Oleh karena itu, jika Anda perlu memilih simpul baru dengan ukuran yang lebih besar atau lebih kecil, segera tersedia. Tidak perlu menunggu sampai memuat.
Seluruh proses penskalaan dikendalikan oleh sistem pemantauan khusus. Pemantauan terus-menerus memonitor status node master saat ini. Jika mendeteksi, misalnya, bahwa beban prosesor telah mencapai nilai kritis, itu memberitahukan kumpulan contoh hangat dari kebutuhan untuk mengalokasikan node baru.
Proxy terdistribusi, instance hangat dan pemantauan.Node daya yang dibutuhkan tersedia. Buffer pools disalin ke sana, dan sistem mulai menunggu saat yang aman untuk beralih.
Biasanya momen untuk berganti cukup cepat. Kemudian komunikasi antara proxy dan node master lama ditangguhkan, semua sesi beralih ke node baru.
Bekerja dengan resume database.
Grafik menunjukkan bahwa penskorsan sangat pendek. Pada grafik biru, beban, dan pada langkah merah - saat penskalaan. Penurunan jangka pendek dalam grafik biru adalah penundaan singkat tersebut.
Omong-omong, Amazon Aurora memungkinkan Anda untuk sepenuhnya menyimpan dan mematikan basis data saat tidak digunakan, misalnya, pada akhir pekan. Setelah menghentikan beban, database secara bertahap mengurangi kekuatannya dan mati untuk sementara waktu. Ketika beban kembali, itu akan kembali naik dengan lancar.
Di bagian selanjutnya dari pembicaraan perangkat Amazon, kita akan berbicara tentang penskalaan jaringan. Berlangganan buletin dan tetap disini agar tidak ketinggalan artikel.
Di HighLoad ++, Vasily Pantyukhin akan memberikan presentasi “ Houston, kami memiliki masalah. Desain sistem kegagalan, pola pengembangan layanan internal cloud Amazon . " Apa yang pengembang desain Amazon menggunakan pola desain sistem terdistribusi, apa alasan kegagalan layanan, apa itu arsitektur berbasis sel, Pekerjaan Konstan, Shuffle Sharding - itu akan menarik. Kurang dari sebulan sebelum konferensi - pesan tiket Anda . 24 Oktober, kenaikan harga akhir.