मार्गदर्शिका

कस्टम डोमेन/SSL, ऑटोकैल और डिप्लॉयमेंट स्लॉट वाली एक प्रोडक्शन वेब ऐप के लिए एक App Service प्लान की आवश्यकता है।

→Standard (S1) App Service प्लान टियर या उससे ऊपर का उपयोग करें।

क्यों: Standard सभी प्रमुख प्रोडक्शन सुविधाओं का समर्थन करने वाला न्यूनतम टियर है: SSL के साथ कस्टम डोमेन, ऑटोकैल और डिप्लॉयमेंट स्लॉट। Basic टियर में ऑटोकैल और स्लॉट की कमी है।

संदर्भ↗

App Service के लिए जीरो-डाउनटाइम डिप्लॉयमेंट करें और प्रोडक्शन सेटिंग्स (जैसे कनेक्शन स्ट्रिंग) को प्रोडक्शन स्लॉट में रखें।

→डिप्लॉयमेंट स्लॉट का उपयोग करें। प्रोडक्शन-विशिष्ट सेटिंग्स को "deployment slot settings" (sticky) के रूप में चिह्नित करें। डिप्लॉय करने के लिए स्वैप ऑपरेशन करें।

क्यों: स्वैप ऑपरेशन ट्रैफ़िक को रीडायरेक्ट करने से पहले स्टेजिंग स्लॉट को वार्म अप करता है। Sticky सेटिंग्स स्वैप के दौरान कोड के साथ नहीं जाती हैं, जिससे स्टेजिंग सेटिंग्स को लाइव होने से रोका जा सकता है।

संदर्भ↗

एक App Service को VPN या ExpressRoute के बिना ऑन-प्रेमिसेस रिसोर्स (जैसे SQL Server) से कनेक्ट करने की आवश्यकता है।

→App Service Hybrid Connections का उपयोग करें। ऑन-प्रेमिसेस पर Hybrid Connection Manager (HCM) इंस्टॉल करें।

क्यों: Hybrid Connections, इनबाउंड फ़ायरवॉल पोर्ट, VPN, या VNet इंटीग्रेशन की आवश्यकता के बिना ऑन-प्रेमिसेस रिसोर्स को एक सुरक्षित TCP टनल प्रदान करते हैं। HCM आउटबाउंड कनेक्शन शुरू करता है।

Consumption प्लान पर एक Azure Function लंबे कोल्ड स्टार्ट का अनुभव करता है, जिससे लेटेंसी होती है।

→Functions Premium प्लान पर माइग्रेट करें और कम से कम एक प्री-वार्मड इंस्टेंस कॉन्फ़िगर करें।

क्यों: Premium प्लान, निर्दिष्ट संख्या में इंस्टेंस को हमेशा तैयार रखकर कोल्ड स्टार्ट को समाप्त करता है। इस उद्देश्य के लिए यह पूर्ण Dedicated प्लान की तुलना में अधिक लागत प्रभावी है।

संदर्भ↗

Consumption प्लान पर एक Azure Function टाइम आउट हो रहा है क्योंकि इसे निष्पादित होने में 10 मिनट से अधिक समय लगता है।

→फंक्शन को Premium या Dedicated (App Service) प्लान पर माइग्रेट करें।

क्यों: Consumption प्लान में अधिकतम 10 मिनट का टाइमआउट होता है। Premium और Dedicated प्लान बहुत लंबे निष्पादन समय (60 मिनट या असीमित तक) का समर्थन करते हैं।

बड़ी संख्या में स्वतंत्र आइटमों को समानांतर में प्रोसेस करें और आगे बढ़ने से पहले सभी के पूरा होने का इंतजार करें।

→Durable Functions Fan-out/Fan-in पैटर्न लागू करें। ऑर्केस्ट्रेटर एक साथ कई गतिविधि फ़ंक्शंस को कॉल करता है और पूरा होने की प्रतीक्षा करने के लिए `Task.WhenAll` (या समकक्ष) का उपयोग करता है।

क्यों: यह पैटर्न समानांतर निष्पादन के लिए डिज़ाइन किया गया है, जो स्वतंत्र कार्यों के लिए अनुक्रमिक प्रोसेसिंग (Function Chaining) की तुलना में कहीं अधिक कुशल है।

संदर्भ↗

एक लंबी चलने वाली वर्कफ़्लो को टाइमआउट के साथ बाहरी घटना, जैसे मानवीय अनुमोदन, की प्रतीक्षा करनी चाहिए।

→Durable Functions Human Interaction पैटर्न का उपयोग करें। `waitForExternalEvent` को `createTimer` के साथ संयोजित करें। इवेंट आने या टाइमर समाप्त होने पर आगे बढ़ने के लिए `Task.WhenAny` का उपयोग करें।

क्यों: यह पैटर्न ऑर्केस्ट्रेशन को कंप्यूट का उपभोग किए बिना अनिश्चित काल तक रुकने की अनुमति देता है, एक बाहरी ट्रिगर की प्रतीक्षा करता है, जबकि टाइमआउट को भी ठीक से संभालता है।

लागत कम करने के लिए, ट्रैफ़िक न होने पर एक कंटेनरीकृत एप्लिकेशन को शून्य इंस्टेंस तक स्केल करने की आवश्यकता होती है।

→KEDA-आधारित स्केलिंग नियम (जैसे, HTTP अनुरोध या क्यू लंबाई) के साथ Azure Container Apps का उपयोग करें।

क्यों: KEDA स्केलर्स के साथ Container Apps निष्क्रिय होने पर शून्य रेप्लिका तक स्केल डाउन कर सकते हैं और मांग पर स्केल अप कर सकते हैं, जो इवेंट-ड्रिवेन या इंटरमिटेंट वर्कलोड के लिए आदर्श है। CPU/मेमोरी स्केलिंग शून्य तक स्केल नहीं कर सकती है।

Azure Container Apps में एक बैकएंड माइक्रोसर्विस केवल उसी एनवायरनमेंट के भीतर अन्य कंटेनर ऐप्स द्वारा एक्सेस करने योग्य होना चाहिए, सार्वजनिक इंटरनेट से नहीं।

→बैकएंड कंटेनर ऐप पर ingress सक्षम करें और ट्रैफ़िक दृश्यता को `internal` पर सेट करें।

क्यों: Internal ingress Container Apps एनवायरनमेंट तक पहुंच को प्रतिबंधित करता है। एनवायरनमेंट में अन्य ऐप इसकी इंटरनल FQDN का उपयोग करके सेवा को खोज और कॉल कर सकते हैं।

ऑर्केस्ट्रेशन के बिना एक साधारण कार्य, एक टेस्ट, या एक बैच जॉब के लिए एक सिंगल कंटेनर चलाने की आवश्यकता है।

→Azure Container Instances (ACI) का उपयोग करें।

क्यों: ACI किसी भी अंतर्निहित इन्फ्रास्ट्रक्चर को प्रबंधित किए बिना एक सिंगल कंटेनर चलाने का सबसे तेज़ और सरल तरीका है। मल्टी-कंटेनर एप्लिकेशन को ऑर्केस्ट्रेट करने के लिए Container Apps या AKS का उपयोग करें।

स्थानीय Dockerfile से Azure Container Registry (ACR) में एक Docker इमेज बनाने और पुश करने की आवश्यकता है, लेकिन Docker स्थानीय रूप से इंस्टॉल नहीं है।

→`az acr build` कमांड का उपयोग करें।

क्यों: `az acr build` बिल्ड प्रक्रिया को क्लाउड में ACR Tasks पर ऑफ़लोड करता है। यह बिल्ड संदर्भ को Azure पर भेजता है, इमेज बनाता है, और इसे सीधे रजिस्ट्री में संग्रहीत करता है।

एक Cosmos DB कंटेनर को डिज़ाइन करना जिसमें एक विशिष्ट प्रॉपर्टी (जैसे, `region`) पर लगातार फ़िल्टरिंग करने वाली क्वेरीज़ होती हैं।

→सबसे अधिक क्वेरी की गई, हाई-कार्डिनैलिटी प्रॉपर्टी को पार्टीशन की (जैसे, `/region`) के रूप में चुनें।

क्यों: वे क्वेरीज़ जिनमें `WHERE` क्लॉज़ में पार्टीशन की शामिल होती है, एक सिंगल लॉजिकल पार्टीशन को लक्षित करती हैं, जिससे महंगे क्रॉस-पार्टीशन फैन-आउट क्वेरीज़ से बचा जा सकता है और RU खपत को कम किया जा सकता है।

संदर्भ↗

एक विश्व स्तर पर वितरित एप्लिकेशन को यह आवश्यक है कि रीड्स हमेशा सबसे हाल ही में कमिटेड राइट को वापस करें।

→Cosmos DB अकाउंट कंसिस्टेंसी लेवल को Strong पर कॉन्फ़िगर करें।

क्यों: Strong consistency एक लिनियराइजेबिलिटी गारंटी प्रदान करती है, यह सुनिश्चित करती है कि रीड्स हमेशा अप-टू-डेट हों। अन्य स्तर (Session, Bounded Staleness, Eventual) कम लेटेंसी और उच्च उपलब्धता के लिए कंसिस्टेंसी का व्यापार करते हैं।

मटेरियलाइज्ड व्यू को अपडेट करने के लिए एक Cosmos DB कंटेनर में सभी नए या अपडेट किए गए डॉक्यूमेंट्स को वास्तविक समय में प्रोसेस करने की आवश्यकता है।

→Cosmos DB ट्रिगर के साथ एक Azure Function का उपयोग करें, जो चेंज फीड प्रोसेसर का लाभ उठाता है।

क्यों: चेंज फीड परिवर्तनों का एक स्थायी लॉग प्रदान करता है। चेंज फीड प्रोसेसर के साथ Cosmos DB ट्रिगर कई फ़ंक्शन इंस्टेंस में स्टेट मैनेजमेंट और लोड संतुलन को स्वचालित करता है।

एक ही लॉजिकल पार्टीशन के भीतर कई डॉक्यूमेंट्स पर एक एटॉमिक ऑपरेशन करने की आवश्यकता है (जैसे, दो बनाएं और एक अपडेट करें)।

→Cosmos DB SDK में `TransactionalBatch` API का उपयोग करें। सभी ऑपरेशंस को एक ही पार्टीशन की को लक्षित करना चाहिए।

क्यों: TransactionalBatch यह सुनिश्चित करता है कि बैच में सभी ऑपरेशंस एक सिंगल एटॉमिक यूनिट के रूप में सफल हों या विफल हों, जिससे आंशिक अपडेट्स को रोका जा सके। यह क्लाइंट-साइड बैच ऑपरेशंस के लिए एक स्टोर्ड प्रोसीजर की तुलना में अधिक कुशल है।

एक Cosmos DB वर्कलोड अप्रत्याशित है, जिसमें ट्रैफ़िक में महत्वपूर्ण चोटियाँ और गर्तियाँ हैं।

→डेटाबेस या कंटेनर पर autoscale प्रोविजन्ड थ्रूपुट कॉन्फ़िगर करें।

क्यों: Autoscale उपयोग के आधार पर RU/s को स्वचालित रूप से स्केल करता है, जिससे पीक के दौरान प्रदर्शन और गर्तियों के दौरान लागत बचत सुनिश्चित होती है। यह अधिकतम कॉन्फ़िगर किए गए RU/s के 10% और 100% के बीच स्केल करता है।

डेटा को पहले अक्सर एक्सेस किया जाता है, फिर कभी-कभी, और अंत में लंबी अवधि के प्रतिधारण के लिए संग्रहीत किया जाता है।

→Hot, Cool, और Archive एक्सेस टियर का संयोजन उपयोग करें। एक Lifecycle Management नीति के साथ परिवर्तनों को स्वचालित करें।

क्यों: एक्सेस पैटर्न के साथ एक्सेस टियर को संरेखित करने से लागत अनुकूलित होती है। Hot लगातार एक्सेस के लिए है, Cool कभी-कभी एक्सेस के लिए, और Archive लंबी अवधि, कम लागत वाले स्टोरेज के लिए है। Lifecycle नीतियां इसे स्वचालित करती हैं।

संदर्भ↗

एक ही blob को एक साथ कई प्रक्रियाओं द्वारा संशोधित होने से रोकें।

→blob लीज लागू करें। एक प्रक्रिया किसी blob को संशोधित करने से पहले उस पर एक एक्सक्लूसिव-राइट लॉक (लीज) प्राप्त करती है।

क्यों: लीज निराशावादी समवर्ती नियंत्रण प्रदान करते हैं। एक बार लीज प्राप्त हो जाने के बाद, कोई अन्य क्लाइंट तब तक blob पर नहीं लिख सकता जब तक लीज जारी नहीं हो जाती या समाप्त नहीं हो जाती।

Blob Storage में ऑडिट लॉग संग्रहीत करें और सुनिश्चित करें कि उन्हें एक निश्चित प्रतिधारण अवधि (जैसे, 7 वर्ष) के लिए संशोधित या हटाया नहीं जा सकता है।

→blob कंटेनर पर एक समय-आधारित प्रतिधारण नीति कॉन्फ़िगर करें। अनिश्चितकालीन होल्ड के लिए, एक लीगल होल्ड का उपयोग करें।

क्यों: अपरिवर्तनीय स्टोरेज नीतियां WORM (Write-Once, Read-Many) स्थिति को लागू करती हैं, जो अनुपालन के लिए आवश्यक है। एक बार लॉक होने के बाद, समय-आधारित नीति को छोटा नहीं किया जा सकता है।

key-value एट्रिब्यूट्स के साथ blobs को वर्गीकृत करने और सभी blobs को सूचीबद्ध किए बिना पूरे स्टोरेज अकाउंट में उन्हें क्वेरी करने की आवश्यकता है।

→Blob Index Tags का उपयोग करें।

क्यों: Index tags स्टोरेज सेवा द्वारा इंडेक्स किए जाते हैं और सर्वर-साइड फ़िल्टरिंग क्वेरीज़ (`Find Blobs by Tags`) में उपयोग किए जा सकते हैं। मेटाडेटा इंडेक्स नहीं किया जाता है और इसे सूचीबद्ध करने के बाद केवल क्लाइंट-साइड पर फ़िल्टर किया जा सकता है।

एक Single-Page Application (SPA) में उपयोगकर्ताओं को सुरक्षित रूप से प्रमाणित करें और एक बैकएंड API के लिए टोकन प्राप्त करें।

→PKCE (Proof Key for Code Exchange) के साथ Authorization Code फ्लो का उपयोग करें।

क्यों: यह पब्लिक क्लाइंट्स के लिए वर्तमान सुरक्षा सर्वोत्तम अभ्यास है। यह URL में टोकन को उजागर करने से बचाता है (अप्रचलित Implicit फ्लो के विपरीत) और क्लाइंट सीक्रेट की आवश्यकता नहीं होती है।

संदर्भ↗

एक बैकग्राउंड सेवा या डीमॉन को साइन-इन किए गए उपयोगकर्ता के बिना एक प्रोटेक्टेड API (जैसे Microsoft Graph) को कॉल करने की आवश्यकता है।

→Application permissions के साथ Client Credentials फ्लो का उपयोग करें।

क्यों: यह फ्लो क्लाइंट सीक्रेट या सर्टिफिकेट का उपयोग करके एप्लिकेशन को प्रमाणित करता है। Application permissions, व्यवस्थापक सहमति के अधीन, पूरे संगठन में एक्सेस प्रदान करती हैं।

एक मिडिल-टियर वेब API को मूल साइन-इन किए गए उपयोगकर्ता की पहचान को बनाए रखते हुए एक डाउनस्ट्रीम API को कॉल करने की आवश्यकता है।

→On-Behalf-Of (OBO) फ्लो लागू करें।

क्यों: मिडिल-टियर API उपयोगकर्ता के एक्सेस टोकन को डाउनस्ट्रीम API के लिए स्कोप किए गए एक नए टोकन के लिए एक्सचेंज करता है। यह उपयोगकर्ता की पहचान को सुरक्षित रूप से डेलिगेट करता है।

MSAL का उपयोग करने वाले एप्लिकेशन को कुशलतापूर्वक टोकन प्राप्त करने की आवश्यकता है, उपयोगकर्ता प्रॉम्प्ट को कम करते हुए।

→हमेशा पहले `AcquireTokenSilent()` को कॉल करें। यदि यह `MsalUiRequiredException` के साथ विफल रहता है, तो `AcquireTokenInteractive()` जैसे इंटरेक्टिव मेथड पर वापस जाएं।

क्यों: `AcquireTokenSilent()` कैश में एक वैध टोकन की जांच करता है या उपयोगकर्ता इंटरैक्शन के बिना एक नया टोकन प्राप्त करने के लिए रिफ्रेश टोकन का उपयोग करता है। यह अच्छे उपयोगकर्ता अनुभव के लिए महत्वपूर्ण है।

एक Azure रिसोर्स (जैसे, App Service, Function) को कोड या कॉन्फ़िग में क्रेडेंशियल संग्रहीत किए बिना दूसरे Azure रिसोर्स (जैसे, Key Vault, SQL Database) तक पहुंचने की आवश्यकता है।

→सोर्स रिसोर्स पर एक मैनेज्ड आइडेंटिटी (सिस्टम-असाइन या यूजर-असाइन) सक्षम करें और उसे टारगेट रिसोर्स पर RBAC परमिशन दें।

क्यों: मैनेज्ड आइडेंटिटी रिसोर्स के लिए Microsoft Entra ID में एक पहचान प्रदान करती है। Azure क्रेडेंशियल लाइफसाइकिल को प्रबंधित करता है, जिससे डेवलपर्स को सीक्रेट्स को संभालने की आवश्यकता समाप्त हो जाती है।

संदर्भ↗

कई Azure रिसोर्स को अन्य सेवाओं तक पहुंचने के लिए एक ही पहचान और परमिशन साझा करने की आवश्यकता है।

→एक सिंगल यूजर-असाइन मैनेज्ड आइडेंटिटी बनाएं और इसे सभी आवश्यक रिसोर्स को असाइन करें।

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

व्यक्तिगत सीक्रेट स्तर पर फाइन-ग्रेन्ड परमिशन वाले Azure AD समूहों का उपयोग करके Key Vault सीक्रेट्स तक पहुंच प्रदान करने की आवश्यकता है।

→Key Vault के लिए Azure RBAC परमिशन मॉडल का उपयोग करें। `Key Vault Secrets User` जैसी भूमिकाएँ प्रिंसिपल्स को असाइन करें।

क्यों: RBAC वॉल्ट, या व्यक्तिगत की/सीक्रेट/सर्टिफिकेट स्कोप पर भूमिका असाइनमेंट की अनुमति देता है, जो एक्सेस नीतियों की तुलना में अधिक ग्रैन्युलैरिटी प्रदान करता है, जो वॉल्ट में एक प्रकार की सभी वस्तुओं पर लागू होती हैं।

एक एप्लिकेशन को पुनरारंभ किए बिना Azure App Configuration से कॉन्फ़िगरेशन परिवर्तन लेने की आवश्यकता है।

→App Configuration प्रोवाइडर/SDK का उपयोग करें और इसे एक sentinel की की निगरानी करके रीफ्रेश करने के लिए कॉन्फ़िगर करें।

क्यों: SDK परिवर्तनों के लिए समय-समय पर एक sentinel की की जांच कर सकता है। जब आप एप्लिकेशन सेटिंग्स को अपडेट करते हैं, तो आप sentinel की को भी अपडेट करते हैं, जो सभी क्लाइंट्स को उनके कॉन्फ़िगरेशन को रीफ्रेश करने के लिए ट्रिगर करता है।

उपयोगकर्ताओं के एक विशिष्ट समूह (जैसे, बीटा टेस्टर) और सामान्य दर्शकों के एक प्रतिशत के लिए एक नई सुविधा को सक्षम करने की आवश्यकता है।

→Targeting फ़िल्टर के साथ एक Azure App Configuration फ़ीचर फ़्लैग का उपयोग करें।

क्यों: Targeting फ़िल्टर जटिल रोलआउट का समर्थन करता है, जिससे आप विशिष्ट प्रतिशत वाले उपयोगकर्ताओं और समूहों के आधार पर दर्शकों को परिभाषित कर सकते हैं, साथ ही अन्य सभी के लिए एक डिफ़ॉल्ट रोलआउट प्रतिशत भी।

एक क्लाइंट को एक विशिष्ट blob तक पहुंच प्रदान करने के लिए एक सुरक्षित, अल्पकालिक टोकन उत्पन्न करने की आवश्यकता है।

→एक user delegation SAS बनाएं।

क्यों: एक user delegation SAS Microsoft Entra ID क्रेडेंशियल के साथ हस्ताक्षरित होता है, न कि स्टोरेज अकाउंट की के साथ। यह अधिक सुरक्षित है क्योंकि यह अकाउंट की को वितरित करने से बचाता है और Entra ID नीतियों के माध्यम से एक्सेस को रद्द किया जा सकता है।

निर्भरताओं को विज़ुअलाइज़ करके और यह पहचान कर कि कौन सी डाउनस्ट्रीम सेवा उच्च लेटेंसी का कारण बन रही है, एक माइक्रोसेवा एप्लिकेशन में प्रदर्शन समस्या का निवारण करें।

→Application Insights में Application Map सुविधा का उपयोग करें।

क्यों: Application Map आपके वितरित एप्लिकेशन का एक टोपोलॉजिकल दृश्य स्वतः-खोज और प्रदर्शित करता है, जिसमें प्रत्येक घटक के लिए स्वास्थ्य और प्रदर्शन मेट्रिक्स और उनके बीच के कॉल दिखाए जाते हैं।

संदर्भ↗

एक सिंगल उपयोगकर्ता अनुरोध को ट्रेस करें क्योंकि यह कई माइक्रोसेवाओं में प्रवाहित होता है।

→Application Insights में End-to-End ट्रांजेक्शन विवरण दृश्य का उपयोग करें। सभी टेलीमेट्री एक साझा `operation_Id` द्वारा सहसंबद्ध होती है।

क्यों: Application Insights SDKs स्वचालित रूप से W3C Trace Context हेडर को प्रसारित करते हैं, जिससे एक सिंगल ऑपरेशन के लिए सभी टेलीमेट्री को उसी `operation_Id` के साथ सहसंबद्ध किया जा सकता है, जिससे एक एकीकृत दृश्य सक्षम होता है।

एक उत्पादन समस्या का निदान करें: रुक-रुक कर धीमी गति से प्रदर्शन बनाम रुक-रुक कर होने वाली अपवाद।

→धीमे प्रदर्शन के लिए, Application Insights Profiler का उपयोग करें। अपवादों के लिए, Snapshot Debugger का उपयोग करें।

क्यों: Profiler धीमी अनुरोधों ("hot paths") के लिए मेथड-लेवल टाइमिंग ट्रेस कैप्चर करता है। Snapshot Debugger उस क्षण कॉल स्टैक और लोकल वेरिएबल्स को कैप्चर करता है जब एक अपवाद फेंका जाता है।

सांख्यिकीय रूप से वैध डेटा बनाए रखते हुए उच्च-ट्रैफिक एप्लिकेशन से Application Insights डेटा वॉल्यूम और लागत को कम करें।

→एप्लिकेशन के SDK कॉन्फ़िगरेशन में adaptive sampling सक्षम करें।

क्यों: Adaptive sampling स्वचालित रूप से नमूना दर को समायोजित करता है ताकि एक लक्ष्य डेटा वॉल्यूम के भीतर रह सके, उच्च ट्रैफ़िक के दौरान अधिक आक्रामक रूप से नमूनाकरण करता है और कम ट्रैफ़िक के दौरान कम, महत्वपूर्ण टेलीमेट्री को संरक्षित करता है।

कई भौगोलिक स्थानों से एक वेब एप्लिकेशन एंडपॉइंट की उपलब्धता की लगातार निगरानी करें।

→Application Insights में एक मानक उपलब्धता टेस्ट (URL पिंग टेस्ट) कॉन्फ़िगर करें।

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

एक अलर्ट बनाएं जो तब ट्रिगर होता है जब एक प्रदर्शन मेट्रिक (जैसे, औसत प्रतिक्रिया समय) एक परिभाषित अवधि के लिए एक विशिष्ट सीमा से अधिक हो जाती है।

→एक Azure Monitor मेट्रिक अलर्ट नियम बनाएं। रिसोर्स और मेट्रिक को लक्षित करें, एक स्टैटिक थ्रेशोल्ड, एग्रीगेशन टाइप और मूल्यांकन अवधि कॉन्फ़िगर करें। एक एक्शन ग्रुप से लिंक करें।

क्यों: मेट्रिक अलर्ट नियर-रियल-टाइम मेट्रिक डेटा की कम-लेटेंसी, स्टेटफुल निगरानी प्रदान करते हैं, जो प्रदर्शन-आधारित अलर्टिंग के लिए आदर्श है।

कॉल आवृत्ति (जैसे, 100 कॉल/मिनट) बनाम लंबी अवधि (जैसे, 10,000 कॉल/माह) में कुल कॉल को सीमित करके API उपयोग को नियंत्रित करें।

→कॉल आवृत्ति के लिए `rate-limit` नीति का उपयोग करें। कुल कॉल वॉल्यूम के लिए `quota` नीति का उपयोग करें।

क्यों: `rate-limit` अल्पकालिक बर्स्ट को थ्रॉटल करता है और HTTP 429 लौटाता है। `quota` लंबी अवधि (जैसे, एक बिलिंग अवधि) में उपयोग की सीमा लागू करता है और HTTP 403 लौटाता है जब यह अधिक हो जाता है।

संदर्भ↗

बैकएंड लोड को कम करने के लिए API Management में API प्रतिक्रियाओं को कैश करें, जिसमें कैश की अनुरोध हेडर द्वारा भिन्न होती है।

→इनबाउंड सेक्शन में `<cache-lookup vary-by-header="..." />` नीति और आउटबाउंड सेक्शन में `<cache-store duration="..." />` नीति का उपयोग करें।

क्यों: यह दो-भाग वाली नीति संयोजन प्रतिक्रिया कैशिंग को सक्षम बनाता है। `cache-lookup` एक कैश किए गए आइटम की जांच करता है, और `cache-store` प्रतिक्रिया को सहेजता है। `vary-by` एट्रिब्यूट्स विभिन्न अनुरोध भिन्नताओं के लिए अद्वितीय कैश प्रविष्टियां सुनिश्चित करते हैं।

एक API में परिवर्तनों को प्रबंधित करें। एक ब्रेकिंग चेंज आवश्यक है बनाम एक गैर-ब्रेकिंग चेंज का परीक्षण करने की आवश्यकता है।

→ब्रेकिंग चेंज (जैसे, /v1, /v2) के लिए Versions का उपयोग करें। गैर-ब्रेकिंग चेंज और सुरक्षित, स्टेज्ड रोलआउट के लिए Revisions का उपयोग करें।

क्यों: वर्जनिंग कई API वर्जन को एक साथ लाइव रहने की अनुमति देती है। Revisions आपको एक API को ऑफ़लाइन संशोधित करने, उसका परीक्षण करने, और फिर बिना डाउनटाइम के इसे "वर्तमान" रिविजन बनाने की अनुमति देते हैं।

जब एक Azure सेवा में कोई इवेंट होता है (जैसे, blob बनाया गया, रिसोर्स ग्रुप बनाया गया), तो कई, स्वतंत्र डाउनस्ट्रीम सेवाओं को सूचित करें।

→Azure Event Grid का उपयोग करें। Azure रिसोर्स के लिए एक सिस्टम टॉपिक और प्रत्येक डाउनस्ट्रीम हैंडलर के लिए इवेंट सब्सक्रिप्शन बनाएं।

क्यों: Event Grid एक पूरी तरह से प्रबंधित, पुश-आधारित पब/सब सेवा है जो इवेंट पब्लिशर्स को सब्सक्राइबर्स से अलग करती है, जिससे रिएक्टिव, इवेंट-ड्रिवेन आर्किटेक्चर सक्षम होते हैं।

संदर्भ↗

कई डिवाइस से टेलीमेट्री या इवेंट डेटा (प्रति सेकंड लाखों इवेंट) की उच्च-मात्रा वाली स्ट्रीम को इन्जेस्ट करें।

→Azure Event Hubs का उपयोग करें।

क्यों: Event Hubs एक बड़े पैमाने पर स्केलेबल डेटा स्ट्रीमिंग प्लेटफॉर्म है जिसे उच्च-थ्रूपुट इन्जेस्टियन के लिए डिज़ाइन किया गया है। यह समानांतर प्रोसेसिंग के लिए एक पार्टीशन किए गए कंज्यूमर मॉडल का उपयोग करता है।

सुनिश्चित करें कि एक ही स्रोत (जैसे, एक विशिष्ट IoT डिवाइस) से इवेंट एक ही कंज्यूमर द्वारा क्रम में संसाधित किए जाते हैं।

→स्रोत पहचानकर्ता (जैसे, डिवाइस ID) पर सेट पार्टीशन की के साथ Event Hubs पर इवेंट भेजें।

क्यों: Event Hubs एक ही पार्टीशन की वाले सभी संदेशों को एक ही पार्टीशन में रूट करता है। एक पार्टीशन के भीतर, संदेश क्रम बनाए रखा जाता है।

संबंधित संदेशों के अनुक्रम को सख्त First-In, First-Out (FIFO) क्रम में प्रोसेस करें।

→Azure Service Bus सत्रों का उपयोग करें। सभी संबंधित संदेशों को समान `SessionId` के साथ भेजें।

क्यों: सत्र संदेशों का एक समवर्ती, क्रमबद्ध स्ट्रीम प्रदान करते हैं। एक सत्र-जागरूक रिसीवर सत्र को लॉक करता है, यह गारंटी देता है कि संदेश एक ही उपभोक्ता द्वारा क्रमिक रूप से संसाधित किए जाते हैं।

एक सिंगल प्रकाशक एक टॉपिक पर संदेश भेजता है, लेकिन कई सब्सक्राइबर केवल उन संदेशों का एक सबसेट चाहते हैं जो संदेश गुणों पर आधारित होते हैं।

→कई सब्सक्रिप्शन के साथ एक Service Bus टॉपिक का उपयोग करें। प्रत्येक सब्सक्रिप्शन पर SQL फ़िल्टर या Correlation फ़िल्टर लागू करें।

क्यों: यह कंटेंट-आधारित रूटिंग के साथ कैनोनिकल पब्लिश-सब्सक्राइब पैटर्न है। प्रत्येक सब्सक्रिप्शन को संदेश की एक कॉपी प्राप्त होती है यदि वह उसके फ़िल्टर नियम से मेल खाती है।

एक संदेश कई पुनः प्रयासों के बाद सफलतापूर्वक संसाधित नहीं किया जा सकता है और इसे बाद के निरीक्षण के लिए अलग रखा जाना चाहिए।

→संदेश को तब तक प्रोसेसिंग में विफल होने दें जब तक उसकी अधिकतम डिलीवरी गणना पार न हो जाए। इसे स्वचालित रूप से Dead-Letter Queue (DLQ) में ले जाया जाएगा।

क्यों: DLQ जहर संदेशों के लिए एक अंतर्निहित सब-क्यू है। यह विफल संदेश को मुख्य क्यू को ब्लॉक करने से रोकता है और ऑफ़लाइन विश्लेषण और पुनर्संसाधन की अनुमति देता है।

इसके लिए एक मैसेजिंग सेवा चुनें: एंटरप्राइज़ कमांड, रिएक्टिव इवेंट, या उच्च-वॉल्यूम टेलीमेट्री।

→कमांड के लिए Service Bus (ऑर्डर, ट्रांजेक्शन)। रिएक्टिव इवेंट्स के लिए Event Grid (blob बनाया गया, रिसोर्स बदला गया)। टेलीमेट्री के लिए Event Hubs (IoT डेटा, क्लिकस्ट्रीम)।

क्यों: Service Bus ऑर्डरिंग, ट्रांजेक्शन और डेड-लेटरिंग जैसी समृद्ध सुविधाएँ प्रदान करता है। Event Grid हल्के, पुश-आधारित इवेंट रूटिंग के लिए है। Event Hubs उच्च-थ्रूपुट डेटा स्ट्रीमिंग के लिए है।