अंतिम समीक्षा: मई 2026
PCA परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक वैश्विक एप्लिकेशन को दुनिया भर के उपयोगकर्ताओं के लिए कम विलंबता (low latency) और उच्च उपलब्धता (high availability) की आवश्यकता है।
बहु-क्षेत्रीय बैकएंड (MIGs/GKE), स्टैटिक कंटेंट के लिए Cloud CDN, और DDoS सुरक्षा के लिए Cloud Armor के साथ एक Global HTTP(S) Load Balancer का उपयोग करें।
क्यों: Global Load Balancer एक सिंगल anycast IP प्रदान करता है जो उपयोगकर्ताओं को निकटतम स्वस्थ बैकएंड पर रूट करता है। CDN एज पर कंटेंट को कैश करता है, जिससे ऑरिजिन लोड और विलंबता कम होती है।
तत्काल विश्लेषण के लिए IoT उपकरणों से उच्च-थ्रूपुट, रीयल-टाइम डेटा को इंजेंस्ट और प्रोसेस करें।
स्केलेबल संदेश इंजेशन के लिए Pub/Sub, रीयल-टाइम प्रोसेसिंग और विसंगति का पता लगाने के लिए एक Dataflow स्ट्रीमिंग पाइपलाइन, और एनालिटिक्स के लिए BigQuery में परिणाम लिखें।
क्यों: यह रीयल-टाइम डेटा के लिए कैननिकल सर्वरलेस पैटर्न है। Pub/Sub इंजेशन को डीकपल्स करता है, Dataflow ऑटो-स्केलिंग के साथ जटिल प्रोसेसिंग को संभालता है, और BigQuery रीयल-टाइम एनालिटिक्स के लिए स्ट्रीमिंग इंसर्ट का समर्थन करता है।
एक गेमिंग बैकएंड को सब-मिलीसेकंड रीड विलंबता (sub-millisecond read latency) और उच्च थ्रूपुट के साथ प्लेयर स्थिति (player state) और लीडरबोर्ड (leaderboards) को स्टोर करने की आवश्यकता है।
गेम की स्थिति/लीडरबोर्ड के लिए Cloud Bigtable और सेशन कैशिंग के लिए Memorystore (Redis) का उपयोग करें।
क्यों: Bigtable उच्च-थ्रूपुट रीड/राइट के लिए एकल-अंकीय मिलीसेकंड विलंबता प्रदान करता है, जो टाइम-सीरीज़ या बड़े एनालिटिकल डेटासेट के लिए आदर्श है। Memorystore सेशन स्थिति के लिए माइक्रोसेकंड विलंबता प्रदान करता है।
एक विश्व स्तर पर वितरित एप्लिकेशन को मजबूत ट्रांजैक्शनल कंसिस्टेंसी (strong transactional consistency) और क्षैतिज स्केलेबिलिटी (horizontal scalability) वाले डेटाबेस की आवश्यकता है।
बहु-क्षेत्रीय कॉन्फ़िगरेशन के साथ Cloud Spanner का उपयोग करें।
क्यों: Spanner एकमात्र सेवा है जो SQL सिमेंटिक्स और क्षैतिज स्केलेबिलिटी के साथ वैश्विक, मजबूत रूप से सुसंगत ट्रांजैक्शन प्रदान करती है। इस पैमाने के लिए Cloud SQL को मैन्युअल शार्डिंग की आवश्यकता होती है।
एक मांग वाले, ऑन-प्रिमाइसेस Oracle या PostgreSQL डेटाबेस को माइग्रेट करना जिसके लिए उच्च उपलब्धता (high availability), प्रदर्शन और न्यूनतम रीफ़ैक्टरिंग की आवश्यकता होती है।
PostgreSQL के लिए AlloyDB का उपयोग करें।
क्यों: AlloyDB एक पूरी तरह से प्रबंधित, PostgreSQL-संगत डेटाबेस है जिसमें बेहतर प्रदर्शन, 99.99% उपलब्धता और Oracle संगतता सुविधाएँ हैं, जो इसे एंटरप्राइज़ माइग्रेशन के लिए आदर्श बनाती हैं।
एक ऑन-प्रिमाइसेस डेटा सेंटर को GCP से सुसंगत, कम विलंबता (<10ms) और उच्च-बैंडविड्थ (10+ Gbps) आवश्यकताओं के साथ जोड़ना।
अतिरिक्त कनेक्शन के साथ Dedicated Interconnect का उपयोग करें।
क्यों: Dedicated Interconnect एक निजी, उच्च-बैंडविड्थ, कम-विलंबता वाला भौतिक कनेक्शन प्रदान करता है। Cloud VPN सार्वजनिक इंटरनेट पर चलता है और इस स्तर पर विलंबता या बैंडविड्थ SLA की गारंटी नहीं दे सकता।
कई टीमों/परियोजनाओं के लिए एक नेटवर्क डिज़ाइन करना जिसके लिए केंद्रीकृत नेटवर्क प्रबंधन लेकिन विकेन्द्रीकृत परियोजना स्वामित्व की आवश्यकता होती है।
Shared VPC का उपयोग करके हब-एंड-स्पोक मॉडल लागू करें। केंद्रीय नेटवर्क टीम होस्ट प्रोजेक्ट का प्रबंधन करती है, और एप्लिकेशन टीमें सेवा परियोजनाओं का उपयोग करती हैं।
क्यों: Shared VPC नेटवर्किंग संसाधनों (सबनेट, फ़ायरवॉल) पर केंद्रीकृत नियंत्रण की अनुमति देता है जबकि सेवा परियोजनाओं में संसाधन प्रबंधन को प्रत्यायोजित करता है। यह VPC पीयरिंग की तुलना में अधिक स्केलेबल और सुरक्षित है।
Google Cloud, AWS, Azure, और ऑन-प्रिमाइसेस वातावरणों में Kubernetes क्लस्टरों का लगातार प्रबंधन करना।
मल्टी-क्लाउड और हाइब्रिड क्लस्टर प्रबंधन, नीति प्रवर्तन और ऑब्जर्वेबिलिटी (observability) के लिए एक एकीकृत नियंत्रण प्लेन (control plane) प्रदान करने के लिए Anthos का उपयोग करें।
क्यों: Anthos GKE को अन्य वातावरणों तक फैलाता है, जिससे आपके पूरे बेड़े में सुसंगत संचालन और GitOps-आधारित कॉन्फ़िगरेशन प्रबंधन (Config Management) सक्षम होता है।
एक डेटा साइंस टीम को इंफ्रास्ट्रक्चर का प्रबंधन किए बिना GPU त्वरण (acceleration) के साथ जटिल ML मॉडल को प्रशिक्षित करने की आवश्यकता है।
कस्टम कंटेनरों के साथ Vertex AI Training और मॉडल पुनरावृति (iterations) को ट्रैक करने के लिए Vertex AI Experiments का उपयोग करें।
क्यों: Vertex AI एक पूरी तरह से प्रबंधित प्रशिक्षण सेवा प्रदान करता है जो इंफ्रास्ट्रक्चर प्रोविजनिंग, स्केलिंग और GPU प्रबंधन को संभालती है। यह मॉडल प्रदर्शन को ट्रैक करने और तुलना करने के लिए प्रयोगों के साथ एकीकृत होता है।
कम विलंबता (low latency) और उच्च उपलब्धता (high availability) के साथ एक बड़े ML मॉडल को सर्व करना, जो ऑटो-स्केलिंग में सक्षम हो।
ऑटोस्केलिंग सक्षम एक प्रबंधित एंडपॉइंट पर डिप्लॉय किए गए कस्टम कंटेनर के साथ Vertex AI Prediction का उपयोग करें।
क्यों: Vertex AI Prediction कम-विलंबता मॉडल सर्विंग के लिए अनुकूलित है। यह ऑटोस्केलिंग, ट्रैफिक स्प्लिटिंग (A/B टेस्टिंग के लिए), और इंफ्रास्ट्रक्चर प्रबंधन को संभालता है, जिससे डेवलपर्स से जटिलता कम हो जाती है।
एक Cloud Function या Cloud Run सेवा को निजी IP के साथ Cloud SQL इंस्टेंस से सुरक्षित रूप से कनेक्ट करने की आवश्यकता है।
सर्वरलेस वातावरण को आपके VPC से जोड़ने के लिए एक Serverless VPC Access Connector कॉन्फ़िगर करें।
क्यों: कनेक्टर आपके VPC में एक सुरंग बनाता है, जिससे सर्वरलेस सेवाओं को इंटरनेट पर उजागर किए बिना अपने निजी IP पते द्वारा आंतरिक संसाधनों तक पहुंचने की अनुमति मिलती है।
स्थानीय सेशन स्टोरेज का उपयोग करने वाले स्टेटफुल एप्लिकेशन को Cloud Run या GKE जैसे स्टेटलेस, ऑटो-स्केलिंग प्लेटफॉर्म पर माइग्रेट करना।
सेशन स्थिति को Memorystore (Redis) जैसे प्रबंधित इन-मेमोरी स्टोर में बाहरीकृत करें।
क्यों: स्टेटलेस कंप्यूट के लिए सेशन डेटा को बाहरी रूप से स्टोर करने की आवश्यकता होती है ताकि कोई भी इंस्टेंस किसी भी उपयोगकर्ता अनुरोध को संभाल सके। Memorystore इसके लिए एक साझा, कम-विलंबता वाला समाधान प्रदान करता है।
अनुमोदन के साथ कई वातावरणों (स्टेजिंग, उत्पादन) में रिलीज़ को बढ़ावा देने के लिए एक प्रबंधित निरंतर वितरण पाइपलाइन बनाएं।
Cloud Deploy का उपयोग करें ताकि डिलीवरी पाइपलाइन को परिभाषित किया जा सके जो अंतर्निहित अनुमोदन गेट्स के साथ लक्ष्य वातावरण (GKE, Cloud Run) में डिप्लॉयमेंट को ऑर्केस्ट्रेट करती है।
क्यों: Cloud Deploy CD के लिए एक पूरी तरह से प्रबंधित सेवा है, जो Spinnaker जैसे स्व-होस्टिंग टूल के परिचालन ओवरहेड के बिना रिलीज़ प्रबंधन, ऑडिटेबिलिटी और स्वचालित रोलबैक क्षमताएं प्रदान करती है।
न्यूनतम परिचालन और प्रबंधन ओवरहेड के साथ उत्पादन-तैयार Kubernetes क्लस्टर पर एक कंटेनरीकृत एप्लिकेशन डिप्लॉय करें।
एक GKE Autopilot क्लस्टर का उपयोग करें।
क्यों: Autopilot क्लस्टर के नियंत्रण प्लेन और नोड्स का प्रबंधन करता है, जिसमें प्रोविजनिंग, स्केलिंग और सुरक्षा सुदृढीकरण शामिल है। आप केवल उन पॉड संसाधनों के लिए भुगतान करते हैं जिनकी आप अनुरोध करते हैं, जिससे संचालन और लागत प्रबंधन दोनों सरल हो जाते हैं।
न्यूनतम जोखिम और डाउनटाइम के साथ एक बड़े, मोनोलिथिक एप्लिकेशन को धीरे-धीरे माइक्रोसर्विसेज आर्किटेक्चर में माइग्रेट करें।
Strangler Fig पैटर्न लागू करें। मोनोलिथ के सामने एक प्रॉक्सी रखें, और विशिष्ट कार्यात्मकताओं के लिए ट्रैफिक को धीरे-धीरे नए माइक्रोसर्विसेज पर रीडायरेक्ट करें जैसे ही वे बनाए और मान्य किए जाते हैं।
क्यों: यह पैटर्न एक उच्च-जोखिम वाले "बिग बैंग" रीराइट से बचता है, जिससे एक क्रमिक, नियंत्रित संक्रमण की अनुमति मिलती है। मोनोलिथ धीरे-धीरे "गला घोंटा" जाता है क्योंकि नई सेवाएं इसकी कार्यक्षमता पर कब्जा कर लेती हैं।
कम डाउनटाइम के साथ बड़ी संख्या में ऑन-प्रिमाइसेस VMs को Google Cloud में माइग्रेट करें।
ऑन-प्रिमाइसेस से GCP तक निरंतर, ब्लॉक-स्तरीय प्रतिकृति करने के लिए Migrate to Virtual Machines (पूर्व में Migrate for Compute Engine) का उपयोग करें, जिसके बाद त्वरित कटओवर होता है।
क्यों: यह टूल लिफ्ट-एंड-शिफ्ट माइग्रेशन के लिए डिज़ाइन किया गया है, जो अंतिम कटओवर तक स्रोत और लक्ष्य VMs को सिंक में रखकर डाउनटाइम को मिनटों तक कम करता है।
एक टीम SRE सिद्धांतों को अपना रही है और उसे अपने प्रारंभिक SLOs स्थापित करने की आवश्यकता है।
पहले उपयोगकर्ता-केंद्रित सर्विस लेवल इंडिकेटर (SLIs) (जैसे, उपलब्धता, विलंबता) परिभाषित करें। यथार्थवादी प्रारंभिक सर्विस लेवल ऑब्जेक्टिव (SLOs) निर्धारित करने के लिए ऐतिहासिक प्रदर्शन डेटा का विश्लेषण करें।
क्यों: SLOs उपयोगकर्ता अनुभव (SLIs) पर आधारित होने चाहिए और प्राप्त करने योग्य होने चाहिए। उन्हें ऐतिहासिक डेटा के आधार पर निर्धारित करने से यह सुनिश्चित होता है कि प्रारंभिक त्रुटि बजट यथार्थवादी है और तुरंत उल्लंघन नहीं किया जाता है।
मानकीकृत कॉन्फ़िगरेशन (APIs, IAM, नेटवर्किंग, सुरक्षा) के साथ नए GCP प्रोजेक्ट्स के निर्माण को स्वचालित करें।
एक Terraform मॉड्यूल के साथ "Project Factory" पैटर्न का उपयोग करें, जिसे Cloud Build द्वारा ट्रिगर किया गया हो। स्व-सेवा इंटरफ़ेस प्रदान करने के लिए Service Catalog का उपयोग करें।
क्यों: यह सुनिश्चित करता है कि सभी नए प्रोजेक्ट संगठनात्मक मानकों और सुरक्षा बेसलाइन का पालन करते हैं, जिससे मैन्युअल प्रयास और कॉन्फ़िगरेशन ड्रिफ्ट (configuration drift) कम हो जाती है। यह बड़े पैमाने पर शासन को सक्षम बनाता है।
Terraform द्वारा प्रबंधित इंफ्रास्ट्रक्चर में मैन्युअल परिवर्तनों (कॉन्फ़िगरेशन ड्रिफ्ट) को रोकना।
सभी एप्लाई के लिए CI/CD पाइपलाइन (जैसे Cloud Build), Terraform स्टेट लॉकिंग (GCS बैकएंड के माध्यम से), कंसोल क्रियाओं को प्रतिबंधित करने के लिए Organization Policies, और नियमित ड्रिफ्ट डिटेक्शन का उपयोग करें।
क्यों: एक बहु-स्तरीय दृष्टिकोण आवश्यक है। पाइपलाइन परिवर्तनों के लिए एक सिंगल पाथ लागू करती है, लॉकिंग समवर्ती एप्लाई को रोकती है, और Org Policies एक निवारक गार्डरेल प्रदान करती हैं।
साझा मॉड्यूल लेकिन विभिन्न कॉन्फ़िगरेशन के साथ कई वातावरणों (देव, स्टेजिंग, उत्पादन) के लिए इंफ्रास्ट्रक्चर कोड (Terraform) का प्रबंधन करना।
पुन: प्रयोज्य Terraform मॉड्यूल का एक सिंगल सेट उपयोग करें और अलग `.tfvars` फ़ाइलों या वर्कस्पेस के माध्यम से वातावरण-विशिष्ट कॉन्फ़िगरेशन प्रदान करें।
क्यों: यह डोंट रिपीट योरसेल्फ (DRY) सिद्धांत का पालन करता है। मॉड्यूल निरंतरता सुनिश्चित करते हैं, जबकि वैरिएबल फ़ाइलें प्रत्येक वातावरण को अनुकूलित करने के लिए लचीलापन प्रदान करती हैं।
एक Git रिपॉजिटरी से GKE क्लस्टरों में Kubernetes मैनिफेस्ट को स्वचालित रूप से डिप्लॉय करने के लिए एक GitOps वर्कफ़्लो लागू करना।
Anthos Config Management (या स्टैंडअलोन Config Sync) का उपयोग क्लस्टर स्थिति को Git रिपॉजिटरी में कॉन्फ़िगरेशन के साथ लगातार सुलझाने के लिए करें।
क्यों: Config Sync एक पूरी तरह से प्रबंधित GitOps समाधान प्रदान करता है जो कॉन्फ़िगरेशन ड्रिफ्ट का पता लगाता है और उसे ठीक करता है, यह सुनिश्चित करता है कि Git रिपॉजिटरी क्लस्टर की स्थिति के लिए सच्चाई का एकल स्रोत है।
जीरो डाउनटाइम और तत्काल रोलबैक क्षमता के साथ एक वेब एप्लिकेशन के लिए ब्लू-ग्रीन डिप्लॉयमेंट लागू करना।
एक HTTP(S) Load Balancer के पीछे दो समान Managed Instance Groups (या GKE Deployments) का उपयोग करें। लोड बैलेंसर की बैकएंड सेवा में ट्रैफिक को रीडायरेक्ट करके कटओवर करें।
क्यों: लोड बैलेंसर स्तर पर ट्रैफिक विभाजन तात्कालिक होता है और मूल बैकएंड पर ट्रैफिक वापस स्विच करके आसान रोलबैक की अनुमति देता है। यह धीमे DNS-आधारित तरीकों से बेहतर है।
एप्लिकेशन के लिए API कुंजियों और डेटाबेस पासवर्ड जैसे रहस्यों को सुरक्षित रूप से स्टोर, प्रबंधित और ऑडिट एक्सेस करें।
पहुंच नियंत्रण के लिए IAM के साथ Secret Manager और GKE/Cloud Run से कीलेस प्रमाणीकरण के लिए Workload Identity का उपयोग करें।
क्यों: Secret Manager संस्करण, रोटेशन नीतियों और ऑडिट लॉगिंग के साथ एक केंद्रीकृत, प्रबंधित सेवा है। Workload Identity का उपयोग करके सेवा खाता कुंजियों का प्रबंधन और वितरण करने से बचा जा सकता है।
BigQuery और Cloud Storage जैसी सेवाओं में संवेदनशील डेटा को अनधिकृत परियोजनाओं या स्थानों पर एक्सेस या कॉपी होने से रोकें।
संवेदनशील परियोजनाओं के चारों ओर एक सेवा परिधि (service perimeter) बनाने और डेटा प्रवाह को प्रतिबंधित करने के लिए VPC Service Controls का उपयोग करें।
क्यों: VPC Service Controls Google-प्रबंधित सेवाओं के लिए फ़ायरवॉल के रूप में कार्य करते हैं, API स्तर पर डेटा के बाहर निकलने को रोकते हैं। यह IAM और नेटवर्क फ़ायरवॉल से परे एक महत्वपूर्ण रक्षा-गहराई परत है।
Google Cloud सेवाओं में डेटा को आराम से एन्क्रिप्ट करें जबकि एन्क्रिप्शन कुंजियों पर पूर्ण नियंत्रण बनाए रखें।
Customer-Managed Encryption Keys (CMEK) का उपयोग करें, जिसमें कुंजियाँ Cloud KMS में संग्रहीत और प्रबंधित होती हैं।
क्यों: CMEK आपको अन्य GCP सेवाओं में डेटा की सुरक्षा के लिए Cloud KMS के माध्यम से अपनी स्वयं की कुंजियों का उपयोग करने की अनुमति देता है। आप कुंजी रोटेशन को नियंत्रित करते हैं और कुंजी को अक्षम करके पहुंच को रद्द कर सकते हैं, जिससे क्रिप्टोग्राफिक इरेज़र (cryptographic erasure) प्रदान होता है।
HIPAA के अनुपालन में प्रोटेक्टेड हेल्थ इंफॉर्मेशन (PHI) को संभालने के लिए एक आर्किटेक्चर डिज़ाइन करना।
एन्क्रिप्शन नियंत्रण के लिए CMEK, बहिर्गमन को रोकने के लिए VPC Service Controls, अनुपालन सीमाओं के लिए Assured Workloads, Cloud Audit Logs, और ऑडिटिंग के लिए Access Transparency का उपयोग करें।
क्यों: HIPAA को तकनीकी नियंत्रणों के संयोजन की आवश्यकता है। CMEK कुंजी नियंत्रण प्रदान करता है, VPC-SC डेटा लीक को रोकता है, और व्यापक लॉगिंग (Audit Logs, Access Transparency) आवश्यक ऑडिटेबिलिटी प्रदान करता है।
एक GKE पॉड को पासवर्ड का उपयोग किए बिना या सेवा खाता कुंजियों का प्रबंधन किए बिना Cloud SQL डेटाबेस से सुरक्षित रूप से कनेक्ट करने की आवश्यकता है।
Kubernetes सर्विस अकाउंट को Google सर्विस अकाउंट से बाइंड करने के लिए Workload Identity का उपयोग करें। Cloud SQL Auth Proxy साइडकार और IAM डेटाबेस प्रमाणीकरण का उपयोग करके कनेक्ट करें।
क्यों: यह "पासवर्डलेस" पैटर्न सबसे सुरक्षित है। Workload Identity कीलेस प्रमाणीकरण प्रदान करता है, Auth Proxy ट्रैफिक को एन्क्रिप्ट करता है, और IAM DB प्रमाणीकरण स्थिर क्रेडेंशियल के बजाय डेटाबेस एक्सेस के लिए IAM का उपयोग करता है।
एक नीति लागू करें कि सभी क्लाउड संसाधन केवल विशिष्ट भौगोलिक क्षेत्रों (जैसे, EU) में बनाए जाने चाहिए।
संगठन या फ़ोल्डर स्तर पर एक Organization Policy constraint (`gcp.resourceLocations`) कॉन्फ़िगर करें, जिसमें अनुमत क्षेत्रों को निर्दिष्ट किया गया हो।
क्यों: यह एक निवारक नियंत्रण है जो API स्तर पर गैर-अनुपालक संसाधन निर्माण को ब्लॉक करता है। यह पूरे संगठन में डेटा रेजिडेंसी नीतियों को लागू करने का आधिकारिक तरीका है।
सुनिश्चित करें कि केवल विश्वसनीय, स्कैन किए गए और अधिकृत कंटेनर इमेज ही उत्पादन GKE क्लस्टरों में डिप्लॉय किए गए हैं।
भेद्यता स्कैनिंग के लिए Artifact Registry और परिनियोजन नीतियों को लागू करने के लिए Binary Authorization का उपयोग करें जिनके लिए वैध अभिप्रमाण (signatures) की आवश्यकता होती है।
क्यों: यह एक सुरक्षित सॉफ्टवेयर आपूर्ति श्रृंखला बनाता है। Artifact Registry कमजोरियों के लिए स्कैन करता है, और Binary Authorization एक नीति प्रवर्तन बिंदु के रूप में कार्य करता है, क्रिप्टोग्राफिक रूप से यह सत्यापित करता है कि एक इमेज ने सभी आवश्यक जांच पास कर ली है।
एक पारंपरिक VPN का उपयोग किए बिना दूरस्थ कर्मचारियों के लिए आंतरिक वेब एप्लिकेशन तक सुरक्षित, संदर्भ-जागरूक पहुंच प्रदान करें।
पहचान-जागरूक प्रॉक्सी (IAP), नीतियों के लिए Access Context Manager, और डिवाइस की स्थिति के लिए Endpoint Verification के साथ BeyondCorp Enterprise का उपयोग करें।
क्यों: यह एक शून्य-विश्वास मॉडल लागू करता है जहां एक्सेस उपयोगकर्ता पहचान और डिवाइस विश्वास के आधार पर दिया जाता है, न कि नेटवर्क स्थान के आधार पर। IAP प्रत्येक अनुरोध के लिए एक प्रमाणीकरण प्रॉक्सी के रूप में कार्य करता है।
एक विनियमित कार्यभार के लिए एन्क्रिप्शन कुंजियों को FIPS 140-2 लेवल 3 प्रमाणित हार्डवेयर सिक्योरिटी मॉड्यूल (HSM) के भीतर संग्रहीत और संसाधित करने की आवश्यकता होती है।
कुंजियों के लिए `HSM` सुरक्षा स्तर के साथ Cloud KMS का उपयोग करें।
क्यों: Cloud HSM एक पूरी तरह से प्रबंधित सेवा है जो FIPS 140-2 लेवल 3 प्रमाणित HSM प्रदान करती है। इस सुरक्षा स्तर के साथ उत्पन्न कुंजियाँ कभी भी प्लेनटेक्स्ट में HSM सीमा से बाहर नहीं निकलती हैं।
Cloud Storage या BigQuery में संवेदनशील डेटा (जैसे PII) को स्वचालित रूप से खोजें और पहचान छुपाएं।
संवेदनशील डेटा के लिए स्कैन करने और मास्किंग, टोकनाइजेशन (tokenization), या रिडैक्शन (redaction) जैसी डी-आइडेंटिफिकेशन तकनीकों को लागू करने के लिए Cloud Data Loss Prevention (DLP) का उपयोग करें।
क्यों: DLP संवेदनशील डेटा प्रकारों की एक विस्तृत श्रृंखला के लिए पूर्व-निर्मित और कस्टम डिटेक्टर प्रदान करता है, जो कस्टम स्क्रिप्टिंग के बिना स्वचालित और स्केलेबल डेटा सुरक्षा को सक्षम करता है।
कई पहचान प्रदाताओं (जैसे, Okta, Azure AD) के कर्मचारियों को Google अकाउंट बनाए बिना Google Cloud संसाधनों तक पहुंचने की अनुमति दें।
बाहरी पहचान प्रदाताओं को Google Cloud IAM से जोड़ने के लिए Workforce Identity Federation का उपयोग करें।
क्यों: यह आपको अपने मौजूदा पहचान प्रणालियों को सच्चाई के स्रोत के रूप में उपयोग करने की अनुमति देता है, जिससे उपयोगकर्ताओं को सिंक करने या अपने कर्मचारियों के लिए अलग Google पहचान का प्रबंधन करने की आवश्यकता नहीं होती है।
अत्यधिक संवेदनशील डेटा को प्रोसेस करें जहां डेटा उपयोग के दौरान (मेमोरी में) भी एन्क्रिप्टेड रहना चाहिए।
Confidential VMs का उपयोग करें।
क्यों: Confidential Computing समर्पित हार्डवेयर सुविधाओं (AMD SEV) का उपयोग करके प्रोसेसिंग के दौरान डेटा को एन्क्रिप्ट करता है। यह मेमोरी स्क्रैपिंग हमलों से बचाता है और संवेदनशील कार्यभार के लिए सुरक्षा की एक अतिरिक्त परत प्रदान करता है।
एक बड़े डेटा वेयरहाउस के लिए BigQuery लागत और प्रदर्शन को अनुकूलित करें।
तिथि के अनुसार पार्टिशनिंग (partitioning) और अक्सर फ़िल्टर किए गए कॉलम पर क्लस्टरिंग (clustering) लागू करें। डैशबोर्ड के लिए BI Engine और सामान्य, महंगे एग्रीगेशन के लिए मैटेरियलाइज्ड व्यू (materialized views) का उपयोग करें।
क्यों: पार्टिशनिंग और क्लस्टरिंग प्रति क्वेरी स्कैन किए गए डेटा की मात्रा को कम करने के लिए मौलिक हैं, जो सीधे लागत कम करता है और गति में सुधार करता है। BI Engine और MVs अनावश्यक गणनाओं को कम करते हैं।
सबसे कम संभव कंप्यूट लागत के साथ बड़े पैमाने पर, दोष-सहिष्णु बैच प्रोसेसिंग जॉब चलाएं।
Managed Instance Group में Spot VMs का उपयोग करें। सुनिश्चित करें कि एप्लिकेशन दोष-सहिष्णु है और प्रीएम्प्शन (preemptions) को संभाल सकता है।
क्यों: Spot VMs ऑन-डिमांड इंस्टेंस की तुलना में 91% तक की बचत प्रदान करते हैं। वे स्टेटलेस, दोष-सहिष्णु वर्कलोड के लिए आदर्श हैं जिन्हें रोका और पुनः आरंभ किया जा सकता है, जैसे कई बैच प्रोसेसिंग कार्य।
विभिन्न टीमों या विभागों को लागत दृश्यता और जवाबदेही प्रदान करने के लिए FinOps प्रथाओं को लागू करें।
एक संसाधन पदानुक्रम (प्रत्येक टीम के लिए फ़ोल्डर) का उपयोग करें, लागत आवंटन के लिए लेबल लागू करें, और विश्लेषण और Looker Studio में विज़ुअलाइज़ेशन के लिए विस्तृत बिलिंग डेटा को BigQuery में एक्सपोर्ट करें।
क्यों: यह संयोजन संसाधनों को व्यवस्थित करने, लेबल के माध्यम से लागतों को बारीक रूप से ट्रैक करने और शोबैक/चार्जबैक के लिए कस्टम, टीम-विशिष्ट डैशबोर्ड बनाने का एक संरचित तरीका प्रदान करता है।
परिवर्तनीय लोड वाले एप्लिकेशनों के लिए GKE क्लस्टर लागत और प्रदर्शन को अनुकूलित करें।
मेट्रिक्स के आधार पर पॉड्स को स्केल करने के लिए Horizontal Pod Autoscaler (HPA) और आवश्यकतानुसार नोड्स जोड़ने/हटाने के लिए Cluster Autoscaler का उपयोग करें।
क्यों: यह दो-स्तरीय ऑटोस्केलिंग दृष्टिकोण सुनिश्चित करता है कि एप्लिकेशन (पॉड्स) और इंफ्रास्ट्रक्चर (नोड्स) दोनों मांग के साथ तालमेल बिठाते हैं, जिससे ओवर-प्रोविजनिंग को रोका जा सकता है और प्रदर्शन सुनिश्चित किया जा सकता है।
एक ML प्रशिक्षण कार्य कम GPU उपयोग (<30%) दिखाता है, जो एक बाधा का संकेत देता है।
डेटा इनपुट पाइपलाइन का निदान और अनुकूलन करें। I/O प्रदर्शन में सुधार के लिए प्रीफेचिंग और समानांतर रीड के साथ `tf.data` या Cloud Storage FUSE का उपयोग करें।
क्यों: कम GPU उपयोग लगभग हमेशा डेटा I/O बाधा होती है। GPU डेटा के अगले बैच की प्रतीक्षा करते समय निष्क्रिय रहता है। प्रशिक्षण दक्षता में सुधार के लिए डेटा लोडिंग का अनुकूलन पहला कदम है।
इंटरनेट पर या क्षेत्रों में डेटा परोसने से होने वाली उच्च नेटवर्क निर्गम (egress) लागत को कम करें।
स्टैटिक कंटेंट को कैश करने के लिए Cloud CDN का उपयोग करें। अंतर-क्षेत्रीय ट्रैफिक के लिए, गैर-विलंबता-संवेदनशील वर्कलोड के लिए Standard Network Service Tier का उपयोग करें।
क्यों: CDN एज से डेटा प्रदान करता है, जो मूल से निर्गम की तुलना में सस्ता है। Standard Tier Google के प्रीमियम नेटवर्क के बजाय सार्वजनिक इंटरनेट पर ट्रैफिक को रूट करता है, जो थोक डेटा ट्रांसफर के लिए कम लागत प्रदान करता है।
विकास और परीक्षण VMs के लिए लागत कम करें जिनकी आवश्यकता केवल व्यावसायिक घंटों के दौरान होती है।
Cloud Scheduler का उपयोग Cloud Functions को ट्रिगर करने के लिए करें जो पूर्वनिर्धारित शेड्यूल पर इंस्टेंस को स्वचालित रूप से शुरू और बंद करते हैं।
क्यों: यह "इंस्टेंस शेड्यूलिंग" पैटर्न संसाधनों को उपयोग में न होने पर बंद करने की प्रक्रिया को स्वचालित करता है, जिससे गैर-उत्पादन वातावरण के लिए लागत में काफी कमी आती है।
एक महत्वपूर्ण एप्लिकेशन को जोनल विफलता के मामले में स्वचालित फेलओवर के साथ एक रिलेशनल डेटाबेस की आवश्यकता है।
Cloud SQL इंस्टेंस को High Availability (HA) विकल्प के साथ कॉन्फ़िगर करें।
क्यों: HA कॉन्फ़िगरेशन एक अलग ज़ोन में सिंक्रोनस प्रतिकृति के साथ एक स्टैंडबाय इंस्टेंस बनाता है। प्राथमिक इंस्टेंस या ज़ोन विफलता के मामले में, फेलओवर स्वचालित होता है और आमतौर पर 60 सेकंड से कम समय लगता है।
अनुत्तरदायी या विफल Compute Engine इंस्टेंस का स्वचालित रूप से पता लगाएं और उनसे उबरें।
Managed Instance Group (MIG) के भीतर इंस्टेंस डिप्लॉय करें और एप्लिकेशन-आधारित हेल्थ चेक के साथ ऑटोहीलिंग कॉन्फ़िगर करें।
क्यों: MIG ऑटोहीलिंग प्रत्येक इंस्टेंस पर एप्लिकेशन को सक्रिय रूप से जांचता है। यदि एप्लिकेशन अपने हेल्थ चेक में विफल रहता है, तो MIG स्वचालित रूप से इंस्टेंस को फिर से बनाता है, जिससे सेवा विश्वसनीयता सुनिश्चित होती है।
RTO < 1 घंटे और RPO < 15 मिनट के साथ एक आपदा रिकवरी योजना डिज़ाइन करें।
एक माध्यमिक क्षेत्र में एक वार्म स्टैंडबाय लागू करें। Cloud SQL क्रॉस-रीजन रेप्लिका, बहु-क्षेत्रीय Cloud Storage, और कंप्यूट के लिए पूर्व-कॉन्फ़िगर इंस्टेंस टेम्पलेट का उपयोग करें।
क्यों: यह दृष्टिकोण लागत और रिकवरी समय को संतुलित करता है। RPO को पूरा करने के लिए डेटा को लगभग-तुल्यकालिक रूप से प्रतिकृति किया जाता है, और RTO को पूरा करने के लिए त्वरित स्केल-अप की अनुमति देने के लिए न्यूनतम इंफ्रास्ट्रक्चर चल रहा होता है (वार्म)।
त्वरित समस्या निवारण को सक्षम करने के लिए माइक्रोसर्विसेज एप्लिकेशन के लिए व्यापक ऑब्जर्वेबिलिटी लागू करें।
कोरिलेशन IDs के साथ संरचित लॉगिंग, वितरित ट्रेसिंग के लिए Cloud Trace, मेट्रिक्स के लिए Cloud Monitoring, और स्वचालित त्रुटि समूहीकरण के लिए Cloud Error Reporting का उपयोग करें।
क्यों: लॉग, ट्रेस और मेट्रिक्स (ऑब्जर्वेबिलिटी के "तीन स्तंभ") का संयोजन आवश्यक है। कई सेवाओं में एकल अनुरोध का पालन करने के लिए कोरिलेशन IDs और वितरित ट्रेसिंग महत्वपूर्ण हैं।
एक माइक्रोसर्विस में विफलता को पूरे एप्लिकेशन में कैस्केडिंग विफलता पैदा करने से रोकें।
सर्किट ब्रेकर, एक्सपोनेंशियल बैकऑफ़ के साथ रिट्राई, और प्रत्येक सेवा-से-सेवा संचार बिंदु पर आक्रामक टाइमआउट जैसे लचीलेपन पैटर्न लागू करें।
क्यों: ये पैटर्न विफलताओं को अलग करते हैं। एक सर्किट ब्रेकर एक विफल सेवा के लिए कॉल को रोकता है, जिससे कॉलिंग सेवा को अपने संसाधनों को समाप्त करने और बदले में विफल होने से रोका जा सकता है।
नए डिप्लॉयमेंट के कारण होने वाले उत्पादन आउटेज के जोखिम को कम करने के लिए SRE सर्वोत्तम प्रथाओं को लागू करें।
परिवर्तनों को धीरे-धीरे रोल आउट करने के लिए कैनरी डिप्लॉयमेंट, रिलीज़ से डिप्लॉयमेंट को अलग करने के लिए फीचर फ़्लैग, और SLO मॉनिटरिंग के आधार पर स्वचालित रोलबैक ट्रिगर का उपयोग करें।
क्यों: ये प्रथाएं एक खराब डिप्लॉयमेंट के "ब्लास्ट रेडियस" को सीमित करती हैं। कैनरी पहले उपयोगकर्ताओं के एक छोटे से उपसमूह को नया संस्करण उजागर करते हैं, और स्वचालित रोलबैक Mean Time to Recovery (MTTR) को कम करता है।
विश्वसनीयता के साथ फीचर वेलोसिटी को संतुलित करने के लिए SRE त्रुटि बजट का उपयोग करें।
एक त्रुटि बजट नीति परिभाषित करें: जब बजट लगभग समाप्त हो जाता है, तो नई फीचर डिप्लॉयमेंट को फ्रीज करें और विश्वसनीयता में सुधार करने वाले कार्य को प्राथमिकता दें।
क्यों: त्रुटि बजट ट्रेड-ऑफ निर्णय लेने के लिए एक डेटा-संचालित तंत्र है। यह टीमों को जोखिम लेने की अनुमति देता है जब बजट स्वस्थ होता है और स्थिरिता पर ध्यान केंद्रित करने को मजबूर करता है जब ऐसा नहीं होता है।
Cloud Spanner का उपयोग करने वाले एक विश्व स्तर पर वितरित एप्लिकेशन को कुछ क्षेत्रों में उच्च राइट विलंबता का अनुभव होता है।
एप्लिकेशन के राइट पैटर्न का विश्लेषण करें और Spanner इंस्टेंस के लीडर क्षेत्र को अधिकांश राइट ऑपरेशंस के भौगोलिक रूप से करीब होने के लिए कॉन्फ़िगर करें।
क्यों: Spanner में, सभी राइट्स कंसिस्टेंसी सुनिश्चित करने के लिए लीडर क्षेत्र के माध्यम से रूट किए जाते हैं। राइट्स के प्राथमिक स्रोत के करीब लीडर क्षेत्र रखने से उन ट्रांजैक्शन के लिए नेटवर्क विलंबता कम हो जाती है।