API Gateway के साथ API रिलीज़ रणनीतियाँ
December 22, 2022
एक बार जब आप डिप्लॉयमेंट और रिलीज़ को पर्याप्त रूप से अलग कर लेते हैं, तो अगला कदम फीचर्स के प्रगतिशील रिलीज़ को नियंत्रित करने के लिए तंत्र चुनना है। यह आवश्यक है कि आप एक रिलीज़ रणनीति चुनें जो आपको प्रोडक्शन में जोखिम को कम करने की अनुमति दे। क्योंकि इससे कोई फर्क नहीं पड़ता कि आप रिलीज़ से पहले अपने API के नए संस्करण का कितना परीक्षण करते हैं, वास्तविक परीक्षण तब होता है जब आप इसे अंततः ग्राहकों के सामने रखते हैं।
हम इस जोखिम को कम करने के लिए ट्रैफ़िक के एक छोटे हिस्से के साथ परीक्षण या प्रयोग करके और परिणाम को सत्यापित करके प्राप्त कर सकते हैं। जब परिणाम सफल होता है, तो सभी ट्रैफ़िक के लिए रिलीज़ ट्रिगर होती है। विशिष्ट रणनीतियाँ कुछ परिदृश्यों के लिए दूसरों की तुलना में बेहतर होती हैं और अतिरिक्त सेवाओं और बुनियादी ढांचे की विभिन्न डिग्री की आवश्यकता होती है। इस पोस्ट में, हम 3 लोकप्रिय API रिलीज़ रणनीतियों का पता लगाएंगे जो आजकल API गेटवे का उपयोग करती हैं।
API डिप्लॉयमेंट में API गेटवे का उपयोग क्यों करें
API-आधारित आर्किटेक्चर की ओर बढ़ने का एक लाभ यह है कि हम जल्दी से पुनरावृत्ति कर सकते हैं और अपनी सेवाओं में नए परिवर्तन डिप्लॉय कर सकते हैं। हमारे पास आर्किटेक्चर के आधुनिकीकृत हिस्से के लिए API गेटवे के साथ ट्रैफ़िक और रूटिंग की अवधारणा भी स्थापित है। API गेटवे स्टेज प्रदान करता है जो आपको एक ही गेटवे के पीछे कई डिप्लॉय किए गए APIs रखने की अनुमति देता है और यह डाउनटाइम के बिना इन-प्लेस अपडेट करने में सक्षम है। API गेटवे का उपयोग करके आप सेवा के कई API प्रबंधन सुविधाओं का लाभ उठा सकते हैं, जैसे प्रमाणीकरण, दर थ्रॉटलिंग, ऑब्ज़र्वेबिलिटी (APIs के लिए महत्वपूर्ण मेट्रिक्स), कई API वर्ज़निंग, और स्टेज डिप्लॉयमेंट प्रबंधन (एक API को कई स्टेज में डिप्लॉय करना जैसे dev, test, stage, और prod)।
ओपन सोर्स API गेटवे (Apache APISIX और Traefik), सर्विस मेश (Istio और Linkerd) समाधान ट्रैफ़िक स्प्लिटिंग और कैनरी रिलीज़ और ब्लू-ग्रीन डिप्लॉयमेंट जैसी कार्यक्षमताओं को लागू करने में सक्षम हैं। कैनरी टेस्टिंग के साथ, आप अपने उपयोगकर्ता आधार के केवल एक छोटे हिस्से का चयन करके API के नए संस्करण का गंभीर परीक्षण कर सकते हैं। हम अगले भाग में कैनरी रिलीज़ को कवर करेंगे।
कैनरी रिलीज़
एक कैनरी रिलीज़ API के नए संस्करण को पेश करती है और ट्रैफ़िक के एक छोटे प्रतिशत को कैनरी की ओर प्रवाहित करती है। API गेटवे में, ट्रैफ़िक स्प्लिटिंग एक टार्गेट सेवा के एक संस्करण से दूसरे संस्करण में धीरे-धीरे ट्रैफ़िक को स्थानांतरित या माइग्रेट करना संभव बनाती है। उदाहरण के लिए, एक सेवा का नया संस्करण, v1.1, मूल संस्करण v1.0 के साथ डिप्लॉय किया जा सकता है। ट्रैफ़िक शिफ्टिंग आपको पहले केवल उपयोगकर्ता ट्रैफ़िक के एक छोटे प्रतिशत, जैसे 1%, को v1.1 की ओर रूट करके कैनरी टेस्ट या अपनी नई सेवा को रिलीज़ करने की अनुमति देती है, फिर समय के साथ अपने सभी ट्रैफ़िक को नई सेवा की ओर शिफ्ट करती है।
यह आपको नई सेवा की निगरानी करने, तकनीकी समस्याओं जैसे बढ़ी हुई लेटेंसी या त्रुटि दरों की तलाश करने, और वांछित व्यावसायिक प्रभाव जैसे ग्राहक रूपांतरण अनुपात या औसत शॉपिंग चेकआउट मूल्य जैसे प्रमुख प्रदर्शन संकेतकों में वृद्धि की तलाश करने की अनुमति देता है। ट्रैफ़िक स्प्लिटिंग आपको A/B या मल्टीवेरिएट टेस्ट चलाने की अनुमति देती है जिसमें एक टार्गेट सेवा के लिए ट्रैफ़िक को सेवा के कई संस्करणों के बीच विभाजित किया जाता है। उदाहरण के लिए, आप अपने टार्गेट सेवा के v1.0 और v1.1 के बीच ट्रैफ़िक को 50/50 विभाजित कर सकते हैं और देख सकते हैं कि एक विशिष्ट समय अवधि में कौन सा बेहतर प्रदर्शन करता है। Apache APISIX Ingress Controller में ट्रैफ़िक स्प्लिट सुविधा के बारे में अधिक जानें।
जहां उपयुक्त हो, कैनरी रिलीज़ एक उत्कृष्ट विकल्प है, क्योंकि कैनरी के लिए एक्सपोज़ किए गए ट्रैफ़िक का प्रतिशत अत्यधिक नियंत्रित होता है। ट्रेड-ऑफ यह है कि सिस्टम में अच्छी निगरानी होनी चाहिए ताकि किसी समस्या को जल्दी से पहचाना जा सके और यदि आवश्यक हो तो रोल बैक किया जा सके (जिसे स्वचालित किया जा सकता है)। यह गाइड आपको दिखाती है कि Apache APISIX और Flagger का उपयोग करके कैनरी रिलीज़ समाधान को जल्दी से कैसे लागू किया जाए।
ट्रैफ़िक मिररिंग
ट्रैफ़िक स्प्लिटिंग का उपयोग करके प्रयोग चलाने के अलावा, आप ट्रैफ़िक मिररिंग का उपयोग करके ट्रैफ़िक को कॉपी या डुप्लिकेट कर सकते हैं और इसे एक अतिरिक्त स्थान या स्थानों की श्रृंखला में भेज सकते हैं। अक्सर ट्रैफ़िक मिररिंग के साथ, डुप्लिकेट किए गए अनुरोधों के परिणाम कॉलिंग सेवा या अंतिम उपयोगकर्ता को वापस नहीं किए जाते हैं। इसके बजाय, प्रतिक्रियाओं को सहीता के लिए आउट-ऑफ-बैंड मूल्यांकन किया जाता है, जैसे कि एक रिफैक्टर्ड और मौजूदा सेवा द्वारा उत्पन्न परिणामों की तुलना करना, या एक नई सेवा संस्करण द्वारा अनुरोध को संभालने के रूप में कुछ परिचालन गुणों का अवलोकन किया जाता है, जैसे प्रतिक्रिया लेटेंसी या आवश्यक CPU।
ट्रैफ़िक मिररिंग का उपयोग करके आप "डार्क रिलीज़" सेवाओं को सक्षम कर सकते हैं, जहां उपयोगकर्ता को नई रिलीज़ के बारे में अंधेरे में रखा जाता है लेकिन आप आंतरिक रूप से आवश्यक प्रभाव के लिए अवलोकन कर सकते हैं।
सिस्टम के किनारे पर ट्रैफ़िक मिररिंग को लागू करना पिछले कुछ वर्षों में तेजी से लोकप्रिय हो गया है। APISIX प्रॉक्सी-मिरर प्लगइन प्रदान करता है जो क्लाइंट अनुरोधों को मिरर करता है। यह वास्तविक ऑनलाइन ट्रैफ़िक को मिररिंग सेवा में डुप्लिकेट करता है और ऑनलाइन सेवा को बाधित किए बिना ऑनलाइन ट्रैफ़िक या अनुरोध सामग्री का विशिष्ट विश्लेषण सक्षम करता है।
ब्लू-ग्रीन
ब्लू-ग्रीन आमतौर पर आर्किटेक्चर में एक बिंदु पर लागू किया जाता है जो एक राउटर, गेटवे, या लोड बैलेंसर का उपयोग करता है, जिसके पीछे एक पूर्ण ब्लू वातावरण और एक ग्रीन वातावरण होता है। वर्तमान ब्लू वातावरण वर्तमान लाइव वातावरण का प्रतिनिधित्व करता है, और ग्रीन वातावरण स्टैक के अगले संस्करण का प्रतिनिधित्व करता है। लाइव ट्रैफ़िक पर स्विच करने से पहले ग्रीन वातावरण की जांच की जाती है, और गो लाइव पर ट्रैफ़िक ब्लू से ग्रीन की ओर फ्लिप हो जाती है। ब्लू वातावरण अब "ऑफ" होता है लेकिन यदि कोई समस्या देखी जाती है तो यह एक त्वरित रोलबैक होता है। अगला परिवर्तन ग्रीन से ब्लू की ओर होगा, पहली रिलीज़ से आगे ऑसिलेट करते हुए।
ब्लू-ग्रीन अपनी सरलता के कारण अच्छी तरह से काम करता है और यह युग्मित सेवाओं के लिए बेहतर डिप्लॉयमेंट विकल्पों में से एक है। यह पर्सिस्टिंग सेवाओं को प्रबंधित करने में भी आसान है, हालांकि रोलबैक की स्थिति में आपको अभी भी सावधान रहने की आवश्यकता है। इसमें वर्तमान सक्रिय वातावरण के समानांतर ठंडा चलाने के लिए संसाधनों की दोगुनी संख्या की आवश्यकता होती है।
Argo Rollouts के साथ ट्रैफ़िक प्रबंधन
चर्चा की गई रणनीतियाँ बहुत अधिक मूल्य जोड़ती हैं, लेकिन रोलआउट स्वयं एक कार्य है जिसे आप मैन्युअल रूप से प्रबंधित करना नहीं चाहेंगे। यह वह जगह है जहाँ Argo Rollouts जैसा टूल चर्चा की गई कुछ चिंताओं को व्यावहारिक रूप से प्रदर्शित करने के लिए मूल्यवान है।
Argo का उपयोग करके, एक रोलआउट CRD (कस्टम रिसोर्स डेफिनिशन) को परिभाषित करना संभव है जो आपके API के नए कैनरी को रोल आउट करने के लिए आपकी रणनीति का प्रतिनिधित्व करता है। एक CRD Argo को Kubernetes API को रोलआउट व्यवहार का समर्थन करने के लिए विस्तारित करने की अनुमति देता है। CRDs Kubernetes के साथ एक लोकप्रिय पैटर्न हैं, और वे उपयोगकर्ता को विभिन्न सुविधाओं का समर्थन करने के लिए एक API के साथ इंटरैक्ट करने की अनुमति देते हैं।
आप Argo Rollouts के साथ ट्रैफ़िक प्रबंधन के लिए Apache APISIX और Apache APISIX Ingress Controller का उपयोग कर सकते हैं। यह गाइड आपको दिखाती है कि ApisixRoute को Argo Rollouts के साथ एक वेटेड राउंड-रॉबिन लोड बैलेंसर के रूप में उपयोग करके कैसे एकीकृत किया जाए।
सारांश
प्रोग्रेसिव डिलीवरी दृष्टिकोण के उदय के साथ, और इससे पहले निरंतर वितरण के भीतर उन्नत आवश्यकताओं के साथ, सेवा (और संबंधित API) के डिप्लॉयमेंट और रिलीज़ को अलग करने की क्षमता एक शक्तिशाली तकनीक है। कैनरी रिलीज़ सेवाओं की क्षमता और API गेटवे ट्रैफ़िक स्प्लिट और मिररिंग सुविधाओं का उपयोग करके आपके व्यवसाय को एक प्रतिस्पर्धात्मक लाभ प्रदान कर सकता है, जो एक खराब रिलीज़ के जोखिम को कम करने और आपके ग्राहक की आवश्यकताओं को अधिक प्रभावी ढंग से समझने में मदद करता है।