Tanpa server bukan berarti tidak adanya server secara fisik. Ini bukanlah sebuah pembunuh kontainer atau tren yang hanya sekedar tren belaka. Ini adalah pendekatan baru untuk membangun sistem di cloud. Dalam artikel hari ini kita akan membahas arsitektur aplikasi Tanpa Server, mari kita lihat peran apa yang dimainkan oleh penyedia layanan Tanpa Server dan proyek sumber terbuka. Terakhir, mari kita bahas tentang masalah penggunaan Tanpa Server.
Saya ingin menulis bagian server dari suatu aplikasi (atau bahkan toko online). Ini bisa berupa obrolan, layanan penerbitan konten, atau penyeimbang beban. Bagaimanapun, akan ada banyak masalah: Anda harus menyiapkan infrastruktur, menentukan dependensi aplikasi, dan memikirkan sistem operasi host. Maka Anda perlu memperbarui komponen kecil yang tidak mempengaruhi pengoperasian monolit lainnya. Baiklah, jangan lupa tentang penskalaan di bawah beban.
Bagaimana jika kita mengambil container sementara, yang dependensinya sudah diinstal sebelumnya, dan container itu sendiri diisolasi satu sama lain dan dari OS host? Kami akan membagi monolit menjadi layanan mikro, yang masing-masing dapat diperbarui dan diskalakan secara independen. Dengan menempatkan kode dalam wadah seperti itu, saya dapat menjalankannya di infrastruktur apa pun. Sudah lebih baik.
Bagaimana jika Anda tidak ingin mengonfigurasi container? Saya tidak ingin memikirkan tentang penskalaan aplikasi. Saya tidak ingin membayar untuk container yang menganggur ketika beban pada layanan minimal. Saya ingin menulis kode. Fokus pada logika bisnis dan bawa produk ke pasar dengan kecepatan cahaya.
Pemikiran seperti itu membawa saya pada komputasi tanpa server. Tanpa server dalam hal ini artinya bukan tidak adanya server secara fisik, tetapi tidak adanya sakit kepala manajemen infrastruktur.
Idenya adalah logika aplikasi dipecah menjadi fungsi-fungsi independen. Mereka memiliki struktur acara. Setiap fungsi melakukan satu “tugas mikro”. Yang diperlukan pengembang hanyalah memuat fungsi ke dalam konsol yang disediakan oleh penyedia cloud dan menghubungkannya dengan sumber peristiwa. Kode akan dieksekusi sesuai permintaan dalam wadah yang disiapkan secara otomatis, dan saya hanya akan membayar waktu eksekusinya.
Mari kita lihat seperti apa proses pengembangan aplikasi sekarang.
Dari sisi pengembang
Sebelumnya kita mulai membicarakan tentang aplikasi untuk toko online. Dalam pendekatan tradisional, logika utama sistem dijalankan oleh aplikasi monolitik. Dan server dengan aplikasi tersebut terus berjalan, meskipun tidak ada beban.
Untuk beralih ke tanpa server, kami memecah aplikasi menjadi tugas mikro. Kami menulis fungsi kami sendiri untuk masing-masingnya. Fungsi-fungsi tersebut tidak bergantung satu sama lain dan tidak menyimpan informasi status (stateless). Mereka bahkan mungkin ditulis dalam bahasa berbeda. Jika salah satunya “jatuh”, seluruh aplikasi tidak akan berhenti. Arsitektur aplikasi akan terlihat seperti ini:
Pembagian fungsi di Tanpa Server mirip dengan bekerja dengan layanan mikro. Namun layanan mikro dapat melakukan beberapa tugas, dan idealnya suatu fungsi harus menjalankan satu tugas. Bayangkan tugasnya adalah mengumpulkan statistik dan menampilkannya atas permintaan pengguna. Dalam pendekatan layanan mikro, tugas dilakukan oleh satu layanan dengan dua titik masuk: menulis dan membaca. Dalam komputasi tanpa server, ini akan menjadi dua fungsi berbeda yang tidak terkait satu sama lain. Pengembang menghemat sumber daya komputasi jika, misalnya, statistik lebih sering diperbarui daripada diunduh.
Fungsi tanpa server harus dijalankan dalam jangka waktu singkat (timeout), yang ditentukan oleh penyedia layanan. Misalnya, untuk AWS batas waktunya adalah 15 menit. Artinya, fungsi yang berumur panjang harus diubah agar sesuai dengan kebutuhan - inilah yang membedakan Tanpa Server dari teknologi populer lainnya saat ini (kontainer dan Platform sebagai Layanan).
Kami menetapkan acara untuk setiap fungsi. Suatu peristiwa adalah pemicu suatu tindakan:
Acara
Tindakan yang dilakukan fungsi tersebut
Gambar produk telah diunggah ke repositori.
Kompres gambar dan unggah ke direktori
Alamat toko fisik telah diperbarui di database
Muat lokasi baru ke dalam peta
Klien membayar barangnya
Mulai pemrosesan pembayaran
Peristiwa dapat berupa permintaan HTTP, streaming data, antrian pesan, dan sebagainya. Sumber peristiwa adalah perubahan atau kemunculan data. Selain itu, fungsi dapat dipicu oleh pengatur waktu.
Arsitekturnya telah berhasil, dan aplikasinya hampir menjadi tanpa server. Selanjutnya kita pergi ke penyedia layanan.
Dari sisi penyedia
Biasanya, komputasi tanpa server ditawarkan oleh penyedia layanan cloud. Mereka disebut berbeda: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Kami akan menggunakan layanan melalui konsol penyedia atau akun pribadi. Kode fungsi dapat diunduh dengan salah satu cara berikut:
- menulis kode di editor bawaan melalui konsol web,
- unduh arsip dengan kode,
- bekerja dengan repositori git publik atau pribadi.
Di sini kita menyiapkan acara yang memanggil fungsi tersebut. Rangkaian peristiwa mungkin berbeda untuk penyedia yang berbeda.
Penyedia membangun dan mengotomatisasi sistem Function as a Service (FaaS) pada infrastrukturnya:
- Kode fungsi berakhir di penyimpanan di sisi penyedia.
- Ketika suatu peristiwa terjadi, kontainer dengan lingkungan yang telah disiapkan secara otomatis disebarkan di server. Setiap instance fungsi memiliki container terisolasinya sendiri.
- Dari penyimpanan, fungsi dikirim ke container, dihitung, dan mengembalikan hasilnya.
- Jumlah acara paralel bertambah - jumlah kontainer bertambah. Sistem secara otomatis menskalakan. Jika pengguna tidak mengakses fungsi tersebut, fungsi tersebut akan menjadi tidak aktif.
- Penyedia menetapkan waktu idle untuk container - jika selama waktu ini fungsi tidak muncul di container, maka container akan dimusnahkan.
Dengan cara ini kita mengeluarkan Serverless dari kotaknya. Kami akan membayar layanan menggunakan model bayar sesuai penggunaan dan hanya untuk fungsi-fungsi yang digunakan, dan hanya pada saat fungsi tersebut digunakan.
Untuk memperkenalkan layanan ini kepada pengembang, penyedia menawarkan pengujian gratis hingga 12 bulan, tetapi membatasi total waktu komputasi, jumlah permintaan per bulan, dana, atau konsumsi daya.
Keuntungan utama bekerja dengan penyedia adalah kemampuan untuk tidak mengkhawatirkan infrastruktur (server, mesin virtual, container). Sementara itu, penyedia dapat mengimplementasikan FaaS baik menggunakan pengembangannya sendiri maupun menggunakan alat sumber terbuka. Mari kita bicarakan lebih lanjut.
Dari sisi sumber terbuka
Komunitas sumber terbuka telah aktif mengerjakan alat Tanpa Server selama beberapa tahun terakhir. Pelaku pasar terbesar juga berkontribusi terhadap pengembangan platform tanpa server:
- Google menawarkan kepada pengembang alat sumber terbukanya - . IBM, RedHat, Pivotal dan SAP berpartisipasi dalam pengembangannya;
- IBM bekerja pada platform Tanpa Server , yang kemudian menjadi proyek Apache Foundation;
- Microsoft membuka sebagian kode platform .
Perkembangan juga sedang dilakukan menuju kerangka kerja tanpa server. и dikerahkan di dalam cluster Kubernetes yang telah disiapkan sebelumnya, bekerja dengan Kubernetes dan Docker Swarm. Kerangka kerja ini bertindak sebagai semacam pengontrol - berdasarkan permintaan, ia menyiapkan lingkungan runtime di dalam cluster, kemudian meluncurkan fungsi di sana.
Kerangka kerja memberikan ruang untuk mengonfigurasi alat agar sesuai dengan kebutuhan Anda. Jadi, di Kubeless, pengembang dapat mengonfigurasi batas waktu eksekusi fungsi (nilai defaultnya adalah 180 detik). Fission, dalam upaya memecahkan masalah cold start, menyarankan untuk menjaga beberapa container tetap berjalan sepanjang waktu (walaupun hal ini memerlukan biaya penghentian sumber daya). Dan OpenFaaS menawarkan serangkaian pemicu untuk setiap selera dan warna: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs, dan lainnya.
Petunjuk untuk memulai dapat ditemukan di dokumentasi resmi kerangka kerja. Bekerja dengan mereka memerlukan lebih banyak keterampilan daripada saat bekerja dengan penyedia - setidaknya ini adalah kemampuan untuk meluncurkan cluster Kubernetes melalui CLI. Paling banyak, sertakan alat sumber terbuka lainnya (misalnya, pengelola antrean Kafka).
Terlepas dari cara kami bekerja dengan Tanpa Server - melalui penyedia atau menggunakan sumber terbuka, kami akan menerima sejumlah kelebihan dan kekurangan dari pendekatan Tanpa Server.
Dilihat dari kelebihan dan kekurangannya
Tanpa server mengembangkan ide infrastruktur kontainer dan pendekatan layanan mikro, di mana tim dapat bekerja dalam mode multibahasa tanpa terikat pada satu platform. Membangun sistem disederhanakan dan kesalahan lebih mudah diperbaiki. Arsitektur layanan mikro memungkinkan Anda menambahkan fungsionalitas baru ke sistem jauh lebih cepat dibandingkan dengan aplikasi monolitik.
Tanpa server mengurangi waktu pengembangan lebih jauh lagi, memungkinkan pengembang untuk fokus hanya pada logika bisnis dan pengkodean aplikasi. Akibatnya, waktu pemasaran untuk pengembangan menjadi berkurang.
Sebagai bonus, kami mendapatkan penskalaan otomatis untuk beban, dan kami hanya membayar untuk sumber daya yang digunakan dan hanya pada saat sumber daya tersebut digunakan.
Seperti teknologi apa pun, Tanpa Server juga memiliki kelemahan.
Misalnya, kerugiannya adalah waktu mulai yang dingin (rata-rata hingga 1 detik untuk bahasa seperti JavaScript, Python, Go, Java, Ruby).
Di satu sisi, pada kenyataannya, waktu mulai dingin bergantung pada banyak variabel: bahasa di mana fungsi ditulis, jumlah perpustakaan, jumlah kode, komunikasi dengan sumber daya tambahan (database atau server otentikasi yang sama). Karena pengembang mengontrol variabel-variabel ini, ia dapat mengurangi waktu startup. Namun di sisi lain, pengembang tidak dapat mengontrol waktu startup container - semuanya tergantung pada penyedia.
Permulaan yang dingin dapat berubah menjadi permulaan yang hangat ketika suatu fungsi menggunakan kembali wadah yang diluncurkan oleh peristiwa sebelumnya. Situasi ini akan muncul dalam tiga kasus:
- jika klien sering menggunakan layanan dan jumlah panggilan ke fungsi tersebut meningkat;
- jika penyedia, platform, atau kerangka kerja mengizinkan Anda untuk menjaga beberapa container tetap berjalan sepanjang waktu;
- jika pengembang menjalankan fungsi pada pengatur waktu (katakanlah setiap 3 menit).
Untuk banyak aplikasi, start dingin tidak menjadi masalah. Di sini Anda perlu mulai dari jenis dan tugas layanan. Penundaan start selama satu detik tidak selalu penting untuk aplikasi bisnis, namun bisa menjadi penting untuk layanan medis. Dalam kasus ini, pendekatan tanpa server mungkin tidak lagi cocok.
Kerugian berikutnya dari Serverless adalah umur suatu fungsi yang singkat (batas waktu selama fungsi tersebut harus dijalankan).
Namun, jika Anda harus bekerja dengan tugas jangka panjang, Anda dapat menggunakan arsitektur hybrid - menggabungkan Tanpa Server dengan teknologi lain.
Tidak semua sistem dapat bekerja menggunakan skema Serverless.
Beberapa aplikasi masih akan menyimpan data dan status selama eksekusi. Beberapa arsitektur akan tetap monolitik dan beberapa fitur akan bertahan lama. Namun (seperti teknologi cloud dan container), Tanpa Server adalah teknologi dengan masa depan cerah.
Dalam hal ini, saya ingin beralih ke masalah penggunaan pendekatan Tanpa Server dengan lancar.
Dari sisi aplikasi
Untuk tahun 2018, persentase penggunaan Serverless . Di antara perusahaan yang telah menerapkan teknologi ini pada layanannya adalah raksasa pasar seperti Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Pada saat yang sama, Anda perlu memahami bahwa Tanpa Server bukanlah obat mujarab, tetapi alat untuk memecahkan sejumlah masalah tertentu:
- Mengurangi waktu henti sumber daya. Tidak perlu terus-menerus menyimpan mesin virtual untuk layanan yang memiliki sedikit panggilan.
- Memproses data dengan cepat. Kompres gambar, potong latar belakang, ubah pengkodean video, bekerja dengan sensor IoT, lakukan operasi matematika.
- “Rekatkan” layanan lain menjadi satu. Repositori Git dengan program internal, bot obrolan di Slack dengan Jira dan kalender.
- Seimbangkan bebannya. Mari kita lihat lebih dekat di sini.
Katakanlah ada layanan yang menarik 50 orang. Di bawahnya ada mesin virtual dengan perangkat keras yang lemah. Dari waktu ke waktu, beban layanan meningkat secara signifikan. Maka perangkat keras yang lemah tidak dapat mengatasinya.
Anda dapat menyertakan penyeimbang dalam sistem yang akan mendistribusikan beban, misalnya, ke tiga mesin virtual. Pada tahap ini, kami tidak dapat memprediksi beban secara akurat, jadi kami menjaga sejumlah sumber daya tetap berjalan “sebagai cadangan”. Dan kami membayar lebih untuk waktu henti.
Dalam situasi seperti ini, kita dapat mengoptimalkan sistem melalui pendekatan hibrid: kita meninggalkan satu mesin virtual di belakang penyeimbang beban dan memasang tautan ke Titik Akhir Tanpa Server dengan fungsi. Jika beban melebihi ambang batas, penyeimbang meluncurkan instance fungsi yang mengambil alih sebagian pemrosesan permintaan.
Dengan demikian, Serverless dapat digunakan ketika diperlukan untuk memproses permintaan dalam jumlah besar, tidak terlalu sering, tetapi secara intensif. Dalam hal ini, menjalankan beberapa fungsi selama 15 menit lebih menguntungkan daripada memelihara mesin virtual atau server sepanjang waktu.
Dengan segala kelebihan komputasi tanpa server, sebelum implementasi, Anda harus mengevaluasi logika aplikasi terlebih dahulu dan memahami masalah apa yang dapat diselesaikan Tanpa Server dalam kasus tertentu.
Tanpa server dan Selectel
Di Selectel kita sudah berada di sana melalui panel kontrol kami. Sekarang kami sedang membangun platform FaaS kami sendiri. Kami ingin pengembang dapat menyelesaikan masalah mereka menggunakan Tanpa Server melalui antarmuka yang nyaman dan fleksibel.
Jika Anda memiliki gagasan tentang platform FaaS yang ideal dan bagaimana Anda ingin menggunakan Tanpa Server dalam proyek Anda, bagikan di komentar. Kami akan mempertimbangkan keinginan Anda saat mengembangkan platform.
Bahan yang digunakan dalam artikel:
Sumber: www.habr.com