Arsitektur Sistem Data Serverless

• Masa depan layanan data cloud adalah struktur "berskala besar, multi-tenant"
  • Alasan layanan SaaS kelas atas seperti S3 dapat menawarkan kesederhanaan, keandalan, durabilitas, skalabilitas, dan harga murah adalah karena teknologi layanan ini secara struktural dirancang untuk menyediakan hal-hal tersebut
  • Menyediakan layanan kepada pelanggan melalui kumpulan sumber daya berskala besar menjamin efisiensi dan keandalan berkat skala

[Definisi sistem Serverless Multi-Tenant]

Definisi "Multi-Tenancy"

• Multi-tenant berkaitan dengan berbagi sumber daya dengan menempatkan beban kerja bersama pada perangkat keras yang sama
• Membangun sistem di cloud berarti beberapa tenant dilayani melalui instance komputasi bersama (misalnya Amazon EC2 atau Google Compute) atau layanan PaaS bersama (misalnya cloud object storage)
• Multi-tenant didefinisikan sebagai "memberikan layanan kepada beberapa tenant di atas sumber daya bersama (seperti server tervirtualisasi, drive, dan layanan building block PaaS)"
• Berbagai model berbagi sumber daya dapat digunakan, dan beberapa sistem menggabungkan beberapa model berbagi di seluruh komponen
  • Proses bersama: proses perangkat lunak yang sama melayani beberapa tenant. Isolasi data dan keamanan bersifat logis
  • Kontainer: menjalankan node single-tenant dan mengemas beberapa kontainer per host. Umumnya dilakukan melalui Kubernetes, di mana node K8s tertentu menampung pod dari banyak tenant
  • Virtualisasi: menjalankan node single-tenant di VM (misalnya QEMU) atau microVM (misalnya Firecracker), lalu mengemas beberapa VM per host. Kubernetes juga dapat digunakan bersama VM melalui Kata Containers
• Ada juga metode isolasi V8 yang memungkinkan tenant berbagi proses V8 yang sama dalam konteks ringan yang terpisah, tetapi sejauh ini belum terlihat digunakan pada sistem data

Definisi serverless

• Pelanggan tidak memilih jenis server atau secara eksplisit memilih perangkat keras
• Sistem seperti ini bergantung pada tingkat elastisitas dan mobilitas tertentu agar dapat menangani permintaan semua beban kerja tanpa pelanggan perlu secara eksplisit menyesuaikan ukuran perangkat keras
  • Elastisitas: kemampuan untuk memperbesar atau memperkecil layanan sesuai kebutuhan beban kerja
  • Mobilitas: kemampuan layanan untuk memindahkan dan menyeimbangkan beban kerja secara internal guna memenuhi persyaratan performa dan stabilitas
• Model serverless menggunakan penetapan harga berbasis penggunaan yang semakin penting bagi pelanggan
  • Banyak pelanggan tidak ingin membuat komitmen besar di muka dan lebih memilih hanya ditagih sesuai penggunaan
  • Penetapan harga berbasis penggunaan memiliki banyak variasi yang sangat berbeda tergantung beban kerja dan implementasi sistem dasarnya
    • Membayar per (jutaan) operasi
    • Membayar biaya untuk penggunaan CPU dan memori dari beban kerja
    • Membayar per GB penyimpanan
    • Membayar untuk unit performa/kapasitas virtual yang terkait dengan sumber daya dan laju kerja (misalnya RCU/WCU pada DynamoDB)
    • Model hibrida di mana pelanggan membayar sebagian kapasitas dasar dan membayar penggunaan di atasnya ("bayar dasar, bayar saat puncak")

[Tantangan umum]

Bekerja dalam batasan yang ditentukan oleh beban kerja

• Banyak batasan yang ditentukan oleh beban kerja suatu sistem data menjadi pendorong penting bagi arsitektur dasarnya.
  • Persyaratan latensi/ketersediaan
  • Persyaratan konsistensi
  • Korelasi/ketergantungan antara permintaan dan data
  • Pola akses sekuensial versus pola akses acak
  • Variasi pekerjaan yang dilakukan per permintaan
  • Ukuran data
  • Protokol berorientasi sesi versus berorientasi permintaan, mekanisme push versus pull
  • Intensitas komputasi dari pekerjaan
• Persyaratan latensi dan konsistensi yang longgar memberi lebih banyak kebebasan kepada engineer
  • Sistem berlatensi pendek memiliki batasan dalam memperkenalkan komponen berlatensi tinggi, sehingga memanfaatkan keunggulan biaya rendah dan durabilitas tinggi dari cloud object storage menjadi contoh yang baik
  • Sistem eventual consistency dapat menghindari dilema ini dengan menulis data secara asinkron ke object storage tanpa memasukkannya ke jalur panas data sinkron
  • Sistem dengan latensi pendek dan konsistensi kuat tidak memiliki kartu bebas seperti ini
• Ketika batasan seperti latensi pendek digabungkan, lokalitas spasial dan temporal dari beban kerja dapat memengaruhi pilihan arsitektur
  • Misalnya, untuk beban kerja yang ditandai dengan pemindaian sekuensial, lebih baik menyimpan rentang data yang berurutan bersama-sama agar pemindaian dari disk cepat dan efisien
  • Memecah rentang ini menjadi subrentang yang lebih kecil membantu mengelola hotspot, tetapi keduanya saling bertentangan sehingga perlu dicari keseimbangannya
  • Pola akses acak yang hampir tidak memiliki korelasi antar permintaan individual dapat memanfaatkan ruang alamat datar yang dapat didistribusikan secara tipis dan merata ke banyak server
• Protokol berorientasi sesi yang membuat koneksi persisten umumnya lebih sulit dibanding protokol berorientasi permintaan di mana setiap permintaan independen dari permintaan sebelumnya
  • Koneksi persisten mungkin memerlukan connection pooling, dan gangguan seperti rolling node maupun penyeimbangan data dapat berdampak secara eksternal dan terlihat oleh klien
• Ada sistem yang merupakan API penyimpanan sederhana seperti object storage atau Kafka API, dan ada juga sistem yang intensif komputasi seperti database SQL
  • Ini mengarah pada tema prediktabilitas dan variabilitas jumlah pekerjaan yang diperlukan untuk menangani setiap permintaan
  • Sebagai contoh ekstrem, ada API data streaming seperti Kafka yang hanya perlu mengambil blok record berurutan, sedangkan di sisi lain ada SQL yang dapat menyebabkan perbedaan beban kerja yang sangat besar antar query

Isolasi tenant

• Berbagi sumber daya meningkatkan utilisasi perangkat keras, tetapi juga dapat memicu persaingan sumber daya di mana beban kerja satu tenant memengaruhi tenant lain
• Dalam sistem multi-tenant, tenant yang dilayani di atas sumber daya perangkat keras bersama harus tetap dijamin seolah-olah mereka dilayani oleh layanan khusus mereka sendiri

Pemisahan storage dan compute

• Pemisahan storage dan compute adalah prinsip desain inti yang dalam kadar tertentu diterapkan oleh semua sistem yang diteliti sejauh ini
• Karena tren perangkat keras, pemisahan storage dan compute makin menjadi kenyataan, sebagian karena jaringan tidak lagi menjadi bottleneck seperti dulu
• Throughput jaringan memang meningkat, tetapi karena cloud object storage menjadi pusat, tetap ada tantangan baru akibat pemisahan ini
  • Cloud object storage masih relatif berlatensi tinggi, sangat durable, dan murah
  • Namun, sulit untuk diperkenalkan ke beban kerja yang biasanya berlatensi rendah seperti database OLTP
  • Selain itu, model ekonomi cloud object storage tidak menguntungkan bagi desain yang bergantung pada banyak objek kecil, sehingga data harus diakumulasikan ke objek yang lebih besar dengan lebih sedikit permintaan, yang makin memperumit lifecycle sistem berlatensi rendah
• Engineer dapat memasukkan object storage ke dalam sistem berlatensi rendah dengan menempatkan write cache yang durable dan fault-tolerant serta read cache prediktif di depan object storage yang lambat untuk mengatasi masalah latensinya
  • Write cache yang durable ini pada dasarnya adalah cluster server yang mengimplementasikan protokol replikasi dan menulis data ke block storage
    • Di latar belakang, cluster mengunggah data secara asinkron ke object storage mengikuti pola ekonomis dengan menulis lebih sedikit file berukuran besar
    • Write cache fault-tolerant mendukung penulisan berlatensi pendek dengan baik
  • Dalam arsitektur ini, yang bisa menjadi masalah adalah read cache
    • Beban kerja sekuensial seperti event streaming itu sederhana dan sangat efektif
    • Selama aggregate prefetching dapat mengikuti permintaan, pembacaan harus selalu mencapai read cache lokal
    • Database menghadapi masalah yang lebih sulit karena pola akses acak yang sulit diprediksi, tetapi table scan tetap dapat memperoleh manfaat dari read-ahead
• Mengimplementasikan write cache terdistribusi yang fault-tolerant dengan protokol replikasi bukan hal yang sederhana, dan di lingkungan multi-AZ dapat timbul biaya lain seperti biaya lintas-AZ
  • Namun untuk saat ini, tidak ada alternatif bagi sistem berlatensi rendah yang ingin menggunakan object storage yang murah dan durable sebagai penyimpanan data utama
  • Sistem lain yang juga berlatensi rendah sebaiknya menghindari penggunaan cloud object storage sama sekali dan lebih memprioritaskan latensi pendek yang dapat diprediksi
  • Cloud storage digunakan secara luas, tetapi bukan solusi universal karena trade-off latensi

Manajemen panas

• Manajemen panas berarti mendistribusikan beban se-merata mungkin ke beberapa node penyimpanan untuk menghindari hotspot yang dapat menimbulkan masalah performa yang terlihat dari luar seperti lonjakan latensi atau penurunan jumlah operasi per detik
• Ini juga bisa disebut load balancing, tetapi istilah load balancer biasanya dipakai untuk node stateless
• Dalam sistem stateful, hotspot dapat muncul ketika objek yang sangat diminati dikelompokkan pada node penyimpanan tertentu sehingga menimbulkan contention
• Load balancer dapat menyebarkan beban secara merata ke kumpulan node stateless dengan strategi sederhana seperti acak, least-connections, atau beberapa variasi FIFO, tetapi sistem stateful harus merutekan permintaan ke node berdasarkan lokasi data
• Memindahkan data untuk mendistribusikan ulang beban biasanya disebut rebalancing
• Masalah yang lebih kompleks adalah distribusi beban dapat berubah seiring waktu
  • Distribusi data menjadi proses dinamis yang harus menangani segalanya, mulai dari lonjakan jangka pendek yang memengaruhi subset data kecil hingga perubahan beban yang lebih besar akibat pola harian atau peristiwa musiman yang muncul di banyak tenant
• Dataset berskala besar seperti database besar atau event stream ber-throughput tinggi perlu di-sharding agar beban dapat didistribusikan secara efektif
  • Rebalancing berarti rebalancing shard, dan sistem bahkan dapat membagi maupun menggabungkan shard saat distribusi beban berubah
  • Namun, ada trade-off lain terkait jumlah dan ukuran shard, seperti lokalitas data
  • Di satu sisi, semakin banyak data ditempatkan bersama, semakin efisien pengambilannya
  • Di sisi lain, biaya pekerjaan komputasi yang harus mengambil dari terlalu banyak shard dapat melebihi manfaat dari penyebaran beban ke lebih banyak server
• Manajemen panas juga dapat diperlukan dalam sistem single-tenant, jadi ini bukan masalah khusus multi-tenant saja
  • Namun, dalam sistem data MT, manajemen panas menjadi lebih penting agar tenant tidak mengalami fluktuasi kualitas layanan

Mencapai utilisasi sumber daya yang tinggi

• Salah satu motivasi utama penerapan arsitektur multi-tenant serverless adalah memberikan efisiensi ekonomi yang lebih baik dengan menggunakan sumber daya perangkat keras dasar secara lebih efisien
• Meningkatkan utilisasi sumber daya melalui resource pooling adalah hal terpenting, tetapi mencapainya sambil menjaga isolasi tenant dan performa yang dapat diprediksi merupakan tantangan yang sulit

Cold start

• Sistem serverless yang menurunkan sumber daya hingga nol per tenant dapat menghadapi masalah cold start ketika tenant melanjutkan kembali beban kerjanya
• Cold start sejak awal telah menjadi fokus utama serverless, dan beberapa sistem data serverless juga dapat terpengaruh olehnya
• Pada beberapa sistem, cold start tidak terjadi sama sekali, sementara pada sistem lain cold start pada dasarnya tak terhindarkan karena arsitektur dan penawaran produk scale-to-zero
• Dalam semua kasus yang saya lihat, masalah cold start merupakan keputusan produk, dan tingkat pengurangan sumber daya dapat berbeda tergantung model paket dan harga
• Pada akhirnya, pelanggan dan penyedia dapat memilih trade-off yang sesuai dengan kebutuhan masing-masing

Sistem yang diteliti

• Group 1 - Storage APIs (compute-light)
  • Amazon DynamoDB (chapter 1)
  • Kora - Serverless Kafka engine inside Confluent Cloud (chapter 2)
  • Backblaze B2 (planned)
• Group 2 - SQL OLTP databases (compute-heavy)
  • Neon - serverless PostgreSQL (chapter 3)
  • CockroachDB’s serverless multi-tenant architecture. (in progress)
  • Planetscale (planned)
• Group 3 - SQL OLAP databases and data warehouses (compute-heavy)
  • Google BigQuery (planned)
  • ClickHouse Cloud (in progress).
• Pekerjaan ini akan terus berlanjut, tetapi ada rencana posting semacam 'kesimpulan' pada Januari/Februari 2024