AWS पर एप्लिकेशन आर्किटेक्चर पैटर्न

AWS पर एप्लिकेशन डिप्लॉय करना

Dunieski Otano

Amazon Web Services Solutions Architect

अपने इंस्ट्रक्टर से मिलें

कोर्स इंस्ट्रक्टर Dunieski Otano, एक AWS सॉल्यूशंस आर्किटेक्ट, जिनके पास लगभग दस साल का क्लाउड अनुभव है

सही आर्किटेक्चर क्यों मायने रखता है

लाइट-थीम निर्णय आरेख, जहाँ एक आर्किटेक्चर विकल्प तीन कारकों—कपलिंग, स्टेट, और कम्युनिकेशन—में बँटता है, और नीचे ट्रेड-ऑफ्स के लिए एक छोटी तराजू-आइकन है

आर्किटेक्चर ट्रेड-ऑफ्स का सेट है, एक सही जवाब नहीं
- हर चुनाव को तीन प्रश्न दिशा देते हैं:
  - कॉम्पोनेंट कितने कपल्ड हैं?
  - स्टेट कहाँ रहता है?
  - कम्युनिकेशन सिंक्रोनस या असिंक्रोनस है?
- पैटर्न को वर्कलोड से मिलाएँ, फैशन से नहीं

फ्राइडे नाइट कैस्केड

धीमा पेमेंट API पूरा चेकआउट फ्रीज कर देता है
हर सर्विस उस पर सिंक्रोनसली इंतज़ार करती रही
समाधान आर्किटेक्चर है, न कि तेज़ API

साइड-बाय-साइड तुलना: टाइटली कपल्ड सर्विसेज जो रुक जाती हैं बनाम मैसेज क्यू से डीकपल्ड सर्विसेज

आर्किटेक्चर चुनाव डिप्लॉयमेंट क्यों तय करते हैं

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

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

मुख्य आर्किटेक्चर पैटर्न

Monolithic: एक डिप्लॉयबल यूनिट, शुरू करना आसान
Microservices: स्वतंत्र सर्विसेज, अलग-अलग डिप्लॉय
Event-driven: कॉम्पोनेंट्स डायरेक्ट कॉल्स नहीं, इवेंट्स पर रिएक्ट करते हैं
- Fanout एक सब-पैटर्न: एक इवेंट कई कंस्यूमर्स तक पहुँचता है

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

Stateful बनाम Stateless

Stateless: रिक्वेस्ट्स के बीच कोई क्लाइंट डेटा नहीं रखा जाता
- कोई भी इंस्टेंस कोई भी रिक्वेस्ट संभाल सकता है
Stateful: इंस्टेंस पिछली इंटरैक्शन्स याद रखता है
Statelessness से आप हॉरिजॉन्टली स्केल कर पाते हैं
- साझा स्टेट को DynamoDB या ElastiCache में रखें

बाएँ: स्टेटलेस फंक्शन इंस्टेंस जिसे कोई भी रिक्वेस्ट पहुंच सकती है; दाएँ: स्टेटफुल इंस्टेंस जो एक क्लाइंट सेशन से बँधा है

टाइट बनाम लूज़ कपलिंग

टाइट कपलिंग जहाँ कॉलर धीमे कली की प्रतीक्षा में ब्लॉक होता है बनाम लूज़ कपलिंग जहाँ SQS क्यू मैसेज बफ़र करती है ताकि प्रोड्यूसर चलता रहे

टाइट कपलिंग: कॉलर उत्तर के लिए कली का इंतज़ार करता है
एक धीमी सर्विस पूरी चेन रोक देती है
लूज़ कपलिंग: सर्विसेज के बीच Amazon SQS क्यू होती है
कंस्यूमर डाउन हो तो भी प्रोड्यूसर काम करता रहता है

Synchronous बनाम Asynchronous

Synchronous: कॉलर ब्लॉक होकर नतीजे का इंतज़ार करता है
तब उपयोग करें जब जवाब अभी चाहिए
Asynchronous: कॉलर काम सौंपकर लौट आता है
धीमे, बर्स्टी, या गैर-जरूरी काम के लिए उपयोग करें

बाएँ: सिंक्रोनस कॉल जहाँ कॉलर रिस्पॉन्स आने तक ब्लॉक है; दाएँ: असिंक्रोनस हैंडऑफ जो तुरंत लौट आता है और प्रोसेसिंग बैकग्राउंड में होती है

थर्ड-पार्टी कॉल्स के लिए रेज़िलिएंस पैटर्न

Exponential backoff के साथ retry: हर प्रयास के बीच अधिक प्रतीक्षा करें
Circuit breaker: कुछ समय के लिए असफल सर्विस को कॉल करना रोकें
Dead-letter queue: बार-बार फेल होने वाले मैसेज पार्क करें
इन्हें मिलाकर उपयोग करें; ब्लैंकेट रिट्राइज आउटेज बढ़ाते हैं

तीन रेज़िलिएंस पैटर्न: एक्सपोनेंशियल बैकऑफ रिट्राई कर्व, सर्किट ब्रेकर जो फेलिंग सर्विस को कॉल्स रोकता है, और डेड-लेटर क्यू जो रिट्राई समाप्त होने पर मैसेज कैप्चर करती है

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

AWS पर एप्लिकेशन डिप्लॉय करना