विनाश की ओर विभाजन की बग

एक सैनिटIZED आउटेज कहानी

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

एक संगठन 203.0.113.5 पर एक एकल प्रॉक्सी सर्वर चलाता है। यह इंग्रेस (यूजर्स के लिए पोर्ट 443) और ईग्रेस (वहां की सेवाओं को आउटबाउंड कॉल करने के लिए प्राइवेट सबनेट में प्राइवेट सबनेट में प्रॉक्सी के लिए पोर्ट 1080 SOCKS5) को संभालता है। आंतरिक सेवाएं सभी आउटबाउंड ट्रैफिक को उसी SOCKS5 प्रॉक्सी के माध्यम से 203.0.113.5:1080 पर भेजती हैं।

एक ही 203.0.113.5 के पीछे होस्ट की गई सेवाओं में से एक api.example.com है। पब्लिक DNS api.example.com को 203.0.113.5 पर रिज़ॉल्व करता है।

अब एक अलग आंतरिक सेवा को api.example.com को कॉल करने की आवश्यकता है। इसकी आउटबाउंड पथ:

1. आंतरिक सेवा api.example.com को 203.0.113.5 पर रिज़ॉल्व करती है।

2. आंतरिक सेवा पैकेट को प्रॉक्सी के माध्यम से SOCKS5 ईग्रेस प्रॉक्सी के लिए 203.0.113.5:1080 पर भेजती है।

3. प्रॉक्सी को खुद को खुद के माध्यम से अपनी सार्वजनिक आईपी के लिए एक कनेक्शन खोलने की कोशिश करता है।

4. कनेक्शन रिजेक्टेड। पैकेट को उसी NAT के बाहर और वापस उसी NAT में जाना होगा, जो अधिकांश नेटवर्क स्टैक्स को अस्वीकार करते हैं। प्रॉक्सी खुद को अपनी सार्वजनिक आईपी के माध्यम से खुद को कॉल नहीं कर सकता।

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

यह क्यों बाद में सामने आता है

प्रोजेक्ट के जीवन के शुरुआती चरण में, हर आंतरिक सेवा either internal सेवाओं को private hostname (internal-api.local) द्वारा बातचीत करती थी या अपनी own संगठन की public सेवाओं को कॉल नहीं करती थी। हेयरपिन पथ सिर्फ मौजूद नहीं था।

फिर एक नया फीचर की आवश्यकता हुई service A को api.example.com (एक public hostname) को कॉल करने की। हेयरपिन पथ सक्रिय हुआ। कनेक्शन अस्वीकृत। outage।

स्थायी समाधान ने लक्षण को ठीक किया (force the resolver को api.example.com के बजाय public की जगह private IP देने के लिए)। मूल कारण: एक ही बॉक्स ने बहुत सारे काम किए थे।

अर्किटेक्चरल फोर्क

एक बॉक्स दो बन जाता है

साफ़ समाधान: प्रॉक्सी को दो मशीनों में विभाजित करें।

Ingress server (public IP 203.0.113.5):

- Caddy / reverse proxy on ports 80, 443

- Public DNS records point here

- Hosts api.example.com, app.example.com, etc.

Egress server (different public IP 203.0.113.99):

- SOCKS5 / forward proxy on port 1080

- Firewall restricts incoming connections to internal subnet IPs only

- Internal services route all outbound through this address

What this buys:

1. हेयरपिन सुलझा। एक internal सेवा कॉल api.example.com routes outbound via 203.0.113.99 (egress), जो फिर सामान्य रूप से 203.0.113.5 (ingress, एक अलग IP) को connect करता है। NAT loop खत्म होता है क्योंकि दो IPs अलग-अलग मशीनों पर रहते हैं।

2. सुरक्षा आइसोलेशन। egress server के firewall को internal IPs के छोटे सेट पर lock कर सकते हैं। ingress server के firewall विश्व के लिए खुला रहता है। दो अलग-अलग rule sets, प्रत्येक को एक role को साफ़ रूप से व्यक्त करते हैं।

3. 独立的なスケーリング。 Ingress bandwidth users के साथ scales; egress bandwidth internal-service activity के साथ scales। एक दूसरे को छूते हुए अपग्रेड करें।

4. failure isolation। egress को गलत सेट नहीं करता है public site को break। DDoS public site के खिलाफ नहीं starves egress bandwidth।

5. स्पष्ट मानसिक मॉडल। प्रत्येक मशीन का एक काम है। इंजीनियर्स इनग्रेस चिंताओं के बारे में सोचते हैं बिना ईग्रेस के बारे में सोचें, और इसके विपरीत।

दो ध्रुव, दो आकार निर्णय

स्वतंत्र प्राविधिक

स्प्लिट से पहले, दोनों दिशाओं में वृद्धि किसी ही मशीन को दबा देती थी। स्प्लिट के बाद, प्रत्येक दिशा के लिए अपना प्राविधिक होता है।

इनग्रेस आकार: उपयोगकर्ता के साथ स्केल करता है। क्षमता निर्णय पब्लिक-फेसिंग टियर में रहते हैं (प्रत्येक विपरीत प्रॉक्सी रेप्लिका, बड़े वीएम, सीडीएन के साथ)। बैंडविड्थ बजट उपयोगकर्ता ट्रैफ़िक के पीक के खिलाफ मापा जाता है।

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

फेलियर आइसोलेशन: पब्लिक इनग्रेस के खिलाफ एक DDoS अब ईग्रेस बैंडविड्थ को खा नहीं सकता (उन भुगतान प्रोसेसर कॉल्स फिर भी जाते हैं)। एक ईग्रेस प्रॉक्सी क्रैश अब पब्लिक साइट को नहीं ले सकता (उसी उपयोगकर्ता साइट पर पहुंचते हैं; सिर्फ आंतरिक बाहरी कॉल फेल होते हैं।)

विभिन्न SLOs: इनग्रेस उपलब्धता उपयोगकर्ताओं को चिंता है (सensible साइट आउटेज); ईग्रेस उपलब्धता ऑपरेटरों को चिंता है (पृष्ठभूमि विफलताएं जो शायद लंबे समय में पता लगाने के लिए ले जा सकती हैं।) प्रत्येक तरफ अपना SLO ले जा सकते हैं।

कई ईग्रेस सर्वर

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

स्टेटलेस टियर के बाद सामान्य बातचीत की तरह: एक बार जब एक तीर अपनी भूमिका के लिए जाता है, तो इसे सस्ते में आसानी से बढ़ाया जा सकता है।

एक नई पार्टनर एकीकरण

आपकी संगठन इनग्रेस / ईग्रेस स्प्लिट को डिज़ाइन के अनुसार चलाता है। ईग्रेस सर्वर में एक स्थिर पब्लिक आईपी (203.0.113.99) होती है जिसे तीन मौजूदा पार्टनर एपीआई (एक भुगतान प्रोसेसर, एक एसएमएस गेटवे, एक ईमेल प्रदाता) के साथ Allowlisted किया गया है।

उत्पाद टीम को चौथी एकीकरण को जोड़ने की इच्छा है: एक वेबहुक डिलीवरी सिस्टम जो ग्लोबल कस्टमर एंडपॉइंट्स में वापस कॉल करता है। खपत अनुमान: प्रति मिनट 10,000 कॉल, 30,000 तक बurst।

एक बढ़ती सेवा के लिए नेटवर्क की सीमा डिज़ाइन करें

सिंथेसिस

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

सभी चार का उपयोग करें।

एक मध्यम आकार की SaaS कंपनी तीन उत्पाद सबडोमेन (app, api, admin) चलाती है जो उनके उपयोगकर्ताओं के लिए होती है, साथ ही चार बाहरी एकीकरण (Stripe, Twilio, SendGrid, एक ग्राहक-वेबहुक सिस्टम)। आज सभी चीजें एक एकल प्रॉक्सी मशीन के पीछे रहती हैं जो एक पब्लिक आईपी पर होती है। उन्होंने आंतरिक सेवाओं को api.example.com को कॉल करने के समय हेयरपिन विफलताओं के अंशांतर की रिपोर्ट शुरू कर दी हैं। वे एक स्थायी समाधान डिज़ाइन करना चाहते हैं।

यह पाठ का अगला चरण

यह पाठ का अगला चरण

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

अगला अध्याय (cs_distsys_failure_modes_and_blast_radius) विफलता आइसोलेशन के विचार को बढ़ाता है। आप एक सेंसिटाइज्ड DNS-SERVFAIL पोस्टमोर्टम पढ़ेंगे, फेलियर पैटर्न की पहचान करेंगे, और लोगों के बजाय प्रणालियों को लक्षित करने वाले दोषरहित कार्रवाई के आइटम लिखेंगे।

साथी पाठ: geometry_of_ingress_egress_separation इस विभाजन को एक द्विपक्षीय ग्राफ के रूप में पुनर्स्थापित करता है और काट वेर्टेक्स, नेटवर्क पार्टिशन, और ग्राफ थ्योरी के बारे में बताता है कि एक नेटवर्क बाउंड्री के बारे में क्या सूचना देता है।

बहुत अच्छा। आगे बढ़ें।