Membangun Layanan Web Highly Available tanpa Database

Membangun Layanan Web Highly Available tanpa Database

Eksplorasi

• Untuk startup baru, biasanya dipilih framework web seperti Rails, Django, atau Node, serta database seperti MySQL, PostgreSQL, atau MongoDB
• Namun bagaimana jika layanan web dan instance database bisa digabung menjadi satu? Pendekatan ini dimungkinkan dengan menyimpan semua data di RAM
• Jika RAM digunakan sebagai database, tidak perlu melakukan serialisasi data dengan kueri SQL
• Indeks dapat diimplementasikan menggunakan hash table di dalam memori
• Pekerjaan latar belakang dapat ditangani sebagai thread di dalam satu proses besar
• Jika proses mengalami crash, pemulihan dimungkinkan dengan mengambil snapshot RAM secara berkala dan mencatat perubahan ke disk

Skalabilitas

• Ketika muncul pelanggan yang membutuhkan high availability, server direplikasi menggunakan algoritma konsensus Raft
• Jika server leader mati, leader baru akan dipilih untuk menangani permintaan
• Dengan cara ini, rolling deployment dapat dilakukan tanpa perlu me-restart server

Ekstraksi

• Saat jumlah pelanggan besar bertambah, layanan web dapat dipecah dan ditangani melalui sharding
• Setiap pelanggan enterprise disediakan cluster khusus
• Bottleneck utama dapat berupa performa thread commit

Stack kami

• Menggunakan Common Lisp: sangat baik dalam mendukung multithreading dan cocok untuk hot reloading kode
• Menggunakan bknr.datastore dan bknr.cluster: memakai library Braft dari Baidu untuk implementasi Raft
• Menggunakan EFS untuk menyimpan file gambar: lebih mudah untuk penanganan error dan pengujian dibandingkan S3

Ringkasan

• Arsitektur ini cocok untuk startup baru, dan dengan Common Lisp banyak tooling sudah tersedia
• Ucapan terima kasih kepada para kontributor bknr.datastore, Braft, dan Raft

Ringkasan GN⁺

• Artikel ini memperkenalkan arsitektur baru untuk membangun layanan web highly available tanpa database
• Dengan menggunakan RAM sebagai database dan algoritma konsensus Raft, high availability dapat dijamin
• Menggunakan Common Lisp untuk mendukung multithreading dan hot reloading kode
• Arsitektur ini cocok untuk startup baru serta memungkinkan pengembangan dan debugging yang cepat
• Proyek dengan fungsi serupa antara lain Redis dan Memcached

[GN⁺]

Komentar Hacker News

• Aneh membuat log transaksi sendiri alih-alih menggunakan SQLite

  • Jika data muat di satu server, lebih baik jalankan saja database di server itu
  • Jika data muat di RAM, menggunakan ramdisk dan mereplikasi ke penyimpanan permanen dengan alat standar itu lebih sederhana

• Membuat database in-memory sendiri alih-alih menggunakan MySQL, Postgres, Redis, MongoDB, dan sebagainya itu rumit

  • Transaksi harus diserialisasi dan ditulis ke disk
  • Log transaksi harus disinkronkan antar web server dan database in-memory harus diperbarui
  • Harus menulis algoritma penyelesaian konflik
  • Harus melakukan sharding web server per tenant dan menulis lapisan load balancing

• Tidak mau mempelajari aspek dasar MySQL atau Postgres adalah pemborosan waktu

  • Saat dijalankan di penyedia cloud publik, masalah konkurensi bisa diatasi dengan tuning dasar
  • Menambahkan 10 juta baris bukan masalah besar
  • Lebih bijak menunggu sampai situasinya benar-benar memburuk lalu mengatasinya

• Arsitekturnya mirip dengan Nomad, Consul, dan Vault dari HashiCorp

  • Pengalaman pengembangnya bagus
  • Status in-memory bisa diatur sesuka hati
  • Tidak cocok untuk startup baru
  • Upgrade sangat sulit, terutama

• Ada kesalahpahaman bahwa RAM itu sangat murah

  • Performa SSD dan vCPU meningkat pesat, tetapi harga RAM tidak banyak turun
  • Harga DRAM berfluktuasi secara siklis, dan baru belakangan ini sedikit lebih murah

• Pernah melihat proyek yang menggunakan direktori file system sebagai tabel, dan file JSON sebagai baris

  • Sudah mempertimbangkan Redis, Mongo, dan Postgres, tetapi malah membangun database sendiri
  • Menggunakan token inovatif untuk membangun database itu tidak efisien

• Menggunakan database relasional lebih andal

  • Ada redundansi bawaan, log transaksi, backup, dan fitur pemulihan
  • Dalam kebanyakan kasus, lebih baik menggunakan database

• Mengimplementasikan lapisan konsensus Raft sendiri untuk menghindari hal yang kompleks

  • Menggunakan Redis mungkin bisa lebih sederhana

• Aplikasi desktop dan mobile modern sering menggunakan database seperti SQLite

  • Penyimpanan dan query data relasional itu berguna

• Membangun database in-memory sendiri tidak lebih sederhana daripada memasang Postgres atau SQLite

  • Menulis SQL lebih mudah daripada menulis kode konkurensi