Flawless - Rust के लिए durable execution engine

 (flawless.dev)
1 पॉइंट द्वारा GN⁺ 2023-10-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Flawless एक durable computation execution engine है, जो विफलता होने पर भी कोड को अंत तक चलाने में मदद करता है
  • वर्कफ़्लो सामान्य Rust functions के रूप में लिखे जाते हैं, लेकिन native code के बजाय WebAssembly में compile होकर deterministic environment में चलते हैं
  • HTTP request या random number generation जैसी बाहरी दुनिया से जुड़ने वाली जगहों पर ही non-deterministic side effects पैदा होते हैं, और Flawless इन्हें log के रूप में सहेजता है
  • execution रुक जाने पर यह सहेजे गए logs का उपयोग करके उसी state तक फिर से पहुँचता है, और पहले से किए गए side effects को दोहराता नहीं है
  • डेवलपर को database में हर state को सीधे model करने की जरूरत नहीं होती; वे code और local variables से persistent state को व्यक्त कर सकते हैं, जिससे server restart के बाद भी रुके हुए बिंदु से execution जारी रह सकता है

कोड से persistent state व्यक्त करने वाला execution model

  • Flawless एक durable computation engine है, जो hardware या software failure होने पर भी code के पूरा होने तक execution जारी रखने के लिए बनाया गया है
  • जटिल user experience के लिए जटिल UI और state की जरूरत होती है, लेकिन हर state को database के भीतर सीधे model करना कठिन होता है
  • अगर उपयोगकर्ता गलती से page refresh कर दे तब भी प्रगति न खोने के लिए आधुनिक applications में persistent storage की जरूरत होती है
  • Flawless का लक्ष्य persistent state को code और local variables के रूप में model करने देना है, ताकि application के जटिल behavior को अधिक आसानी से व्यक्त किया जा सके

WebAssembly आधारित execution और failure recovery

  • वर्कफ़्लो सामान्य Rust functions के रूप में लिखे जाते हैं और इनमें किसी भी तरह का logic शामिल हो सकता है
  • functions native code के बजाय WebAssembly में compile होते हैं और पूरी तरह deterministic environment में चलते हैं
  • केवल तब non-determinism आता है जब external world के साथ interaction होता है, जैसे HTTP request करना या random number generation
  • Flawless ऐसे non-deterministic side effect logs को सहेजता है और recovery में उनका उपयोग करता है
    • वर्कफ़्लो execution रुकने पर इसे फिर से चलाकर उसी state तक पहुँचाया जाता है
    • जो side effects पहले ही हो चुके हैं, उन्हें दोबारा नहीं किया जाता
    • सहेजकर रखने वाले data की मात्रा न्यूनतम रखी जाती है, और बाकी को failure होने पर जरूरत के अनुसार फिर से compute किया जाता है
  • यह execution model पूरे system के behavior को बेहतर ढंग से observe करने में मदद करता है
    • पूरा हो चुके या चल रहे workflows के सटीक execution path का analysis किया जा सकता है
    • deterministic execution environment की वजह से reproduce करने में कठिन bugs को संभालना आसान हो जाता है
  • डेवलपर state persistence के बोझ को कम कर सकते हैं और business logic लिखने पर अधिक ध्यान दे सकते हैं
  • maintenance के लिए server restart करना पड़े तब भी Flawless engine को फिर से शुरू करने पर workflow वहीं से आगे चलता है जहाँ वह रुका था
  • 9 दिसंबर 2024 तक Flawless Beta 3 उपलब्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-27
Hacker News की राय

  • यह जानना चाहूंगा कि workflow version management कैसे संभाला जाएगा। Temporal/Cadence जैसे सिस्टम में मुझे यह सबसे कठिन समस्या लगती है

    • मैं लेखक हूं। लंबे समय तक चलने वाले, या व्यावहारिक रूप से हमेशा चलते रहने वाले workflows के लिए, मुझे zero-downtime upgrades की अनुमति देना सबसे सहज समाधान लगता है
      upgrade तभी सफल होता है जब नया code मौजूदा side-effect log records को ठीक-ठीक replay कर सके। तरीका यह है कि नए code से catch up किया जाए, और catch up होने के बाद उसी तरह execution जारी रहे
      अगर नया code मौजूदा records से अलग हो जाता है, तो upgrade fail हो जाता है और पुराने code पर वापस लौटता है। ऐसे में किसी इंसान को हस्तक्षेप करके देखना होगा कि क्या गलत हुआ
      दूसरे approaches भी हैं, लेकिन असल में समझने और इस्तेमाल करने के लिहाज से मुझे यह तरीका सबसे सरल लगता है। development के दौरान भी मौजूदा logs का उपयोग करके test किया जा सकता है कि code diverge हो रहा है या नहीं
    • मेरा सवाल यह है कि क्या समस्या यह है कि पहले से live और in-progress workflows मौजूद हैं, और workflow को update करने पर वे टूटें नहीं
      क्या आप कई versions को साथ-साथ maintain करना चाहते हैं, या in-progress workflows को नवीनतम workflow definition पर migrate करने का तरीका चाहिए?
    • सही। वह हिस्सा Conductor अच्छी तरह संभालता है

  • लगता है हमारा क्षेत्र अब architecture या medicine के और करीब होता जा रहा है। ऐसी technologies की वजह से हम tinkering के चरण से निकलकर गंभीर engineering culture में प्रवेश कर सकते हैं
    संक्षेप में पूछूं तो, ऐसे systems में DoS attack के effect का स्थायी हो जाना कैसे रोका जाता है?

    • “architecture और medicine के करीब जाना” वाली बात machine learning से बनी बकवास जैसी पढ़ती है
      architecture, regulatory constraints के भीतर subjective opinions से निपटने के ज्यादा करीब है, और medicine experiments से validate होने वाला empirical knowledge है। दोनों को engineering जैसा कहना मुश्किल है
    • Architecture भी और medicine भी engineering fields नहीं हैं, इसलिए उनके करीब जाना engineering culture की ओर जाने का रास्ता क्यों है, यह समझ नहीं आता
      architecture कला के एक रूप के ज्यादा करीब है, और universities में architecture departments भी आम तौर पर arts colleges में होते हैं
      medicine, engineering की तरह applied science तो है, लेकिन खुद engineering field नहीं है

  • जानना चाहूंगा कि यह determinism floating-point calculations तक extend होता है या नहीं
    multiplayer games में clients की state floating-point calculations में थोड़ा-थोड़ा drift जमा करती थी, इसलिए server state के साथ समय-समय पर फिर से sync करना पड़ता था, और historically यह काफी दर्दनाक मुद्दा रहा है

    • जब मैंने WASM compiler implement किया था, floating-point आधारित non-determinism का एकमात्र कारण NaN की exact byte representation था। floating-point math खुद deterministic है
      https://webassembly.org/docs/faq/#why-is-there-no-fast-math-... और https://github.com/WebAssembly/design/blob/main/Nondetermini... देखें
    • वह शायद GPU द्वारा तेज होने के लिए tricks इस्तेमाल करने वाली समस्या के ज्यादा करीब होगा
      https://asawicki.info/news_1741_myths_about_floating-point_n...
      पहले CPU results भी execution path के हिसाब से बदल सकते थे। article में tweet देखें
    • सोच रहा हूं कि f64 की जगह large number struct को synchronize करना भी एक option हो सकता है, या complexity और size के लिहाज से यह practical नहीं होगा

  • side effects की state कहां store होती है? उदाहरण के लिए, अगर कोई AWS Lambda है जिसे idempotent बनाना चाहते हैं, तो Lambda के पास executions के बीच बना रहने वाला local storage नहीं होता
    जब तक EBS volume जैसा कुछ mount न किया जाए, state बनी नहीं रहती, तो क्या यह मान सकते हैं कि state DB में store की जा सकती है?

    • मुझे लगता है product launch होने पर यही वह हिस्सा होगा जिसके लिए पैसे देकर इस्तेमाल करना पड़ेगा

  • core principle और काम करने का तरीका दिखाने वाली animation पसंद आई। वाकई बहुत अच्छी बनाई है

    • धन्यवाद। इसे मैंने सिर्फ HTML, CSS और JavaScript से खुद code किया है, और इसमें बहुत मेहनत और लगाव लगाया है
      code बहुत सुंदर नहीं है, लेकिन implementation straightforward है; अगर देखना चाहें तो यहां है: https://flawless.dev/js/how-does-it-work-animation.js
    • external endpoint call करते समय timeout की वजह से यह कहीं ज्यादा common failure point होता है, इसलिए मैं HTTP execution step में fail होता हुआ भी देखना चाहता था

  • दिलचस्प लगता है, लेकिन functions को side-effectful के रूप में mark करने का तरीका बिना गलतियों के बनाना आसान होगा या नहीं, यह जानना चाहूंगा
    example में random number generation side effect है, ऐसा मैं मान रहा हूं क्योंकि यह flawless द्वारा दिए गए random number generator से आता है। क्या यह सामान्य Rust function से भी संभव होता?
    मुझे लगता है developer के पास workflow verify करने के लिए test harness जैसा कुछ भी होगा

    • मैं flawless का लेखक हूं। WebAssembly का उपयोग करने पर यह by default काफी सुरक्षित बनाया जा सकता है
      WebAssembly module के अंदर host calls को explicitly declare करना जरूरी करता है। अगर आप flawless द्वारा provide न किए गए किसी और host call का उपयोग करने की कोशिश करते हैं, तो module instantiate नहीं किया जा सकता
      WebAssembly ecosystem में कई standardization efforts भी चल रहे हैं। उदाहरण के लिए, अगर Rust rand crate का उपयोग करके WebAssembly में compile करें, तो random number generation के लिए WASI host function का उपयोग होता है
      wasi, wasi-http आदि के standardize होने का इंतजार करते हुए फिलहाल हम अपना interface expose कर रहे हैं
      बेशक, बड़ी कमी भी है। हर Rust code को WebAssembly में compile नहीं किया जा सकता। फिर भी, unintended side effects कभी न हों यह guarantee करने वाला default-deny approach मुझे बेहतर लगता है
    • random number generator और HTTP requests दोनों flawless namespace के तहत हैं, इससे लगता है कि पूरे Rust ecosystem तक access देने के बजाय std::flawless जैसा कुछ use कराया जाएगा
      harness ज्यादातर समस्याएं हल कर देगा, लेकिन कितनी functionality map की जा सकेगी यह जानना दिलचस्प होगा
      अभी तक यह Rust इस्तेमाल करने वाले scripting runtime के ज्यादा करीब दिखता है

  • यह Temporal का Rust विकल्प जैसा दिखता है, जो runtime के रूप में WASM का उपयोग करता है। पसंद आया
    मैं windmill.dev का founder हूं, और हम भी Rust में बने durable engine पर काम करते हैं। हालांकि वह बहुत कम elegant है। हम workflows को Python/TypeScript/Go/Bash के स्पष्ट steps में बांटते हैं, और incomplete step से resume करने के लिए last step से फिर शुरू करते हैं, साथ ही हर step का result Postgres DB के jsonb में permanently store करते हैं
    use cases निश्चित रूप से अलग हैं, और flawless, जैसा site पर कहा गया है, बहुत lightweight है, इसलिए यह UI flow state को model करने और छोटे server पर millions तक scale करने के लिए भी उपयोगी दिखता है
    शानदार। उम्मीद है किसी दिन Rust सभी distributed systems को चलाएगा

  • “किसी दूसरी language में लिखा गया पर्याप्त complex concurrent program, ad-hoc तरीके से, unofficial spec में buggy और slow Erlang का आधा-अधूरा implementation शामिल करता है” — Virding का programming का पहला नियम

    • Flawless का लक्ष्य किसी workflow की intermediate state को save करना और failure होने पर बीच के point से फिर शुरू करना लगता है
      यह Erlang से काफी अलग है। Erlang मुख्य रूप से तब software develop करने के लिए बनाया गया था जब आपके पास केवल prototype equipment हो जिसमें hardware समस्याएं बहुत हों
      मुझे दोनों approaches बिल्कुल उलटी लगती हैं। Flawless बीच में crash होने वाले workflow को पूरा करने के लिए loop में फंस सकता है, जबकि Erlang hardware bug hit करने वाले 50% traffic को खुशी से drop कर सकता है
    • पहले blog post में Erlang/OTP का जिक्र है: https://flawless.dev/essays/when-letting-it-crash-is-not-eno...
    • यह Erlang जैसी समस्या हल करता हुआ बिल्कुल नहीं लगता
      Erlang persistent state को practically खत्म करके समस्या हल करता है। लगभग सारी state message queues या external DB जैसी जगहों में रहती है
      Flawless समस्या को filesystem journaling जैसी, लेकिन पूरी तरह वैसी नहीं, technique से हल करता लगता है। side effects perform करते समय उन्हें record करने का तरीका है
      filesystem journaling crash के बाद फिर से run करने के लिए होता है, लेकिन यहां मकसद फिर से run करने की जरूरत ही न रहने देना है
      यह किन domains में कितना fit बैठेगा, यह स्पष्ट नहीं है, लेकिन Erlang जिन domains में fit बैठता है उनसे overlap पूरा नहीं दिखता
    • https://codesync.global/media/erlangrt-a-beam-vm-reimplement...
    • तो फिर unofficial spec में buggy program को उम्मीदों से आगे निकलने के लिए बस तेज होना जरूरी है

  • बहुत बढ़िया। Ambient नाम के WASM game runtime में भी similar problem है। competing processes होते हैं और interactions को retry करना पड़ सकता है, इसलिए यहां दिखाया गया approach दिलचस्प है
    लेकिन Lunatic से इसका relation जानना चाहूंगा। क्या Lunatic पर भी अभी काम जारी है, यह side project है, या पूरी तरह अलग है?
    https://lunatic.solutions/

    • अच्छा observation। इसे Bernard Kolobara ने बनाया है, जो Lunatic के CEO और co-founder हैं
      https://kolobara.com

  • “कल्पना करें कि आप कोई arbitrary computation शुरू करते हैं, और system guarantee करता है कि वह completion तक चलेगा और हर operation exactly once perform होगा”
    यह guarantee कैसे होती है, जानना चाहूंगा। distributed systems में exactly-once delivery असंभव नहीं है क्या?

    • at-least-once delivery system के ऊपर idempotency keys इस्तेमाल करें तो exactly-once processing संभव है
    • अगर आप CAP theorem की बात कर रहे हैं, तो थोड़ी अतिरिक्त context चाहिए: https://www.infoq.com/articles/cap-twelve-years-later-how-th...
    • असंभव नहीं है। CAP theorem में CP चुनना होगा। यानी availability छोड़नी होगी
      अगर system आगे बढ़ सकता है, तो message exactly once deliver होगा
      अगर existence proof चाहिए, तो NFSv3 ने 1980s में ही इसे काम करा दिया था। यह पहला था या नहीं, पता नहीं
    • article में “कल्पना करें” लिखा है। आपने जो quoted phrase दिया है वह कहां है, पता नहीं, और original text में भी मुझे यह sentence नहीं मिला