AWS पर फ़ॉल्ट-टॉलरेंट और रेज़िलिएंट एप्लिकेशन डिज़ाइन करना

AWS पर एप्लिकेशन विकसित करना

Ricardo Sueiras

Principal Technologist

रेज़िलिएंस के लिए बनाना

अस्थायी विफलताएँ

 

• आम फेल्योर मोड समझें:
• अस्थायी एरर खुद ठीक हो जाते हैं, आम तौर पर रीट्राई सुरक्षित है.

टाइमआउट्स

 

• आम फेल्योर मोड समझें:
• अस्थायी एरर खुद ठीक हो जाते हैं, आम तौर पर रीट्राई सुरक्षित है.
• टाइमआउट: बाहरी सर्विस का रिस्पॉन्स बहुत देर से आता है.

स्थायी त्रुटियाँ

 

• आम फेल्योर मोड समझें:
• अस्थायी एरर खुद ठीक हो जाते हैं, आम तौर पर रीट्राई सुरक्षित है.
• टाइमआउट: बाहरी सर्विस का रिस्पॉन्स बहुत देर से आता है.
• स्थायी एरर: रिक्वेस्ट मूल रूप से टूटी है, रीट्राई बेअसर होगा.

API सीमाएँ

 

• आम फेल्योर मोड समझें:
• अस्थायी एरर खुद ठीक हो जाते हैं, आम तौर पर रीट्राई सुरक्षित है.
• टाइमआउट: बाहरी सर्विस का रिस्पॉन्स बहुत देर से आता है.
• स्थायी एरर: रिक्वेस्ट मूल रूप से टूटी है, रीट्राई बेअसर होगा.
• API रेट लिमिट्स: बहुत ज़्यादा रिक्वेस्ट; HTTP 429 Too Many Requests मिलेगा.

रीट्राई रणनीतियाँ

• डिस्ट्रिब्यूटेड सिस्टम में फेल्योर अक्सर अस्थायी होते हैं.
• रीट्राई की गई रिक्वेस्ट अक्सर सफल हो जाती है.
• रीट्राई लॉजिक सोच-समझकर जोड़ें, ब्लाइंड रीट्राई हालात बिगाड़ सकते हैं.
• Exponential backoff: रीट्राई के बीच डिले बढ़ाएँ.
• Jitter: रीट्राई स्पाइक्स से बचने को रैंडमनेस जोड़ें.
• रीट्राई लिमिट्स: अनंत लूप रोकें.

 

AWS SDK की नेटिव क्षमताएँ

• AWS SDKs रीट्राई लॉजिक ऑटोमैटिकली संभालते हैं.
• बिल्ट-इन रीट्राई में exponential backoff और jitter शामिल हैं.
• फेल या throttled रिक्वेस्ट बढ़ते डिले के साथ रीट्राई होती हैं.
• इससे आपको कम एरर-हैंडलिंग कोड लिखना पड़ता है.

 

रीट्राई लॉजिक प्रबंधन

 

• रीट्राई लॉजिक हमेशा समाधान नहीं है.
• HTTP 4xx एरर: सर्वर ने आपकी रिक्वेस्ट समझकर अस्वीकार कर दी.
• Non-idempotent रिक्वेस्ट: रीट्राई से डुप्लिकेट या असंगत क्रियाएँ हो सकती हैं.

टाइमआउट्स प्रबंधन

 

• बिना लिमिट के रीट्राई लोड में समस्या बढ़ा सकते हैं.
• रीट्राई को टाइमआउट्स के साथ मिलाएँ.
• टाइमआउट वह अधिकतम प्रतीक्षा समय तय करता है.
• हर बाहरी सर्विस कॉल में टाइमआउट होना चाहिए.

सर्किट ब्रेकर्स

• जब कोई सर्विस लगातार फेल हो, केवल रीट्राई काफ़ी नहीं.
• रिक्वेस्ट भेजते रहना फेल सर्विस को ओवरलोड कर सकता है.
• सर्किट ब्रेकर पैटर्न अस्वस्थ डिपेंडेंसी को अस्थायी रूप से रोकता है.
• Closed स्टेट: रिक्वेस्ट सामान्य रूप से बहती हैं.

 

सर्किट ब्रेकर्स

• जब फेल्योर थ्रेशहोल्ड से ऊपर जाएँ, सर्किट खुल जाता है.
• बाद की रिक्वेस्ट ब्लॉक हो जाती हैं.

 

सर्किट ब्रेकर्स

• कूलडाउन के बाद रिकवरी जाँचने को सर्किट half-open स्टेट में जाता है.
• सर्विस सफल रिस्पॉन्स दे: सामान्य ऑपरेशन फिर शुरू.
• अब भी फेल: सर्किट खुला रहता है.
• सर्किट ब्रेकर्स को एप्लिकेशन लेवल पर लागू करें.

 

Dead letter queues

 

• बार-बार फेल होने वाले मैसेज सिस्टम को ब्लॉक कर सकते हैं.
• उन्हें मुख्य प्रोसेसिंग फ्लो से हटा दें.
• फेल मैसेज Dead Letter Queue में भेजें.
• रेज़िलिएंट एप्लिकेशन बनाने का अहम हिस्सा.
• लेकिन trade-offs समझें.

AWS API सीमाएँ

 

• आप AWS सर्विसेज़ से APIs के ज़रिए इंटरेक्ट करते हैं.
• हर सर्विस अपनी API रेट लिमिट्स तय करती है.
• लिमिट पार होने पर throttling (HTTP 429 Too Many Requests) ट्रिगर होता है.
• अपनी एप्लिकेशन को throttling संभालने लायक डिज़ाइन करें.

थर्ड-पार्टी सर्विसेज़ के साथ इंटीग्रेशन

• थर्ड-पार्टी सर्विसेज़ अनिश्चितता लाती हैं.
• उनके प्रदर्शन या उपलब्धता पर आपका नियंत्रण नहीं.
• लंबा इंतज़ार रोकने को टाइमआउट सेट करें.
• अस्थायी समस्याओं के लिए बैकऑफ के साथ रीट्राई करें.
• डिपेंडेंसीज़ को आइसोलेट करें ताकि प्रभाव सीमित रहे.

 

थर्ड-पार्टी इंटीग्रेशन

• synchronous से asynchronous कम्युनिकेशन पर शिफ्ट करने पर विचार करें.
• बाहरी सर्विस में देरी हो तब भी आपका सिस्टम प्रोसेस करता रहता है.

 

अभ्यास करते हैं!

AWS पर एप्लिकेशन विकसित करना