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

माइक्रोसेवाओं को सिंक्रोनस रिक्वेस्ट/रिस्पांस और एसिंक्रोनस इवेंट-ड्रिवन कम्युनिकेशन दोनों की आवश्यकता होती है।

→सिंक्रोनस कॉल्स के लिए gRPC या HTTP का उपयोग करें। एसिंक्रोनस इवेंटिंग और फैन-आउट के लिए Pub/Sub का उपयोग करें।

क्यों: Pub/Sub विश्वसनीयता और स्वतंत्र स्केलिंग के लिए सेवाओं को पूरी तरह से डीकपल करता है। डायरेक्ट कॉल कम-विलंबता वाले सिंक्रोनस रिस्पांस प्रदान करते हैं।

संदर्भ↗

एक स्टेटलेस कंप्यूट सेवा (Cloud Run, Cloud Functions) को अस्थायी फ़ाइलों को प्रोसेस करने की आवश्यकता है।

→सभी अस्थायी फ़ाइल I/O के लिए Cloud Storage का उपयोग करें।

क्यों: सर्वरलेस प्लेटफ़ॉर्म का लोकल फ़ाइलसिस्टम क्षणभंगुर, इन-मेमोरी होता है और साझा नहीं होता है। Cloud Storage सभी इंस्टेंस द्वारा एक्सेस किया जा सकने वाला टिकाऊ, स्केलेबल स्टोरेज प्रदान करता है।

12-फैक्टर सिद्धांतों का पालन करते हुए GKE वर्कलोड के लिए वातावरण-विशिष्ट कॉन्फ़िगरेशन और सीक्रेट्स का प्रबंधन करें।

→गैर-संवेदनशील कॉन्फ़िग के लिए K8s ConfigMaps का उपयोग करें। संवेदनशील मानों के लिए Secret Manager का उपयोग करें, जिन्हें Workload Identity के माध्यम से सुरक्षित रूप से एक्सेस किया जाता है।

क्यों: Secret Manager, K8s Secrets की तुलना में अधिक सुरक्षित, प्रबंधित और ऑडिट योग्य समाधान है। Workload Identity सेवा खाते की कुंजियों को प्रबंधित और वितरित करने से बचाता है।

संदर्भ↗

एप्लिकेशन में अत्यधिक ट्रैफ़िक पीक होते हैं, लेकिन लंबे निष्क्रिय समय भी होते हैं जहाँ लागत को कम किया जाना चाहिए।

→`min-instances` को 0 पर सेट करके Cloud Run का उपयोग करें।

क्यों: Cloud Run शून्य तक स्केल डाउन हो सकता है, जिससे निष्क्रिय अवधि के दौरान सभी कंप्यूट लागत समाप्त हो जाती हैं। GKE और Compute Engine को न्यूनतम चलने वाले नोड्स/इंस्टेंसेस की आवश्यकता होती है।

एप्लिकेशन कोड में बदलाव किए बिना माइक्रोसेवाओं में रिट्राई, सर्किट ब्रेकर और mTLS को लगातार लागू करें।

→GKE पर एक सर्विस मेश (Anthos Service Mesh) डिप्लॉय करें।

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

रेट लिमिटिंग, API कुंजियों और उपयोग एनालिटिक्स के साथ बैकएंड सेवाओं को बाहरी भागीदारों या मोबाइल ऐप्स के सामने उजागर करें।

→बैकएंड सेवाओं (जैसे, Cloud Run, GKE) के सामने API Gateway का उपयोग करें।

क्यों: API Gateway API जीवनचक्र संबंधी चिंताओं (सुरक्षा, निगरानी, ​​संस्करण) के लिए एक पूरी तरह से प्रबंधित समाधान प्रदान करता है, उन्हें बैकएंड सेवा से ऑफलोड करता है।

संदर्भ↗

इवेंट्स के केवल-जोड़ने वाले लॉग के लिए एक टिकाऊ, स्केलेबल और दृढ़ता से सुसंगत स्टोर का चयन करें।

→इवेंट स्टोर के लिए Cloud Spanner का उपयोग करें।

क्यों: Spanner मजबूत वैश्विक स्थिरता के साथ क्षैतिज स्केलेबिलिटी प्रदान करता है, जो बड़े पैमाने पर एक इवेंट लॉग की अखंडता बनाए रखने के लिए महत्वपूर्ण है।

एक लंबे समय तक चलने वाले कार्य के लिए एक API को तुरंत प्रतिक्रिया देनी चाहिए, जबकि पृष्ठभूमि में प्रोसेसिंग जारी रहती है।

→API एंडपॉइंट Pub/Sub या Cloud Tasks में एक कार्य को कतारबद्ध करता है और एक जॉब ID के साथ 202 Accepted लौटाता है। एक अलग वर्कर (Cloud Run, Cloud Function) कार्य को प्रोसेस करता है।

क्यों: यह उपयोगकर्ता-सामने वाली प्रतिक्रिया समय को बैकएंड प्रोसेसिंग समय से अलग करता है, UX और सिस्टम विश्वसनीयता में सुधार करता है। स्थिति अपडेट के लिए Cloud Storage का उपयोग करें।

साझा डेटाबेस के बिना कई माइक्रोसेवाओं में डेटा स्थिरता बनाए रखें।

→एक ऑर्केस्ट्रेटर (Cloud Workflows) या कोरियोग्राफी (Pub/Sub इवेंट्स) का उपयोग करके क्षतिपूर्ति लेनदेन के साथ सागा पैटर्न को लागू करें।

क्यों: जटिल और लॉकिंग-प्रोन टू-फेज कमिट्स से बचा जाता है, अंततः निरंतरता को प्राथमिकता दी जाती है जो डिस्ट्रीब्यूटेड सिस्टम के लिए बेहतर है।

एप्लिकेशन एक रेट-लिमिटेड थर्ड-पार्टी API को कॉल करता है जहाँ डेटा शायद ही कभी बदलता है।

→एक डिस्ट्रीब्यूटेड कैश के रूप में Redis के लिए Memorystore का उपयोग करें। TTL के साथ कैश-साइड पैटर्न लागू करें। कैश स्टैम्पीस को रोकने के लिए एक डिस्ट्रीब्यूटेड लॉक (जैसे, Redis SETNX) का उपयोग करें।

क्यों: एक डिस्ट्रीब्यूटेड कैश सभी ऐप इंस्टेंस में डेटा साझा करता है, बाहरी API के लिए कॉल को नाटकीय रूप से कम करता है, विलंबता में सुधार करता है और रेट लिमिट का सम्मान करता है।

एक डेवलपमेंट टीम को निजी VPC संसाधनों तक पहुंच के साथ सुसंगत, पूर्व-कॉन्फ़िगर, सुरक्षित डेवलपमेंट वातावरण की आवश्यकता होती है।

→Cloud Workstations का उपयोग करें।

क्यों: Cloud Workstations एकीकृत सुरक्षा और VPC एक्सेस के साथ प्रबंधित, कंटेनर-आधारित डेवलपमेंट वातावरण प्रदान करता है, जो "यह मेरी मशीन पर काम करता है" समस्या को हल करता है।

संदर्भ↗

एक SaaS एप्लिकेशन को किरायेदारों के लिए पूरी तरह से अलग डेटा, एन्क्रिप्शन कुंजी और डेटा रेजिडेंसी की आवश्यकता होती है।

→प्रति-किरायेदार मॉडल का उपयोग करें। IaC (Terraform) का उपयोग करके प्रावधान और कॉन्फ़िगरेशन को केंद्रीय रूप से प्रबंधित करें।

क्यों: IAM, बिलिंग, कोटा, नेटवर्किंग और डेटा स्थान के लिए उच्चतम स्तर का अलगाव प्रदान करता है, जिसकी अक्सर उद्यम या विनियमित ग्राहकों द्वारा आवश्यकता होती है।

यह सुनिश्चित करें कि केवल एक आधिकारिक पाइपलाइन से विश्वसनीय, स्कैन किए गए कंटेनर इमेज को ही प्रोडक्शन में डिप्लॉय किया जा सकता है।

→SLSA प्रोवेनेंस उत्पन्न करने के लिए Cloud Build, भेद्यता स्कैनिंग के लिए Artifact Registry, और अटैस्टेशन के आधार पर डिप्लॉयमेंट नीतियों को लागू करने के लिए Binary Authorization का उपयोग करें।

क्यों: कोड से डिप्लॉयमेंट तक विश्वास की एक सत्यापन योग्य, अन-बाईपासेबल क्रिप्टोग्राफिक श्रृंखला बनाता है, जो समझौता किए गए या अनस्कैन किए गए आर्टिफैक्ट के डिप्लॉयमेंट को रोकता है।

संदर्भ↗

Cloud Run सेवा का एक नया संस्करण डिप्लॉय करें, इसे उपयोगकर्ता पर प्रभाव डाले बिना परीक्षण करें, और तुरंत ट्रैफ़िक स्विच करें।

→नए रिवीजन को `--no-traffic` के साथ डिप्लॉय करें। अद्वितीय रिवीजन URL या रिवीजन टैग का उपयोग करके परीक्षण करें। एक बार मान्य होने पर 100% ट्रैफ़िक नए रिवीजन पर स्विच करें।

क्यों: Cloud Run का नेटिव ट्रैफ़िक प्रबंधन नए संस्करण को किसी भी प्रोडक्शन ट्रैफ़िक प्राप्त करने से पहले मान्य करके सुरक्षित, शून्य-डाउनटाइम डिप्लॉयमेंट की अनुमति देता है।

धीरे-धीरे एक नया संस्करण रोल आउट करें, स्वचालित रूप से मेट्रिक्स का विश्लेषण करें और विफलता पर रोल बैक करें।

→कैनरी डिप्लॉयमेंट रणनीति के साथ Cloud Deploy का उपयोग करें। स्वचालित मेट्रिक विश्लेषण और रोलबैक ट्रिगर्स के लिए Cloud Monitoring के साथ इंटीग्रेट करें।

क्यों: Cloud Deploy पूरे प्रगतिशील वितरण वर्कफ़्लो को स्वचालित करता है, जिसमें मेट्रिक विश्लेषण और सुरक्षा जांच शामिल हैं, जिससे मैनुअल प्रयास और जोखिम कम होता है।

कोड को डुप्लिकेट किए बिना देव, स्टेजिंग और प्रोडक्शन वातावरण के लिए Kubernetes मैनिफेस्ट का प्रबंधन करें।

→Kustomize या Helm का उपयोग करें। एक बेस कॉन्फ़िगरेशन परिभाषित करें और अंतरों को पैच करने के लिए वातावरण-विशिष्ट ओवरले या वैल्यू फ़ाइलें बनाएं।

क्यों: DRY सिद्धांत का पालन करता है, जिससे कॉन्फ़िगरेशन का प्रबंधन करना आसान हो जाता है और वातावरण बहाव के जोखिम को कम करता है।

तेजी से डिप्लॉयमेंट और छोटे अटैक सरफेस के लिए कंटेनर इमेज का आकार कम करें।

→मल्टी-स्टेज बिल्ड का उपयोग करें। एक `build` स्टेज एक पूर्ण SDK/JDK इमेज का उपयोग करता है; अंतिम स्टेज केवल संकलित आर्टिफैक्ट को एक न्यूनतम `distroless` बेस इमेज में कॉपी करता है।

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

मर्ज करने से पहले सत्यापन के लिए प्रत्येक पुल रिक्वेस्ट के लिए अल्पकालिक वातावरण को स्वचालित रूप से डिप्लॉय करें।

→PR इवेंट्स पर Cloud Build ट्रिगर्स का उपयोग करें ताकि Cloud Run पर एक रिवीजन टैग (जैसे, `pr-123`) के साथ डिप्लॉय किया जा सके। टैग किए गए रिवीजन को साफ करने के लिए PR बंद होने पर एक और ट्रिगर का उपयोग करें।

क्यों: रिवीजन टैग नए सेवाओं को बनाने के ओवरहेड के बिना प्रत्येक PR के लिए अद्वितीय, अस्थायी URL प्रदान करते हैं, जिससे यह लागत प्रभावी और स्वचालित करना आसान हो जाता है।

सार्वजनिक सॉफ्टवेयर निर्भरताओं (जैसे, npm, Maven Central से) को कैश करके CI/CD बिल्ड गति और विश्वसनीयता में सुधार करें।

→एक Artifact Registry रिमोट रिपॉजिटरी का उपयोग करें, जो सार्वजनिक रिपॉजिटरी के लिए पुल-थ्रू कैश के रूप में कार्य करता है।

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

समवर्ती CI/CD पाइपलाइन निष्पादन के लिए Terraform स्टेट को सुरक्षित रूप से स्टोर और लॉक करें।

→Terraform स्टेट के लिए Cloud Storage बैकएंड का उपयोग करें, जिसमें Cloud Build सेवा खाते के लिए उचित IAM हो।

क्यों: Cloud Storage एक टिकाऊ, संस्करणित और लॉक करने योग्य बैकएंड प्रदान करता है, जो समवर्ती बिल्ड से स्टेट भ्रष्टाचार को रोकता है।

एक Cloud Run या Cloud Function को एक निजी VPC नेटवर्क पर एक संसाधन (जैसे, Cloud SQL, Memorystore) तक पहुंचने की आवश्यकता है।

→एक सर्वरलेस VPC एक्सेस कनेक्टर कॉन्फ़िगर करें।

क्यों: कनेक्टर एक नेटवर्क ब्रिज के रूप में कार्य करता है, जो संसाधनों को सार्वजनिक रूप से उजागर किए बिना सर्वरलेस वातावरण से लक्ष्य VPC में एग्रेस ट्रैफ़िक की अनुमति देता है।

संदर्भ↗

GKE पर एक स्टेटफुल एप्लिकेशन को स्थिर पहचान और स्थायी स्टोरेज की आवश्यकता होती है जो पॉड/नोड विफलता से बचता है।

→पहचान के लिए हेडलेस सेवा के साथ StatefulSet का उपयोग करें। स्टोरेज के लिए क्षेत्रीय Persistent Disk के साथ PersistentVolumeClaim (PVC) का उपयोग करें।

क्यों: यह स्टेटफुल वर्कलोड के लिए कैनोनिकल Kubernetes पैटर्न है, जो डेटा दृढ़ता, उच्च उपलब्धता और अनुमानित पॉड नामकरण/नेटवर्किंग सुनिश्चित करता है।

GKE पर एक पॉड को स्थिर सेवा खाते की कुंजियों को प्रबंधित किए बिना GCP API को सुरक्षित रूप से एक्सेस करने की आवश्यकता है।

→Workload Identity कॉन्फ़िगर करें और उसका उपयोग करें।

क्यों: Workload Identity एक Kubernetes सेवा खाते को एक Google सेवा खाते से जोड़ता है, जिससे पॉड मेटाडेटा सर्वर से प्राप्त अल्पकालिक GCP क्रेडेंशियल्स का उपयोग कर सकते हैं।

एक बैच जॉब चलाएं जिसे पूरा होने में घंटों लगते हैं (जैसे, एक बड़ी फ़ाइल को प्रोसेस करना, रात भर डेटा एग्रीगेशन)।

→Cloud Run जॉब्स का उपयोग करें, जो Eventarc या Cloud Scheduler द्वारा ट्रिगर होते हैं।

क्यों: Cloud Run जॉब्स को लंबे समय तक चलने वाले (24 घंटे तक) कार्यों के लिए डिज़ाइन किया गया है, शून्य तक स्केल होते हैं, और बैच वर्कलोड के लिए एक समर्पित GKE क्लस्टर या VM की तुलना में अधिक लागत प्रभावी और सरल हैं।

Cloud Run पर एक मल्टी-कंटेनर एप्लिकेशन डिप्लॉय करें जहाँ मुख्य कंटेनर को लॉगिंग, मेट्रिक्स या प्रॉक्सी के लिए एक साइडकार की आवश्यकता होती है।

→निर्दिष्ट कई कंटेनर इमेज के साथ Cloud Run सेवा डिप्लॉय करें, एक मुख्य कंटेनर के रूप में और अन्य साइडकार के रूप में।

क्यों: Cloud Run का नेटिव मल्टी-कंटेनर समर्थन GKE की जटिलता के बिना सर्वरलेस वर्कलोड के लिए साइडकार पैटर्न को सक्षम बनाता है।

एक नए Cloud Run रिवीजन को ट्रैफ़िक प्राप्त होने से पहले डेटाबेस माइग्रेशन पूरे होने चाहिए।

→कंटेनर स्टार्टअप के दौरान माइग्रेशन चलाएं, और एक Cloud Run स्टार्टअप प्रोब का उपयोग करें जो माइग्रेशन सफल होने के बाद ही पास होता है।

क्यों: स्टार्टअप प्रोब ट्रैफ़िक रूटिंग को तब तक विलंबित करता है जब तक कंटेनर पूरी तरह से तैयार न हो जाए, यह सुनिश्चित करता है कि कोई भी रिक्वेस्ट सेवा देने से पहले डेटाबेस स्कीमा सही है।

एक GKE एप्लिकेशन को Pub/Sub से क्यू डेप्थ जैसे कस्टम मेट्रिक के आधार पर स्केल करने की आवश्यकता है, न कि केवल CPU/मेमोरी के आधार पर।

→Cloud Monitoring से कस्टम मेट्रिक्स पढ़ने के लिए कॉन्फ़िगर किए गए Horizontal Pod Autoscaler (HPA) का उपयोग करें।

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

एक मैसेज-ड्रिवन सेवा को प्रत्येक मैसेज को ठीक एक बार प्रोसेस करना चाहिए, रिट्राई और संभावित डुप्लिकेट डिलीवरी के बावजूद।

→Pub/Sub (कम से कम एक बार या ठीक एक बार डिलीवरी के साथ) को एक आइडेंपोटेंट कंज्यूमर के साथ मिलाएं। कंज्यूमर एक स्थायी स्टोर (जैसे, Firestore, Memorystore) में प्रोसेस किए गए मैसेज IDs को ट्रैक करता है।

क्यों: Pub/Sub डिलीवरी की गारंटी देता है, लेकिन कंज्यूमर एप्लिकेशन-लेवल रिट्राई को संभालने और सही ठीक-एक-बार प्रोसेसिंग प्राप्त करने के लिए आइडेंपोटेंसी के लिए जिम्मेदार है।

एक ही इकाई (जैसे, एक विशिष्ट उपयोगकर्ता) से संबंधित इवेंट्स को उसी क्रम में प्रोसेस किया जाना चाहिए जिसमें वे उत्पन्न हुए थे।

→`orderingKey` के साथ Pub/Sub पर मैसेज पब्लिश करें। सब्सक्रिप्शन पर मैसेज ऑर्डरिंग सक्षम करें।

क्यों: Pub/Sub गारंटी देता है कि समान ऑर्डरिंग कुंजी वाले मैसेज क्रम में डिलीवर होते हैं, जबकि विभिन्न कुंजियों वाले मैसेज को स्केलेबिलिटी के लिए समानांतर में प्रोसेस किया जा सकता है।

संदर्भ↗

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

→Cloud Tasks का उपयोग करें। स्पष्ट नामों (जैसे, `report-userX-2024-10-26`) के साथ कार्य बनाएं। Cloud Tasks मौजूदा नाम के साथ एक कार्य बनाने के लिए अनुरोधों को डुप्लिकेट करेगा।

क्यों: यह deduplication लॉजिक को क्यूइंग सेवा में ऑफलोड करता है, एप्लिकेशन कोड को सरल बनाता है और अनावश्यक काम को रोकता है।

एक Pub/Sub मैसेज कई रिट्राई के बाद लगातार प्रोसेसिंग में विफल रहता है और क्यू को ब्लॉक कर रहा है।

→Pub/Sub सब्सक्रिप्शन पर एक डेड-लेटर टॉपिक (DLQ) कॉन्फ़िगर करें और डिलीवरी प्रयासों की अधिकतम संख्या निर्धारित करें।

क्यों: Pub/Sub स्वचालित रूप से "पॉइजन" मैसेज को DLQ में ले जाता है, जिससे अन्य मैसेज को प्रोसेस किया जा सकता है और विश्लेषण के लिए विफल मैसेज को संरक्षित किया जा सकता है।

एक व्यावसायिक प्रक्रिया में सशर्त तर्क, त्रुटि हैंडलिंग और लंबे इंतजार के साथ सेवा कॉल्स का एक क्रम शामिल होता है।

→ऑर्केस्ट्रेशन लॉजिक को परिभाषित और निष्पादित करने के लिए Cloud Workflows का उपयोग करें।

क्यों: Cloud Workflows एक सर्वरलेस ऑर्केस्ट्रेटर है जो स्टेट, रिट्राई और लंबे इंतजार का प्रबंधन करता है, जो मैन्युअल रूप से चेन किए गए फ़ंक्शंस की तुलना में बेहतर विश्वसनीयता और दृश्यता प्रदान करता है।

संदर्भ↗

एक Cloud Function या Cloud Run सेवा को केवल विशिष्ट क्लाउड इवेंट्स (जैसे, Cloud Storage में कुछ फ़ाइल प्रकार) द्वारा ट्रिगर किया जाना चाहिए।

→इवेंट एट्रीब्यूट्स पर CEL (Common Expression Language) फ़िल्टरिंग के साथ Eventarc ट्रिगर का उपयोग करें।

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

Cloud Run जैसी क्षैतिज रूप से-स्केल्ड सेवा से थर्ड-पार्टी API के लिए आउटगोइंग कॉल्स को रेट-लिमिट करें।

→`rateLimits` कॉन्फ़िगर (जैसे, प्रति सेकंड अधिकतम प्रेषण) के साथ एक Cloud Tasks क्यू में API कॉल्स को कार्य के रूप में कतारबद्ध करें।

क्यों: Cloud Tasks केंद्रीकृत, सर्वरलेस रेट लिमिटिंग प्रदान करता है जो जटिल डिस्ट्रीब्यूटेड काउंटर्स की आवश्यकता के बिना सभी स्केल्ड इंस्टेंस पर काम करता है।

दो Cloud Run (या Cloud Functions) सेवाओं के बीच कॉल्स को सुरक्षित रूप से प्रमाणित करें।

→कॉलर सेवा के सेवा खाते को कैली सेवा पर `roles/run.invoker` IAM भूमिका प्रदान करें। कॉलर अपने अनुरोध के साथ एक Google-हस्ताक्षरित ID टोकन भेजता है।

क्यों: यह सेवा-से-सेवा प्रमाणीकरण के लिए नेटिव, सुरक्षित और कुंजी-रहित विधि है, जो Google की पहचान इन्फ्रास्ट्रक्चर का लाभ उठाती है।

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

→डेटाबेस परिवर्तनों को Pub/Sub पर स्ट्रीम करने के लिए Datastream (CDC) का उपयोग करें। Pub/Sub टॉपिक से Cloud Run सेवा को ट्रिगर करने के लिए Eventarc का उपयोग करें।

क्यों: यह एक डीकपल किया गया, विश्वसनीय पैटर्न है जो डेटाबेस पोलिंग से बचाता है और डेटाबेस में लिखने वाले एप्लिकेशन को संशोधित करने की आवश्यकता नहीं होती है।

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

→एक कॉलबैक एंडपॉइंट के साथ Cloud Workflows का उपयोग करें। वर्कफ़्लो तब तक रुकता है (एक वर्ष तक के लिए) जब तक उसे अपने अद्वितीय कॉलबैक URL पर एक HTTP अनुरोध प्राप्त नहीं होता है।

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

एक विलंबता-संवेदनशील सर्वरलेस एप्लिकेशन निष्क्रिय अवधि के बाद धीमी प्रारंभिक प्रतिक्रियाओं का अनुभव करता है।

→`min-instances` को 1 या अधिक पर कॉन्फ़िगर करें। अपरिहार्य कोल्ड स्टार्ट के लिए, `startup-cpu-boost` का उपयोग करें। एप्लिकेशन को भी ऑप्टिमाइज़ करें (छोटा इमेज, तेज़ इनिट)।

क्यों: `min-instances` कोल्ड स्टार्ट को खत्म करने का सबसे प्रभावी तरीका है लेकिन इसमें लागत लगती है। `startup-cpu-boost` स्टार्टअप प्रक्रिया को ही तेज करता है।

संदर्भ↗

कई माइक्रोसेवाओं में एक अनुरोध धीमा हो रहा है या विफल हो रहा है, और बॉटलनेक लॉग या व्यक्तिगत सेवा मेट्रिक्स से स्पष्ट नहीं है।

→संदर्भ प्रसार के साथ Cloud Trace का उपयोग करें। ट्रेस हेडर (जैसे, W3C Trace Context) को फॉरवर्ड करने के लिए एप्लिकेशन को इंस्ट्रूमेंट करें।

क्यों: Cloud Trace सभी सेवाओं में पूरे अनुरोध जीवनचक्र का एक झरना विज़ुअलाइज़ेशन प्रदान करता है, जो विलंबता या त्रुटियों के स्रोत का पता लगाता है।

संदर्भ↗

एक एप्लिकेशन प्रोडक्शन में धीमा चल रहा है, और यह स्पष्ट नहीं है कि समस्या CPU-बाउंड है, मेमोरी लीक है, या I/O है।

→प्रोडक्शन में CPU और हीप उपयोग का लगातार विश्लेषण करने के लिए Cloud Profiler का उपयोग करें।

क्यों: Cloud Profiler बहुत कम ओवरहेड के साथ कोड-स्तरीय प्रदर्शन बॉटलनेक (हॉट पाथ, मेमोरी लीक) की पहचान करता है, बिना परीक्षण वातावरण में समस्याओं को पुन: उत्पन्न करने की आवश्यकता के।

सरल थ्रेशोल्ड अलर्ट (जैसे, "विलंबता > 500ms") से सेवा स्तर उद्देश्यों (SLOs) पर आधारित अधिक सार्थक अलर्ट पर जाएं।

→Cloud Monitoring में SLI और SLO परिभाषित करें। त्रुटि बजट की "बर्न रेट" के आधार पर अलर्टिंग नीतियां बनाएं।

क्यों: बर्न रेट अलर्टिंग महत्वपूर्ण परिवर्तनों के प्रति अधिक संवेदनशील और सरल थ्रेशोल्ड अलर्ट की तुलना में कम शोरगुल वाली होती है, यह संकेत देती है कि आप अपने SLO को मिस करने की राह पर हैं।

फ्रीक्वेंसी को ट्रैक करने, स्टैक ट्रेस देखने और नए त्रुटि प्रकारों की सूचना प्राप्त करने के लिए कई सेवाओं से एप्लिकेशन अपवादों को एकत्रित करें।

→Cloud Error Reporting का उपयोग करें।

क्यों: Error Reporting स्वचालित रूप से संरचित लॉग से अपवादों को इनजेस्ट, समूह और विश्लेषण करता है, जो एप्लिकेशन त्रुटियों के प्रबंधन के लिए एक केंद्रीकृत डैशबोर्ड प्रदान करता है।

कस्टम व्यावसायिक मेट्रिक्स (जैसे, प्रति मिनट ऑर्डर, उपयोगकर्ता साइनअप) पर निगरानी करें, विज़ुअलाइज़ करें और अलर्ट करें।

→OpenTelemetry SDK का उपयोग करके एप्लिकेशन कोड को इंस्ट्रूमेंट करें। मेट्रिक्स को Cloud Monitoring पर भेजने के लिए एक्सपोर्टर को कॉन्फ़िगर करें।

क्यों: यह कस्टम इंस्ट्रूमेंटेशन के लिए आधुनिक, वेंडर-न्यूट्रल मानक है। यह किसी भी मेट्रिक को ट्रैक करने और उसके लिए Cloud Monitoring की सभी सुविधाओं का लाभ उठाने की अनुमति देता है।