Samsung की चिप मेमोरी के अंदर ही प्रोसेसिंग करती है: SaaS के लिए सबक

आपका सिस्टम धीमा है और सर्वर का बिल बस बढ़ता ही जा रहा है। आपने प्लान बदल लिया, मशीन बड़ी कर ली, और समस्या फिर लौट आई। मैं आपको बताना चाहता हूं कि ऐसा क्यों होता है। और वह भी एक अनोखे उदाहरण से: Samsung की एक मेमोरी चिप जिसने खुद गणना करना सीख लिया।

Hot Chips में, जहां निर्माता अपनी नई चिप्स दिखाते हैं, Samsung ने PIM का नया संस्करण पेश किया। PIM यानी Processing-in-Memory। सीधी भाषा में: मेमोरी के अंदर ही प्रोसेसिंग। और इस तकनीक के पीछे का विचार बहुत कुछ समझाता है कि कोई SaaS महंगा और धीमा क्यों हो जाता है। मेरे साथ बने रहिए, मैं सब आसान भाषा में समझाता हूं।

Samsung जिस समस्या पर हमला कर रही है

हर कंप्यूटर ऐसे काम करता है: डेटा मेमोरी में रखा रहता है, और प्रोसेसर गणना करता है। लेकिन मेमोरी और प्रोसेसर अलग-अलग चिप्स हैं। कुछ भी कैलकुलेट करने के लिए डेटा को एक चिप से दूसरी तक जाना पड़ता है, और फिर वापस आना पड़ता है।

यही सफर असली अड़चन है। इंडस्ट्री इसे "memory wall" कहती है, यानी मेमोरी की दीवार। पिछले दशकों में प्रोसेसर बेहद तेज़ हो गया। लेकिन उसके और मेमोरी के बीच की सड़क उतनी नहीं। नतीजा: प्रोसेसर ज़्यादातर समय खाली बैठा डेटा का इंतज़ार करता रहता है।

और एक बात जो इस क्षेत्र के बाहर बहुत कम लोग जानते हैं: डेटा को हिलाने में गणना करने से ज़्यादा ऊर्जा खर्च होती है। गणित का ऑपरेशन खुद सस्ता है। ढुलाई महंगी है। AI के साथ यह समस्या फट पड़ी, क्योंकि AI मॉडल असल में डेटा के पहाड़ हैं जो लगातार एक तरफ से दूसरी तरफ ढोए जा रहे हैं।

Samsung का समाधान इतना सरल है कि लगभग स्पष्ट लगता है: अगर सफर ही समस्या है, तो सफर खत्म कर दो। उन्होंने छोटी-छोटी गणना इकाइयां मेमोरी चिप के अंदर ही डाल दीं। अब डेटा सफर नहीं करता। गणना वहीं होती है जहां डेटा रहता है। कम ऊर्जा, कम इंतज़ार, प्रति वॉट ज़्यादा नतीजा।

महंगी चीज़ कभी गणना नहीं थी। ढुलाई है।

इसका आपके SaaS से क्या लेना-देना है

सब कुछ। क्योंकि आपका सिस्टम भी ठीक इसी बीमारी से जूझता है, बस बड़े पैमाने पर।

अपने सिस्टम की किसी आम स्क्रीन का रास्ता सोचिए, जैसे बिक्री का डैशबोर्ड। ग्राहक का ब्राउज़र पेज मांगता है। सर्वर उसे पाता है। सर्वर डेटाबेस से पूछता है, जो कभी दूसरी मशीन पर होता है, कभी दूसरे डेटा सेंटर में। डेटाबेस 50 हज़ार लाइनें लौटाता है। सर्वर उन्हें प्रोसेस करता है, जोड़ता है, ग्रुप करता है, फ़िल्टर करता है। नतीजा ब्राउज़र को भेजता है। ब्राउज़र स्क्रीन बनाता है।

देखा कितने सफर हुए? हर तीर डेटा की आवाजाही है। और हर आवाजाही समय और पैसा खर्च कराती है। क्लाउड प्रोवाइडर आउटगोइंग ट्रैफ़िक का पैसा लेते हैं, हर रिक्वेस्ट का लेते हैं, प्रोसेसिंग टाइम का लेते हैं। जब डेटा ज़रूरत से ज़्यादा घूमता है, तो उस घुमाई का किराया आप देते हैं।

क्लासिक गलती यह है: स्क्रीन पर एक अकेला नंबर दिखाने के लिए डेटाबेस से 50 हज़ार लाइनें खींचकर सर्वर पर जोड़ना। डेटाबेस को जोड़ना आता है। वह यह काम आपके किसी भी कोड से बेहतर और तेज़ करता है। कच्ची लाइनों की जगह तैयार जोड़ मांगना ठीक वही है जो Samsung ने हार्डवेयर में किया, बस सॉफ्टवेयर संस्करण में: गणना को डेटा तक ले जाना, डेटा को गणना तक घसीटने की बजाय।

संकेत कि आपका सिस्टम ज़रूरत से ज़्यादा भाड़ा चुका रहा है

शक करने के लिए आपको कोड पढ़ने की ज़रूरत नहीं। कुछ लक्षण रोज़ के कामकाज में ही दिख जाते हैं:

• क्लाउड का बिल ग्राहकों की संख्या से तेज़ बढ़ता है।
• रिपोर्ट खुलने में कई सेकंड लगते हैं, या महीने के अंत में "अटक" जाती हैं।
• तकनीकी टीम सुस्ती हमेशा एक ही तरीके से ठीक करती है: मशीन बड़ी करके।
• स्क्रीनें सब कुछ एक साथ लोड करती हैं, तब भी जब यूज़र सिर्फ सारांश देखना चाहता था।

आखिरी वाला धोखेबाज़ है। मैंने ऐसा सिस्टम देखा है जो सिर्फ नाम और बैलेंस दिखाने के लिए ग्राहक का पूरा इतिहास डाउनलोड करता था। 200 ग्राहकों के साथ ठीक चलता था। 20 हज़ार पर वह एक लिफाफा पहुंचाने के लिए पूरा मूविंग ट्रक बन गया।

मशीन बड़ी करने से लक्षण कुछ महीनों के लिए दब जाता है। यह ऐसा है जैसे बड़ा ट्रक खरीद लेना क्योंकि आप हर बार पूरा सामान ढोने पर अड़े हैं। सही सवाल यह नहीं है कि "बड़ा ट्रक कितने का है"। सही सवाल है "हम यह सब ढो ही क्यों रहे हैं"।

तीन बदलाव जो PIM वाली ही सोच पर चलते हैं

मैं यह नहीं कह रहा कि आप Samsung की चिप खरीदें। मैं कह रहा हूं कि सिद्धांत चुरा लें: प्रोसेसिंग को डेटा के पास ले जाएं। व्यवहार में तीन मोर्चे ज़्यादातर मामले सुलझा देते हैं।

डेटाबेस को काम करने दें। जोड़, औसत, ग्रुपिंग, फ़िल्टर: यह सब डेटाबेस अपने आप करता है। अगर आपका सर्वर विशाल सूचियां प्रोसेस करने के लिए मंगा रहा है, तो गणना गलत जगह हो रही है। एक अच्छी लिखी क्वेरी सैकड़ों लाइनों का कोड बदल देती है और डेटा के सफर को जड़ से काट देती है।

नतीजा संभालकर रखें, गणना दोहराएं नहीं। अगर बिक्री का डैशबोर्ड दिन में 300 बार देखा जाता है और आंकड़े हर घंटे ही बदलते हैं, तो घंटे में एक बार गणना करें और तैयार नतीजा परोसें। इसे cache कहते हैं, और परफॉर्मेंस में शायद इससे बेहतर रिटर्न किसी चीज़ का नहीं। Samsung ने डेटा का सफर खत्म किया। Cache दोहराई गई गणना खत्म करता है। एक ही परिवार का विचार है।

कंटेंट को इस्तेमाल करने वाले के पास परोसें। अगर आपके ग्राहक ब्राज़ील में हैं और सर्वर वर्जीनिया में, तो हर क्लिक दो बार महाद्वीप पार करता है। CDN और यूज़र के करीब वाले सर्वर रीजन PIM का भौगोलिक रूप हैं: डेटा और उसकी ज़रूरत वाले के बीच की दूरी घटाना।

इन तीनों में से किसी के लिए सिस्टम दोबारा लिखने की ज़रूरत नहीं। ये आर्किटेक्चर के समायोजन हैं, जो लगभग हमेशा सर्वर अपग्रेड से सस्ते पड़ते हैं। और अपग्रेड के उलट, असर स्थायी है: आप भाड़ा देना बंद कर देते हैं, हर साल बड़ा ट्रक खरीदने की बजाय।

आगे चलकर यह और क्यों भारी पड़ेगा

Samsung इसमें भारी निवेश AI की वजह से कर रही है। भाषा मॉडल बेतहाशा मात्रा में डेटा हिलाते हैं, और उसकी ऊर्जा लागत अरबों डॉलर की समस्या बन चुकी है। जब दुनिया के सबसे बड़े निर्माता डेटा का रास्ता छोटा करने के लिए हार्डवेयर दोबारा डिज़ाइन करते हैं, तो यह संकेत है कि ढुलाई कंप्यूटिंग की सबसे बड़ी लागत बन गई है।

यह पूरी चेन से होते हुए आप तक उतरता है। डेटा सेंटर ज़्यादा ऊर्जा खर्च करेंगे तो क्लाउड महंगा होगा। क्लाउड महंगा होगा तो फिज़ूलखर्च सिस्टम आपके नतीजे में दिखने वाला खर्च बन जाएगा। आने वाले सालों में अच्छे और बुरे आर्किटेक्चर वाले SaaS का फर्क सिर्फ रफ्तार का नहीं होगा। मार्जिन का होगा।

मेरी राय, और यह पक्की है: मैं जो सिस्टम देखता हूं, उनमें से ज़्यादातर को और सर्वर नहीं चाहिए। कम सफर चाहिए। मशीन का अपग्रेड इंडस्ट्री की डिफ़ॉल्ट दर्दनिवारक गोली बन गया है, और वह इसीलिए काम करता है क्योंकि आर्किटेक्चर वाली मुश्किल बातचीत को टाल देता है।

तकनीकी जटिल भाषा का बंधक बने बिना कहां से शुरू करें

काम करने के लिए आपको चिप समझने की ज़रूरत नहीं। ज़रूरत है अपने सिस्टम संभालने वालों से सही सवाल पूछने की:

• सबसे धीमी तीन स्क्रीनें कौन सी हैं, और जो दिखाती हैं उसके लिए कितना डेटा लोड करती हैं?
• हम हर बार क्या कैलकुलेट कर रहे हैं जो एक बार करके संभालकर रखा जा सकता था?
• हमारा क्लाउड बिल किस मद में बढ़ रहा है: प्रोसेसिंग, ट्रैफ़िक या स्टोरेज?

अगर जवाब गोलमोल आएं, तो वही डायग्नोसिस है। स्वस्थ सिस्टम के पास इन सवालों के सटीक जवाब होते हैं।

मैं ठीक इसी परत पर काम करता हूं: किसी कंपनी का सिस्टम देखना, यह ढूंढना कि डेटा कहां बेवजह घूम रहा है, और ऑटोमेशन तथा सादे आर्किटेक्चर से रास्ता छोटा करना। बड़ा सर्वर बेचे बिना, क्योंकि बड़ा सर्वर लगभग कभी जवाब नहीं होता। अगर आपका क्लाउड बिल आपकी कमाई से तेज़ बढ़ रहा है, तो मुझे बताएं कि आपका सिस्टम कैसा है और मैं बताऊंगा कि पहले कहां देखना है।

क्लाउड का बिल ग्राहकों की संख्या से भी तेज़ बढ़ रहा है? समस्या सर्वर नहीं है।

Samsung ने अभी एक ऐसी चिप दिखाई है जो गणना मेमोरी के अंदर ही कर लेती है। क्यों? क्योंकि डेटा को हिलाना उसे प्रोसेस करने से ज़्यादा महंगा पड़ता है।

आपका SaaS भी इसी बीमारी से जूझता है: स्क्रीन पर एक नंबर दिखाने के लिए डेटाबेस से 50 हज़ार लाइनें खींचता है। डेटा ज़रूरत से ज़्यादा सफर करता है, और उस सफर का किराया आप चुकाते हैं।

मशीन बड़ी करना ऐसा है जैसे हर बार पूरा घर का सामान ढोने के लिए बड़ा ट्रक खरीद लेना। सही सवाल यह है: हम यह सब ढो ही क्यों रहे हैं?

ज़्यादातर सिस्टम को और सर्वर की ज़रूरत नहीं है। कम सफर की ज़रूरत है।

अगर आपका क्लाउड बिल आपकी कमाई से तेज़ बढ़ रहा है, तो मुझसे बात करें। मैं बताऊंगा कि पहले कहां देखना है।

#SaaS #आर्किटेक्चर #CloudComputing #Performance #टेक्नोलॉजी