Database “serverless” saat ini bukan serverless yang sebenarnya

Ilusi serverless

• Serverless telah menjadi tren inti dalam teknologi cloud.
• Paradigma ini memungkinkan pengembang untuk fokus pada logika bisnis tanpa beban pengelolaan server.
• Model pembayaran: Pengguna hanya membayar sesuai pemakaian, dan biaya operasional praktis nol.
• Berbagai database serverless telah muncul di pasar, dengan pemain mapan seperti Elastic, Confluent, Pinecone serta pendatang baru seperti Neon, WarpStream, Upstash, dan Turbopuffer yang bersaing.

Masalah pada database serverless yang ada

• Banyak database serverless bukanlah benar-benar serverless.
• Sebagian besar layanan dibangun di atas arsitektur cloud-native, yaitu desain inovatif untuk era kumpulan server (server pool).
• Mereka mengelola klaster server dan menggunakan perangkat lunak kompleks serta intervensi manusia untuk memprediksi beban dan mengelola kapasitas.
• Ilusi seperti ini menimbulkan masalah nyata bagi pengguna.

Dampak arsitektur yang tidak efisien

• Ketidaksesuaian arsitektur bukan sekadar detail teknis, tetapi menyebabkan masalah nyata bagi pengguna.
• Pengguna membayar untuk server yang menganggur, karena klaster server selalu berjalan untuk beragam kebutuhan.
• Masalah skalabilitas: menambahkan server baru ke klaster membutuhkan beberapa menit, sehingga lonjakan trafik mendadak tidak bisa ditangani secara instan.
• Pilihan yang terbatas: karena memerlukan pengelolaan infrastruktur di setiap wilayah cloud, opsi wilayah layanan menjadi terbatas bagi pengguna.

Model yang tidak berkelanjutan

• Database “serverless” berbasis arsitektur server pool tidak berkelanjutan.
• Penyedia memerlukan investasi besar untuk mengoperasikan klaster server, dan itu bisa mendorong perubahan harga.
• Pengguna ringan menanggung biaya berlebih untuk menopang sistem, sementara pengguna sukses berisiko menghadapi kenaikan harga tak terduga.

Kebutuhan arsitektur serverless-native

• Pada awal era komputasi cloud, mayoritas database ‘cloud’ adalah database warisan (legacy).
• Arsitektur serverless-native menyerahkan seluruh pengelolaan infrastruktur ke penyedia cloud, dan menggunakan fungsi stateless serta layanan serverless sebagai pengganti klaster server.
• Pendekatan ini memperlakukan infrastruktur cloud sebagai satu superkomputer besar tunggal, memungkinkan skalabilitas instan dan model bayar-per-permintaan yang sesungguhnya.
• Tes Litmus: untuk memeriksa apakah suatu database benar-benar serverless-native, pastikan ia dapat dideploy ke akun cloud tanpa provisioning klaster Kubernetes maupun VM.

Pengenalan LambdaDB

• LambdaDB adalah mesin pencari baru yang dibangun secara serverless-native.
• Sistem ini dijalankan sebagai sekumpulan fungsi dan sumber daya serverless, dan memisahkan sepenuhnya logika database dari infrastruktur.
• Permintaan pengguna mengalir lewat gateway regional dan dirutekan ke Control Functions (fungsi kontrol) atau Data Functions (fungsi data) sesuai jenis permintaan.
• Fitur enterprise: LambdaDB menyediakan fitur seperti point-in-time restore dan zero-copy cloning, tanpa kebutuhan pengelolaan infrastruktur.

Cara kerja LambdaDB

• Arsitektur LambdaDB: semua komponennya dibangun menggunakan layanan cloud serverless.
• Gateway memverifikasi API key dari permintaan pengguna, lalu merutekan permintaan ke fungsi kontrol atau fungsi data.
• Fungsi kontrol menangani operasi CRUD dan permintaan manajemen data, sedangkan fungsi data menangani operasi tulis dan baca data yang sebenarnya.
• Jalur tulis: Writer Function mencatat permintaan, menulisnya ke buffer tulis serverless yang tahan lama, lalu merespons klien.

Paradoks efisiensi biaya

• LambdaDB menurunkan biaya komputasi dibandingkan database berbasis server pool.
• Harga satuan Lambda lebih tinggi daripada instans EC2, tetapi biaya tetap lebih hemat berkat redundansi yang diperlukan untuk menjamin high availability dan fault tolerance.
• Pemborosan kapasitas tetap: utilisasi komputasi rata-rata perusahaan hanya 10-20%, sehingga komputasi serverless bisa menghemat biaya sebesar 50-90%.

Performa dan skalabilitas

• Performa dan skalabilitas: LambdaDB memamerkan performanya melalui eksperimen penambahan jutaan vektor menggunakan vektor berdimensi 960.
• Latensi tulis: untuk 10 upsert per detik, median latensi adalah 43ms, dan latensi tetap relatif stabil ketika trafik naik 100x.
• Latensi kueri: latensi kueri tetap stabil di berbagai beban, dengan persentil ke-99 berkisar antara 172ms dan 210ms.
• Upaya optimalisasi: dilakukan optimisasi berkelanjutan untuk memperbaiki latensi fungsi kueri sambil terus meningkatkan infrastruktur serverless.

Manfaat untuk pelanggan

• Penghematan biaya: LambdaDB lebih dari 10x lebih murah karena tidak ada server menganggur.
• Skalabilitas instan dan tak terbatas: LambdaDB dapat menskalakan ke ribuan fungsi paralel dalam hitungan milidetik.
• Mulai dan skala dengan mudah: Anda dapat membangun aplikasi AI yang kuat, dengan arsitektur yang tetap sederhana dan hemat biaya seiring pertumbuhan.
• Fitur enterprise: menyediakan point-in-time restore dan zero-copy cloning tanpa menambah kompleksitas maupun biaya.

Rencana dan visi ke depan

• LambdaDB saat ini telah menangani ratusan juta dokumen dengan ratusan juta permintaan per hari.
• Rencana jangka panjang: akan mendukung model data lain, termasuk data relasional, streaming, key-value, graph, dan lainnya.

[davidshim]

Idenya bagus, tetapi untuk mengurangi latensi query secara berarti state menjadi kebutuhan yang tak terhindarkan. Dibandingkan dengan MySQL, PostgreSQL, dan sebagainya, latensi querynya tampak hampir 100 kali lebih tinggi. Rasanya mirip seperti menulis dan membaca input/output di sistem berkas.

[stevenk]

Terima kasih atas masukannya. Poin bahwa "state perlu untuk mengurangi latensi" yang Anda sebutkan tepat sekali menyoroti trade-off inti dari arsitektur kami.

Pertama, terkait latensi query, dalam benchmark kami, p99 (persentil ke-99) berada di kisaran sekitar 130-210 ms. Mungkin bagian yang Anda katakan selisihnya 100x merujuk pada kasus terburuk yang disebutkan di dalam artikel, yaitu bahwa saat cold start bisa memakan waktu beberapa detik. Seperti yang Anda soroti, bagian ini jelas merupakan kelemahan arsitektur kami, dan seperti disebutkan di artikel, di lingkungan produksi ini terjadi di bawah 0,01% (P99.99). Selain itu, sebagian besar query lainnya dirancang agar memanfaatkan memori lokal dan disk lokal setiap Lambda sebagai cache untuk menghasilkan performa yang stabil.

Oleh karena itu, seperti yang Anda sebutkan, untuk sistem transaksi keuangan berlatensi sangat rendah yang membutuhkan jaminan semua query di bawah 10ms, arsitektur seperti ini mungkin tidak cocok. Namun, untuk mayoritas aplikasi pencarian dan rekomendasi berbasis AI, latensi sekitar 100-200ms pada P99 sudah cukup baik, dan menurut saya keuntungan mengurangi biaya infrastruktur dan beban operasional sebesar lebih dari 90% jauh lebih besar.

Sekali lagi, terima kasih atas masukan yang mendalam.

[davidshim]

Seperti yang Anda sampaikan, sepertinya ini lebih cocok dipandang sebagai solusi yang dapat digunakan secara “serverless” yang sesungguhnya pada situasi tertentu, daripada sebagai database serbaguna.

[davidshim]

Saya tidak menyangka akan ada balasan dalam bahasa Korea! (Ternyata saya menulisnya terlalu sinis...)

Awalnya saya benar-benar menganggap ini sebagai ide yang revolusioner. Sebenarnya, masalah terbesar database serverless adalah adanya server nyata yang berjalan di tempat yang tidak terlihat. Jadi ketika trafik membludak, akan terjadi kondisi tidak responsif sampai server itu dialokasikan (sekitar 5 menit). Karena itu, serverless DB cloud yang ada saat ini (seperti AWS dan lain-lain) sulit digunakan pada level produksi.

Saya sempat berpikir, "coba saja?", tapi alasan saya khawatir adalah bahwa kita harus mengimplementasikan logika biner untuk pengindeksan, pengurutan, dan lainnya yang telah dibuat di mysql, postgresql, dan sebagainya, sehingga saya bertanya-tanya betapa sulitnya membuat ulang proyek DB open source yang andal di atas Lambda.

Karena ini adalah produk yang Anda buat sendiri, saya menantikan banyak perkembangan ke depannya~!

[stevenk]

Terima kasih banyak atas tanggapannya. Sesuai dengan yang Anda sampaikan, hal ini tidak cocok untuk kasus penggunaan RDB dan lebih tepat dipahami sebagai mesin pencari (Elasticsearch) serta vector DB (Pinecone). Di internal, kami juga memanfaatkan Lucene yang telah teruji selama bertahun-tahun untuk mendukung fitur-fitur seperti pengindeksan, pengurutan, dan agregasi. Terima kasih :)