क्लाउड कम्प्युटिङ व्याख्या गरिएको: तपाईंले जान्नै पर्ने ११ वास्तुकला अवधारणाहरू (4K मास्टरक्लास)।

यो भिडियोले के समेट्छ

• - वास्तुकला पर्खाल र मास्टर ब्लुप्रिन्ट
• - ०१. ठाडो बनाम तेर्सो स्केलिंग
• - ०२. लोड ब्यालेन्सिङ वास्तुकला (L4 बनाम L7 र स्वास्थ्य जाँच)
• - ०३. अटोस्केलिंग र लोच
• - ०४. सर्भरलेस (FaaS र फायरक्र्याकर माइक्रोभीएम)

अनुवादित ट्रान्सक्रिप्ट

मूल अंग्रेजी कथाबाट अनुवादित। उपलब्ध अडियो र क्याप्सनहरू YouTube द्वारा नियन्त्रित हुन्छन्।

- वास्तुकला पर्खाल र मास्टर ब्लुप्रिन्ट

0:00 प्रत्येक सफ्टवेयर इन्जिनियरले अन्ततः क्लाउड आर्किटेक्चरको पर्खाल सामना गर्छ। तपाईं आफ्नो ल्यापटपमा एप्लिकेसन बनाउनुहुन्छ, त्यसलाई उत्पादनमा धकेल्नुहुन्छ, र वास्तविक प्रयोगकर्ताहरू आउने बित्तिकै, सर्भरहरू क्र्यास हुन्छन्, डाटाबेस जडानहरू सकिन्छ, र तपाईंको AWS बिल फोन नम्बर जस्तो देखिन्छ। अधिकांश विकासकर्ताहरूले क्लाउड इन्जिनियरिङलाई तीन सय फरक AWS उत्पादन एक्रोनिमहरू कण्ठ गरेर समाधान गर्ने प्रयास गर्छन्। तर वास्तविक क्लाउड कम्प्युटिङ विक्रेता सूची कण्ठ गर्ने बारे होइन: यो एघार मौलिक वास्तुकलाको प्रिमिटिभहरूमा आधारित छ।

0:34 यस मास्टरक्लासमा, हामी सम्पूर्ण इन्टरप्राइज ब्लुप्रिन्टमा हिंड्नेछौं: स्केलिंग र लोड ब्यालेन्सिङदेखि सर्भरलेस, घटना-संचालित डिकपलिंग, भण्डारण पदानुक्रम, र क्लाउड नेटवर्किङसम्म। यी एघार अवधारणाहरूमा निपुण हुनुहोस्, र तपाईं AWS, GCP, वा Azure मा कुनै पनि ब्याकेन्ड डिजाइन गर्न सक्नुहुन्छ। यो The Daily Diff, पर्दा पछाडि।

- ०१. ठाडो बनाम तेर्सो स्केलिंग

0:57 अवधारणा नम्बर एक: स्केलिंग। जब तपाईंको एप्लिकेसनले ट्राफिक वृद्धि अनुभव गर्छ, तपाईंसँग भार ह्यान्डल गर्ने दुई मौलिक रूपमा फरक तरिकाहरू छन्: ठाडो स्केलिंग, वा तेर्सो स्केलिंग। ठाडो स्केलिंग, वा स्केलिंग अप, भनेको तपाईंको मौजूदा मेसिन लिने र थप स्रोतहरू थप्नु हो: चार सीपीयू कोरबाट बत्तीसमा अपग्रेड गर्ने, वा बत्तीस गिगाबाइट र्यामलाई एक सय अठ्ठाईसमा साट्ने। ठाडो स्केलिंगलाई शून्य वास्तुकला परिवर्तनहरू आवश्यक पर्छ: तपाईंको कोड

1:28 र डाटाबेस ठ्याक्कै उस्तै रहन्छन्। तर यसले क्रूर हार्डवेयर सीमामा पुग्छ। विश्वमा कुनै पनि एक मेसिनमा दश हजार सीपीयू कोर छैन, र शीर्ष-स्तरीय उदाहरणहरूले घातांक मूल्य प्रिमियम बोक्छन्। तेर्सो स्केलिंग, वा स्केलिंग आउट, भनेको तपाईंको सर्भरहरू साना र कमोडिटी-मूल्यमा राख्नु हो, तर राउटर पछाडि समानान्तरमा धेरै उदाहरणहरू चलाउनु हो। यदि एउटा उदाहरण क्र्यास भयो भने, बाँकी नोडहरूले शून्य डाउनटाइममा ट्राफिक अवशोषित गर्छन्। तेर्सो स्केलिंगको सुनौलो नियम

2:01 स्टेटलेसनेस हो: तपाईंको एप्लिकेसन सर्भरहरूले प्रयोगकर्ता सत्रहरू, अपलोड गरिएका फाइलहरू, वा राज्यलाई उनीहरूको स्थानीय डिस्कमा भण्डारण गर्न सक्दैनन्। राज्य बाह्य डाटाबेस वा क्यासमा रहनुपर्छ, कुनै पनि नोडलाई कुनै पनि प्रयोगकर्ता अनुरोध ह्यान्डल गर्न अनुमति दिँदै।

- ०२. लोड ब्यालेन्सिङ वास्तुकला (L4 बनाम L7 र स्वास्थ्य जाँच)

2:17 अवधारणा नम्बर दुई: लोड ब्यालेन्सिङ। तेर्सो स्केलिंग कागजमा राम्रो सुनिन्छ, तर यसले तत्काल समस्या उत्पन्न गर्छ: जब दश हजार प्रयोगकर्ताहरू तपाईंको डोमेन नाममा आउँछन्, कुन विशिष्ट सर्भरले उनीहरूको ट्राफिक प्राप्त गर्छ? एक लोड ब्यालेन्सर सार्वजनिक इन्टरनेट र तपाईंको निजी ब्याकेन्ड क्लस्टरको बीचमा बस्ने रिभर्स प्रोक्सीको रूपमा कार्य गर्दछ। यसले आगमन TCP वा HTTP जडानहरू स्वीकार गर्दछ र तपाईंको स्वस्थ उदाहरणहरूमा अनुरोधहरू वितरण गर्दछ।

2:47 लोड ब्यालेन्सरहरू दुई प्राथमिक नेटवर्क तहमा सञ्चालन हुन्छन्। लेयर ४ नेटवर्क लोड ब्यालेन्सरहरू यातायात तहमा सञ्चालन हुन्छन्, आईपी ठेगाना र पोर्टको आधारमा कच्चा TCP र UDP प्याकेटहरू राउट गर्दै माइक्रोसेकेन्ड विलम्बता र प्रति सेकेन्ड लाखौं अनुरोधहरू सहित। लेयर ७ एप्लिकेसन लोड ब्यालेन्सरहरूले HTTP प्रोटोकललाई नै निरीक्षण गर्छन्: URL पथहरू, अनुरोध हेडरहरू, कुकीहरू, र HTTP विधिहरू पढ्छन्। यसले पथ-आधारित राउटिङ सक्षम गर्दछ: स्ल्याश-एपीआई अनुरोधहरू तपाईंको ब्याकेन्ड क्लस्टरमा पठाउने र स्ल्याश-स्टेटिक अनुरोधहरू

3:25 एक वस्तु भण्डारमा पठाउने। महत्वपूर्ण रूपमा, लोड ब्यालेन्सरहरूले सक्रिय स्वास्थ्य जाँचहरू गर्छन्। प्रत्येक केही सेकेन्डमा, ब्यालेन्सरले प्रत्येक उदाहरणमा स्वास्थ्य एन्डपोइन्ट पिंग गर्छ। यदि एउटा उदाहरणले तीन लगातार पाँच सय त्रुटिहरू फ्याँक्यो वा प्रतिक्रिया दिन असफल भयो भने, यसलाई शून्य ड्रप गरिएको अनुरोधहरू सहित पूलबाट स्वचालित रूपमा हटाइन्छ।

- ०३. अटोस्केलिंग र लोच

3:45 अवधारणा नम्बर तीन: अटोस्केलिंग। यदि तपाईंको वेब एपलाई बिहान तीन बजे दुई सर्भर चाहिन्छ, तर दिउँसोको सुरुवातमा बीस सर्भर चाहिन्छ भने, क्लाउड कन्सोलमा म्यानुअल रूपमा बटनहरू क्लिक गर्नु डाउनटाइम र दिवालियापनको ग्यारेन्टी गरिएको मार्ग हो। अटोस्केलिंगले तेर्सो सर्भर पूलहरूमा गतिशील लोच ल्याउँछ। एक अटो स्केलिंग समूहले औसत सीपीयू उपयोगिता, नेटवर्क आई-ओ, वा कतार ब्याकलॉग गहिराइ जस्ता प्रदर्शन मेट्रिक्स निगरानी गर्दछ। जब औसत सीपीयू परिभाषित थ्रेसहोल्ड पार गर्छ — भन्नुहोस्,

4:19 लगातार तीन मिनेटको लागि सत्तरी प्रतिशत — अटोस्केलरले स्वचालित रूपमा नयाँ भर्चुअल मेसिनहरू सुरु गर्छ, तिनीहरूलाई तपाईंको लोड ब्यालेन्सरमा दर्ता गर्छ, र ट्राफिक राउट गर्न सुरु गर्छ। उस्तै महत्त्वपूर्ण स्केलिंग इन हो: जब ट्राफिक लहर घट्छ, अटोस्केलरले अतिरिक्त उदाहरणहरू बन्द गर्छ ताकि तपाईं निष्क्रिय कम्प्युटको लागि भुक्तान गर्न रोक्नुहुन्छ। फ्ल्यापिङ रोक्नको लागि — जहाँ सर्भरहरू छिटो सिर्जना गरिन्छ र अन्तहीन थ्र्यासिंग लूपमा नष्ट हुन्छ — क्लाउड आर्किटेक्टहरूले कन्फिगर गर्छन् कूलडाउन अवधिहरू। अवधारणा नम्बर चार: सर्भरलेस।

- ०४. सर्भरलेस (FaaS र फायरक्र्याकर माइक्रोभीएम)

4:53 वर्षौंदेखि, मार्केटिङ टोलीहरूले सर्भरलेसलाई जादुई कोडको रूपमा बेचेका छन् आकाशमा चलिरहेको। वास्तवमा, सर्भरलेसले अझै पनि सर्भरहरू प्रयोग गर्दछ — तर तपाईंसँग स्वामित्व छैन, कुनै कोड नचल्दा तिनीहरूलाई प्याच गर्ने वा तिनीहरूको लागि भुक्तानी गर्ने। AWS Lambda वा Google Cloud Functions जस्ता Function-as-a-Service सँग, तपाईंले एउटा स्ट्यान्डअलोन ह्यान्डलर फंक्शन लेख्नुहुन्छ। जब HTTP अनुरोध, S3 फाइल अपलोड, वा डेटाबेस परिवर्तन हुन्छ, क्लाउड रनटाइमले एक क्षणिक

5:23 फायरक्राकर जस्ता माइक्रो-भर्चुअल-मेसिन पाँच मिलिसेकेन्ड भित्र बुट गर्छ। तपाईंको कोड एक्जिक्युट हुन्छ, प्रतिक्रिया फर्काउँछ, र बन्द हुन्छ। यदि कसैले तीन महिनासम्म तपाईंको वेबसाइट भ्रमण गर्दैन भने, तपाईंको कम्प्युट बिल ठ्याक्कै शून्य डलर र शून्य सेन्ट हुन्छ। यदि दस लाख प्रयोगकर्ताहरूले एकैसाथ हिट गर्छन् भने, प्रदायकले दस लाख एकैसाथ माइक्रो-भर्चुअल-मेसिनहरू घुमाउँछ। इन्जिनियरिङका ट्रेड-अफहरू वास्तविक हुन्छन्: कोल्ड स्टार्ट ताजा रनटाइमहरू घुमाउँदा ढिलाइ, Lambda मा कडा पन्ध्र मिनेटको कार्यान्वयन सीमा र कडा स्टेटलेसनेस।

5:55 सर्भरलेस घटना पाइपलाइनहरू र छिटपुट API हरूका लागि अपराजेय छ, तर लगातार वेबसकेटहरू वा बहु-घण्टा प्रशिक्षण रनहरूका लागि खराब छ।

- ०५. घटना-संचालित वास्तुकला (EDA र डिकपलिंग)

6:05 अवधारणा नम्बर पाँच: घटना-संचालित वास्तुकला, वा EDA। परम्परागत वास्तुकलाहरूमा, सेवाहरू समकालिक रूपमा सञ्चार गर्छन्। तपाईंको चेकआउट सेवाले भुक्तानीलाई कल गर्छ, भुक्तानीले सूचीलाई कल गर्छ, सूचीले धोखाधडीलाई कल गर्छ, र धोखाधडीले इमेललाई कल गर्छ। यसले विनाशको समकालिक झरना सिर्जना गर्दछ। यदि तेस्रो-पक्ष इमेल प्रदायकले नेटवर्कमा अवरोध अनुभव गर्छ र दस सेकेन्ड प्रतिक्रिया दिन लाग्छ भने, तपाईंको ग्राहकको सम्पूर्ण चेकआउट अनुरोध टाइमआउट हुन्छ र त्रुटि देखाउँछ। घटना-संचालित वास्तुकलामा, सेवाहरू पूर्ण रूपमा डिकपल गरिएका हुन्छन्।

6:37 जब एक ग्राहकले 'किन्नुहोस्' मा क्लिक गर्छ, चेकआउट सेवाले डाउनस्ट्रीम सेवाहरूलाई कल गर्दैन। यसले केवल 'अर्डरप्लेस्ड' नामक घटनालाई केन्द्रीय इभेन्ट बस जस्तै Amazon EventBridge वा SNS विषयमा प्रकाशित गर्छ। चेकआउट पचास मिलिसेकेन्डमा पूरा हुन्छ। भुक्तानी, सूची कटौती, र इमेल रसिदहरूका लागि डाउनस्ट्रीम कार्यकर्ताहरू आफ्नै समर्पित SQS क्यूहरूबाट स्वतन्त्र रूपमा सन्देशहरू तान्छन्। यदि इमेल सेवा एक घण्टाको लागि बन्द हुन्छ भने, सन्देशहरू सुरक्षित रूपमा क्यूमा बफर हुन्छन् र एउटा पनि अर्डर छुट्दैन।

- ०६. कन्टेनर अर्केस्ट्रेसन (डकर र कुबर्नेटिज)

7:13 अवधारणा नम्बर छ: कन्टेनर अर्केस्ट्रेसन। Docker ले प्याकेजिङको समस्या हल गर्यो: यसले तपाईंको अनुप्रयोग कोडलाई बेर्छ, प्रणाली लाइब्रेरीहरू, कन्फिगरेसन, र रनटाइमलाई एक अपरिवर्तनीय छविमा राख्छ जुन तपाईंको MacBook र क्लाउडमा समान रूपमा चल्छ। तर एउटा कन्टेनर प्याकेज गर्न सजिलो छ। पचास भौतिक भर्चुअल मेसिनहरूमा पाँच सय कन्टेनरहरू चलाउनु इन्जिनियरिङमा समस्या हुन्छ। त्यसैले Kubernetes र AWS ECS जस्ता कन्टेनर अर्केस्ट्रेटहरू

7:41 अवस्थित छन्। एक अर्केस्ट्रेटरले नियन्त्रण प्लेन प्रदान गर्दछ: एक API सर्भर, एक etcd स्टेट स्टोर, र एक बुद्धिमान शेड्युलर। तपाईं आफ्नो वांछित अवस्था घोषणा गर्नुहुन्छ: मलाई मेरो प्रमाणीकरण सेवाका दस प्रतिकृतिहरू चाहिन्छ, प्रत्येकमा दुई गिगाबाइट र्यामका साथ। शेड्युलरले क्लस्टरको निरीक्षण गर्छ, खाली मेमोरी भएका नोडहरूमा पोडहरू राख्छ, आन्तरिक नेटवर्किङ कन्फिगर गर्छ, र वास्तविकतालाई निरन्तर मिलाउँछ। यदि कुनै नोडले हार्डवेयर विफलता भोग्छ भने, Kubernetes ले त्यसको हानि पत्ता लगाउँछ र तुरुन्तै सबै विस्थापित पोडहरूलाई

- ०७. ४ क्लाउड भण्डारणका स्तम्भहरू (S3, EBS, DBs र Redis)

8:16 स्वस्थ नोडहरूमा पुन: तालिकाबद्ध गर्छ। अवधारणा नम्बर सात: क्लाउड भण्डारण पदानुक्रम। शुरुआतीहरूले प्रायः क्लाउड भण्डारणलाई एउटा मात्र बाल्टिनको रूपमा लिन्छन् जहाँ तपाईं फाइलहरू डम्प गर्नुहुन्छ। उत्पादन वास्तुकलामा, भण्डारणलाई पहुँच ढाँचा र विलम्बतामा आधारित चार फरक स्तम्भहरूमा विभाजित गरिन्छ। पहिलो वस्तु भण्डारण हो, जस्तै Amazon S3 वा Google Cloud भण्डारण। तपाईं HTTP REST API हरू प्रयोग गरेर फाइलहरू पहुँच गर्नुहुन्छ साधारण PUT र GET कलहरू प्रयोग गरेर। यसले प्रति महिना प्रति गिगाबाइट दुई सेन्टमा अनन्त क्षैतिज क्षमता प्रदान गर्दछ,

8:49 जसले यसलाई भिडियो, प्रयोगकर्ता अपलोड, लगहरू, र ब्याकअपहरूको लागि आदर्श बनाउँछ। दोस्रो ब्लक भण्डारण हो, जस्तै Amazon EBS। यी उच्च-गति इन्टरकनेक्टहरू मार्फत सिधा एक विशिष्ट भर्चुअल मेसिनमा माउन्ट गरिएका भर्चुअल हार्ड ड्राइभहरू हुन्। उच्च-गति इन्टरकनेक्टहरू मार्फत। तिनीहरू ext4 जस्ता मानक फाइल प्रणालीहरूमा ढाँचाबद्ध हुन्छन्, डेटाबेस इन्जिनहरूले आवश्यक पर्ने द्रुत अनियमित पढ्ने र लेख्ने पहुँचलाई समर्थन गर्दै। तेस्रो व्यवस्थित डेटाबेसहरू हुन्: RDS मा PostgreSQL जस्ता रिलेशनल इन्जिनहरूले ACID लेनदेनहरू र जटिल जोडहरू प्रदान गर्दछन्, र DynamoDB जस्ता NoSQL इन्जिनहरूले एकल-अंकको

9:21 मिलिसेकेन्ड विलम्बता प्रदान गर्दछन् विशाल स्तरमा। र चौथो Redis जस्ता इन-मेमोरी क्याचहरू हुन्। र्यामबाट डाटा पढ्न मिलिसेकेन्डको सट्टा माइक्रोसेकेन्ड लाग्छ। क्याचहरू तपाईंको डेटाबेसको अगाडि बस्छन्, यसलाई दोहोर्याइएको पढ्ने ट्राफिकबाट बचाउँछन् र अस्थिर प्रयोगकर्ता सत्र टोकनहरू व्यवस्थापन गर्छन्।

- ०८. उच्च उपलब्धता र नाइनहरू (बहु-AZ फेलओभर)

9:44 अवधारणा नम्बर आठ: उच्च उपलब्धता, वा HA। उपलब्धताले एउटा प्रश्नको जवाफ दिन्छ: तपाईंको अनुप्रयोग कति प्रतिशत समयसम्म सञ्चालनमा छ र प्रयोगकर्ताहरूद्वारा पहुँचयोग्य छ? उद्यम सम्झौताहरूमा, उपलब्धतालाई नाइनमा मापन गरिन्छ। दुई नाइन, वा ९९% उपलब्धताले प्रत्येक वर्ष साढे तीन दिन भन्दा बढी डाउनटाइमको अनुमति दिन्छ। चार नाइनले अनुमति प्राप्त डाउनटाइमलाई ५२ मिनेटमा झार्छ, र पाँच नाइनले प्रति वर्ष जम्मा पाँच मिनेट मात्र डाउनटाइमको अनुमति दिन्छ।

10:15 उच्च उपलब्धता प्राप्त गर्न, तपाईंले त्रुटि डोमेनहरूमा एकल विफलता बिन्दुहरू हटाउनुपर्छ। त्रुटि डोमेनहरूमा। क्लाउडमा, यसको अर्थ बहु उपलब्धता क्षेत्रहरूमा डिप्लोय गर्नु हो। एक उपलब्धता क्षेत्र एकल र्याक होइन: यो एक वा अधिक फरक भौतिक डाटा सेन्टरहरू हुन् जुन माइल टाढा छन् र स्वतन्त्र पावर र कूलिंग छन्। जोन ए र जोन बी मा सक्रिय उदाहरणहरू सिङ्क्रोनस डेटाबेस प्रतिकृतिसँग चलाएर, बिजुलीको स्ट्राइक वा फाइबर कटले सम्पूर्ण भौतिक सुविधालाई डाउन गर्दा स्वचालित फेलओभर हुन्छ

10:50 मानव हस्तक्षेप बिना तीस सेकेन्डमा।

- ०९. टिकाऊपन बनाम उपलब्धता (११ नाइनहरू अपटाइम किन होइन)

10:53 अवधारणा नम्बर नौ: स्थायित्व बनाम उपलब्धता। यो क्लाउड वास्तुकला अन्तर्वार्ताहरूमा सबैभन्दा सामान्य वैचारिक जाल हो। इन्जिनियरहरू प्रायः शब्दहरू एकअर्काको सट्टामा प्रयोग गर्छन्, तर तिनीहरूले पूर्ण रूपमा फरक गुणहरू मापन गर्छन्। उपलब्धताले अपटाइम मापन गर्छ: के म मेरो डाटा पढ्न वा लेख्नको लागि एपीआई कल गर्न सक्छु अहिले नै? स्थायित्वले संरक्षण मापन गर्छ: के मेरो डाटा स्थायी बिट रोट, भ्रष्टाचार, वा दस वर्ष भन्दा बढी विनाश बिना बाँच्नेछ?

11:24 अमेजन S3 Standard हेर्नुहोस्। यसको सेवा स्तर सम्झौताले ९९.९% उपलब्धता प्रदान गर्दछ, जसले हरेक महिना लगभग ४३ मिनेटको डाउनटाइमलाई अनुमति दिन्छ जहाँ एपीआई अनुरोधले पाँच सय त्रुटि फर्काउन सक्छ। तर S3 ले ११ नौको स्थायित्वको प्रतिज्ञा गर्दछ: ९९ दशमलव नौ नौ नौ नौ नौ नौ नौ नौ नौ प्रतिशत। नौ नौ प्रतिशत। यदि तपाईंले S3 मा एक करोड फाइलहरू भण्डारण गर्नुभयो भने, तपाईंले तथ्याङ्कीय रूपमा हरेक दश हजार

11:56 वर्षमा एउटा फाइल गुमाउने अपेक्षा गर्न सक्नुहुन्छ। S3 ले इरेजर-कोडिङ वस्तुहरू र कम्तिमा तीन भौगोलिक रूपमा छुट्याइएका डाटा सुविधाहरूमा खण्डहरू प्रतिकृति गरेर यो हासिल गर्दछ। प्रमुख क्षेत्रीय नेटवर्क अवरोधको समयमा, S3 अस्थायी रूपमा अनुपलब्ध हुन सक्छ, तर तपाईंको डाटा कहिल्यै नष्ट हुँदैन।

- १०. इन्फ्रास्ट्रक्चर एज कोड (टेराफर्म बनाम कन्सोल ड्रिफ्ट)

12:14 अवधारणा नम्बर दश: कोडको रूपमा पूर्वाधार, वा IaC। क्लाउड कम्प्युटिङको प्रारम्भिक दिनहरूमा, इन्जिनियरहरू AWS वेब व्यवस्थापन कन्सोलमा लगइन गर्थे र भर्चुअल मेसिनहरू सिर्जना गर्न, सबनेटहरू कन्फिगर गर्न, र सुरक्षा समूहहरू संलग्न गर्न म्यानुअल रूपमा क्लिक गर्थे। उद्योगले यसलाई ClickOps भन्छ, र उत्पादनमा, यो पूर्ण विपत्ति हो। म्यानुअल कन्सोल परिवर्तनहरूको कुनै अडिट ट्रेल छैन, कुनै रोलब्याक मेकानिजम छैन, र अनिवार्य रूपमा स्टेजिंग र उत्पादन वातावरणहरू बीच कन्फिगरेसन विचलन निम्त्याउँछ। Terraform, OpenTofu, Pulumi, वा AWS CDK

12:48 जस्ता कोड उपकरणहरूको रूपमा पूर्वाधारको साथ, तपाईंले Git मा भण्डारण गरिएका घोषणात्मक कन्फिगरेसन फाइलहरूमा तपाईंको सम्पूर्ण क्लाउड वास्तुकला परिभाषित गर्नुहुन्छ। खुला पोर्ट वा डाटाबेस प्रतिकृतिमा हरेक परिवर्तन पुल अनुरोध र साथी समीक्षा मार्फत जान्छ। Terraform योजना चलाउँदा केही पनि नछोइकन सटीक एपीआई भिन्नताको पूर्वावलोकन गर्दछ, र तपाईंको उत्पादन स्ट्याकको समान प्रतिकृति सेटअप गर्न चार हप्ताको सट्टा चार मिनेट लाग्छ। अवधारणा नम्बर एघार: क्लाउड नेटवर्किङ र भर्चुअल निजी क्लाउडहरू।

- ११. क्लाउड नेटवर्किङ (VPC, सबनेट, NAT र सुरक्षा समूह)

13:20 जब तपाईं क्लाउडमा सर्भरहरू डिप्लोय गर्नुहुन्छ, तिनीहरू कच्चा सार्वजनिक इन्टरनेटमा खुला बस्दैनन्। तिनीहरू VPC भनिने सफ्टवेयर-परिभाषित पृथक सीमा भित्र बस्छन्। तपाईंको VPC भित्र, तपाईंले १०.०.०.०/१६ जस्तो निजी आईपी ठेगाना स्थान छुट्याउनुहुन्छ, र यसलाई सार्वजनिक र निजी सबनेटहरूमा विभाजन गर्नुहुन्छ। सार्वजनिक सबनेटमा इन्टरनेट गेटवेमा सीधा मार्ग हुन्छ। यसले तपाईंको एप्लिकेसन लोड ब्यालेन्सर र NAT गेटवेहरू जस्ता सार्वजनिक-सामुन्नेका सम्पत्तिहरू राख्छ।

13:51 यो तपाईंको नेटवर्कको एक मात्र भाग हो जसमा सार्वजनिक आईपी ठेगानाहरू छन्। तपाईंको अनुप्रयोग सर्भरहरू र उत्पादन डाटाबेसहरू निजी सबनेटहरूमा बस्छन् जसमा कुनै सार्वजनिक आईपीहरू छैनन् र इन्टरनेटबाट शून्य इनबाउन्ड मार्गहरू छन्। जब तपाईंको ब्याकेन्ड सर्भरहरूलाई सुरक्षा अपडेटहरू डाउनलोड गर्न आवश्यक हुन्छ, तिनीहरूको आउटबाउन्ड ट्राफिक सार्वजनिक सबनेटमा NAT गेटवे मार्फत मार्गहरू। हरेक उदाहरणलाई घेरेर सुरक्षा समूहहरू छन्: राज्यविहीन भर्चुअल फायरवालहरू जसले न्यूनतम विशेषाधिकारको सिद्धान्त लागू गर्छन्। तपाईंको डाटाबेस सुरक्षा समूहले पोर्ट 5432 मा तपाईंको अनुप्रयोग

- १२. पूर्ण इन्टरप्राइज ब्लुप्रिन्ट र फैसला

14:28 सर्भरहरूको सुरक्षा समूहबाट मात्र जडानहरू स्वीकार गर्दछ, बाहिर घुसपैठ गणितीय रूपमा असम्भव बनाउँछ। जब तपाईं बाहिर जुम गर्नुहुन्छ, यी एघार आदिमहरू एक सुसंगत प्रणालीमा जडान हुन्छन्। तपाईंको DNS सार्वजनिक सबनेटमा लोड ब्यालेन्सरमा मार्गहरू गर्दछ, स्वतःस्केलिङ समूहहरूले धेरै उपलब्धता क्षेत्रहरूमा ट्राफिक वृद्धिहरू ह्यान्डल गर्छन्, घटना बसहरूले ब्याकेन्ड कामदारहरूलाई अलग गर्छन्, र तपाईंको सम्पूर्ण स्ट्याक कोडको रूपमा पूर्वाधार प्रयोग गरेर Git बाट डिप्लोय गरिएको छ। आजको मास्टरक्लास निर्णय: SHIP IT।

15:02 सयौं क्लाउड मार्केटिङ एक्रोनियमहरू याद गर्न बन्द गर्नुहोस्। यी एघार वास्तुकला ढाँचाहरूमा मास्टर गर्नुहोस्, तपाईंको स्थितिलाई अलग गर्नुहोस्, र असफल हुन नसक्ने प्रणालीहरू निर्माण गर्नुहोस्। तपाईंले पहिलो पटक निर्माण सुरु गर्दा कुन क्लाउड अवधारणाले तपाईंलाई सबैभन्दा ठूलो टाउको दुखाइ दियो टिप्पणीहरूमा भन्नुहोस्। र पूर्ण वास्तुकला चिट शीट प्राप्त गर्न, daily diff डट dev मा न्यूजलेटरको सदस्यता लिनुहोस्, लिङ्क तल छ। र आजको लागि यो भिन्नता हो।

15:28 म Axrisi बाट Niko हुँ। जिम्मेवारीपूर्वक मर्ज गर्नुहोस्। Merge responsibly.

स्रोतहरू

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io