3.14 मल्टी-टेनेंसी और SaaS आर्किटेक्चर

अवलोकन और प्रेरणा

मल्टीटेनेंसी आपके सॉफ़्टवेयर का एक ही इंस्टेंस चलाकर एक साथ कई अलग-अलग ग्राहकों को सेवा देने की प्रथा है, जिसमें प्रत्येक ग्राहक का डेटा और कॉन्फ़िगरेशन तार्किक रूप से अलग रखा जाता है जबकि वे एक ही कोड और अक्सर एक ही इन्फ्रास्ट्रक्चर साझा करते हैं। प्रत्येक ग्राहक एक टेनेंट है। यही एक विचार सॉफ़्टवेयर ऐज़ अ सर्विस (SaaS) का आर्थिक इंजन है, वह मॉडल जिसमें आप इंस्टॉल करने के लिए एक प्रति नहीं, बल्कि एक चलते हुए एप्लिकेशन तक पहुँच बेचते हैं। जब एक हज़ार टेनेंट एक ही डिप्लॉयमेंट साझा करते हैं, तो आप एक बार पैच करते हैं, एक सिस्टम को स्केल करते हैं, और अगले ग्राहक की सीमांत लागत लगभग शून्य के करीब पहुँच जाती है। यही कारण है कि एक अच्छी तरह से बना मल्टी-टेनेंट उत्पाद दो लोगों के स्टार्टअप और एक लाख सीटों वाले एंटरप्राइज़ दोनों को एक ही कोडबेस से सेवा दे सकता है, और यही कारण है कि आप जो टेनेंसी मॉडल चुनते हैं वह वर्षों तक आपके मार्जिन, आपकी सुरक्षा स्थिति, और आपके परिचालन भार को आकार देता है।

बड़ी टीमों के लिए दांव लागत से कहीं अधिक गहरे हैं। मल्टी-टेनेंसी आपके आर्किटेक्चर के केंद्र में एक सख़्त आवश्यकता रखती है: टेनेंट A को किसी भी बग, रेस कंडीशन, या मिसकॉन्फ़िगरेशन के तहत टेनेंट B का डेटा कभी नहीं दिखना चाहिए। एक भी क्रॉस-टेनेंट लीक किसी कंपनी को समाप्त कर सकता है। साथ ही, साझा करने का पूरा उद्देश्य दक्षता है, इसलिए हर डिज़ाइन निर्णय मज़बूत आइसोलेशन (सुरक्षित, अधिक महंगा) और घनी शेयरिंग (सस्ता, अधिक जोखिम भरा) के बीच एक स्पेक्ट्रम पर बैठता है। इसे सही ढंग से करना ही एक ऐसे उत्पाद के बीच का अंतर है जो सहजता से स्केल करता है, और एक ऐसे उत्पाद के बीच जो या तो आपको इन्फ्रास्ट्रक्चर पर दिवालिया कर देता है या आपको सुर्खियों में ला देता है। यह अध्याय क्लाउड आर्किटेक्चर (अध्याय 3.11) पर आधारित है, डेटा आर्किटेक्चर (अध्याय 3.4) और क्लाउड सुरक्षा (अध्याय 4.3) पर भारी निर्भर करता है, और स्केलेबिलिटी व रेज़िलिएंस (अध्याय 3.5) तथा लागत आरोपण (अध्याय 9.4) से जुड़ता है।

एंटरप्राइज़ और सरकारें बार को और ऊँचा उठाती हैं। एंटरप्राइज़ खरीदार संविदात्मक डेटा गारंटी पर बातचीत करते हैं, अपने टियर के लिए समर्पित आइसोलेशन की मांग करते हैं, और अपेक्षा करते हैं कि आप उन्हें बिना डाउनटाइम के वातावरणों के बीच माइग्रेट करें। सरकारें डेटा निवास कानून, वर्गीकरण-आधारित पृथक्करण, और यह अक्सर आवश्यकता जोड़ती हैं कि प्रत्येक एजेंसी अपने स्वयं के ऑडिट सीमा के साथ अपना स्वयं का टेनेंट हो। यहाँ के टेनेंसी निर्णय कार्यान्वयन विवरण नहीं हैं; वे उन प्रतिबद्धताओं हैं जो आप हर उस ग्राहक से करते हैं जो अपना डेटा आप पर भरोसा करता है।

मुख्य सिद्धांत

• आइसोलेशन एक स्पेक्ट्रम है, स्विच नहीं। साइलो, पूल, और ब्रिज मॉडल दक्षता को पृथक्करण के मुकाबले ट्रेड करते हैं; प्रति टियर और प्रति संसाधन चुनें, न कि सब कुछ के लिए एक बार में।
• टेनेंट संदर्भ पवित्र है। हर रिक्वेस्ट, क्वेरी, लॉग लाइन, और बैकग्राउंड जॉब को एक टेनेंट पहचानकर्ता ले जाना चाहिए, और हर डेटा एक्सेस को उसके द्वारा सीमित किया जाना चाहिए।
• क्रॉस-टेनेंट लीक वह विफलता है जो सबसे अधिक मायने रखती है। ऐसा डिज़ाइन करें कि एक भी गायब फ़िल्टर किसी दूसरे टेनेंट का डेटा उजागर न कर सके; गहराई में रक्षा, एक WHERE क्लॉज़ नहीं।
• शोरगुल वाले पड़ोसी एक आर्किटेक्चर समस्या हैं। कोटा और निष्पक्षता के बिना, एक भारी टेनेंट सभी को नीचे गिरा देता है; इसके होने से पहले योजना बनाएं।
• प्रति-टेनेंट कॉन्फ़िगरेशन स्केल करता है; प्रति-टेनेंट कोड नहीं। उत्पाद को डेटा और फ़्लैग से मोड़ें, फ़ोर्क से नहीं।
• टेनेंट जीवनचक्र एक उत्पाद सुविधा है। ऑनबोर्डिंग, प्रोविज़निंग, ऑफ़बोर्डिंग, और डेटा एक्सपोर्ट प्रथम-श्रेणी, स्वचालित, और ऑडिट योग्य होने चाहिए।
• आप उसका प्रबंधन नहीं कर सकते जिसे आप आरोपित नहीं कर सकते। ऑब्ज़र्वेबिलिटी और लागत को प्रति टेनेंट विभाजित होना चाहिए, अन्यथा आप विश्वसनीयता और मार्जिन दोनों पर अंधे उड़ते हैं।

सिफ़ारिशें

प्रति टियर, आइसोलेशन-बनाम-दक्षता स्पेक्ट्रम के साथ एक टेनेंसी मॉडल चुनें

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

पूरे उत्पाद के लिए एक मॉडल न चुनें। सही उत्तर आमतौर पर एक ब्रिज है जो आपके प्राइसिंग टियर से मेल खाता है। छोटे टेनेंट की लंबी पूँछ को एक कुशल साझा पूल में रखें जहाँ उनकी अर्थव्यवस्था काम करती है। उन एंटरप्राइज़ ग्राहकों के लिए एक प्रीमियम टियर के रूप में एक समर्पित या सिंगल-टेनेंट डिप्लॉयमेंट प्रस्तुत करें जो आइसोलेशन और संविदात्मक गारंटियों के लिए भुगतान करेंगे। इस मैपिंग को एक आर्किटेक्चर निर्णय रिकॉर्ड (अध्याय 3.11) के रूप में लिखें, क्योंकि “कौन से टेनेंट क्या साझा करते हैं” एक दावा है जिस पर आपकी सुरक्षा, बिक्री, और वित्त टीमें सभी निर्भर करती हैं।

डेटा को जानबूझकर विभाजित करें, और टेनेंट स्कोपिंग को भूलना असंभव बनाएं

डेटा वह है जहाँ मल्टी-टेनेंसी जीती या मरती है, इसलिए विभाजन के चुनाव को एक मूल डेटा-आर्किटेक्चर निर्णय (अध्याय 3.4) के रूप में मानें। तीन रणनीतियाँ टेनेंसी मॉडल के समानांतर हैं। प्रति टेनेंट अलग डेटाबेस सबसे मज़बूत आइसोलेशन, आसान प्रति-टेनेंट बैकअप और रीस्टोर, और सरल डेटा एक्सपोर्ट देता है, जिसकी कीमत चलाने के लिए कई डेटाबेस और फैलाने के लिए स्कीमा माइग्रेशन है। एक साझा डेटाबेस के भीतर प्रति टेनेंट अलग स्कीमा एक मध्य मार्ग है: एक सर्वर, तार्किक पृथक्करण, फिर भी माइग्रेट करने के लिए बहुत सारी वस्तुएं। एक टेनेंट कॉलम द्वारा कुंजीबद्ध साझा टेबल, जहाँ हर पंक्ति एक tenant_id ले जाती है, सबसे घना और सबसे सस्ता है, और सबसे खतरनाक भी, क्योंकि अब एक भी क्वेरी जिसमें उसका टेनेंट फ़िल्टर गायब हो, ग्राहकों के बीच डेटा लीक कर सकती है।

यदि आप टेबल साझा करते हैं, तो डेवलपर्स के फ़िल्टर याद रखने पर निर्भर न रहें। टेनेंट स्कोपिंग को ऐसी परत में लागू करें जिसे बायपास नहीं किया जा सकता: डेटाबेस रो-लेवल सिक्योरिटी जो सत्र के टेनेंट के आधार पर हर क्वेरी में एक अनिवार्य प्रिडिकेट जोड़ती है, एक ORM या डेटा-एक्सेस परत जो टेनेंट क्लॉज़ को स्वचालित रूप से इंजेक्ट करती है, या दोनों। यहाँ “बेल्ट और सस्पेंडर्स” सही है। जैसे-जैसे टेनेंट बढ़ते हैं, टेनेंट के अनुसार शार्डिंग स्वाभाविक हो जाती है: टेनेंट के समूहों को अलग-अलग डेटाबेस शार्ड पर रखें ताकि कोई एक इंस्टेंस सबका डेटा न रखे, जो एक शार्ड की विफलता के ब्लास्ट रेडियस को भी सीमित करता है और आपको मॉडल बदले बिना एक बड़े टेनेंट को उसके अपने शार्ड में ले जाने देता है।

टेनेंट संदर्भ को हर जगह प्रचारित करें, और गहराई में क्रॉस-टेनेंट लीक से बचाव करें

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

क्रॉस-टेनेंट आइसोलेशन को गहराई में रक्षा वाली एक सुरक्षा संपत्ति मानें, और विवरण अध्याय 4.3 को सौंपें। न्यूनतम विशेषाधिकार के सिद्धांत को लागू करें ताकि एक समझौता किया गया घटक भी केवल उस टेनेंट तक पहुंच सके जिसके लिए वह कार्य कर रहा है। प्राधिकरण निर्णयों के लिए क्लाइंट-नियंत्रित इनपुट से टेनेंट पहचानकर्ता कभी स्वीकार न करें; इसे प्रमाणित पहचान से प्राप्त करें। कैश, ऑब्जेक्ट स्टोरेज प्रीफ़िक्स, और सर्च इंडेक्स को टेनेंट के अनुसार नेमस्पेस करें ताकि एक कुंजी टकराव सीमा को पार न कर सके। फिर सीमा को जानबूझकर परखें: स्वचालित परीक्षण जो यह दावा करते हैं कि टेनेंट A के क्रेडेंशियल टेनेंट B के रिकॉर्ड नहीं पढ़ सकते, और आवधिक रेड-टीम अभ्यास जो टेनेंट से बाहर निकलने की कोशिश करते हैं। आपके परीक्षण सूट द्वारा पाया गया लीक एक बग है; ग्राहक द्वारा पाया गया लीक एक संकट है।

कोटा, रेट लिमिट, और निष्पक्षता के साथ शोरगुल वाले पड़ोसियों को नियंत्रित करें

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

अपने टेनेंसी मॉडल के साथ प्रवर्तन का मिलान करें। एक साझा पूल में, कोटा और निष्पक्षता प्राथमिक बचाव हैं, इसलिए उनमें निवेश करें। एक ऐसे टेनेंट के लिए जिसका लोड वास्तव में उससे अधिक है जिसे निष्पक्ष शेयरिंग अवशोषित कर सकती है, उत्तर अक्सर उसे पूल से बाहर ब्रिज या साइलो डिप्लॉयमेंट में प्रोमोट करना है, जो एक विफलता के बजाय एक सुविधा है जिसे आप बेच सकते हैं। इसे अपने स्केलेबिलिटी और रेज़िलिएंस कार्य (अध्याय 3.5) से जोड़ें: लोड-शेडिंग, सर्किट ब्रेकर, और बैकप्रेशर सभी को टेनेंट-जागरूक होने की आवश्यकता है ताकि एक टेनेंट के अतिरिक्त लोड को हटाना बाकियों की रक्षा करे न कि पूरे सिस्टम को खराब करे।

टेनेंट को कोड के फ़ोर्क से नहीं, डेटा से कॉन्फ़िगर करें

हर ग्राहक थोड़ा अलग कुछ चाहेगा: उनका लोगो, उनके वर्कफ़्लो नियम, उनके इंटीग्रेशन, एक फ़ील्ड जो आपके पास नहीं है। हाँ कहने का स्केलेबल तरीका प्रति-टेनेंट कॉन्फ़िगरेशन है: फ़ीचर फ़्लैग, सेटिंग्स, एंटाइटलमेंट, और एक्सटेंसिबिलिटी पॉइंट जो डेटा हैं, रनटाइम पर मूल्यांकित होते हैं, और एक कोडबेस द्वारा साझा किए जाते हैं। जो मार्ग SaaS बिज़नेस को नष्ट करता है वह है प्रति-टेनेंट कस्टम कोड: एक बड़े ग्राहक के लिए कोड पथ में एक ब्रांच या एक फ़ोर्क या एक विशेष स्थिति। इनमें से दस हो जाएं और आपके पास अब एक उत्पाद नहीं रहता, बल्कि दस उत्पाद एक ट्रेंच कोट पहने रहते हैं, और हर बदलाव को दस बार परखा जाना चाहिए।

एक दृढ़ रेखा खींचें। भिन्नता के उन अक्षों को मॉडल करें जिन्हें आप प्रथम-श्रेणी कॉन्फ़िगरेशन के रूप में समर्थन देने को तैयार हैं, और उन अक्षों के बाहर के अनुरोधों को या तो उत्पाद रोडमैप या एक दृढ़ इनकार के रूप में मानें। जब किसी ग्राहक को सच्ची कस्टमाइज़ेशन चाहिए, तो उन्हें एक्सटेंशन पॉइंट (वेबहुक, एक API, प्लगइन, कस्टम फ़ील्ड) दें जो आपके कोड को ब्रांच किए बिना उनके लॉजिक को चलाते हैं। वास्तव में बेस्पोक डिप्लॉयमेंट को सिंगल-टेनेंट प्रीमियम टियर के लिए आरक्षित रखें, जहाँ आइसोलेशन ही मुद्दा है और उच्च कीमत परिचालन लागत को कवर करती है।

टेनेंट जीवनचक्र को स्वचालित, अवलोकनीय, और लागत-आरोपित बनाएं

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

हर चीज़ को प्रति टेनेंट इंस्ट्रूमेंट करें। लॉग, ट्रेस, और मेट्रिक को टेनेंट पहचानकर्ता से टैग करें ताकि आप सेकंडों में “क्या यह आउटेज सभी टेनेंट का है या एक का?” और “कौन सा टेनेंट इस लागत को चला रहा है?” का उत्तर दे सकें। इन्फ्रास्ट्रक्चर लागत को टेनेंट के लिए आरोपित करें ताकि आप हर ग्राहक पर अपना सच्चा मार्जिन जानें और उस टेनेंट को पहचान सकें जिसका उपयोग उन्हें उनकी वर्तमान कीमत पर अलाभकारी बनाता है (अध्याय 9.4)। टेनेंट-जागरूक ऑब्ज़र्वेबिलिटी और लागत आरोपण मल्टी-टेनेंसी को एक ब्लैक बॉक्स से एक ऐसे सिस्टम में बदल देते हैं जिसे आप वास्तव में चला और मूल्य निर्धारित कर सकते हैं।

ट्रेड-ऑफ़: फ़ायदे और नुकसान

टेनेंसी मॉडल	फ़ायदे	नुकसान
साइलो (प्रति टेनेंट समर्पित स्टैक)	सबसे मज़बूत आइसोलेशन, सबसे छोटा ब्लास्ट रेडियस, आसान प्रति-टेनेंट अनुपालन और एक्सपोर्ट, सरल शोरगुल-पड़ोसी कहानी	सबसे अधिक लागत, प्रति टेनेंट निष्क्रिय क्षमता, संचालित और पैच करने के लिए कई प्रतियाँ
पूल (पूर्णतः साझा)	सबसे कम सीमांत लागत, सबसे घनी पैकिंग, स्केल और अपग्रेड करने के लिए एक सिस्टम	आइसोलेशन पूरी तरह कोड की सही होने पर निर्भर, सबसे खराब शोरगुल-पड़ोसी जोखिम, सबसे कठिन प्रति-टेनेंट एक्सपोर्ट और डिलीशन
ब्रिज (हाइब्रिड, टियर्ड)	छोटे टेनेंट के लिए कुशल, बड़े टेनेंट के लिए समर्पित आइसोलेशन, प्राइसिंग से मेल खाता है	बनाने और संचालित करने के लिए अधिक मॉडल, टियर के बीच बनाए रखने के लिए प्रोमोशन मार्ग
साझा DB, साझा स्कीमा (टेनेंट कॉलम)	सबसे सस्ता स्टोरेज, एक माइग्रेशन, सबसे सरल संचालन	एक गायब फ़िल्टर डेटा लीक करता है; बैकस्टॉप के रूप में रो-लेवल सिक्योरिटी चाहिए
साझा DB, प्रति टेनेंट स्कीमा	तार्किक आइसोलेशन, एक सर्वर, अच्छा एक्सपोर्ट	कई स्कीमा ऑब्जेक्ट, माइग्रेशन फैलते हैं, प्रति सर्वर स्केलिंग सीमाएं
प्रति टेनेंट डेटाबेस	मज़बूत डेटा आइसोलेशन, प्रति-टेनेंट बैकअप और एक्सपोर्ट	कई डेटाबेस, माइग्रेशन फैलाव, अधिक लागत

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

अपनी टीम के साथ चर्चा के लिए प्रश्न

1. यदि कल एक टेनेंट-स्कोपिंग फ़िल्टर गायब हो जाए, तो क्या एक ग्राहक दूसरे ग्राहक का डेटा देख पाएगा? यही वह प्रश्न है जो एक रक्षणीय मल्टी-टेनेंट उत्पाद को होने की प्रतीक्षा में एक दुर्घटना से अलग करता है। ईमानदार परीक्षण एक वास्तविक रीड पथ को ट्रेस करना और यह पूछना है कि टेनेंट सीमा को क्या लागू करता है: क्या यह एक डेवलपर-लिखित WHERE क्लॉज़ है, या डेटाबेस रो-लेवल सिक्योरिटी या एक डेटा-एक्सेस परत जैसा बैकस्टॉप है जो हर हाल में स्कोप इंजेक्ट करता है? अपने वास्तविक क्वेरी पथ, अपने बैकग्राउंड जॉब, और अपने कैश लाएं, क्योंकि लीक लगभग हमेशा उस असिंक्रोनस कोने में छिपा होता है जिसे किसी ने स्कोप नहीं किया। आपको उस परीक्षण के परिणाम भी लाने चाहिए जो जानबूझकर टेनेंट A के सत्र का उपयोग करके टेनेंट B के रिकॉर्ड का अनुरोध करता है और अस्वीकृति का दावा करता है। यदि सीमा केवल मानवीय सतर्कता पर टिकी है, तो आपके पास एक अव्यक्त उल्लंघन है, और इसका समाधान (गहराई में रक्षा) बैकलॉग के शीर्ष पर कूद जाना चाहिए।

2. प्रत्येक ग्राहक टियर वास्तव में कौन सा टेनेंसी और डेटा-विभाजन मॉडल उपयोग करता है, और क्या यह उससे मेल खाता है जो हमने उन्हें बेचा था? कई टीमें डिफ़ॉल्ट रूप से एक ही मॉडल की ओर बह जाती हैं, फिर पता चलता है कि उनकी प्राइसिंग और उनका आर्किटेक्चर असहमत हैं: एंटरप्राइज़ ग्राहकों को वह आइसोलेशन वादा किया गया था जो साझा पूल प्रदान नहीं करता, या छोटे ग्राहक महंगे समर्पित स्टैक में बैठे हैं जो मार्जिन को बर्बाद करते हैं। हर टियर को उसके वास्तविक मॉडल (साइलो, पूल, या ब्रिज; प्रति-टेनेंट डेटाबेस, स्कीमा, या साझा टेबल) से मैप करें और इसे अपनी बिक्री टीम द्वारा दी गई संविदात्मक डेटा गारंटियों के साथ रखें। जहाँ वे अलग होते हैं, आपके पास या तो अनुपालन जोखिम है या लागत समस्या है, और किसी ग्राहक या ऑडिटर के इसे खोजने से पहले दोनों को सामने लाना उचित है। लाने योग्य सबूत टियर-से-मॉडल मैपिंग, प्रति-टेनेंट लागत, और आपके एंटरप्राइज़ अनुबंधों की वास्तविक भाषा है।

3. जब एक बड़े टेनेंट का लोड बढ़ता है, तो और कौन इसे महसूस करता है, और हमारी क्या योजना है? एक साझा पूल में उत्तर अक्सर “सभी” होता है, और टीमों को अक्सर यह तब तक पता नहीं चलता जब तक कोई घटना इसे स्पष्ट न कर दे। यह देखें कि जब आपका सबसे बड़ा टेनेंट एक बल्क इंपोर्ट चलाता है या एक ट्रैफ़िक उछाल पाता है तो क्या होता है: क्या प्रति-टेनेंट कोटा और निष्पक्ष शेड्यूलिंग इसे रोकती है, क्या लोड-शेडिंग पड़ोसियों की रक्षा करती है, या क्या पूरा सिस्टम एक साथ खराब हो जाता है? लोड डेटा और अपनी पिछली शोरगुल-पड़ोसी घटना की कहानी लाएं, क्योंकि जो टेनेंट आपको नुकसान पहुंचाता है वह आमतौर पर वह है जिसे आप नाम से जानते हैं। उत्तर आपके रेट-लिमिटिंग निवेश और आपकी टियरिंग रणनीति दोनों को आकार देना चाहिए, क्योंकि जो टेनेंट निष्पक्ष शेयरिंग से आगे बढ़ जाता है उसके लिए सबसे साफ़ समाधान उसे एक ब्रिज या समर्पित डिप्लॉयमेंट में प्रोमोट करना है जिसके लिए आप शुल्क ले सकते हैं।

4. जब कोई टेनेंट कल ऑफ़बोर्ड करता है, तो क्या हम उन्हें एक साफ़ एक्सपोर्ट दे सकते हैं और साबित कर सकते हैं कि हमने हर निशान हटा दिया, या क्या हम हड़बड़ी में होंगे? ऑफ़बोर्डिंग टेनेंट जीवनचक्र का वह हिस्सा है जिसे टीमें तब तक नज़रअंदाज़ करती हैं जब तक कोई अनुबंध निकास खंड या गोपनीयता-कानून अनुरोध मुद्दे को मजबूर न करे, और तब तक साझा स्कीमा निष्कर्षण और डिलीशन को कष्टदायक बना देती है। एक बड़ी टीम के लिए जोखिम मिश्रित होता है, क्योंकि एक टेनेंट का डेटा प्राथमिक डेटाबेस, कैश, ऑब्जेक्ट स्टोरेज, सर्च इंडेक्स, बैकअप, और एनालिटिक्स पाइपलाइन में बिखरा होता है, और प्रत्येक को उपयोग योग्य प्रारूप में एक्सपोर्ट किया जाना चाहिए और फिर साबित तरीके से हटाया जाना चाहिए। प्रतिस्पर्धी विचार वास्तविक हैं: घनी साझा टेबल जो आपको सस्ता स्टोरेज देती हैं, वही हैं जो प्रति-टेनेंट निष्कर्षण और डिलीशन को सबसे कठिन बनाती हैं, इसलिए जो दक्षता आपने स्टोरेज परत पर खरीदी थी आप उसे वापस चुका सकते हैं। ऑफ़बोर्डिंग का एक वास्तविक टेनेंट पर लाइव वॉक-थ्रू लाएं, टेनेंट डेटा रखने वाले हर स्टोर की सूची, और वह सबूत जो आप दिखाएंगे कि डिलीशन वास्तव में हुआ। एंटरप्राइज़ और सरकारी टेनेंट के लिए, एक्सपोर्ट प्रमाणित होना चाहिए और डिलीशन सार्वजनिक-रिकॉर्ड और गोपनीयता क़ानूनों को संतुष्ट करने के लिए साबित होना चाहिए, इसलिए एक गायब डिलीशन मार्ग को अभी बंद करने वाले अनुपालन दोष के रूप में मानें, न कि ग्राहक के जाने पर जोड़ी जाने वाली सुविधा के रूप में।

5. व्यक्तिगत ग्राहकों के लिए कितने वन-ऑफ़ विशेष मामले पहले से हमारे कोड पथ में रहते हैं, और वह रेखा कहाँ है जिसे हम पार करने से इनकार करते हैं? प्रति-टेनेंट कोड फ़ोर्क वह चुपचाप तरीका है जिससे एक SaaS बिज़नेस एक उत्पाद होना बंद कर देता है और एक नाम के तहत कई उत्पाद बन जाता है, जहाँ हर बदलाव को हर विशेष मामले के खिलाफ़ परखा जाना चाहिए और जैसे-जैसे आप ग्राहक जोड़ते हैं वेलोसिटी क्षीण होती जाती है। तनाव यह है कि एक वास्तविक आवश्यकता वाले बड़े ग्राहक को मना करना कठिन है, और कोड पथ में एक ब्रांच एक कॉन्फ़िगरेशन सतह बनाने से तेज़ महसूस होती है, इसलिए विशेष मामले एक-एक करके उचित अपवाद के रूप में जमा होते जाते हैं। एक ईमानदार सूची लाएं: कोडबेस में ग्राहक नामों और टियर-विशिष्ट ब्रांचों को खोजें, उन्हें गिनें, और अनुमान लगाएं कि प्रत्येक असंबंधित बदलाव पर कितनी अतिरिक्त परीक्षण और समीक्षा लागत लगाता है। चर्चा को उस भिन्नता के बीच एक दृढ़ रेखा खींचनी चाहिए जिसे आप प्रथम-श्रेणी कॉन्फ़िगरेशन (फ़्लैग, एंटाइटलमेंट, एक्सटेंशन पॉइंट) के रूप में मॉडल करते हैं और सच्चे बेस्पोक काम के बीच जिसे आप सिंगल-टेनेंट प्रीमियम टियर के लिए आरक्षित रखते हैं जहाँ उच्च कीमत परिचालन लागत को कवर करती है। गहरी कस्टमाइज़ेशन की मांग करने वाले एंटरप्राइज़ खरीदारों के लिए, टिकाऊ उत्तर एक्सटेंशन पॉइंट हैं जो आपके कोड को ब्रांच किए बिना उनके लॉजिक को चलाते हैं, ताकि गवर्नेंस और ऑडिट पूरे बेड़े में प्रबंधनीय रहें।

6. क्या हम प्रति टेनेंट बता सकते हैं कि एक घटना किसे कितनी लागत पहुंचा रही है और कौन से ग्राहक अपनी वर्तमान कीमत पर अलाभकारी हैं? मल्टी-टेनेंसी एक ब्लैक बॉक्स में तब बदल जाती है जब आपके लॉग, ट्रेस, मेट्रिक, और इन्फ्रास्ट्रक्चर लागत कोई टेनेंट आयाम नहीं रखते, क्योंकि तब आप यह उत्तर नहीं दे सकते कि क्या एक आउटेज एक टेनेंट का है या पूरे बेड़े का, और आप उस टेनेंट का नाम नहीं बता सकते जिसका उपयोग उन्हें उनकी अनुबंध कीमत पर नुकसान बनाता है। एक बड़ी टीम के लिए यह आरोपण वह है जो प्लेटफ़ॉर्म को चलाने को उसका अनुमान लगाने से अलग करता है, और यह सीधे रिलायबिलिटी प्रतिक्रिया और प्राइसिंग दोनों को आकार देता है। विचार इंस्ट्रूमेंटेशन लागत और कार्डिनैलिटी के विरुद्ध खिंचते हैं: हर चीज़ को टेनेंट के अनुसार टैग करना मुफ़्त नहीं है, और उच्च-कार्डिनैलिटी मेट्रिक आपके ऑब्ज़र्वेबिलिटी बजट पर दबाव डालते हैं, इसलिए आप जानबूझकर चुनते हैं कि प्रति टेनेंट क्या विभाजित करना है और क्या सैंपल करना है। अपनी वर्तमान टेनेंट-टैगिंग कवरेज, एक वास्तविक क्वेरी जो क्लाउड खर्च को एक टेनेंट से जोड़ती है, और वह मार्जिन तालिका लाएं जो आपको अपने सबसे कम लाभप्रद ग्राहक का नाम बताने दे। एंटरप्राइज़ और सरकारी सेटिंग्स में, प्रति-टेनेंट लागत और ऑडिट-स्कोप्ड ऑब्ज़र्वेबिलिटी भी चार्जबैक, क्षमता योजना, और हर एजेंसी या व्यवसाय इकाई के हकदार ऑडिट सीमा को फ़ीड करती हैं, इसलिए टेनेंट आयाम एक परिचालन आवश्यकता जितना ही गवर्नेंस आवश्यकता भी है।

क्षेत्र लेंस

स्टार्टअप। पहले दिन से एक एकल साझा पूल शिप करें और अपना दुर्लभ इंजीनियरिंग ध्यान उस एक चीज़ पर लगाएं जिसे बाद में रेट्रोफ़िट नहीं किया जा सकता: लागू टेनेंट स्कोपिंग। रो-लेवल सिक्योरिटी वाला एक प्रबंधित Postgres, हर टेबल पर एक tenant_id, और एज पर हल किया गया टेनेंट संदर्भ आपको बिना ऑपरेशंस टीम के सुरक्षित घनत्व दिलाता है। सट्टेबाज़ी में साइलो टियर या प्रति-टेनेंट इन्फ्रास्ट्रक्चर न बनाएं; एक ब्रिज टियर तभी जोड़ें जब कोई भुगतान करने वाला एंटरप्राइज़ प्रॉस्पेक्ट आइसोलेशन को उसकी लागत के लायक बनाए।

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

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

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

उदाहरण

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

एंटरप्राइज़। बड़े वित्तीय संस्थानों की सेवा करने वाला एक SaaS विक्रेता एक टियर्ड ब्रिज आर्किटेक्चर चलाता है। हज़ारों छोटे और मध्यम आकार के ग्राहक क्षेत्रीय साझा पूल में रहते हैं, टेनेंट के अनुसार शार्ड किए गए, जिसमें कोटा और निष्पक्ष शेड्यूलिंग शोरगुल वाले पड़ोसियों को नियंत्रण में रखते हैं। शीर्ष-स्तरीय बैंकिंग ग्राहकों को अलग-अलग क्लाउड खातों में सिंगल-टेनेंट डिप्लॉयमेंट मिलते हैं, जिसमें समर्पित डेटाबेस, प्रति-टेनेंट एन्क्रिप्शन कुंजियाँ, और मास्टर एग्रीमेंट में लिखी गई संविदात्मक डेटा-निवास और आइसोलेशन गारंटी होती हैं। एक प्लेटफ़ॉर्म क्षमता एक टेनेंट को बिना डाउनटाइम के टियर के बीच माइग्रेट करती है जब वे बढ़ते हैं या उनकी अनुपालन आवश्यकताएं बदलती हैं। हर टेनेंट की लागत टैगिंग के माध्यम से आरोपित होती है ताकि वित्त हर खाते पर सच्चा मार्जिन जान सके, और टेनेंट-टैग की गई ऑब्ज़र्वेबिलिटी ऑन-कॉल इंजीनियर को सेकंडों में बताने देती है कि एक अलर्ट एक टेनेंट का है या पूरे बेड़े का।

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

बिज़नेस केस: प्रेरणाएं, ROI, और TCO

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

रिटर्न तीन जगहों पर दिखता है: परिचालन लीवरेज (एक टीम पूरे बेड़े को चलाती है), तेज़ डिलीवरी (एक फ़िक्स हर टेनेंट को एक साथ शिप होता है, इसलिए जैसे-जैसे आप ग्राहक जोड़ते हैं वेलोसिटी क्षीण नहीं होती), और प्राइसिंग वैकल्पिकता (लंबी पूँछ के लिए एक साझा योजना और एंटरप्राइज़ के लिए एक प्रीमियम पृथक योजना, दोनों एक कोडबेस से)। इनके मुक़ाबले उन लागतों को ईमानदारी से बजट करें जिन्हें आपको फ़ंड करना चाहिए: लागू टेनेंट आइसोलेशन, कोटा, जीवनचक्र स्वचालन, और प्रति-टेनेंट ऑब्ज़र्वेबिलिटी बनाने की इंजीनियरिंग, साथ ही सीमा को अक्षुण्ण रखने का अनुशासन। इसे गलत करने की लागत असममित और गंभीर है, क्योंकि एक भी क्रॉस-टेनेंट डेटा भंग नियामक दंड, बड़े पैमाने पर ग्राहक हानि, और प्रतिष्ठा को नुकसान पहुंचा सकता है जो साझाकरण से बचाई गई इन्फ्रास्ट्रक्चर लागत को बौना बना देता है। नेतृत्व के सामने इस केस को ऊपर की ओर मार्जिन और स्केलेबिलिटी के रूप में और नीचे की ओर अस्तित्व संबंधी जोखिम के रूप में प्रस्तुत करें। सर्विस-लेवल एग्रीमेंट और संविदात्मक डेटा गारंटी को उस टेनेंसी मॉडल पर एंकर करें जिसे आप वास्तव में डिलीवर कर सकते हैं, क्योंकि ऐसा वादा जिसे आपका आर्किटेक्चर नहीं निभा सकता एक देयता है, बिक्री नहीं।

एंटी-पैटर्न और गड्ढे

• परंपरा से टेनेंट स्कोपिंग। हर क्वेरी पर टेनेंट फ़िल्टर याद रखने के लिए डेवलपर्स पर निर्भर रहना, बिना किसी डेटाबेस-स्तर या डेटा-एक्सेस-परत बैकस्टॉप के; एक चूक ही एक भंग है।
• क्लाइंट-सप्लाई किए गए टेनेंट पहचानकर्ता पर भरोसा करना। प्राधिकरण के लिए रिक्वेस्ट इनपुट से टेनेंट स्वीकार करना, न कि प्रमाणित पहचान से इसे प्राप्त करना, जो एक कॉलर को किसी और का डेटा मांगने देता है।
• अनस्कोप्ड बैकग्राउंड काम। जॉब, कैश, वेबहुक, और एक्सपोर्ट जो टेनेंट संदर्भ खो देते हैं क्योंकि किसी ने केवल सिंक्रोनस रिक्वेस्ट पथ को स्कोप किया था।
• प्रति-टेनेंट कोड फ़ोर्क। एक बड़े ग्राहक को कोड पथ में विशेष-मामला बनाना जब तक आप एक नाम के तहत कई भिन्न उत्पादों को बनाए नहीं रख रहे हैं और हर बदलाव की लागत दस गुना नहीं हो जाती।
• कोई शोरगुल-पड़ोसी बचाव नहीं। बिना किसी प्रति-टेनेंट कोटा या निष्पक्षता के एक साझा पूल चलाना, ताकि उछाल लाने वाला पहला टेनेंट सबको नीचे ले जाए।
• ऑफ़बोर्डिंग को बाद की सोच के रूप में लेना। बिना डेटा एक्सपोर्ट और साबित डिलीशन के बनाना, फिर एक ग्राहक के निकास खंड या गोपनीयता-कानून अनुरोध में विफल होना क्योंकि साझा स्कीमा निष्कर्षण को कष्टदायक बनाती है।
• प्रति टेनेंट अंधे उड़ना। बिना किसी टेनेंट आयाम के लॉग, मेट्रिक, और लागत, ताकि आप न बता सकें कि किसकी घटना है या कौन सा टेनेंट अलाभकारी है।

परिपक्वता मॉडल

• स्तर 1, आरंभ: मल्टी-टेनेंसी तात्कालिक और प्रतिक्रियात्मक है। टेनेंट पृथक्करण बिना किसी बैकस्टॉप के हाथ से लिखे फ़िल्टर पर टिका है, मॉडल एक-आकार-सभी-के-लिए है, कोई कोटा नहीं है, ऑनबोर्डिंग मैनुअल है, और लॉग व लागत कोई टेनेंट आयाम नहीं रखते। टीम शोरगुल वाले पड़ोसी और निकट-चूक लीक के बारे में घटनाओं से सीखती है।
• स्तर 2, विकास: मूल प्रथाएं दिखाई देती हैं लेकिन टीमों में असंगत हैं। एक टेनेंसी मॉडल चुना जाता है और टेनेंट संदर्भ मुख्य रिक्वेस्ट पथ के माध्यम से प्रचारित होता है, एक डेटाबेस-स्तर या डेटा-एक्सेस बैकस्टॉप मुख्य टेबल पर स्कोपिंग लागू करता है, और बुनियादी प्रति-टेनेंट कोटा मौजूद हैं। ऑनबोर्डिंग आंशिक रूप से स्वचालित है और लॉग एक टेनेंट पहचानकर्ता रखते हैं, लेकिन बैकग्राउंड पथ, एक्सपोर्ट, और लागत आरोपण सेवा-दर-सेवा भिन्न होते हैं और कहीं भी लिखे नहीं गए हैं।
• स्तर 3, मानकीकरण: टेनेंसी दृष्टिकोण संगठन भर में दस्तावेज़ीकृत और लागू है। टियर्ड टेनेंसी प्राइसिंग से मैप होती है, छोटे टेनेंट के लिए एक साझा पूल और एंटरप्राइज़ व विनियमित टेनेंट के लिए पृथक डिप्लॉयमेंट के साथ, टेनेंट स्कोपिंग गहराई में लागू और जानबूझकर परखी जाती है, कोटा और निष्पक्ष शेड्यूलिंग शोरगुल वाले पड़ोसियों को नियंत्रित करते हैं, एक्सपोर्ट और साबित डिलीशन सहित टेनेंट जीवनचक्र स्वचालित है, और ऑब्ज़र्वेबिलिटी व लागत प्रति टेनेंट विभाजित हैं। हर टीम अपने खुद के बजाय एक ही टेनेंसी मानक का पालन करती है।
• स्तर 4, प्रबंधन: टेनेंसी संपत्ति को बेसलाइन के विरुद्ध मापा और नियंत्रित किया जाता है। प्रति-टेनेंट आइसोलेशन, निष्पक्षता, विलंबता, और लागत को सहमत लक्ष्यों के साथ मेट्रिक के रूप में ट्रैक किया जाता है: क्रॉस-टेनेंट परीक्षण कवरेज, कोटा-उल्लंघन और शोरगुल-पड़ोसी घटना दरें, ऑनबोर्डिंग और ऑफ़बोर्डिंग समय, और प्रति-टेनेंट मार्जिन बेसलाइन के विरुद्ध रिपोर्ट किए जाते हैं, और एक टेनेंट को टियर के बीच प्रोमोट करने या किसी अलाभकारी को पुनः मूल्य देने के निर्णय किस्से के बजाय इस साक्ष्य पर आधारित होते हैं। निवास और वर्गीकरण अनुरूपता की निरंतर निगरानी की जाती है, और मानक से विचलन एक दस्तावेज़ीकृत प्रतिक्रिया को ट्रिगर करता है।
• स्तर 5, आर्केस्ट्रेशन: टेनेंसी निरंतर सुधरती है और संगठन भर में एकीकृत है। क्रॉस-टेनेंट सीमाओं को नियमित रेड-टीम अभ्यासों द्वारा परखा जाता है, टेनेंट बिना डाउनटाइम के टियर के बीच चलते हैं जब वे बढ़ते हैं या उनकी अनुपालन आवश्यकताएं बदलती हैं, प्रति-टेनेंट मार्जिन प्राइसिंग और क्षमता योजना को फ़ीड करता है, और निवास व वर्गीकरण नियम समीक्षा के बजाय पॉलिसी द्वारा लागू किए जाते हैं। मॉडल ग्राहक मिश्रण और नियामक तस्वीर के बदलने पर अनुकूलित होता है, और सबक उत्पाद, सुरक्षा, और वित्त को एक ही लूप के रूप में फ़ीड करते हैं।

चर्चा के लिए विचार

1. आज आपका प्रत्येक ग्राहक टियर आइसोलेशन-बनाम-दक्षता स्पेक्ट्रम पर कहाँ बैठता है, और क्या कोई टियर उन गारंटियों या उस मार्जिन के लिए ग़लत मॉडल में है जो आपने बेचा या जिसकी आपको आवश्यकता है?
2. यदि आपको एक ऑडिटर को यह साबित करना पड़े कि टेनेंट A टेनेंट B के डेटा तक नहीं पहुंच सकता, तो आप अभी क्या सबूत प्रस्तुत कर सकते हैं, और उसका कितना हिस्सा स्वचालित बनाम दावा किया हुआ है?
3. आपके कौन से असिंक्रोनस पथ (जॉब, कैश, वेबहुक, एक्सपोर्ट, सर्च इंडेक्स) टेनेंट संदर्भ को फिर से स्थापित करते हैं, और कौन से केवल इसे विरासत में लेते हैं या कॉलर पर भरोसा करते हैं?
4. जब कोई टेनेंट निष्पक्ष शेयरिंग से आगे बढ़ जाता है, तो क्या आपके पास एक ब्रिज या समर्पित डिप्लॉयमेंट में एक समर्थित, मूल्य निर्धारित प्रोमोशन मार्ग है, या क्या उत्तर डिफ़ॉल्ट रूप से एक घटना बन जाता है?
5. क्या आप इन्फ्रास्ट्रक्चर लागत को व्यक्तिगत टेनेंट से इतनी अच्छी तरह आरोपित कर सकते हैं कि अपने सबसे कम लाभप्रद ग्राहक का नाम बता सकें, और क्या इससे आपकी प्राइसिंग बदलेगी?
6. किसी सरकारी या विनियमित टेनेंट के लिए, क्या आप डेटा निवास और वर्गीकरण-आधारित आइसोलेशन को पॉलिसी द्वारा लागू कर सकते हैं, और एक प्रमाणित एक्सपोर्ट व साबित डिलीशन के साथ ऑफ़बोर्ड कर सकते हैं?

मुख्य निष्कर्ष

• मल्टी-टेनेंसी, अनेक टेनेंट की सेवा करने वाला एक इंस्टेंस, SaaS का आर्थिक इंजन है: यह आपके मार्जिन को चलाता है, और यह आपके आर्किटेक्चर के केंद्र में क्रॉस-टेनेंट आइसोलेशन रखता है।
• आइसोलेशन बनाम दक्षता को एक स्पेक्ट्रम मानें और इसे टियर करें: छोटे टेनेंट को एक कुशल साझा पूल में पैक करें, बड़े और विनियमित टेनेंट को ब्रिज या साइलो डिप्लॉयमेंट में पृथक करें जिनके लिए वे भुगतान करेंगे।
• टेनेंट स्कोपिंग को कभी एक हाथ से लिखे फ़िल्टर पर आराम न करने दें; इसे रो-लेवल सिक्योरिटी या डेटा-एक्सेस परत के साथ गहराई में लागू करें, और सीमा को जानबूझकर परखें।
• टेनेंट संदर्भ को हर रिक्वेस्ट, जॉब, कैश, और लॉग के माध्यम से प्रचारित करें, और उन असिंक्रोनस पथों की रक्षा करें जहाँ लीक छिपते हैं।
• प्रति-टेनेंट कोटा, रेट लिमिट, और निष्पक्ष शेड्यूलिंग से शोरगुल वाले पड़ोसियों को नियंत्रित करें, और पूल को खराब करने के बजाय पूल से आगे बढ़ने वाले टेनेंट को प्रोमोट करें।
• उत्पाद को प्रति-टेनेंट कोड से नहीं, प्रति-टेनेंट कॉन्फ़िगरेशन से मोड़ें, और टेनेंट जीवनचक्र व प्रति-टेनेंट ऑब्ज़र्वेबिलिटी और लागत आरोपण को प्रथम-श्रेणी बनाएं।

संदर्भ और आगे पढ़ना

• Tom Kwok, Thao Nguyen, and Linh Lam, A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application (IEEE International Conference on Services Computing)
• Frederick Chong and Gianpaolo Carraro, Architecture Strategies for Catching the Long Tail (Microsoft)
• Amazon Web Services, SaaS Lens, AWS Well-Architected Framework and SaaS Tenant Isolation Strategies
• Microsoft, Multitenant SaaS architecture and patterns (Azure Architecture Center)
• Google Cloud, Architecture for Multi-tenant SaaS Applications
• Cor-Paul Bezemer and Andy Zaidman, Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare? (Proceedings of the Joint ERCIM Workshop on Software Evolution)
• The Open Web Application Security Project, OWASP Application Security Verification Standard (access-control and multi-tenancy requirements)
• Martin Kleppmann, Designing Data-Intensive Applications (partitioning, sharding, and data isolation)