डेवलपर्स के रूप में, बड़े पैमाने पर डेटा प्रोसेसिंग और डिलीवरी से निपटने के दौरान हमें अक्सर चुनौतियों का सामना करना पड़ता है। कामेरो में, हमने हाल ही में अपनी फ़ाइल वितरण पाइपलाइन में एक महत्वपूर्ण बाधा का सामना किया है। हमारा एप्लिकेशन उपयोगकर्ताओं को किसी विशेष घटना से जुड़ी हजारों फ़ाइलों को एक ज़िप फ़ाइल के रूप में डाउनलोड करने की अनुमति देता है। यह सुविधा, जो Node.js-आधारित लैम्ब्डा फ़ंक्शन द्वारा संचालित है, जो S3 बकेट से फ़ाइलों को लाने और ज़िप करने के लिए जिम्मेदार है, हमारे उपयोगकर्ता आधार के बढ़ने के साथ मेमोरी बाधाओं और लंबे निष्पादन समय से जूझ रही थी।

यह पोस्ट संसाधन-भूखे Node.js कार्यान्वयन से एक दुबले और बिजली की तेजी से चलने वाले गो समाधान तक की हमारी यात्रा का विवरण देती है जो बड़े पैमाने पर S3 डाउनलोड को कुशलतापूर्वक संभालता है। हम यह पता लगाएंगे कि विशिष्ट घटनाओं से बड़ी संख्या में फ़ाइलों का अनुरोध करते समय उपयोगकर्ताओं को एक सहज अनुभव प्रदान करने के लिए हमने अपने सिस्टम को कैसे अनुकूलित किया, सभी को एक सुविधाजनक एकल ज़िप डाउनलोड में पैक किया गया।

चुनौती

बड़े इवेंट-आधारित फ़ाइल सेट को संसाधित करते समय हमारे मूल लैम्ब्डा फ़ंक्शन को कई महत्वपूर्ण मुद्दों का सामना करना पड़ा:

1. मेमोरी खपत: 10 जीबी आवंटित मेमोरी के साथ भी, बड़े आयोजनों के लिए 20,000 फ़ाइलों को संसाधित करते समय फ़ंक्शन विफल हो जाएगा।
2. निष्पादन समय: कई फ़ाइलों वाले ईवेंट के लिए ज़िप संचालन में बहुत अधिक समय लग रहा था, कभी-कभी पूरा होने से पहले ही समय समाप्त हो जाता था।
3. स्केलेबिलिटी: फ़ंक्शन बढ़ते लोड को कुशलतापूर्वक संभाल नहीं सका, जिससे लोकप्रिय घटनाओं से बड़े फ़ाइल सेट वाले उपयोगकर्ताओं को सेवा प्रदान करने की हमारी क्षमता सीमित हो गई।
4. उपयोगकर्ता अनुभव: धीमी डाउनलोड तैयारी का समय उपयोगकर्ता की संतुष्टि को प्रभावित कर रहा था, विशेष रूप से पर्याप्त फ़ाइल संख्या वाले ईवेंट के लिए।

Node.js कार्यान्वयन: एक त्वरित नज़र

हमारे मूल कार्यान्वयन ने S3 ऑब्जेक्ट से ज़िप फ़ाइलें बनाने के लिए s3-ज़िप लाइब्रेरी का उपयोग किया। हम फ़ाइलों को कैसे संसाधित कर रहे थे इसका एक सरलीकृत स्निपेट यहां दिया गया है:

const s3Zip = require("s3-zip");

// ... other code ...

const body = s3Zip.archive(
  { bucket: bucketName },
  eventId,
  files,
  entryData
);

await uploadZipFile(Upload_Bucket, zipfileKey, body);

जबकि यह दृष्टिकोण काम करता था, इसने ज़िप बनाने से पहले सभी फाइलों को मेमोरी में लोड कर दिया, जिससे उच्च मेमोरी उपयोग और बड़े फ़ाइल सेट के लिए संभावित आउट-ऑफ-मेमोरी त्रुटियां हुईं।

एंटर गो: ए गेम-चेंजिंग रीराइट

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

1. मेमोरी उपयोग: समान कार्यभार के लिए 10जीबी से घटकर मात्र 100एमबी रह गया।
2. गति: फ़ंक्शन लगभग 10 गुना तेज़ हो गया।
3. विश्वसनीयता: बिना किसी समस्या के 20,000 फ़ाइलों को सफलतापूर्वक संसाधित करता है।

गो कार्यान्वयन में प्रमुख अनुकूलन

1. कुशल S3 संचालन

हमने Go v2 के लिए AWS SDK का उपयोग किया, जो v1 की तुलना में बेहतर प्रदर्शन और कम मेमोरी उपयोग प्रदान करता है:

cfg, err := config.LoadDefaultConfig(context.TODO())
s3Client = s3.NewFromConfig(cfg)

2. समवर्ती प्रसंस्करण

गो के गोरआउट्स ने हमें एक साथ कई फाइलों को संसाधित करने की अनुमति दी:

var wg sync.WaitGroup
sem := make(chan struct{}, 10) // Limit concurrent operations

for _, photo := range photos {
    wg.Add(1)
    go func(photo Photo) {
        defer wg.Done()
        sem 



यह दृष्टिकोण हमें सिस्टम पर दबाव डालने से रोकने के लिए समवर्ती स्तर को नियंत्रित करते हुए एक साथ कई फाइलों को संसाधित करने की अनुमति देता है।


  
  
  3. स्ट्रीमिंग ज़िप निर्माण


सभी फ़ाइलों को मेमोरी में लोड करने के बजाय, हम ज़िप सामग्री को सीधे S3 पर स्ट्रीम करते हैं:


pipeReader, pipeWriter := io.Pipe()

go func() {
    zipWriter := zip.NewWriter(pipeWriter)
    // Add files to zip
    zipWriter.Close()
    pipeWriter.Close()
}()

// Upload streaming content to S3
uploader.Upload(ctx, &s3.PutObjectInput{
    Bucket: &destBucket,
    Key:    &zipFileKey,
    Body:   pipeReader,
})




यह स्ट्रीमिंग दृष्टिकोण मेमोरी उपयोग को काफी कम कर देता है और हमें बहुत बड़े फ़ाइल सेट को संभालने की अनुमति देता है।


  
  
  परिणाम


गो को पुनः लिखने से प्रभावशाली सुधार हुए:


मेमोरी उपयोग: 99% कम (10जीबी से 100एमबी तक)

प्रसंस्करण गति: लगभग 1000% की वृद्धि

विश्वसनीयता: बिना किसी समस्या के 20,000 फ़ाइलों को सफलतापूर्वक संभालता है

लागत दक्षता: कम मेमोरी उपयोग और तेज़ निष्पादन समय के परिणामस्वरूप AWS लैम्ब्डा लागत कम हो जाती है

  
  
  सीख सीखी



भाषा चयन मायने रखता है: गो की दक्षता और समवर्ती मॉडल ने हमारे उपयोग के मामले में भारी अंतर ला दिया है।

अपनी बाधाओं को समझें: हमारे Node.js फ़ंक्शन की प्रोफाइलिंग से हमें सुधार के लिए प्रमुख क्षेत्रों की पहचान करने में मदद मिली।

क्लाउड-नेटिव सॉल्यूशंस का लाभ उठाएं: बेहतर एकीकरण और प्रदर्शन के लिए Go v2 के लिए AWS SDK का उपयोग करना और S3 की क्षमताओं को समझना संभव है।

स्ट्रीम्स में सोचें: बड़े पैमाने के संचालन के लिए सब कुछ मेमोरी में लोड करने के बजाय डेटा को स्ट्रीम के रूप में संसाधित करना महत्वपूर्ण है।

  
  
  निष्कर्ष


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

याद रखें, सबसे अच्छी भाषा या रूपरेखा आपके विशिष्ट उपयोग के मामले पर निर्भर करती है। हमारे परिदृश्य में, गो की प्रदर्शन विशेषताएँ हमारी आवश्यकताओं के साथ पूरी तरह से मेल खाती हैं, जिसके परिणामस्वरूप उपयोगकर्ता अनुभव में काफी सुधार हुआ और परिचालन लागत कम हो गई।

क्या आपने सर्वर रहित कार्यों के साथ समान चुनौतियों का सामना किया है? आपने उन पर कैसे काबू पाया? हमें नीचे टिप्पणियों में आपके अनुभवों के बारे में सुनना अच्छा लगेगा!