Serverless डेटा सिस्टम की आर्किटेक्चर

• cloud data services का भविष्य "large-scale, multi-tenant" संरचना है
  • S3 जैसी शीर्ष SaaS services सादगी, विश्वसनीयता, durability, scalability और कम कीमत इसलिए दे पाती हैं क्योंकि इन services की तकनीकें संरचनात्मक रूप से इन्हीं गुणों को देने के लिए डिज़ाइन की गई हैं
  • बड़े resource pool के माध्यम से ग्राहकों को service देना scale के साथ efficiency और reliability सुनिश्चित करता है

[Serverless Multi-Tenant सिस्टम की परिभाषा]

"Multi-Tenancy" की परिभाषा

• multi-tenant का मतलब shared hardware पर workloads को साथ में place करके resources साझा करना है
• cloud में system बनाना इस बात का अर्थ है कि कई tenants shared computing instances (जैसे Amazon EC2 या Google Compute) या shared PaaS services (जैसे cloud object storage) पर service प्राप्त करते हैं
• multi-tenant को "shared resources (virtualized servers, drives और PaaS building-block services आदि) पर कई tenants को service देना" के रूप में परिभाषित किया जाता है
• कई resource-sharing models इस्तेमाल किए जा सकते हैं, और कुछ systems पूरे component set में कई shared models को मिलाकर उपयोग करते हैं
  • shared process: वही software process कई tenants को service देता है। data और security isolation logical होती है
  • container: single-tenant node चलाया जाता है और प्रति host कई containers पैकेज किए जाते हैं। आम तौर पर यह Kubernetes के जरिए होता है, जहाँ कोई खास K8s node अनेक tenants के pods host करता है
  • virtualization: VM (जैसे QEMU) या microVM (जैसे Firecracker) में single-tenant node चलाया जाता है और प्रति host कई VMs पैकेज किए जाते हैं। Kubernetes को Kata containers के जरिए VM के साथ भी उपयोग किया जा सकता है
• V8 isolation का एक तरीका भी है, जिसमें tenants एक ही V8 process साझा करते हुए अलग lightweight contexts में इस्तेमाल कर सकते हैं, लेकिन data systems में यह अभी तक नहीं देखा गया है

serverless की परिभाषा

• ग्राहक server type नहीं चुनते और न ही hardware को explicitly चुनते हैं
• ऐसे systems कुछ स्तर की elasticity और mobility पर निर्भर करते हैं ताकि ग्राहक को hardware का size explicitly adjust किए बिना सभी workloads की demand संभाली जा सके
  • elasticity: workload की ज़रूरत के अनुसार service को scale up/scale down करने की क्षमता
  • mobility: performance और stability requirements पूरी करने के लिए workloads को भीतर ही भीतर move और balance करने की service capability
• serverless model usage-based pricing का उपयोग करता है, जो ग्राहकों के लिए लगातार अधिक महत्वपूर्ण होता जा रहा है
  • कई ग्राहक पहले से बड़े commitment नहीं करना चाहते और सिर्फ जितना इस्तेमाल करें उतना ही भुगतान करना पसंद करते हैं
  • usage-based pricing में कई variations होती हैं, जो workload और underlying system implementation के अनुसार काफी बदलती हैं
    • प्रति (million) operation भुगतान
    • workload के CPU और memory उपयोग के लिए भुगतान
    • प्रति GB storage भुगतान
    • resources और work rate से जुड़े virtual performance/capacity units (जैसे DynamoDB के RCU/WCU) के लिए भुगतान
    • hybrid model, जिसमें ग्राहक कुछ base capacity का भुगतान करते हैं और उससे ऊपर के usage के लिए अतिरिक्त भुगतान करते हैं ("base pay, peak pay")

[सामान्य चुनौतियाँ]

workload द्वारा लगाए गए constraints के भीतर काम करना

• किसी दिए गए data system के workload द्वारा लगाए गए कई constraints underlying architecture के महत्वपूर्ण driver होते हैं।
  • latency/availability requirements
  • consistency requirements
  • requests और data के बीच correlation/dependency
  • sequential access patterns बनाम random access patterns
  • प्रति request किए जाने वाले work की विविधता
  • data size
  • session बनाम request-oriented protocols, push बनाम pull mechanisms
  • work की computational intensity
• ढीली latency और consistency requirements engineers को अधिक स्वतंत्रता देती हैं
  • कम latency वाले systems में high-latency components जोड़ने की सीमाओं के कारण cloud object storage की low-cost और high-durability खूबियों का उपयोग करना इसका अच्छा उदाहरण है
  • eventually consistent systems data को synchronous data hot path में शामिल किए बिना object storage में asynchronously लिखकर इस दुविधा से बच सकते हैं
  • कम latency और strong consistency वाले systems के पास ऐसा कोई छूट-पत्र नहीं होता
• short latency जैसे constraints जब एक साथ आते हैं, तो workload की spatial और temporal locality architecture choices को प्रभावित कर सकती है
  • उदाहरण के लिए, sequential scan वाले workloads में disk पर तेज़ और efficient scan के लिए contiguous data ranges को साथ रखना बेहतर होता है
  • इन ranges को छोटे sub-ranges में तोड़ना hotspot management में मदद करता है, लेकिन ये दोनों एक-दूसरे के साथ trade-off में हैं, इसलिए इनके बीच संतुलन ढूँढ़ना पड़ता है
  • random access patterns, जिनमें individual requests के बीच correlation कम होती है, flat address space का लाभ उठा सकती हैं जिसे कई servers पर समान और पतले रूप से फैलाया जा सके
• session-oriented protocols जो persistent connections स्थापित करते हैं, आम तौर पर उन request-oriented protocols की तुलना में अधिक कठिन होते हैं जिनमें हर request पिछली request से स्वतंत्र होती है
  • persistent connections के लिए connection pooling की ज़रूरत पड़ सकती है, और rolling node तथा data balancing जैसी disturbances होने पर clients पर externally visible प्रभाव पड़ सकता है
• कुछ systems में object storage या Kafka API जैसी simple storage APIs होती हैं, जबकि कुछ SQL database जैसे compute-intensive systems होते हैं
  • इससे यह विषय आता है कि प्रत्येक request को संभालने के लिए आवश्यक work कितना predictable या variable है
  • एक चरम उदाहरण के रूप में Kafka जैसी data streaming API है, जिसमें बस लगातार record blocks fetch करने होते हैं, जबकि दूसरे छोर पर SQL है, जहाँ हर query पर work में बड़ा अंतर आ सकता है

tenant isolation

• resource sharing hardware utilization बढ़ाता है, लेकिन इससे resource contention भी हो सकती है, जहाँ एक tenant का workload दूसरे tenant को प्रभावित करे
• multi-tenant systems में यह सुनिश्चित करना होता है कि shared hardware resources पर service पाने वाले tenants को ऐसा अनुभव हो मानो उन्हें उनकी अपनी dedicated service मिल रही हो

storage और compute का separation

• storage और compute का separation एक मुख्य design principle है, जिसे अब तक देखे गए सभी systems ने किसी न किसी स्तर पर लागू किया है
• hardware trends के कारण storage और compute का separation लगातार अधिक व्यावहारिक हो रहा है, आंशिक रूप से इसलिए भी क्योंकि network अब पहले जैसा bottleneck नहीं रहा
• network throughput बढ़ रहा है, लेकिन cloud object storage को प्राथमिकता मिलने के साथ इस separation से जुड़ी नई चुनौतियाँ अब भी मौजूद हैं
  • cloud object storage में अब भी अपेक्षाकृत high latency होती है, लेकिन durability अधिक और लागत कम होती है
  • पर OLTP databases जैसे सामान्यतः low-latency workloads में इसे शामिल करना कठिन हो सकता है
  • साथ ही cloud object storage का economic model उन designs के खिलाफ जाता है जो बहुत छोटे objects पर निर्भर हों; डेटा को कम requests में बड़े objects में इकट्ठा करना पड़ता है, जिससे low-latency systems का जीवनचक्र और जटिल हो जाता है
• engineers low-latency systems में object storage शामिल कर सकते हैं, लेकिन उसकी latency समस्या से निपटने के लिए धीमे object storage के आगे durable, fault-tolerant write cache और predictive read cache रख सकते हैं
  • यह durable write cache मूल रूप से एक server cluster है जो replication protocol लागू करता है और block storage में data लिखता है
    • background में cluster कम संख्या में बड़े files लिखने वाले आर्थिक pattern के अनुसार data को object storage में asynchronously upload करता है
    • fault-tolerant write cache short-latency writes को अच्छी तरह support करता है
  • इस architecture में पढ़ने वाली cache समस्या बन सकती है
    • event streaming जैसे sequential workloads में यह सरल और बहुत प्रभावी होता है
    • जब तक Aggregate Prefetching मांग के साथ चलती रहती है, reads हमेशा local read cache तक पहुँचनी चाहिए
    • databases के लिए unpredictable random access patterns के कारण यह अधिक कठिन समस्या है, लेकिन table scans अब भी read-ahead के लाभ ले सकते हैं
• replication protocol के साथ distributed fault-tolerant write cache लागू करना आसान नहीं है, और multi-AZ environment में cross-AZ charges जैसे अतिरिक्त खर्च भी आ सकते हैं
  • लेकिन फिलहाल low-latency systems के लिए, जो सस्ते और durable object storage को base data store के रूप में इस्तेमाल करना चाहते हैं, कोई वास्तविक विकल्प नहीं है
  • अन्य low-latency systems को cloud object storage का उपयोग पूरी तरह टालना पड़ सकता है, और वे सबसे ऊपर predictable short latency को प्राथमिकता देते हैं
  • cloud storage व्यापक रूप से उपयोग होता है, लेकिन latency trade-offs के कारण सार्वभौमिक नहीं है।

heat management

• heat management का मतलब है load को कई storage nodes में यथासंभव समान रूप से फैलाना, ताकि hotspots से बचा जा सके जो latency spikes या प्रति second operations में गिरावट जैसी externally visible performance problems पैदा कर सकते हैं
• इसे load balancing भी कहा जा सकता है, लेकिन आम तौर पर load balancer शब्द stateless nodes के लिए इस्तेमाल होता है
• stateful systems में hotspots हो सकते हैं, जहाँ high-demand objects किसी खास storage node पर group हो जाते हैं और contention पैदा करते हैं
• load balancer random, least-connections या कुछ FIFO variants जैसी simple strategies से stateless node set में load समान रूप से बाँट सकते हैं, लेकिन stateful systems में requests को उस node पर route करना पड़ता है जहाँ data मौजूद है
• load को फिर से बाँटने के लिए data को move करना आम तौर पर rebalancing कहलाता है
• इससे भी जटिल बात यह है कि समय के साथ load distribution बदल सकती है
  • data distribution एक dynamic process बन जाती है जिसे छोटे data subset को प्रभावित करने वाले short-term peaks से लेकर कई tenants में दिखाई देने वाले daily patterns या seasonal events से होने वाले बड़े load shifts तक सब कुछ संभालना पड़ता है
• बड़े data sets, जैसे large-scale databases या high-throughput event streams, को load effectively distribute करने के लिए shard करना पड़ता है
  • rebalancing तब shards की rebalancing बन जाती है, और system load distribution बदलने पर shards को split और merge भी कर सकता है
  • लेकिन shard की संख्या और size से जुड़े trade-offs, जैसे data locality, मौजूद हो सकते हैं
  • एक तरफ data का अधिक co-location retrieval को अधिक efficient बनाता है
  • दूसरी तरफ, बहुत अधिक shards से data fetch करने वाले compute work की लागत, ज्यादा servers पर load फैलाने से मिलने वाले लाभ से अधिक हो सकती है
• heat management single-tenant systems में भी ज़रूरी हो सकती है, इसलिए यह सिर्फ multi-tenant समस्या नहीं है
  • लेकिन MT data systems में यह और अधिक महत्वपूर्ण हो जाती है ताकि tenants को service quality में उतार-चढ़ाव न झेलना पड़े

उच्च resource utilization हासिल करना

• serverless multi-tenant architecture लागू करने की एक प्रमुख प्रेरणा यह है कि underlying hardware resources का अधिक कुशल उपयोग करके बेहतर economic performance दी जा सके
• resource pooling के जरिए resource utilization बढ़ाना सबसे महत्वपूर्ण है, लेकिन tenant isolation और predictable performance के साथ इसे हासिल करना कठिन चुनौती है

cold start

• ऐसे serverless systems जो tenant स्तर पर resources को zero तक scale down करते हैं, वे तब cold start की समस्या का सामना कर सकते हैं जब tenant workload फिर से शुरू करता है
• cold start शुरू से ही serverless functions का मुख्य फोकस रहा है, और यह कुछ serverless data systems को भी प्रभावित कर सकता है
• कुछ systems में cold start बिल्कुल नहीं होता, जबकि दूसरे systems में architecture और scale-to-zero product offering के कारण cold start लगभग अपरिहार्य हो सकता है
• मैंने जो भी उदाहरण देखे हैं, उनमें cold start की समस्या एक product decision है, और pricing plan तथा billing model के अनुसार resource reduction का स्तर अलग हो सकता है
• अंततः ग्राहक और provider अपनी-अपनी ज़रूरत के अनुसार trade-off चुन सकते हैं

जिन systems का अध्ययन किया गया

• Group 1 - Storage APIs (compute-light)
  • Amazon DynamoDB (chapter 1)
  • Kora - Confluent Cloud के भीतर serverless Kafka engine (chapter 2)
  • Backblaze B2 (planned)
• Group 2 - SQL OLTP databases (compute-heavy)
  • Neon - serverless PostgreSQL (chapter 3)
  • CockroachDB की 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).
• यह कार्य आगे भी जारी रहेगा, लेकिन जनवरी/फ़रवरी 2024 में किसी तरह की 'conclusion' post आने की योजना है