Awan bagaikan kotak ajaib - Anda menanyakan apa yang Anda perlukan, dan sumber daya muncul begitu saja. Mesin virtual, database, jaringan - semua ini hanya milik Anda. Ada penyewa cloud lainnya, tetapi di Semesta Anda, Anda adalah satu-satunya penguasa. Anda yakin bahwa Anda akan selalu menerima sumber daya yang diperlukan, Anda tidak memperhitungkan siapa pun dan Anda sendiri yang menentukan seperti apa jaringan itu nantinya. Bagaimana cara kerja keajaiban yang membuat cloud mengalokasikan sumber daya secara elastis dan sepenuhnya mengisolasi penyewa satu sama lain?
AWS cloud adalah sistem mega-super kompleks yang telah berkembang secara evolusioner sejak tahun 2006. Sebagian dari perkembangan ini terjadi Vasily Pantyukhin - Arsitek Layanan Web Amazon. Sebagai seorang arsitek, dia melihat ke dalam tidak hanya hasil akhirnya, namun juga tantangan yang diatasi AWS. Semakin besar pemahaman tentang cara kerja sistem, semakin besar kepercayaannya. Oleh karena itu, Vasily akan membagikan rahasia layanan cloud AWS. Di bawah ini adalah desain server AWS fisik, skalabilitas basis data elastis, basis data Amazon khusus, dan metode untuk meningkatkan kinerja mesin virtual sekaligus mengurangi harganya. Pengetahuan tentang pendekatan arsitektur Amazon akan membantu Anda menggunakan layanan AWS secara lebih efektif dan mungkin memberi Anda ide-ide baru untuk membangun solusi Anda sendiri.
Tentang pembicara: Vasily Pantyukhin () dimulai sebagai admin Unix di perusahaan .ru, bekerja pada perangkat keras Sun Microsystem besar selama 6 tahun, dan mengkhotbahkan dunia yang berpusat pada data di EMC selama 11 tahun. Secara alami, cloud berevolusi menjadi cloud pribadi, dan pada tahun 2017 dipindahkan ke cloud publik. Kini dia memberikan saran teknis untuk membantu hidup dan berkembang di AWS cloud.
Penafian: semua yang di bawah ini adalah pendapat pribadi Vasily dan mungkin tidak sesuai dengan posisi Amazon Web Services. Laporan yang menjadi dasar artikel ini tersedia di saluran YouTube kami.
Mengapa saya berbicara tentang perangkat Amazon?
Mobil pertama saya memiliki transmisi manual. Itu luar biasa karena saya merasa bisa mengemudikan mobil dan memiliki kendali penuh atas mobil tersebut. Saya juga suka karena saya setidaknya memahami secara kasar prinsip pengoperasiannya. Tentu saja, saya membayangkan struktur kotaknya cukup primitif - seperti girboks pada sepeda.
Semuanya baik-baik saja, kecuali satu hal - terjebak kemacetan. Sepertinya Anda sedang duduk dan tidak melakukan apa-apa, tetapi Anda terus-menerus mengganti persneling, menekan kopling, gas, rem - itu benar-benar membuat Anda lelah. Masalah kemacetan sebagian teratasi ketika keluarga tersebut mendapatkan mobil matic. Saat mengemudi, saya punya waktu untuk memikirkan sesuatu dan mendengarkan buku audio.
Misteri lain muncul dalam hidup saya, karena saya benar-benar berhenti memahami cara kerja mobil saya. Mobil modern adalah perangkat yang kompleks. Mobil beradaptasi secara bersamaan dengan lusinan parameter berbeda: tekanan gas, rem, gaya mengemudi, kualitas jalan. Saya tidak mengerti cara kerjanya lagi.
Ketika saya mulai mengerjakan cloud Amazon, hal itu juga merupakan misteri bagi saya. Hanya misteri ini yang jauh lebih besar, karena ada satu pengemudi di dalam mobil, dan di AWS ada jutaan pengemudi. Semua pengguna secara bersamaan menyetir, menekan gas dan mengerem. Sungguh menakjubkan mereka pergi ke tempat yang mereka inginkan - ini merupakan keajaiban bagi saya! Sistem secara otomatis mengadaptasi, menskalakan, dan menyesuaikan secara elastis kepada setiap pengguna sehingga ia merasa sendirian di Alam Semesta ini.
Keajaiban itu sedikit memudar ketika saya kemudian bekerja sebagai arsitek di Amazon. Saya melihat permasalahan apa saja yang kami hadapi, bagaimana kami menyelesaikannya, dan bagaimana kami mengembangkan layanan. Dengan meningkatnya pemahaman tentang cara kerja sistem, semakin banyak kepercayaan terhadap layanan yang muncul. Jadi saya ingin berbagi gambaran tentang apa yang ada di balik terpal cloud AWS.
Apa yang akan kita bicarakan
Saya memilih pendekatan yang terdiversifikasi - saya memilih 4 layanan menarik yang layak untuk dibicarakan.
Optimalisasi server. Awan fana dengan perwujudan fisik: pusat data fisik di mana terdapat server fisik yang berdengung, memanas, dan berkedip dengan lampu.
Fungsi tanpa server (Lambda) mungkin merupakan layanan yang paling skalabel di cloud.
Penskalaan basis data. Saya akan memberi tahu Anda tentang cara kami membangun database kami yang dapat diskalakan.
Penskalaan jaringan. Bagian terakhir di mana saya akan membuka perangkat jaringan kami. Ini adalah hal yang luar biasa - setiap pengguna cloud percaya bahwa dia sendirian di cloud dan tidak melihat penyewa lain sama sekali.
Catatan. Artikel ini akan membahas optimasi server dan penskalaan database. Kami akan mempertimbangkan penskalaan jaringan di artikel berikutnya. Di manakah fungsi tanpa server? Transkrip terpisah diterbitkan tentang mereka “" Ini membahas beberapa metode penskalaan yang berbeda, dan membahas secara rinci solusi Firecracker - simbiosis kualitas terbaik dari mesin virtual dan container.
Server
Awan itu bersifat sementara. Namun kefanaan ini masih memiliki perwujudan fisik - server. Awalnya, arsitektur mereka klasik. Chipset x86 standar, kartu jaringan, Linux, hypervisor Xen tempat mesin virtual dijalankan.
Pada tahun 2012, arsitektur ini mengatasi tugasnya dengan cukup baik. Xen adalah hypervisor yang hebat, namun memiliki satu kelemahan utama. Dia sudah cukup overhead tinggi untuk emulasi perangkat. Dengan tersedianya kartu jaringan atau drive SSD baru yang lebih cepat, overhead ini menjadi terlalu tinggi. Bagaimana cara mengatasi masalah ini? Kami memutuskan untuk bekerja di dua bidang sekaligus - mengoptimalkan perangkat keras dan hypervisor. Tugasnya sangat serius.
Mengoptimalkan perangkat keras dan hypervisor
Melakukan semuanya sekaligus dan melakukannya dengan baik tidak akan berhasil. Apa yang “baik” pada awalnya juga tidak jelas.
Kami memutuskan untuk mengambil pendekatan evolusioner - kami mengubah satu elemen penting arsitektur dan memasukkannya ke dalam produksi.
Kami menginjak setiap penggaruk, mendengarkan keluhan dan saran. Kemudian kita ubah komponen lainnya. Jadi, sedikit demi sedikit, kami mengubah keseluruhan arsitektur secara radikal berdasarkan masukan dari pengguna dan dukungan.
Transformasi dimulai pada tahun 2013 dengan hal yang paling kompleks – jaringan. DI DALAM С3 misalnya, kartu Akselerator Jaringan khusus telah ditambahkan ke kartu jaringan standar. Itu terhubung secara harfiah dengan kabel loopback pendek di panel depan. Itu tidak cantik, tapi tidak terlihat di awan. Namun interaksi langsung dengan perangkat keras secara mendasar meningkatkan jitter dan throughput jaringan.
Selanjutnya kami memutuskan untuk meningkatkan akses untuk memblokir penyimpanan data EBS - Elastic Block Storage. Ini adalah kombinasi jaringan dan penyimpanan. Kesulitannya adalah meskipun kartu Network Accelerator sudah ada di pasaran, tidak ada pilihan untuk sekadar membeli perangkat keras Storage Accelerator. Jadi kami beralih ke startup Laboratorium Annapurna, yang mengembangkan chip ASIC khusus untuk kami. Mereka mengizinkan volume EBS jarak jauh untuk dipasang sebagai perangkat NVMe.
Dalam beberapa kasus C4 kami memecahkan dua masalah. Yang pertama adalah kami menerapkan landasan bagi masa depan teknologi NVMe yang menjanjikan, namun baru pada saat itu. Kedua, kami menurunkan beban prosesor pusat secara signifikan dengan mentransfer pemrosesan permintaan ke EBS ke kartu baru. Ternyata bagus, jadi sekarang Annapurna Labs menjadi bagian dari Amazon.
Pada bulan November 2017, kami menyadari bahwa sudah waktunya untuk mengubah hypervisor itu sendiri.
Hypervisor baru dikembangkan berdasarkan modul kernel KVM yang dimodifikasi.
Hal ini memungkinkan pengurangan biaya emulasi perangkat secara mendasar dan bekerja secara langsung dengan ASIC baru. Contoh С5 adalah mesin virtual pertama dengan hypervisor baru yang berjalan di bawah tenda. Kami menamainya Nitro.
Evolusi instance di timeline.
Semua jenis mesin virtual baru yang muncul sejak November 2017 dijalankan di hypervisor ini. Instans Bare Metal tidak memiliki hypervisor, tetapi disebut juga Nitro karena menggunakan kartu Nitro khusus.
Selama dua tahun berikutnya, jumlah jenis mesin Nitro melebihi beberapa lusin: A1, C5, M5, T3, dan lainnya.
Jenis instans.
Cara kerja mesin Nitro modern
Mereka memiliki tiga komponen utama: hypervisor Nitro (dibahas di atas), chip keamanan, dan kartu Nitro.
Chip keamanan terintegrasi langsung ke motherboard. Ia mengontrol banyak fungsi penting, seperti mengontrol pemuatan OS host.
Kartu nitro - Ada empat jenisnya. Semuanya dikembangkan oleh Annapurna Labs dan didasarkan pada ASIC umum. Beberapa firmware mereka juga umum.
Empat jenis kartu Nitro.
Salah satu kartu dirancang untuk digunakan jaringanVPC. Inilah yang terlihat di mesin virtual sebagai kartu jaringan ENA - Adaptor Jaringan Elastis. Ini juga merangkum lalu lintas ketika mentransmisikannya melalui jaringan fisik (kita akan membicarakannya di bagian kedua artikel), mengontrol firewall Grup Keamanan, dan bertanggung jawab atas perutean dan hal-hal jaringan lainnya.
Kartu tertentu berfungsi dengan penyimpanan blok EBS dan disk yang dibangun ke dalam server. Mereka tampak di mesin virtual tamu sebagai Adaptor NVMe. Mereka juga bertanggung jawab atas enkripsi data dan pemantauan disk.
Sistem kartu Nitro, hypervisor dan chip keamanan terintegrasi ke dalam jaringan SDN atau Jaringan yang Ditentukan Perangkat Lunak. Bertanggung jawab untuk mengelola jaringan ini (Control Plane) kartu pengontrol.
Tentu saja, kami terus mengembangkan ASIC baru. Misalnya, pada akhir tahun 2018 mereka merilis chip Inferentia, yang memungkinkan Anda bekerja lebih efisien dengan tugas-tugas pembelajaran mesin.
Chip Prosesor Pembelajaran Mesin Inferentia.
Basis Data yang Dapat Diskalakan
Basis data tradisional memiliki struktur berlapis. Untuk menyederhanakannya, tingkatan berikut dibedakan.
- SQL — klien dan petugas operator permintaan mengerjakannya.
- Ketentuan transaksi - semuanya jelas di sini, ACID dan sebagainya.
- caching, yang disediakan oleh kumpulan buffer.
- Penebangan — menyediakan pekerjaan dengan redo log. Di MySQL disebut Bin Logs, di PosgreSQL - Write Ahead Logs (WAL).
- Penyimpanan – perekaman langsung ke disk.
Struktur database berlapis.
Ada berbagai cara untuk menskalakan database: sharding, arsitektur Shared Nothing, disk bersama.
Namun, semua metode ini mempertahankan struktur database monolitik yang sama. Hal ini secara signifikan membatasi penskalaan. Untuk mengatasi masalah ini, kami mengembangkan database kami sendiri - Amazon Aurora. Ini kompatibel dengan MySQL dan PostgreSQL.
Amazon Aurora
Ide arsitektur utamanya adalah untuk memisahkan tingkat penyimpanan dan logging dari database utama.
Ke depan, saya akan mengatakan bahwa kami juga menjadikan tingkat caching independen. Arsitekturnya tidak lagi menjadi sebuah monolit, dan kami mendapatkan tingkat kebebasan tambahan dalam menskalakan setiap blok.
Tingkat logging dan penyimpanan terpisah dari database.
DBMS tradisional menulis data ke sistem penyimpanan dalam bentuk blok. Di Amazon Aurora, kami menciptakan penyimpanan cerdas yang dapat berbahasa ulangi log. Di dalamnya, penyimpanan mengubah log menjadi blok data, memantau integritasnya, dan membuat cadangan secara otomatis.
Pendekatan ini memungkinkan Anda untuk mengimplementasikan hal-hal menarik seperti kloning. Ia bekerja secara fundamental lebih cepat dan lebih ekonomis karena tidak memerlukan pembuatan salinan lengkap semua data.
Lapisan penyimpanan diimplementasikan sebagai sistem terdistribusi. Ini terdiri dari sejumlah besar server fisik. Setiap log pengulangan diproses dan disimpan secara bersamaan enam knot. Hal ini memastikan perlindungan data dan penyeimbangan beban.
Penskalaan baca dapat dicapai dengan menggunakan replika yang sesuai. Penyimpanan terdistribusi menghilangkan kebutuhan akan sinkronisasi antara instance database utama, yang digunakan untuk menulis data, dan replika yang tersisa. Data terkini dijamin tersedia untuk semua replika.
Satu-satunya masalah adalah menyimpan data lama pada replika baca. Namun masalah ini sedang diselesaikan transfer semua log pengulangan untuk direplikasi melalui jaringan internal. Jika log ada di cache, itu ditandai sebagai salah dan ditimpa. Jika tidak ada dalam cache, maka akan dibuang begitu saja.
Kami telah mengatur penyimpanannya.
Cara menskalakan tingkatan DBMS
Di sini, penskalaan horizontal jauh lebih sulit. Jadi mari kita ambil jalan yang sudah biasa penskalaan vertikal klasik.
Anggaplah kita mempunyai aplikasi yang berkomunikasi dengan DBMS melalui node master.
Saat melakukan penskalaan secara vertikal, kami mengalokasikan node baru yang akan memiliki lebih banyak prosesor dan memori.
Selanjutnya kita alihkan aplikasi dari master node yang lama ke yang baru. Masalah muncul.
- Hal ini memerlukan waktu henti aplikasi yang signifikan.
- Node master baru akan memiliki cache dingin. Performa database akan maksimal hanya setelah cache melakukan pemanasan.
Bagaimana cara memperbaiki situasi? Siapkan proxy antara aplikasi dan node master.
Apa manfaatnya bagi kita? Sekarang semua aplikasi tidak perlu dialihkan secara manual ke node baru. Peralihan dapat dilakukan di bawah proxy dan pada dasarnya lebih cepat.
Tampaknya masalahnya telah teratasi. Tapi tidak, kami masih perlu menghangatkan cache. Selain itu, masalah baru telah muncul - sekarang proxy berpotensi menjadi titik kegagalan.
Solusi akhir dengan Amazon Aurora tanpa server
Bagaimana kami mengatasi masalah ini?
Meninggalkan proxy. Ini bukan contoh yang terpisah, tetapi seluruh armada proxy terdistribusi yang melaluinya aplikasi terhubung ke database. Jika terjadi kegagalan, node mana pun dapat diganti hampir seketika.
Menambahkan kumpulan simpul hangat dengan berbagai ukuran. Oleh karena itu, jika diperlukan untuk mengalokasikan node baru dengan ukuran lebih besar atau lebih kecil, node tersebut segera tersedia. Tidak perlu menunggu untuk memuat.
Seluruh proses penskalaan dikendalikan oleh sistem pemantauan khusus. Pemantauan terus-menerus memonitor keadaan node master saat ini. Jika ia mendeteksi, misalnya, bahwa beban prosesor telah mencapai nilai kritis, ia akan memberi tahu kumpulan instance hangat tentang perlunya mengalokasikan node baru.
Proksi terdistribusi, instance hangat, dan pemantauan.
Sebuah node dengan daya yang dibutuhkan tersedia. Kumpulan buffer disalin ke dalamnya, dan sistem mulai menunggu saat yang aman untuk beralih.
Biasanya momen peralihan datang cukup cepat. Kemudian komunikasi antara proxy dan node master lama dihentikan, semua sesi dialihkan ke node baru.
Bekerja dengan database dilanjutkan.
Grafik tersebut menunjukkan suspensinya memang sangat pendek. Grafik biru menunjukkan beban, dan langkah merah menunjukkan momen penskalaan. Penurunan jangka pendek pada grafik biru merupakan penundaan yang singkat.
Omong-omong, Amazon Aurora memungkinkan Anda menghemat uang sepenuhnya dan mematikan database saat tidak digunakan, misalnya di akhir pekan. Setelah menghentikan beban, DB secara bertahap mengurangi dayanya dan mati selama beberapa waktu. Ketika beban kembali, ia akan naik kembali dengan lancar.
Di bagian selanjutnya dari cerita tentang perangkat Amazon, kita akan membahas tentang penskalaan jaringan. Langganan dan pantau terus agar tidak ketinggalan artikelnya.
Pada Vasily Pantyukhin akan memberikan laporan “" Pola desain sistem terdistribusi apa yang digunakan oleh pengembang Amazon, apa alasan kegagalan layanan, apa itu arsitektur berbasis Sel, Pekerjaan Konstan, Shuffle Sharding - ini akan menarik. Kurang dari sebulan hingga konferensi - . Kenaikan harga akhir 24 Oktober.
Sumber: www.habr.com