Rekam mikrovirtual Petasan. Kami mengambil dua metode populer untuk mengisolasi beban kerja multi-pengguna - mesin dan wadah virtual. Kami memeras yang terbaik dari kedua pendekatan, menyederhanakan sebanyak mungkin, menguji pada beban nyata. Akibatnya, kami mendapatkan isolasi komputer virtual yang tidak dapat ditembus yang dapat diluncurkan dalam ratusan milidetik. Solusi ini bekerja di bawah naungan AWS Lambda dan Fargate, menjalankan jutaan fungsi dan wadah tanpa server setiap detik di cloud. Ini disebut Petasan.
Alat mikrovirtualisasi ini tersedia di
OpenSource . Jika tugas Anda memerlukan isolasi multi-penyewa, (misalnya, Anda memutuskan untuk membuat cloud sendiri), Firecracker adalah yang Anda butuhkan.
Vasily Pantyukhin , arsitek Amazon Web Services, berbicara tentang arsitektur Firecracker, bagaimana itu digunakan oleh AWS Lambda, membandingkannya dengan solusi alternatif dan memberikan contoh integrasi.
Penafian: Segala sesuatu di bawah ini adalah pendapat pribadi Vasily, dan itu mungkin tidak sesuai dengan posisi Amazon Web Services.Fitur alami dari awan publik
Salah satu sifat mendasar dari cloud publik adalah multi-tenancy.
Seseorang menerjemahkan istilah ini sebagai "multi-tenancy" atau "multi-user environment." Tetapi dari sudut pandang saya, ini tidak mencerminkan esensi. Multi-tenancy adalah ketika pengguna yang berbeda dan muatannya hidup di infrastruktur fisik yang sama, berbagi di antara mereka sendiri, tetapi tidak tahu apa-apa tentang satu sama lain. Dari beban kerja multi-pengguna, multi-tenancy dibedakan oleh persyaratan yang lebih ketat secara fundamental untuk isolasi sumber daya dan akses ke sana.
Properti lain yang melekat dalam cloud publik adalah highload.
Percayalah, dalam kasus AWS, ini adalah beban yang sangat besar! Tangkapan layar adalah contoh data nyata. Saya tidak akan mengatakan berapa lama dan di wilayah mana jutaan "kakatua" ini diukur, tetapi ini bukan semacam darurat, tetapi mode operasi yang biasa bagi kami.
Ternyata kontradiksi tertentu. Di satu sisi, kita perlu membuat pengguna terisolasi mungkin. Di sisi lain, kita harus memastikan tingkat produktivitas dan pemanfaatan sumber daya yang sangat tinggi. Memperbaiki satu sering menyebabkan keterbatasan yang lain. Bagaimana menemukan kompromi, dan bahkan lebih baik, untuk mendapatkan hasil maksimal di semua lini?
Mesin atau wadah virtual?
Ada dua pendekatan dasar yang berpotensi membantu. Ini adalah mesin dan wadah virtual. Masing-masing memiliki pro dan kontra.
Kerugian utama dari mesin virtual adalah bahwa mereka membutuhkan waktu
lama untuk memuat . Biasanya diperlukan puluhan detik, atau bahkan beberapa menit, untuk menghidupkan mesin. Tetapi virtualoks memiliki sifat baik - mereka
melindungi muatan
beton dari satu sama lain. Dan dari kedua sudut pandang:
- keamanan ketika satu mesin virtual tidak dapat mengakses data di komputer lain;
- sumber daya , ketika saya memesan memori 8 GB, saya berharap bahwa RAM ini akan menjadi milik saya dan tidak ada yang bisa mengklaim sumber daya yang saya bayar.
Sebaliknya dengan wadah: mereka ringan dan karena itu
memuat sangat cepat. Mereka dapat dengan mudah diskalakan secara horizontal. Tetapi ada satu fitur yang dengannya kita, sebagai penyedia cloud publik, tidak dapat hidup. Mereka menggunakan
kernel yang dibagikan - kernel OS dibagikan di antara semua kontainer .
Bisakah wadah dikatakan tidak aman? Tidak, meskipun ada kerentanan serius.
Saya percaya bahwa hari ini wadah yang "dilas" dengan benar memberikan tingkat keamanan yang memadai.
Masalahnya berbeda - kernel yang dibagikan tidak secara fundamental menjamin bahwa suatu saat di masa depan, kerentanan tidak akan muncul yang memecah isolasi penyewa. Cloud publik tidak mampu membelinya bahkan dalam teori.
Ada kontradiksi lain, dan solusi harus dicari. Cara termudah adalah mengambil semua yang terbaik dari ibu - mesin virtual, dan dari ayah - wadah, silangkan dan dapatkan sesuatu yang
konvergen . Sebenarnya, kita berhasil. Ternyata Petasan.
Petasan sudah dalam produksi. Dalam layanan kritis yang sama, misalnya, AWS Lambda (fungsi serverless) dan AWS Fargate (serverless-container).
Masalah AWS Lambda lama
AWS Lambda adalah layanan fitur tanpa server. Kami mengambil fungsi dalam Java, Go, Python atau bahasa lain, kami membuangnya di Lambda, dan dijalankan secara ajaib. Tidak perlu mengalokasikan dan mengelola sumber daya. Bagaimana ini diterapkan sebelumnya?
Untuk setiap akun AWS, satu atau lebih mesin virtual EC2 terpisah dialokasikan untuk mengisolasi fungsi yang dimiliki oleh penyewa yang berbeda. Mesin virtual semacam itu menghabiskan sumber daya, bahkan ketika ia tidak melakukan apa pun. Misalkan kita menjalankan fungsi sekali setiap 10 menit, dan dijalankan dalam 200 ms seperti Lambda biasa. Ternyata dalam satu jam mesin EC2 hanya digunakan beberapa detik. Selain itu, bahkan saat runtime, ia tidak mengkonsumsi semua sumber daya yang tersedia - pembuangan di bawah alas tiang. Ini sangat tidak menguntungkan.
Bagaimana Anda memecahkan masalah daur ulang?
Dikembangkan dari awal, solusi Firecracker mereka sendiri. Ini jelas dari judul laporan :)
Untuk mulai mengembangkan produk baru, Anda memerlukan tugas teknis. Ini memiliki banyak teks, tetapi jika Anda hanya memilih artinya, Anda mendapatkan yang berikut.
- Didukung oleh KVM sebagai hypervisor. Siapa pun yang bekerja dengan AWS tahu bahwa kami memiliki dua hypervisor favorit. VM lawas berjalan di Xen. Sejak akhir 2017, KVM telah hidup di bawah kap semua mobil.
- Itu dimulai secepat mungkin. Pada perangkat keras referensi, persyaratannya adalah beban penuh mikrovirtual dalam 125 ms.
- Overhead virtualisasi minimum . Dalam arsitektur referensi, satu mesin mikro-virtual Firecracker juga hanya mengkonsumsi memori 5 MB.
- Kemungkinan awal paling padat . Parameter desain - beban penuh 5 mikrovirtual per inti per detik. Persyaratan ini sangat mendasar untuk layanan seperti AWS Lambda. Fungsi harus cepat lepas landas, berolahraga dan mati, membebaskan sumber daya untuk selanjutnya.
- Kemungkinan berlangganan kembali . Ini adalah kesempatan - tidak perlu menggunakannya. Bahkan, ini adalah alokasi sumber daya virtual ke tingkat yang lebih besar daripada yang tersedia secara fisik. Ini berarti bahwa server memiliki 16 GB RAM, dan Anda secara bersamaan menjalankan 4 mesin virtual di atasnya, yang masing-masing yakin bahwa ia memiliki 8 GB memori.
AWS Lambda dengan Petasan di bawah kap
Apa yang berubah di AWS Lambda versi baru? Dari sudut pandang pengguna akhir, tidak ada yang berubah. Migrasi ke arsitektur yang diperbarui dalam produksi benar-benar transparan dan tidak terlihat oleh konsumen. Fitur Lambda berumur pendek - itu mudah dilakukan.
Seperti apa arsitektur modern?
Pada level terendah sekarang bukan mesin virtual, tetapi fisik logam kosong.
Server semacam itu memungkinkan penggunaan penuh semua fungsi CPU, misalnya, Intel VT. Ini memberikan manfaat tambahan saat menggunakan virtualisasi di tingkat yang lebih tinggi.
Di atas potongan besi adalah
OS host dengan modul KVM di kernel. Mikro petualang dengan
OS tamu mereka sendiri diluncurkan di atas. Ya, mereka sudah mengimplementasikan komponen layanan AWS Lambda itu sendiri.
Sebelumnya, untuk setiap pelanggan yang menggunakan fitur Lambda, kami mengalokasikan mesin virtual EC2 terpisah dengan pemanfaatan rendah. Pendekatan baru memungkinkan Anda untuk menjalankan microvirtual ringan hanya ketika Anda benar-benar membutuhkannya. Mengisolasi sumber daya Petasan satu sama lain memungkinkan kami melakukan ini pada perangkat keras umum dengan kepadatan maksimum. Pemanfaatan sumber daya telah meningkat secara mendasar.
Apa yang ada di dalam kotak?
Saya berjanji anboxing, jadi mari kita lihat komponen utama Firecracker, pertimbangkan masing-masing secara terpisah, dan kemudian kumpulkan semuanya.
Prinsip desain
Ketika kami pertama kali mulai membahas pengembangan Petasan, kami sepakat untuk mematuhi dua prinsip.
Singkirkan semua yang tidak perlu. Mengapa mesin virtual klasik dimuat dengan lambat? Khususnya, karena kode kelebihan beban. Mereka harus mendukung sejumlah besar perangkat warisan. Tapi mengapa meniru perangkat yang tidak digunakan orang lain 10 tahun yang lalu? Tidak perlu, oleh karena itu, kami menyingkirkan semua yang tidak perlu. Kami menyelesaikan tugas sempit tertentu dan fungsi apa pun yang tidak membantu menyelesaikan masalah ini dianggap tidak perlu.
Singkirkan semua yang tidak perlu dan fokus pada satu tugas.
Sederhanakan apa yang tersisa. Bahkan apa yang tersisa harus sesederhana mungkin.
Apa yang mereka tulis?
Petasan ditulis dalam Rust yang trendi karena:
- ini memungkinkan Anda untuk menulis kode yang lebih aman , khususnya, dalam hal memori;
- Kinerja dan overhead sebanding dengan C ++ modern;
- Rust telah digunakan sejak lama, sejak 2015 telah menulis banyak solusi keren yang keren.
Besi
Saya ulangi - Petasan membutuhkan instalasi pada perangkat keras nyata. Sebagai konfigurasi referensi, mesin bare-metal i3.metal dipilih.
Catatan: laporan itu pada awal April 2019. Saat itu, hanya platform Intel yang didukung. Pada bulan Mei, mereka menambahkan dukungan alpha untuk AMD, dan pada bulan Juni ARM. AMD mungkin sedikit lebih murah daripada Intel, dan dukungan ARM menawarkan peluang menarik untuk bekerja dengan IoT multi-tenant.Jika Anda memesan mesin i3.metal atau bare-metal lainnya di AWS, maka untuk eksperimen itu akan terlalu kuat dan konfigurasi mahal. Karena itu, jika Anda memutuskan untuk menginstal Firecracker pada mereka, maka jangan lupa untuk melunasi mesin-mesin ini setelah percobaan. Kalau tidak, skor yang layak akan datang pada akhir bulan.
Apakah ada opsi yang lebih murah? Ya, Anda dapat mem-boot Petasan di lingkungan virtual. Tetapi tidak di AWS lagi - pada dasarnya kami tidak mendukung virtualisasi bersarang di EC2. Tetapi Anda bisa melakukannya di GCP, Azure, DigitalOcean atau menggunakan Proxmox, Parallels, VMware Fusion. Semuanya akan berfungsi jika Anda mematuhi persyaratan, khususnya, sesuai dengan versi kernel dari OS tamu.
Intinya
Elemen mendasar dari solusinya adalah modul kernel KVM.
Untuk jaga-jaga, saya akan menggambarkan sebagai penyimpangan apa KVM itu. Ini bukan seluruh hypervisor, tetapi hanya sebagian saja. Tugas utamanya adalah
menyiapkan prosesor virtual (vCPU) dan
memulai mesin virtual .
Tetapi ini tidak cukup untuk pekerjaan penuh. Selain prosesor, beberapa perangkat lain dibutuhkan. Persaingan mereka terjadi di ruang pengguna.
VMM
Untuk setidaknya perangkat dasar muncul, Anda memerlukan komponen lain - Virtual Machine Manager (VMM). Sebelum Firecracker, opsi VMM utama adalah QEMU.
Kami serius mempertimbangkan kemungkinan menggunakan QEMU, tetapi memutuskan untuk mengembangkan "sepeda" kami sendiri. Ada beberapa alasan untuk ini.
Manajemen pengembangan . QEMU adalah produk besar dan matang dengan lebih dari sejuta baris kode. Untuk melakukan perubahan, Anda perlu melihat terlalu banyak kode sumber. Banyak orang berpartisipasi dalam pengembangan dan pengambilan keputusan tentang pembangunan.
Keamanan QEMU dapat meniru banyak perangkat. Itu sebabnya ia memiliki permukaan serangan yang cukup besar. Tugas kita adalah membuat mikrovirtual. Dari sudut pandang keamanan, kita harus meminimalkan permukaan serangan.
Kebutuhan untuk mengimplementasikan fitur-fitur baru. QEMU memiliki kode yang baik. Ini adalah produk matang di mana semua bug yang jelas sudah tertangkap. Tetapi dalam bentuk saat ini, fungsionalitas QEMU masih tidak sesuai dengan kita - kita harus menambahkan banyak. Dari sudut pandang ini, kode baru dalam QEMU dan produk baru akan memiliki kualitas yang sama. Karena itu, kemenangan khusus tidak akan berhasil.
Perangkat
Petasan mengimplementasikan VMM, yang digunakan untuk meniru perangkat. Kami meniru perangkat berikut:
- Konsol Suatu hal yang bermanfaat dan perlu, meskipun bisa dimatikan.
- Keyboard Kami membuat keyboard yang rumit - hanya dengan satu tombol "Reset". Kami tidak mempercayai "Reset" perangkat lunak dari sistem operasi yang berpotensi berjalan di Firecracker. Karena itu, mereka membuat besi.
- Driver Virtio untuk disk dan jaringan . Virtio adalah perangkat yang sangat primitif. Intinya, ini adalah "ring buffer". Sistem tamu menulis sesuatu ke buffer, mengklik panggilan, dan sistem host membaca data dari buffer ini melalui file.
Dalam beberapa kasus, misalnya, untuk integrasi dengan wadah, kita masih memerlukan perangkat jaringan yang akan mewakili fungsionalitas dasar kartu jaringan biasa. Virtio tidak cocok di sini, terlalu sederhana. Karena itu, untuk jaringan kami menggunakan perangkat lain -
Vsock .
Kita juga perlu kemampuan untuk mengendalikan konsumsi sumber daya.
Pembatas laju bertanggung jawab untuk ini.
Ada beberapa perangkat. Tetapi bagaimana cara mengatur dan mengkonfigurasi mikrovirtual? API manajemen akan membantu kami di sini.
Manajemen
Amazon memiliki beberapa prinsip dasar yang tidak dapat dipecahkan. Salah satunya adalah bahwa setiap layanan berkomunikasi satu sama lain hanya melalui API. Tidak masalah apakah ini adalah layanan eksternal yang Anda gunakan sebagai pengguna, atau layanan internal kami. Itu tidak terjadi bahwa satu layanan langsung ke database layanan lain - itu dilarang dan dihukum. Thread Firecracker API hanya digunakan untuk mengakses pengaturan dan fungsionalitas microvirtuals melalui REST API.
Kami mematuhi spesifikasi Open API, sehingga Anda dapat menggunakan Swagger.
Metadata
Ada pengkodean yang sangat buruk. Inilah saat beberapa data dijahit langsung ke dalam kode, misalnya, login dan kata sandi akses ke sumber daya lain. Ini, tentu saja, tidak diizinkan. Secara berkala, kita perlu mentransfer beberapa data di dalam microvirtual. Ini dilakukan melalui
layanan metadata .
Kami meneruskan informasi yang diperlukan melalui soket ke perdagangan metadata IMDS. Untuk mendapatkan informasi ini di dalam microvirtual, Anda perlu meminta
http://169.254.169.254/latest/meta-data menggunakan REST API. Pengguna AWS sudah mengetahui IP ajaib ini. Dengan cara yang sama, mikrovirtual dapat memperoleh informasi terperinci tentang konfigurasi mereka sendiri.
Log
Sangat penting untuk dapat membuang log microvirtuals ke dunia luar sebelum dia meninggal. Ini dilakukan melalui
FIFO Unix biasa.
Isolasi tambahan
Plus utama dari mesin virtual secara terpisah. Tampaknya ini sudah cukup, tetapi kami melangkah lebih jauh. Untuk berjaga-jaga, untuk menjalankan produksi disarankan untuk meletakkan lapisan isolasi tambahan yang disebut
Jailer .
Ini adalah tindakan pencegahan standar:
- cgroups untuk membatasi sumber daya;
- namespace untuk mengisolasi proses;
- seccomp - analog dari firewall untuk panggilan sistem;
- dan, tentu saja, chroot favorit semua orang .
Integrasi dengan layanan lain
Apakah ada solusi yang sudah jadi berdasarkan Firecracker? Tentu saja ya
OSV
Sistem operasi ini dirancang untuk menjalankan hanya satu aplikasi. Karena ini, ia memiliki pekerjaan yang sangat sederhana dengan memori dan penjadwal. OS yang kuat dan mudah dikelola sekarang
bekerja di atas Firecracker .
Containerd
Kami juga membuat integrasi dengan contenterd. Jika Anda sudah bekerja dengannya, maka Anda perlu sedikit upaya untuk meluncurkan wadah yang dibungkus dengan Petasan untuk isolasi.
Alih-alih shim biasa, containerd merujuk ke shim Petasan. Ini sudah mengelola runc, melalui agen yang dipasang di dalam microvirtual.
Sudah diperiksa, berfungsi .
Wadah kata
Ketika kami pertama kali mengumumkan Petasan, salah satu pertanyaan pelanggan paling populer adalah:
- Mekanisme untuk mengisolasi wadah sudah ditemukan - ini adalah Kata Containers. Mengapa Anda tidak menggunakannya? Mengapa mengembangkan milik Anda sendiri?- Kata bekerja dengan QEMU, tetapi kami tidak ingin bekerja dengan QEMU. Karena itu, kami memutuskan untuk memasak sendiri.Tapi ternyata menarik. Pengembang Kata bertemu dengan pengembang Firecracker dan setuju untuk berintegrasi. Karena semua orang melihat ini sebagai nilai tambah yang besar.
Kata Containers v1.5 sudah mendukung QEMU dan Firecracker.
Ternyata kami tidak bersaing, tetapi saling melengkapi secara harmonis. Di Kubernetes dengan v1.12, Anda dapat mendefinisikan runtimeClassName sebagai Kata FC atau Kata QEMU, dan menjalankan kontainer Anda dalam isolasi yang tepat.
Bagaimana memilih isolasi yang sesuai dengan aplikasi Anda - Petasan atau QEMU? Pendapat pribadi saya adalah yang
penting adalah apakah aplikasi Anda adalah
hewan peliharaan atau sapi ?
Kata with QEMU adalah solusi untuk hewan peliharaan. QEMU adalah sistem multi fungsi yang besar. Secara potensial, ia menawarkan lebih banyak dukungan dan opsi perawatan untuk hewan peliharaan favorit Anda.
Petasan sangat cocok saat memuat adalah ternak. Jika aplikasi stateless Anda pada awalnya dirancang untuk penskalaan horizontal yang fleksibel dan kegagalan satu atau lebih kontainer tidak penting. Menyediakan isolasi yang andal, memungkinkan Anda untuk dengan cepat memuat jumlah kontainer baru yang diperlukan untuk menggantikan yang gagal.
Apa hasilnya?
Kami mulai dengan kontradiksi. Tampaknya menyelesaikan kontradiksi adalah pendekatan "milik kita dan milikmu", sesuatu di antaranya yang akan memuaskan semua orang. Tetapi pengalaman mengatakan bahwa kompromi tidak perlu.
Kami menetapkan tujuan pengembangan solusi baru di mana tidak akan ada yang berlebihan yang tidak diperlukan untuk menyelesaikan tugas yang sempit. Penting juga untuk menyederhanakan segala yang kami gunakan sebanyak mungkin. Saya ingin percaya bahwa kami tidak mendapatkan kompromi, tetapi solusi yang solid, yang memungkinkan Anda untuk meluncurkan ribuan mikrovirtual dengan cepat dan tanpa mengorbankan isolasi mereka.
Kami sudah menggunakan Petasan untuk memproduksi beberapa layanan kami. Kelebihan utama yang kami dapatkan adalah peningkatan pemanfaatan layanan. Ini memungkinkan untuk menyimpan secara signifikan. Bagian dari penghematan ini kami bagi dengan pelanggan. Misalnya, setelah pengenalan Petasan, harga untuk wadah tanpa server AWS Fargate pada Januari 2019 turun 35-50%. Manfaatnya terlihat dengan mata telanjang, jadi tidak ada keraguan bahwa kami akan terus mengembangkan produk ini dan berbagi praktik terbaik kami dengan Open Source. Fakta bahwa Firecracker sudah mulai berintegrasi dengan solusi lain menunjukkan minat yang semakin besar di pihak masyarakat.
Jika Anda memiliki ide atau produk jadi dalam uraian yang terdapat kata "isolasi multi-penyewa" - ini adalah indikator yang jelas tentang apa yang harus Anda coba dengan microvirtuals Petasan.
Laporan ini menggambarkan dengan sempurna prinsip yang kami coba patuhi di konferensi Ontiko - untuk menerima pengalaman dunia dari para pakar berbahasa Rusia. Dan intinya tidak hanya dalam hambatan bahasa yang mungkin, tetapi dalam budaya kita terbiasa berbagi rincian teknis. Pada bulan November, Vasily akan tampil di HighLoad ++ lagi, dan ia akan bergabung dengan , misalnya, Artemy Kolesnikov dari Facebook, Vittorio Cioe dari Oracle dan, tentu saja, Petr Zaitsev dari Percona. Kami juga akan memiliki laporan dalam bahasa Inggris, berlangganan buletin - kami akan memberi tahu Anda ketika yang baru akan ditambahkan ke laporan empat puluh yang diterima.