सेवाओं का समन्वय और स्टेट मैनेजमेंट

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

Ricardo Sueiras

Principal Technologist

Service Coordination

 

• एक वर्कफ़्लो पूरा करने के लिए कई सेवाओं को साथ काम करना होता है.
• उन्हें एक समन्वय रणनीति चाहिए.
• दो तरीके: orchestration और choreography.

Orchestration

 

• एक केंद्रीय orchestrator वर्कफ़्लो का समन्वय करता है.
• Orchestrator क्रम नियंत्रित करता है और अगली सेवा तय करता है.
• रीट्राई, कंडीशनल लॉजिक, और एरर हैंडलिंग के लिए उपयोगी.
• AWS पर: Step Functions से Lambda, ECS, DynamoDB में लागू.

Orchestration

 

• वर्कफ़्लो लॉजिक एक ही जगह होने से डिबग और मॉनिटर करना आसान.
• ट्रेडऑफ: एक केंद्रीय निर्भरता जुड़ती है.

Choreography

• कोई केंद्रीय कंट्रोलर नहीं.
• सेवाएँ इवेंट्स पर स्वतंत्र रूप से रिएक्ट करती हैं.
• हर सेवा संबंधित इवेंट सुनती है और अपना काम करती है.
• किसी सेवा को पूरा वर्कफ़्लो जानने की ज़रूरत नहीं.
• ढीला कपलिंग और स्केलेबिलिटी बेहतर होती है.

 

Choreography

• AWS पर: EventBridge, SNS, SQS.
• अत्यधिक स्केलेबल.
• ट्रेडऑफ: वर्कफ़्लो बढ़ने पर समझना और डिबग करना कठिन.

 

Event-driven architecture

• सेवाएँ इवेंट्स प्रोड्यूस और कंज्यूम करके संवाद करती हैं.
• सेवाओं के बीच ढीला कपलिंग बढ़ता है.
• उच्च स्केलेबिलिटी को बढ़ावा.
• इवेंट्स का पैरेलल प्रोसेसिंग संभव.
• नए सेवाएँ बिना मौजूदा बदले सब्सक्राइब कर सकती हैं.

 

Event-driven architecture

 

• EDA लागू करते समय ट्रेडऑफ:
• eventual consistency के लिए डिज़ाइन करें.
• idempotency लागू करें.
• फ़ेल्योर हैंडलिंग अधिक जटिल होती है.

Idempotency

 

• वही ऑपरेशन कई बार चलाने पर भी परिणाम समान रहे.
• async और event-driven सिस्टम में अहम डिज़ाइन सिद्धांत.
• डिस्ट्रीब्यूटेड सिस्टम डुप्लिकेट इवेंट दे सकते हैं (रीट्राई, नेटवर्क फ़ेल्योर, रीप्रोसेसिंग).
• सिस्टम की करेक्टनेस और विश्वसनीयता बनी रहती है.

Dead letter queues

 

• असिंक्रोनस कम्युनिकेशन में फ़ेल्योर मैनेज करता है.
• समस्याग्रस्त "poison" मैसेज अलग करता है.
• बार-बार रीट्राई फ़ेल होने पर मैसेज DLQ में जाता है.
• मुख्य प्रोसेसिंग फ्लो चलता रहता है.

Dead letter queues

• तब उपयोग करें जब मैसेज ऑर्डरिंग क्रिटिकल न हो.
• नॉन-क्रिटिकल सिस्टम के लिए छोड़ें जहाँ कभी-कभार डेटा लॉस स्वीकार्य हो.
• तब अवॉइड करें जब मैसेज ऑर्डरिंग बनाए रखना ज़रूरी हो.

 

स्टेट मैनेजमेंट

• क्लाउड-नेटिव ऐप्स के लिए स्टेट मैनेजमेंट बुनियादी है.
• स्टेट वह डेटा है जो इंटरैक्शन के बीच बना रहता है.
• सर्वर पर लोकल स्टेट रखने से स्केलेबिलिटी और रेज़िलिएंस सीमित होती है.

 

स्टेट मैनेजमेंट

• आप जो बना रहे हैं, उसके आधार पर स्टेट मैनेजमेंट में ट्रेडऑफ होते हैं.
• एक्सटर्नल स्टेट स्केलेबिलिटी और रेज़िलिएंस बढ़ाता है.
• लागत: अतिरिक्त लेटेंसी और जटिलता.
• ध्यान दें: consistency, caching, और डेटा एक्सेस पैटर्न.

 

Stateful

 

• सेशन डेटा सर्वर पर बना रहता है.
• रिक्वेस्ट्स को उसी इंस्टेंस पर रूट करना होता है (sticky sessions).
• स्केलिंग फ्लेक्सिबिलिटी सीमित होती है.
• इंस्टेंस फेल होने पर सेशन खत्म.

Stateless

 

• हर रिक्वेस्ट स्वतंत्र माना जाता है.
• सर्वर पर कोई स्टेट नहीं रखा जाता.
• स्टेट बाहरी सिस्टम में रहता है.
• क्लाउड-नेटिव ऐप्स के लिए पसंदीदा तरीका.
• कोई भी इंस्टेंस कोई भी रिक्वेस्ट संभाल सकता है, इसलिए हॉरिज़ोंटल स्केलिंग आसान.

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

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