Tantangan tersembunyi dari fungsi tanpa server

· 4 min read
Tantangan tersembunyi dari fungsi tanpa server
Photo by C Dustin / Unsplash

Fungsi Tanpa Server Sangat Cocok untuk Tugas Kecil 

Komputasi berbasis cloud yang menggunakan fungsi tanpa server telah memperoleh popularitas yang luas. Daya tariknya untuk menerapkan fungsionalitas baru berasal dari kesederhanaan  komputasi tanpa server . Anda dapat menggunakan fungsi tanpa server untuk menganalisis foto yang masuk atau memproses suatu peristiwa dari perangkat IoT. Cepat, sederhana, dan dapat diskalakan. Anda tidak perlu mengalokasikan dan memelihara sumber daya komputasi – Anda cukup menerapkan kode aplikasi. Vendor cloud utama, termasuk AWS ,  Microsoft , dan  Google , semuanya menawarkan fungsi tanpa server. 

Untuk aplikasi sederhana atau ad hoc, fungsi tanpa server sangat masuk akal. Namun, apakah fungsi tersebut sesuai untuk alur kerja kompleks yang membaca dan memperbarui set data penting yang terus-menerus? Pertimbangkan maskapai penerbangan yang mengelola ribuan penerbangan setiap hari. Penyimpanan data NO-SQL yang dapat diskalakan (seperti  Amazon Dynamo DB  atau  Azure Cosmos DB ) dapat menyimpan data yang menjelaskan penerbangan, penumpang, tas, penugasan gerbang, penjadwalan pilot, dan banyak lagi. Sementara fungsi tanpa server dapat mengakses penyimpanan data ini untuk memproses kejadian, seperti pembatalan penerbangan dan pemesanan ulang penumpang, apakah itu cara terbaik untuk mengimplementasikan pemrosesan kejadian dalam jumlah besar yang diandalkan oleh maskapai penerbangan?

Masalah dan Keterbatasan 

Kekuatan fungsi serverless, yaitu bahwa fungsi tersebut bersifat tanpa server, menciptakan batasan bawaan. Berdasarkan sifatnya, fungsi tersebut memerlukan overhead untuk mengalokasikan sumber daya komputasi saat dipanggil. Selain itu, fungsi tersebut bersifat stateless dan harus mengambil data dari penyimpanan data eksternal. Hal ini semakin memperlambatnya. Fungsi tersebut tidak dapat memanfaatkan caching lokal dalam memori untuk menghindari pergerakan data; data harus selalu mengalir melalui jaringan cloud ke tempat fungsi serverless berjalan. 

Saat membangun sistem besar, fungsi tanpa server juga tidak menawarkan arsitektur perangkat lunak yang jelas untuk mengimplementasikan alur kerja yang kompleks. Pengembang perlu menerapkan 'pemisahan masalah' yang jelas dalam kode yang dijalankan setiap fungsi. Saat membuat beberapa fungsi tanpa server, mudah untuk terjebak dalam duplikasi fungsi dan mengembangkan basis kode yang kompleks dan tidak dapat dikelola. Selain itu, fungsi tanpa server dapat menghasilkan pengecualian yang tidak biasa, seperti batas waktu dan kuota, yang harus ditangani oleh logika aplikasi.

Alternatif: Pindahkan Kode ke Data

Kita dapat menghindari keterbatasan fungsi tanpa server dengan melakukan hal sebaliknya: memindahkan kode ke data. Pertimbangkan untuk menggunakan komputasi dalam memori yang dapat diskalakan untuk menjalankan kode yang diimplementasikan oleh fungsi tanpa server. Komputasi dalam memori menyimpan objek dalam memori utama yang didistribusikan di seluruh kluster server. Komputasi ini dapat memanggil fungsi pada objek ini dengan menerima pesan. Komputasi ini juga dapat mengambil data dan menyimpan perubahan pada penyimpanan data, seperti penyimpanan NO-SQL.

Alih-alih mendefinisikan fungsi tanpa server yang beroperasi pada data yang disimpan dari jarak jauh, kita cukup mengirim pesan ke objek yang disimpan dalam platform komputasi dalam memori untuk menjalankan fungsi tersebut. Pendekatan ini mempercepat pemrosesan dengan menghindari kebutuhan untuk mengakses penyimpanan data berulang kali, yang mengurangi jumlah data yang harus mengalir melalui jaringan. Karena komputasi data dalam memori sangat skalabel, ia dapat menangani beban kerja yang sangat besar yang melibatkan sejumlah besar objek. Selain itu, pemrosesan pesan dengan ketersediaan tinggi menghindari kebutuhan kode aplikasi untuk menangani pengecualian lingkungan.

Komputasi dalam memori menawarkan manfaat utama untuk menyusun kode yang mendefinisikan alur kerja kompleks dengan menggabungkan kekuatan penyimpanan struktur data, seperti  Redis , dan model aktor . Tidak seperti fungsi tanpa server, kisi data dalam memori dapat membatasi pemrosesan pada objek ke metode yang ditentukan oleh tipe datanya. Ini membantu pengembang menghindari penerapan kode duplikat dalam beberapa fungsi tanpa server. Ini juga menghindari kebutuhan untuk mengimplementasikan penguncian objek, yang dapat menjadi masalah untuk penyimpanan data persisten.

Contoh Benchmarking

Untuk mengukur perbedaan kinerja antara fungsi tanpa server dan komputasi dalam memori, kami membandingkan alur kerja sederhana yang diimplementasikan dengan fungsi AWS Lambda dengan alur kerja yang sama yang dibangun menggunakan  ScaleOut Digital Twins , arsitektur komputasi dalam memori yang dapat diskalakan. Alur kerja ini mewakili pemrosesan peristiwa yang mungkin digunakan maskapai penerbangan untuk membatalkan penerbangan dan memesan ulang semua penumpang pada penerbangan lain. Ini menggunakan dua tipe data, objek penerbangan dan penumpang, dan menyimpan semua instans di Dynamo DB. Pengontrol peristiwa memicu pembatalan untuk sekelompok penerbangan dan mengukur waktu yang diperlukan untuk menyelesaikan semua pemesanan ulang.

Dalam implementasi tanpa server, pengontrol kejadian memicu fungsi lambda untuk membatalkan setiap penerbangan. Setiap 'lambda penumpang' memesan ulang penumpang dengan memilih penerbangan yang berbeda dan memperbarui informasi penumpang. Kemudian, pengontrol kejadian memicu fungsi tanpa server yang mengonfirmasi penghapusan dari penerbangan asli dan menambahkan penumpang ke penerbangan baru. Fungsi-fungsi ini memerlukan penggunaan penguncian untuk menyinkronkan akses ke objek Dynamo DB.

Implementasi kembaran digital secara dinamis membuat objek dalam memori untuk semua penerbangan dan penumpang saat objek ini diakses dari Dynamo DB. Objek penerbangan menerima pesan pembatalan dari pengendali acara dan mengirim pesan ke objek kembaran digital penumpang. Kembaran digital penumpang memesan ulang sendiri dengan memilih penerbangan yang berbeda dan mengirim pesan ke penerbangan lama dan baru. Kode aplikasi tidak perlu menggunakan penguncian, dan platform dalam memori secara otomatis menyimpan pembaruan kembali ke Dynamo DB.

Pengukuran kinerja menunjukkan bahwa kembaran digital memproses 25 pembatalan penerbangan dengan 100 penumpang per penerbangan lebih dari 11 kali lebih cepat daripada fungsi tanpa server. Kami tidak dapat menskalakan fungsi tanpa server untuk menjalankan beban kerja target pembatalan 250 penerbangan dengan masing-masing 250 penumpang, tetapi ScaleOut Digital Twins tidak mengalami kesulitan memproses dua kali lipat beban kerja target ini dengan 500 penerbangan.

Menyimpulkan

Meskipun fungsi tanpa server sangat cocok untuk aplikasi kecil dan ad hoc, fungsi tersebut mungkin bukan pilihan terbaik saat membangun alur kerja kompleks yang harus mengelola banyak objek data dan diskalakan untuk menangani beban kerja besar. Memindahkan kode ke data dengan komputasi dalam memori mungkin merupakan pilihan yang lebih baik. Fungsi tersebut meningkatkan kinerja dengan meminimalkan pergerakan data, dan memberikan skalabilitas tinggi. Fungsi tersebut juga menyederhanakan desain aplikasi dengan memanfaatkan akses terstruktur ke data.

Untuk mempelajari lebih lanjut tentang ScaleOut Digital Twins dan menguji pendekatan ini untuk mengelola objek data dalam alur kerja yang kompleks, kunjungi: https://www.scaleoutdigitaltwins.com/landing/scaleout-data-twins.