Flawless - Mesin eksekusi tahan gangguan untuk Rust

 (flawless.dev)
1 poin oleh GN⁺ 2023-10-27 | 1 komentar | Bagikan ke WhatsApp
  • Flawless adalah mesin eksekusi komputasi tahan lama yang membantu kode tetap berjalan sampai selesai meskipun terjadi gangguan
  • Workflow ditulis sebagai fungsi Rust biasa, tetapi dikompilasi ke WebAssembly alih-alih kode native dan dijalankan dalam lingkungan deterministik
  • Efek samping nondeterministik hanya muncul di titik yang berinteraksi dengan dunia luar, seperti permintaan HTTP atau pembuatan bilangan acak, dan Flawless menyimpannya sebagai log
  • Jika eksekusi terputus, Flawless menggunakan log yang tersimpan untuk mengejar kembali hingga status yang sama, dan tidak mengulangi efek samping yang sudah dijalankan
  • Pengembang dapat merepresentasikan status persisten dengan kode dan variabel lokal tanpa harus memodelkan seluruh status langsung di database, sehingga dapat melanjutkan dari titik terhenti bahkan setelah server dimulai ulang

Model eksekusi yang merepresentasikan status persisten dengan kode

  • Flawless adalah mesin komputasi tahan lama yang memastikan kode terus dieksekusi sampai selesai meskipun terjadi kegagalan perangkat keras atau perangkat lunak
  • Pengalaman pengguna yang kompleks membutuhkan UI dan status yang kompleks, tetapi sulit untuk memodelkan seluruh status langsung di dalam database
  • Agar kemajuan pengguna tidak hilang meskipun halaman tidak sengaja dimuat ulang, aplikasi modern memerlukan penyimpanan persisten
  • Flawless bertujuan memudahkan ekspresi perilaku aplikasi yang kompleks dengan memungkinkan status persisten dimodelkan melalui kode dan variabel lokal

Eksekusi berbasis WebAssembly dan pemulihan dari gangguan

  • Workflow ditulis sebagai fungsi Rust biasa dan dapat memuat logika apa pun
  • Fungsi dikompilasi ke WebAssembly alih-alih kode native, lalu dijalankan dalam lingkungan yang sepenuhnya deterministik
  • Nondeterminisme hanya diperkenalkan saat berinteraksi dengan dunia luar, seperti menjalankan permintaan HTTP atau membuat bilangan acak
  • Flawless menyimpan log efek samping nondeterministik ini untuk digunakan saat pemulihan
    • Jika eksekusi workflow terhenti, workflow dijalankan kembali untuk mengejar hingga status yang sama
    • Efek samping yang sudah dijalankan tidak akan dijalankan lagi
    • Jumlah data yang perlu disimpan diminimalkan, dan sisanya dihitung ulang sesuai kebutuhan saat terjadi gangguan
  • Model eksekusi ini memungkinkan perilaku seluruh sistem diamati dengan lebih baik
    • Jalur eksekusi yang tepat dari workflow yang sudah selesai maupun yang sedang berjalan dapat dianalisis
    • Berkat lingkungan eksekusi yang deterministik, bug yang sulit direproduksi menjadi lebih mudah ditangani
  • Pengembang dapat mengurangi beban penyimpanan status dan lebih fokus menulis logika bisnis
  • Bahkan jika server harus dimulai ulang untuk pemeliharaan, workflow akan melanjutkan eksekusi dari titik berhenti saat mesin Flawless dijalankan kembali
  • Per 9 Desember 2024, Flawless Beta 3 tersedia

Bacaan terkait

1 komentar

 
GN⁺ 2023-10-27
Komentar Hacker News

  • Saya penasaran bagaimana manajemen versi workflow akan ditangani. Menurut saya ini masalah tersulit di sistem seperti Temporal/Cadence

    • Saya penulisnya. Untuk workflow yang berjalan lama atau pada dasarnya berjalan selamanya, menurut saya solusi paling intuitif adalah mengizinkan upgrade tanpa downtime
      Upgrade hanya berhasil jika kode baru bisa memutar ulang catatan log efek samping yang sudah ada secara persis. Caranya, kode baru mengejar ketertinggalan, lalu setelah tersusul, eksekusi dilanjutkan begitu saja
      Jika kode baru menyimpang dari catatan yang ada, upgrade gagal dan kembali ke kode sebelumnya. Dalam kasus ini, manusia perlu turun tangan untuk memeriksa apa yang salah
      Ada pendekatan lain, tetapi menurut saya cara ini yang paling sederhana untuk benar-benar dipahami dan digunakan. Saat pengembangan pun, log yang ada bisa dipakai untuk menguji apakah kode bercabang
    • Saya penasaran apakah masalahnya adalah sudah ada workflow yang hidup dan sedang berjalan, lalu ingin memperbarui workflow tanpa merusaknya
      Saya juga penasaran apakah tujuannya mempertahankan beberapa versi sekaligus, atau perlu cara memigrasikan yang sedang berjalan ke definisi workflow terbaru
    • Betul. Bagian itu adalah area yang ditangani dengan baik oleh Conductor

  • Saya merasa bidang kita sekarang makin mendekati arsitektur atau kedokteran. Berkat teknologi seperti ini, kita bisa keluar dari tahap coba-coba dan masuk ke budaya rekayasa yang serius
    Singkatnya, saya penasaran bagaimana mencegah efek serangan DoS menjadi persisten dalam sistem seperti ini

    • Ungkapan “mendekati arsitektur dan kedokteran” terbaca seperti omong kosong buatan machine learning
      Arsitektur lebih dekat ke penanganan opini subjektif di dalam batasan regulasi, sedangkan kedokteran adalah pengetahuan empiris yang diverifikasi lewat eksperimen. Keduanya sulit dibilang mirip dengan rekayasa
    • Baik arsitektur maupun kedokteran bukan bidang rekayasa, jadi saya kurang paham mengapa mendekati bidang itu berarti menuju budaya rekayasa
      Arsitektur lebih dekat ke salah satu bentuk seni, dan jurusan arsitektur di universitas biasanya juga berada di fakultas seni
      Kedokteran memang ilmu terapan seperti rekayasa, tetapi bukan bidang rekayasa itu sendiri

  • Saya penasaran apakah determinisme ini juga mencakup komputasi floating-point
    Di game multiplayer, state klien menumpuk drift sedikit demi sedikit dari komputasi floating-point, sehingga harus disinkronkan ulang secara berkala dengan state server, dan secara historis ini titik yang cukup menyakitkan

  • Saya penasaran di mana state efek samping disimpan. Misalnya ada AWS Lambda yang ingin dibuat idempoten; Lambda tidak punya penyimpanan lokal yang bertahan antar-eksekusi
    Karena state tidak bertahan kecuali memasang sesuatu seperti volume EBS, apakah bisa diasumsikan state disimpan di DB?

    • Sepertinya itulah bagian yang akan dibayar dan dipakai ketika produknya diluncurkan

  • Saya suka animasi yang menunjukkan prinsip inti dan cara kerjanya. Dibuat dengan sangat baik

    • Terima kasih. Saya mengodekannya sendiri hanya dengan HTML, CSS, dan JavaScript, dan mencurahkan banyak usaha serta kasih sayang
      Kodenya tidak terlalu cantik, tetapi implementasinya intuitif; kalau ingin melihat, ada di sini: https://flawless.dev/js/how-does-it-work-animation.js
    • Karena pemanggilan endpoint eksternal jauh lebih sering meledak akibat timeout, saya juga ingin melihat kegagalan terjadi pada tahap eksekusi HTTP

  • Terlihat menarik, tetapi saya penasaran apakah cara menandai fungsi sebagai memiliki efek samping akan mudah dibuat tanpa kesalahan
    Dalam contoh, saya berasumsi pembuatan angka acak dianggap efek samping karena berasal dari generator angka acak yang disediakan flawless. Apakah itu juga mungkin dengan fungsi Rust biasa?
    Saya kira juga ada semacam test harness agar developer bisa memeriksa workflow

    • Saya penulis flawless. Dengan WebAssembly, ini pada dasarnya bisa dibuat cukup aman
      WebAssembly mengharuskan pemanggilan host dideklarasikan secara eksplisit di dalam modul. Jika mencoba memakai pemanggilan host lain yang tidak disediakan flawless, modul tidak bisa diinstansiasi
      Di ekosistem WebAssembly juga sedang berjalan beberapa upaya standardisasi. Misalnya, jika memakai crate Rust rand dan mengompilasinya ke WebAssembly, ia memakai fungsi host WASI untuk pembuatan angka acak
      Sambil menunggu wasi, wasi-http, dan lain-lain distandardisasi, untuk sementara kami mengekspos antarmuka sendiri
      Tentu ada kelemahan besar juga. Tidak semua kode Rust bisa dikompilasi ke WebAssembly. Meski begitu, menurut saya pendekatan deny-by-default yang menjamin efek samping tak disengaja sama sekali tidak terjadi lebih baik
    • Melihat generator angka acak dan permintaan HTTP sama-sama berada di bawah namespace flawless, sepertinya alih-alih memberi akses ke seluruh ekosistem Rust, pengguna akan memakai sesuatu seperti std::flawless
      Harness akan menyelesaikan sebagian besar masalah, tetapi saya penasaran seberapa banyak fitur yang bisa dipetakan
      Sejauh ini, ini lebih terlihat seperti runtime scripting yang memakai Rust

  • Terlihat seperti alternatif Rust untuk Temporal yang memakai WASM sebagai runtime. Saya suka
    Saya pendiri windmill.dev, dan kami juga menangani durable engine yang dibuat dengan Rust. Hanya saja jauh kurang elegan. Kami membagi workflow menjadi langkah-langkah eksplisit dalam Python/TypeScript/Go/Bash, lalu untuk melanjutkan dari langkah yang belum selesai, kami memulai lagi dari langkah terakhir dan menyimpan hasil tiap langkah secara permanen di jsonb pada DB Postgres
    Kasus penggunaannya jelas berbeda, dan flawless tampaknya sangat ringan seperti yang dikatakan di situsnya, sehingga bisa dipakai untuk memodelkan status alur UI dan menskalakan hingga jutaan di server kecil
    Fantastis. Semoga suatu hari Rust menggerakkan semua sistem terdistribusi

  • “Program konkurensi yang cukup kompleks yang ditulis dalam bahasa lain akan berisi, sebagai solusi tambal-sulam, implementasi setengah Erlang yang bug-nya banyak, lambat, dan spesifikasinya tidak resmi” — Hukum Pemrograman Pertama Virding

    • Tujuan Flawless tampaknya adalah menyimpan status perantara dari suatu workflow, lalu saat gagal memulai lagi dari titik tengah
      Ini cukup berbeda dari Erlang. Erlang terutama dibuat untuk mengembangkan perangkat lunak bahkan ketika yang tersedia hanya perangkat prototipe dengan banyak masalah hardware
      Bagi saya, kedua pendekatan ini tampak berlawanan. Flawless bisa terjebak dalam loop untuk menyelesaikan workflow yang crash di tengah jalan, sedangkan Erlang bisa dengan rela membuang 50% traffic yang mengenai bug hardware
    • Di posting blog pertama disebutkan Erlang/OTP: https://flawless.dev/essays/when-letting-it-crash-is-not-eno...
    • Ini sepertinya sama sekali tidak memecahkan masalah yang sama dengan Erlang
      Erlang menyelesaikannya dengan pada dasarnya meniadakan status persisten. Hampir semua status berada di tempat seperti antrean pesan atau DB eksternal
      Flawless tampaknya memecahkan masalah dengan teknik yang mirip journaling filesystem, tetapi tidak sepenuhnya sama. Caranya adalah mencatat saat melakukan efek samping
      Journaling filesystem ditujukan untuk dijalankan ulang setelah crash, tetapi di sini tujuannya agar tidak perlu dijalankan ulang
      Belum jelas seberapa cocok di domain mana, tetapi tumpang tindihnya dengan domain yang cocok untuk Erlang tampaknya tidak penuh
    • https://codesync.global/media/erlangrt-a-beam-vm-reimplement...
    • Kalau begitu, yang diperlukan agar program penuh bug dengan spesifikasi tidak resmi bisa melampaui ekspektasi hanyalah cukup cepat

  • Sangat keren. Di runtime game WASM bernama Ambient juga ada masalah serupa. Ada proses-proses yang saling bersaing dan interaksinya mungkin perlu dicoba ulang, jadi pendekatan yang ditunjukkan di sini menarik
    Namun saya penasaran hubungan dengan Lunatic. Apakah Lunatic juga masih dikerjakan, apakah ini proyek sampingan, atau benar-benar terpisah?
    https://lunatic.solutions/

    • Pengamatan yang bagus. Ini dibuat oleh Bernard Kolobara, CEO sekaligus salah satu pendiri Lunatic
      https://kolobara.com

  • “Bayangkan jika Anda memulai komputasi arbitrer, sistem menjamin bahwa komputasi itu berjalan hingga selesai dan semua operasi dilakukan tepat satu kali”
    Saya penasaran bagaimana ini dijamin. Bukankah exactly-once delivery mustahil dalam sistem terdistribusi?

    • Di atas sistem pengiriman setidaknya satu kali, pemrosesan tepat satu kali bisa dilakukan dengan memakai idempotency key
    • Kalau yang Anda maksud teorema CAP, perlu sedikit penjelasan tambahan: https://www.infoq.com/articles/cap-twelve-years-later-how-th...
    • Tidak mustahil. Dalam teorema CAP, pilih saja CP. Artinya mengorbankan ketersediaan
      Jika sistem bisa terus berjalan, pesan akan dikirim tepat satu kali
      Kalau butuh bukti keberadaan, NFSv3 sudah membuat ini berjalan pada 1980-an. Saya tidak tahu apakah itu yang pertama
    • Di tulisannya tertulis “bayangkan”. Saya tidak tahu kalimat yang Anda kutip itu ada di mana, dan saya juga tidak menemukan kalimat ini di teks aslinya