Flawless - Rust için dayanıklı yürütme motoru

• Flawless, arıza olsa bile kodun sonuna kadar çalışmasına yardımcı olan dayanıklı hesaplama yürütme motorudur
• İş akışları normal Rust fonksiyonları olarak yazılır, ancak yerel kod yerine WebAssembly’e derlenerek deterministik bir ortamda çalıştırılır
• HTTP istekleri veya rastgele sayı üretimi gibi dış dünyayla temas edilen noktalarda yalnızca deterministik olmayan yan etkiler oluşur ve Flawless bunları log olarak kaydeder
• Yürütme kesilirse, kaydedilmiş log kullanılarak aynı duruma kadar yeniden ilerlenir ve daha önce gerçekleştirilmiş yan etkiler tekrarlanmaz
• Geliştiriciler tüm durumu doğrudan veritabanında modellemek zorunda kalmadan, kalıcı durumu kod ve yerel değişkenlerle ifade edebilir; böylece sunucu yeniden başladıktan sonra da kesilen noktadan devam edilebilir

---

Kodla kalıcı durumu ifade eden yürütme modeli

• Flawless, donanım ya da yazılım arızaları meydana gelse bile kod tamamlanana kadar çalışmasını sağlayan bir dayanıklı hesaplama motorudur
• Karmaşık kullanıcı deneyimleri karmaşık arayüzler ve durum yönetimi gerektirir, ancak tüm durumu doğrudan veritabanı içinde modellemek zordur
• Kullanıcının sayfayı yanlışlıkla yenilemesi durumunda bile ilerlemenin kaybolmaması için modern uygulamalarda kalıcı depolama gereklidir
• Flawless, kalıcı durumun kod ve yerel değişkenlerle modellenmesini sağlayarak uygulamanın karmaşık davranışlarını daha kolay ifade etmeyi amaçlar

WebAssembly tabanlı yürütme ve arıza kurtarma

• İş akışları normal Rust fonksiyonları olarak yazılır ve herhangi bir mantığı içerebilir
• Fonksiyonlar yerel kod yerine WebAssembly’e derlenir ve tamamen deterministik bir ortamda çalıştırılır
• Deterministik olmama yalnızca HTTP isteği gönderme veya rastgele sayı üretme gibi dış dünyayla etkileşimlerde ortaya çıkar
• Flawless, bu deterministik olmayan yan etki loglarını kaydederek kurtarma için kullanır
  • İş akışı yürütmesi kesilirse yeniden çalıştırılır ve aynı duruma kadar tekrar ilerlenir
  • Daha önce gerçekleştirilmiş yan etkiler yeniden gerçekleştirilmez
  • Saklanması gereken veri miktarı en aza indirilir, geri kalan kısım ise arıza durumunda gerektiğinde yeniden hesaplanır
• Bu yürütme modeli, tüm sistemin davranışının daha iyi gözlemlenmesini sağlar
  • Tamamlanmış veya hâlen çalışan iş akışlarının tam yürütme yolu analiz edilebilir
  • Deterministik yürütme ortamı sayesinde yeniden üretmesi zor hatalarla uğraşmak kolaylaşır
• Geliştiriciler durum saklama yükünü azaltıp iş mantığı yazmaya daha fazla odaklanabilir
• Bakım için sunucuların yeniden başlatılması gerekse bile, Flawless motoru yeniden başlatıldığında iş akışları durduğu noktadan devam ederek çalışır
• 9 Aralık 2024 itibarıyla Flawless Beta 3 sunulmaktadır

[GN⁺]

Hacker News görüşleri

• İş akışı sürüm yönetiminin nasıl ele alınacağını merak ediyorum. Temporal/Cadence gibi sistemlerde en zor sorunun bu olduğunu düşünüyorum

  • Yazarıyım. Uzun süre çalışan ya da fiilen sonsuza kadar çalışan iş akışları için kesintisiz yükseltmeye izin vermenin en sezgisel çözüm olduğunu düşünüyorum
    Yükseltme yalnızca yeni kod mevcut yan etki günlük kayıtlarını birebir yeniden oynatabildiğinde başarılı olur. Yeni kodla mevcut duruma yetişip, yetiştiğinde de aynı şekilde çalışmaya devam etme modeli
    Yeni kod mevcut kayıtlardan saparsa yükseltme başarısız olur ve eski koda geri dönülür. Bu durumda neyin yanlış gittiğini anlamak için insan müdahalesi gerekir
    Başka yaklaşımlar da var, ama pratikte anlaması ve kullanması en basit yöntemin bu olduğunu düşünüyorum. Geliştirme sırasında da mevcut günlükleri kullanarak kodun ayrışıp ayrışmadığını test edebilirsiniz
  • Zaten canlı ve devam eden bir iş akışı varken, iş akışını güncellediğinizde bunun bozulmamasını sağlama probleminden mi söz edildiğini merak ediyorum
    Birden fazla sürümü aynı anda mı sürdürmek istiyorsunuz, yoksa devam edenleri en yeni iş akışı tanımına taşımak için bir yönteme mi ihtiyacınız var, onu da merak ediyorum
  • Evet. Bu kısım Conductor'ın sizin yerinize iyi ele aldığı alan

• Alanımızın artık mimarlığa veya tıbba giderek yaklaştığını hissediyorum. Bu tür teknolojiler sayesinde kurcalama aşamasından çıkıp ciddi bir mühendislik kültürüne girebiliriz
  Kısaca sormak gerekirse, böyle bir sistemde DoS saldırısının etkilerinin kalıcı hale gelmesini nasıl engelliyorsunuz?

  • “Mimarlığa ve tıbba yaklaşmak” ifadesi, makine öğreniminin ürettiği türden saçmalık gibi okunuyor
    Mimarlık daha çok düzenleyici kısıtlar içinde öznel görüşlerle uğraşan bir alan, tıp ise deneylerle doğrulanan ampirik bilgidir. İkisini de mühendisliğe benzer görmek zor
  • Ne mimarlık ne de tıp mühendislik alanı olduğundan, onlara yaklaşmanın neden mühendislik kültürüne giden yol olduğunu pek anlamıyorum
    Mimarlık daha çok bir sanat biçimine yakın; üniversitelerde mimarlık bölümleri de genellikle güzel sanatlar fakültesinde yer alır
    Tıp, mühendislik gibi uygulamalı bilimdir ama mühendislik alanının kendisi değildir

• Bu determinizmin kayan nokta hesaplamalarına kadar uzanıp uzanmadığını merak ediyorum
  Çok oyunculu oyunlarda istemci durumu, kayan nokta hesaplamalarında küçük küçük drift biriktirdiği için sunucu durumuyla periyodik olarak yeniden senkronize edilmek zorundaydı; tarihsel olarak oldukça acı veren bir noktaydı

  • WASM derleyicisi uyguladığımda, kayan nokta kaynaklı nondeterminizmin tek nedeni NaN'in birebir bayt gösterimiydi. Kayan nokta matematiğinin kendisi deterministiktir
    https://webassembly.org/docs/faq/#why-is-there-no-fast-math-... ve https://github.com/WebAssembly/design/blob/main/Nondetermini... bağlantılarına bakın
  • Bu muhtemelen GPU'nun daha hızlı olmak için kestirme yöntemler kullanmasıyla ilgili bir meseleye daha yakın gibi
    https://asawicki.info/news_1741_myths_about_floating-point_n...
    Eskiden CPU sonuçları da yürütme yoluna bağlı olarak değişebiliyordu. Yazıdaki tweet'e bakın
  • f64 yerine büyük sayı struct'larını senkronize etmek de bir seçenek olabilir mi, yoksa karmaşıklık ve boyut açısından gerçekçi değil mi, merak ediyorum

• Yan etkilerin durumu nerede saklanıyor, merak ediyorum. Örneğin idempotent hale getirmek istediğim bir AWS Lambda olduğunu varsayarsak, Lambda'nın çalıştırmalar arasında korunan yerel depolaması yok
  EBS volume gibi bir şey mount etmediğiniz sürece durum korunmayacağına göre, durumun DB'de saklanabileceğini varsayabilir miyiz?

  • Ürün çıktığında bunun ücret ödeyip kullanacağınız kısım olacağını düşünüyorum

• Temel prensibi ve çalışma biçimini gösteren animasyon hoşuma gitti. Gerçekten iyi yapılmış

  • Teşekkürler. Sadece HTML, CSS ve JavaScript ile kendim kodladım; üzerine çok emek ve sevgi koydum
    Kod çok güzel değil ama uygulama anlaşılır; bakmak isterseniz burada: https://flawless.dev/js/how-does-it-work-animation.js
  • Harici endpoint çağrılarında timeout nedeniyle çok daha sık patlayan yer orası olduğu için, HTTP yürütme adımında başarısız olduğu hali de görmek isterdim

• İlginç görünüyor, ama fonksiyonları yan etkili olarak işaretleme yönteminin hatasız yapılmasının kolay olup olmayacağını merak ediyorum
  Örnekte rastgele sayı üretiminin, flawless'ın sağladığı rastgele sayı üretecinden geldiği için yan etki olduğunu varsayıyorum. Sıradan bir Rust fonksiyonuyla da mümkün olur muydu?
  Geliştiricinin iş akışını doğrulayabileceği bir test harness'ı gibi bir şeyin de olacağını düşünüyorum

  • flawless'ın yazarıyım. WebAssembly kullanırsanız bunu varsayılan olarak oldukça güvenli hale getirebilirsiniz
    WebAssembly, modül içinde host çağrılarının açıkça bildirilmesini gerektirir. flawless'ın sağlamadığı başka host çağrılarını kullanmaya çalışırsanız modül instantiate edilemez
    WebAssembly ekosisteminde çeşitli standartlaştırma çalışmaları da sürüyor. Örneğin Rust rand crate'ini kullanıp WebAssembly'ye derlerseniz, rastgele sayı üretimi için WASI host fonksiyonunu kullanır
    wasi, wasi-http vb. standartlaşmasını beklerken şimdilik kendi arayüzümüzü sunuyoruz
    Elbette büyük bir dezavantajı da var. Tüm Rust kodu WebAssembly'ye derlenemez. Yine de istenmeyen yan etkilerin kesinlikle oluşmamasını garanti eden varsayılan reddetme yaklaşımının daha iyi olduğunu düşünüyorum
  • Rastgele sayı üreteci ve HTTP isteğinin ikisi de flawless namespace'i altında olduğuna göre, tüm Rust ekosistemine erişim vermek yerine std::flawless gibi bir şey kullandıracak gibi görünüyor
    Harness sorunların çoğunu çözecektir, ama ne kadar çok işlevin eşlenebileceğini merak ediyorum
    Şimdilik Rust kullanan bir scripting runtime'a daha yakın görünüyor

• WASM’i çalışma zamanı olarak kullanan Temporal’ın Rust alternatifi gibi görünüyor. Hoşuma gitti.
  windmill.dev’in kurucusuyum; biz de Rust ile yapılmış bir dayanıklı motorla ilgileniyoruz. Ancak bizimki çok daha az zarif. İş akışını Python/TypeScript/Go/Bash’te net adımlara bölüyor, tamamlanmamış bir adımdan devam etmek için son adımdan yeniden başlıyor ve her adımın sonucunu Postgres DB’deki jsonb içinde kalıcı olarak saklıyor.
  Kullanım senaryosu kesinlikle farklı; flawless, sitede söylendiği gibi çok hafif olduğu için UI akış durumunu modellemek ve küçük bir sunucuda milyonlara kadar ölçeklemek için de kullanılabilir görünüyor.
  Harika. Bir gün Rust’ın tüm dağıtık sistemleri çalıştırmasını umuyorum.

• “Başka bir dilde yazılmış yeterince karmaşık bir eşzamanlılık programı, geçici bir çözüm olarak, gayriresmî biçimde belirtilmiş, bol hatalı ve yavaş bir Erlang’ın yarım yamalak uygulamasını içerir” — Virding’in programlamaya dair birinci yasası

  • Flawless’ın amacı, herhangi bir iş akışının ara durumunu kaydetmek ve hata durumunda ara noktadan yeniden başlatmak gibi görünüyor.
    Bu Erlang’dan oldukça farklı. Erlang esas olarak, elinizde donanım sorunları bol olan prototip ekipmandan başka bir şey yokken bile yazılım geliştirmek için yapılmıştı.
    Bana göre iki yaklaşım birbirinin tam tersi gibi. Flawless, ortasında çöken bir iş akışını bitirmeye çalışırken döngüye sıkışabilir; Erlang ise bir donanım hatasına takılan trafiğin %50’sini memnuniyetle çöpe atabilir.
  • İlk blog yazısında Erlang/OTP’den bahsediyor: https://flawless.dev/essays/when-letting-it-crash-is-not-eno...
  • Bu, Erlang ile hiç aynı problemi çözüyor gibi görünmüyor.
    Erlang bunu kalıcı durumu fiilen ortadan kaldırarak çözer. Neredeyse tüm durum mesaj kuyrukları ya da harici DB gibi yerlerde bulunur.
    Flawless ise sorunu dosya sistemi günlüklemeye benzeyen, ama tamamen aynı olmayan bir teknikle çözüyor gibi. Yan etkileri gerçekleştirirken bunları kaydetme yaklaşımı.
    Dosya sistemi günlükleme, çökmeden sonra yeniden çalıştırmak içindir; burada ise yeniden çalıştırmaya gerek kalmamasını sağlamak için.
    Hangi alana ne kadar uyacağı net değil, ama Erlang’ın iyi uyduğu alanlarla örtüşmesi tam değil gibi görünüyor.
  • https://codesync.global/media/erlangrt-a-beam-vm-reimplement...
  • O halde gayriresmî biçimde belirtilmiş, hatalarla dolu bir programın beklentileri aşması için gereken tek şey sadece hızlı olması.

• Çok havalı. Ambient adlı WASM oyun çalışma zamanında da benzer bir problem var. Yarışan süreçler var ve etkileşimleri yeniden denemek gerekebiliyor; bu yüzden burada gösterilen yaklaşım ilginç.
  Bu arada Lunatic ile ilişkisini merak ediyorum. Lunatic üzerinde hâlâ çalışılıyor mu, bu bir yan proje mi, yoksa tamamen ayrı mı?
  https://lunatic.solutions/

  • İyi gözlem. Bunu Lunatic’in CEO’su ve kurucu ortağı Bernard Kolobara yaptı.
    https://kolobara.com

• “Rastgele bir hesaplamayı başlattığınızda, sistemin tamamlanana kadar çalışacağını ve tüm işlerin tam olarak bir kez gerçekleştirileceğini garanti ettiğini hayal edin.”
  Bunun nasıl garanti edildiğini merak ediyorum. Dağıtık sistemlerde tam olarak bir kez teslimat imkânsız değil mi?

  • En az bir kez teslimat sistemi üzerinde idempotency key kullanırsanız tam olarak bir kez işleme mümkün olur.
  • CAP teoreminden bahsediyorsanız, biraz ek açıklama gerekir: https://www.infoq.com/articles/cap-twelve-years-later-how-th...
  • İmkânsız değil. CAP teoreminde CP’yi seçmek yeterli. Yani erişilebilirlikten vazgeçmek.
    Sistem ilerleyebiliyorsa mesaj tam olarak bir kez teslim edilir.
    Bir varlık kanıtı gerekiyorsa NFSv3 bunu 1980’lerde zaten çalışır hâle getirmişti. İlk miydi bilmiyorum.
  • Yazıda “hayal edin” deniyor. Alıntıladığınız ifadenin nerede olduğunu bilmiyorum; asıl metinde de bu cümleyi bulamadım.