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 ধারা, নাকি ডেটাবেস রো-লেভেল সিকিউরিটি বা এমন ডেটা-অ্যাক্সেস স্তরের মতো ব্যাকস্টপ আছে যা যাই হোক সীমা ঢোকায়? আপনার প্রকৃত কোয়েরি পথ, ব্যাকগ্রাউন্ড কাজ ও ক্যাশ আনুন, কারণ ফাঁস প্রায় সবসময় কেউ সীমাবদ্ধ না করা অ্যাসিনক্রোনাস কোণে লুকিয়ে থাকে। টেন্যান্ট B-র রেকর্ড চাইতে ইচ্ছা করে টেন্যান্ট A-র সেশন ব্যবহার করে অস্বীকৃতি দাবি করা একটি পরীক্ষার ফলও আনুন। সীমানা কেবল মানুষের সতর্কতার ওপর দাঁড়ালে আপনার একটি সুপ্ত ভাঙন আছে, এবং সমাধান (গভীর প্রতিরক্ষা) ব্যাকলগের শীর্ষে ওঠা উচিত।

2. প্রতিটি গ্রাহক স্তর আসলে কোন টেন্যান্সি ও ডেটা-বিভাজন মডেল ব্যবহার করে, এবং তা কি আমরা তাদের যা বেচেছি তার সঙ্গে মেলে? অনেক দল ডিফল্টে একটি একক মডেলে ভেসে যায়, তারপর আবিষ্কার করে তাদের মূল্য ও স্থাপত্য একমত নয়: এন্টারপ্রাইজ গ্রাহকদের এমন বিচ্ছিন্নতার প্রতিশ্রুতি দেওয়া হয়েছিল যা ভাগ করা পুল দেয় না, বা ছোট গ্রাহকরা মার্জিন নষ্ট করা ব্যয়বহুল নিবেদিত স্ট্যাকে বসে। প্রতিটি স্তরকে তার প্রকৃত মডেলে (সাইলো, পুল বা ব্রিজ; প্রতি-টেন্যান্ট ডেটাবেস, স্কিমা বা ভাগ করা টেবিল) মেলান এবং আপনার বিক্রয় দলের দেওয়া চুক্তিগত ডেটা নিশ্চয়তার পাশে রাখুন। যেখানে অমিল, আপনার হয় সম্মতি ঝুঁকি নয়তো খরচ সমস্যা আছে, এবং কোনো গ্রাহক বা নিরীক্ষক পাওয়ার আগে দুটিই প্রকাশ করার যোগ্য। আনার প্রমাণ হলো স্তর-থেকে-মডেল মানচিত্র, প্রতি-টেন্যান্ট খরচ, এবং আপনার এন্টারপ্রাইজ চুক্তির প্রকৃত ভাষা।

3. একটি বড় টেন্যান্টের লোড স্পাইক করলে আর কে অনুভব করে, এবং আমাদের পরিকল্পনা কী? ভাগ করা পুলে উত্তর প্রায়ই “সবাই”, এবং একটি ঘটনা তা স্পষ্ট না করা পর্যন্ত দলগুলো প্রায়ই তা জানে না। আপনার সবচেয়ে বড় টেন্যান্ট বাল্ক ইমপোর্ট চালালে বা ট্রাফিক ঢেউ পেলে কী ঘটে তা হাঁটুন: প্রতি-টেন্যান্ট কোটা ও ন্যায্য শিডিউলিং কি তা সীমিত করে, লোড-শেডিং কি প্রতিবেশীদের রক্ষা করে, নাকি পুরো সিস্টেম একসঙ্গে অবনমিত হয়? লোড ডেটা এবং আপনার শেষ কোলাহলপূর্ণ-প্রতিবেশী ঘটনার গল্প আনুন, কারণ যে টেন্যান্ট আপনাকে আঘাত করে সে সাধারণত এমন একজন যার নাম আপনি বলতে পারেন। উত্তর আপনার হার-সীমাবদ্ধকরণ বিনিয়োগ ও স্তর কৌশল দুটিই আকার দেওয়া উচিত, কারণ ন্যায্য ভাগাভাগি ছাড়িয়ে যাওয়া টেন্যান্টের সবচেয়ে পরিচ্ছন্ন সমাধান হলো তাঁকে এমন একটি ব্রিজ বা নিবেদিত ডিপ্লয়মেন্টে উন্নীত করা যার জন্য আপনি চার্জ করতে পারেন।

4. আগামীকাল একটি টেন্যান্ট অফবোর্ড করলে আমরা কি একটি পরিচ্ছন্ন এক্সপোর্ট দিতে এবং প্রমাণ করতে পারব যে প্রতিটি চিহ্ন মুছেছি, নাকি হুড়োহুড়ি করতাম? অফবোর্ডিং টেন্যান্ট জীবনচক্রের সেই অংশ যা দলগুলো চুক্তি প্রস্থান ধারা বা গোপনীয়তা-আইন অনুরোধ বিষয়টি বাধ্য করা পর্যন্ত অবহেলা করে, এবং তখন ভাগ করা স্কিমা নিষ্কাশন ও মুছে ফেলা যন্ত্রণাদায়ক করে। একটি বড় দলের জন্য ঝুঁকি চক্রবৃদ্ধি হয়, কারণ একটি টেন্যান্টের ডেটা প্রাথমিক ডেটাবেস, ক্যাশ, অবজেক্ট সংরক্ষণ, অনুসন্ধান ইনডেক্স, ব্যাকআপ ও বিশ্লেষণ পাইপলাইনে ছড়ানো, এবং প্রতিটি ব্যবহারযোগ্য ফরম্যাটে এক্সপোর্ট করে তারপর প্রমাণযোগ্যভাবে মুছতে হবে। প্রতিদ্বন্দ্বী বিবেচনা প্রকৃত: আপনাকে সস্তা সংরক্ষণ দেওয়া ঘন ভাগ করা টেবিল ঠিক সেগুলো যা প্রতি-টেন্যান্ট নিষ্কাশন ও মুছে ফেলা সবচেয়ে কঠিন করে, তাই সংরক্ষণ স্তরে কেনা দক্ষতার দাম আপনি প্রস্থানে ফেরত দিতে পারেন। একটি প্রকৃত টেন্যান্টে অফবোর্ডিংয়ের একটি লাইভ হাঁটা, টেন্যান্ট ডেটা ধরে রাখা প্রতিটি স্টোরের তালিকা, এবং মুছে ফেলা আসলে ঘটেছে তা দেখানোর প্রমাণ আনুন। এন্টারপ্রাইজ ও সরকারি টেন্যান্টের জন্য জনরেকর্ড ও গোপনীয়তা বিধি পূরণ করতে এক্সপোর্ট প্রত্যয়িত ও মুছে ফেলা প্রমাণযোগ্য হতে হবে, তাই একটি অনুপস্থিত মুছে ফেলা পথকে কোনো গ্রাহক চলে গেলে যোগ করার ফিচার নয়, এখনই বন্ধ করার সম্মতি ত্রুটি গণ্য করুন।

5. ব্যক্তিগত গ্রাহকদের জন্য কতগুলো একবারের বিশেষ কেস ইতিমধ্যে আমাদের কোড পথে বাস করে, এবং কোথায় রেখা যা আমরা পেরোব না? প্রতি-টেন্যান্ট কোড ফর্ক হলো নিঃশব্দ উপায় যাতে একটি SaaS ব্যবসা একটি পণ্য থেকে একটি নামের নিচে অনেক পণ্য হয়ে ওঠে, যেখানে প্রতিটি পরিবর্তন প্রতিটি বিশেষ কেসের বিপরীতে পরীক্ষা করতে হয় এবং আপনি গ্রাহক যোগ করার সঙ্গে গতি ক্ষয় হয়। টানাপোড়েন হলো প্রকৃত প্রয়োজনের একটি বড় গ্রাহককে প্রত্যাখ্যান করা কঠিন, এবং কোড পথে একটি ব্রাঞ্চ কনফিগারেশন পৃষ্ঠ গড়ার চেয়ে দ্রুত মনে হয়, তাই বিশেষ কেস একটি একটি যুক্তিসঙ্গত ব্যতিক্রমে জমে। একটি সৎ তালিকা আনুন: কোডবেসে গ্রাহকের নাম ও স্তর-নির্দিষ্ট ব্রাঞ্চ grep করুন, গুনুন, এবং প্রতিটি অসম্পর্কিত পরিবর্তনের ওপর যে বাড়তি টেস্ট ও পর্যালোচনা খরচ চাপায় তা অনুমান করুন। আলোচনা প্রথম-শ্রেণির কনফিগারেশন (ফ্ল্যাগ, অধিকার, সম্প্রসারণ বিন্দু) হিসেবে মডেল করা ভিন্নতা এবং একক-টেন্যান্ট প্রিমিয়াম স্তরের জন্য সংরক্ষিত সত্যিকারের বিশেষায়িত কাজের মধ্যে একটি দৃঢ় রেখা টানা উচিত, যেখানে উচ্চতর দাম পরিচালনগত খরচ ঢাকে। গভীর কাস্টমাইজেশন দাবি করা এন্টারপ্রাইজ ক্রেতাদের জন্য টেকসই উত্তর হলো সম্প্রসারণ বিন্দু যা আপনার ব্রাঞ্চ না করে তাদের যুক্তি চালায়, যাতে বহর জুড়ে শাসন ও নিরীক্ষা সামলানো-যায় থাকে।

6. আমরা কি প্রতি টেন্যান্টে বলতে পারি একটি ঘটনা কাকে কত খরচ করছে, এবং কোন গ্রাহকরা তাঁদের বর্তমান দামে অলাভজনক? আপনার লগ, ট্রেস, মেট্রিক ও অবকাঠামো খরচে কোনো টেন্যান্ট মাত্রা না থাকলে মাল্টি-টেন্যান্সি ব্ল্যাক বক্স হয়ে যায়, কারণ তখন আপনি বলতে পারেন না একটি বিভ্রাট একটি টেন্যান্ট নাকি পুরো বহর, এবং চুক্তি মূল্যে ক্ষতিতে থাকা টেন্যান্টের নাম বলতে পারেন না। একটি বড় দলের জন্য এই আরোপই প্ল্যাটফর্ম চালানো ও তা নিয়ে অনুমান করার পার্থক্য, এবং এটি নির্ভরযোগ্যতা সাড়া ও মূল্য নির্ধারণ দুটিই সরাসরি আকার দেয়। বিবেচনা যন্ত্রসজ্জা খরচ ও কার্ডিনালিটির বিপরীতে টানে: সবকিছু টেন্যান্ট ধরে ট্যাগ করা বিনামূল্যের নয়, এবং উচ্চ-কার্ডিনালিটি মেট্রিক আপনার অবজার্ভেবিলিটি বাজেটে চাপ দেয়, তাই আপনি সুচিন্তিতভাবে বাছেন প্রতি টেন্যান্টে কী ভাগ করবেন আর কী নমুনা করবেন। আপনার বর্তমান টেন্যান্ট-ট্যাগিং কভারেজ, একক টেন্যান্টে ক্লাউড ব্যয় আরোপ করা একটি প্রকৃত কোয়েরি, এবং আপনার সবচেয়ে কম লাভজনক গ্রাহকের নাম বলতে দেওয়া মার্জিন টেবিল আনুন। এন্টারপ্রাইজ ও সরকারি পরিবেশে প্রতি-টেন্যান্ট খরচ ও নিরীক্ষা-পরিসরের অবজার্ভেবিলিটি চার্জব্যাক, সক্ষমতা পরিকল্পনা এবং প্রতিটি সংস্থা বা ব্যবসা ইউনিট যে নিরীক্ষা সীমানার প্রাপ্য তাতেও জোগান দেয়, তাই টেন্যান্ট মাত্রা পরিচালনগত প্রয়োজনের মতোই শাসন প্রয়োজন।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। প্রথম দিন থেকে একটি একক ভাগ করা পুল পাঠান এবং আপনার দুর্লভ প্রকৌশল মনোযোগ ঢালুন সেই একটি জিনিসে যা পরে জুড়ে দেওয়া যায় না: প্রয়োগ করা টেন্যান্ট সীমাবদ্ধতা। রো-লেভেল সিকিউরিটিসহ একটি ম্যানেজড Postgres, প্রতিটি টেবিলে একটি tenant_id, এবং প্রান্তে সমাধান করা টেন্যান্ট প্রসঙ্গ আপনাকে পরিচালনা দল ছাড়াই নিরাপদ ঘনত্ব কেনে। অনুমানের ভিত্তিতে সাইলো স্তর বা প্রতি-টেন্যান্ট অবকাঠামো গড়বেন না; একটি বেতনভোগী এন্টারপ্রাইজ সম্ভাব্য গ্রাহক বিচ্ছিন্নতাকে খরচের যোগ্য করলেই কেবল ব্রিজ স্তর যোগ করুন।

ছোট ব্যবসা। কোনো প্ল্যাটফর্ম বিশেষজ্ঞ নেই আর বাজেট কম, তাই বিচ্ছিন্নতা যন্ত্রপাতি নিজে গড়ার বদলে আপনার ক্লাউড ও ফ্রেমওয়ার্ক ইতিমধ্যে যা দেয় তার ওপর ভর করুন। রো-লেভেল সিকিউরিটিসহ ম্যানেজড ডেটাবেস, আপনার জন্য টেন্যান্ট সীমিত করা একটি প্ল্যাটফর্ম-অ্যাজ-আ-সার্ভিস, এবং টেন্যান্ট পরিচয় বহনকারী একটি প্রমাণীকরণ প্রদানকারী সাধারণত হাতে-গড়া সমতুল্যের চেয়ে সস্তা ও নিরাপদ। প্রতিটি স্তরে মাল্টি-টেন্যান্সিকে কেনা-বনাম-বানানোর সিদ্ধান্ত গণ্য করুন, এবং কাস্টম কাজ সংরক্ষণ করুন কেবল আপনি লিখতে পারেন এমন টেন্যান্ট সীমানা পরীক্ষার জন্য।

এন্টারপ্রাইজ। সমস্যা অনেক দল জুড়ে পোর্টফোলিও শাসন: একটি স্তরিত ব্রিজ স্থাপত্য, প্রতিটি স্তরকে তার টেন্যান্সি ও ডেটা-বিভাজন মডেলে মেলানো একটি স্থাপত্য সিদ্ধান্ত রেকর্ড, এবং প্রতি-টেন্যান্ট খরচ আরোপ যাতে অর্থ বিভাগ প্রতিটি অ্যাকাউন্টের প্রকৃত মার্জিন জানে। টেন্যান্ট-প্রসঙ্গ প্রচার ও সীমাবদ্ধতা ব্যাকস্টপ প্রমিত করুন যাতে কোনো দল তা পুনরাবিষ্কার না করে, বিচ্ছিন্নতা ও জীবনচক্র স্বয়ংক্রিয়তা সুস্পষ্টভাবে বাজেট করুন, এবং একটি টেন্যান্ট বাড়লে বা তার সম্মতি প্রয়োজন বদলালে ডাউনটাইম ছাড়া তাকে স্তরের মধ্যে স্থানান্তর করার একটি সমর্থিত, মূল্য-নির্ধারিত পথ রাখুন।

সরকার। ক্রয়, ডেটা আবাসন ও জনগণের কাছে জবাবদিহি মডেল চালায়। নীতি-হিসেবে-কোড দিয়ে প্রতিটি সংস্থার ডেটা দেশের ভেতরের অঞ্চলে পিন করুন, সংবেদনশীল বা উচ্চ-শ্রেণির ওয়ার্কলোড নিজস্ব নিরীক্ষা সীমানাসহ আলাদা অ্যাকাউন্টে সাইলো করুন, এবং প্রতিটি সংস্থাকে নিজস্ব পরিচয় ইন্টিগ্রেশন, ধারণ নিয়ম ও নিরীক্ষা ট্রেইল দিন যাতে এক সংস্থার নিরীক্ষকরা কখনো অন্যের কার্যকলাপ না দেখেন। অফবোর্ডিংকে জনরেকর্ড ও গোপনীয়তা বিধি পূরণ করতে একটি প্রত্যয়িত এক্সপোর্ট ও প্রমাণযোগ্য মুছে ফেলা তৈরি করতে হবে, এবং আপনার স্বাক্ষরিত টেন্যান্সি নিশ্চয়তা এমন হতে হবে যা আপনার স্থাপত্য আসলে রাখতে পারে।

উদাহরণ

স্টার্টআপ। পনেরোজনের একটি স্টার্টআপ প্রথম দিন থেকে একটি একক ভাগ করা পুল হিসেবে তার পণ্য গড়ে এবং এটি সঠিক। সব টেন্যান্ট প্রতিটি টেবিলে একটি tenant_id-সহ একটি ম্যানেজড Postgres ডেটাবেস ভাগ করে, রো-লেভেল সিকিউরিটি ডেটাবেসে টেন্যান্ট শর্ত প্রয়োগ করে যাতে ভুলে যাওয়া ফিল্টার ফাঁস করতে না পারে, এবং অ্যাপ্লিকেশন প্রান্তে একটি সাবডোমেইন থেকে টেন্যান্ট সমাধান করে প্রতিটি অনুরোধ ও ব্যাকগ্রাউন্ড কাজের মধ্য দিয়ে বয়ে নেয়। অনবোর্ডিং স্ব-সেবা: একটি নতুন সাইনআপ তার টেন্যান্ট সারি প্রভিশন করে, ডিফল্ট সিড করে, এবং সেকেন্ডে চালু। দুজন ইঞ্জিনিয়ার পুরো প্ল্যাটফর্ম চালান কারণ চালানোর একটি সিস্টেম। তাদের প্রথম প্রকৃত এন্টারপ্রাইজ সম্ভাব্য গ্রাহক নিবেদিত ডেটাবেস ও চুক্তিগত বিচ্ছিন্নতা নিশ্চয়তা দাবি করলে তারা একটি ব্রিজ স্তর যোগ করে: একই কোডবেস, কিন্তু এই টেন্যান্ট নিজস্ব শার্ডে নিজস্ব ডেটাবেস পায়, খরচ ঢাকা দামে বিক্রি।

এন্টারপ্রাইজ। বড় আর্থিক প্রতিষ্ঠানকে সেবা দেওয়া একটি SaaS বিক্রেতা একটি স্তরিত ব্রিজ স্থাপত্য চালায়। হাজার হাজার ছোট ও মাঝারি গ্রাহক আঞ্চলিক ভাগ করা পুলে বাস করে, টেন্যান্ট ধরে শার্ড করা, কোটা ও ন্যায্য শিডিউলিং কোলাহলপূর্ণ প্রতিবেশীদের নিয়ন্ত্রণে রেখে। শীর্ষ-স্তরের ব্যাংকিং গ্রাহকরা বিচ্ছিন্ন ক্লাউড অ্যাকাউন্টে একক-টেন্যান্ট ডিপ্লয়মেন্ট পায়, নিবেদিত ডেটাবেস, প্রতি-টেন্যান্ট এনক্রিপশন কী এবং মাস্টার চুক্তিতে লেখা চুক্তিগত ডেটা-আবাসন ও বিচ্ছিন্নতা নিশ্চয়তাসহ। একটি প্ল্যাটফর্ম সামর্থ্য একটি টেন্যান্ট বাড়লে বা তার সম্মতি প্রয়োজন বদলালে ডাউনটাইম ছাড়া তাকে স্তরের মধ্যে স্থানান্তর করে। ট্যাগিংয়ের মাধ্যমে প্রতিটি টেন্যান্টের খরচ আরোপিত তাই অর্থ বিভাগ প্রতিটি অ্যাকাউন্টের প্রকৃত মার্জিন জানে, এবং টেন্যান্ট-ট্যাগ করা অবজার্ভেবিলিটি অন-কল ইঞ্জিনিয়ারকে সেকেন্ডে বলতে দেয় একটি অ্যালার্ট একটি টেন্যান্ট নাকি পুরো বহর।

সরকার। একটি জাতীয় প্ল্যাটফর্ম প্রদানকারী অনেক সরকারি সংস্থাকে আলাদা টেন্যান্ট হিসেবে হোস্ট করে এবং বিচ্ছিন্নতাকে পছন্দ নয়, আইনি প্রয়োজন গণ্য করে। ডেটা আবাসন আইন প্রতিটি সংস্থার ডেটা দেশের ভেতরের অঞ্চলে পিন করে, নীতি-হিসেবে-কোড দ্বারা প্রয়োগ করা যা অননুমোদিত অঞ্চলে যেকোনো সম্পদ আটকায় (অধ্যায় 3.11)। শ্রেণিবিন্যাস মডেল চালায়: সংবেদনশীল উপাদান সামলানো সংস্থা নিজস্ব নিরীক্ষা সীমানাসহ আলাদা অ্যাকাউন্টে পূর্ণ সাইলো করা ডিপ্লয়মেন্ট পায়, যখন কম-শ্রেণির ওয়ার্কলোড একটি শাসিত পুল ভাগ করে। প্রতিটি সংস্থা নিজস্ব পরিচয় ইন্টিগ্রেশন, নিজস্ব ধারণ ও এক্সপোর্ট নিয়ম এবং তার সীমানায় সীমিত একটি নিরীক্ষা ট্রেইলসহ নিজেই একটি টেন্যান্ট, তাই এক সংস্থার নিরীক্ষকরা কখনো অন্যের কার্যকলাপ দেখেন না। অফবোর্ডিং একটি প্রত্যয়িত ডেটা এক্সপোর্ট ও প্রমাণযোগ্য মুছে ফেলা তৈরি করে, কারণ রেকর্ডগুলো জনরেকর্ড ও গোপনীয়তা বিধির অধীন।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

মাল্টি-টেন্যান্সির মূল ব্যবসায়িক যুক্তি মার্জিন। একটি একক-টেন্যান্ট মডেল, যেখানে আপনি প্রতি গ্রাহকে একটি নতুন কপি ডিপ্লয় করেন, মানে অবকাঠামো ও পরিচালনা খরচ গ্রাহক সংখ্যার সঙ্গে মোটামুটি রৈখিকভাবে বাড়ে, এবং আপনার ইঞ্জিনিয়াররা অনেক কপি প্যাচ করে দিন কাটায়। একটি ভাগ করা মাল্টি-টেন্যান্ট মডেল সেই যোগসূত্র ভাঙে: আপনি একবার প্যাচ করেন, একটি সিস্টেম স্কেল করেন, এবং গ্রাহকদের এত ঘন প্যাক করেন যে পরের টেন্যান্টের প্রান্তিক খরচ শূন্যের কাছে যায়। এটাই একটি SaaS ব্যবসাকে খরচের চেয়ে অনেক দ্রুত রাজস্ব বাড়াতে দেয়, এবং এ কারণেই বিনিয়োগকারী ও বোর্ড একটি পরিচ্ছন্ন মাল্টি-টেন্যান্ট স্থাপত্যকে একটি স্কেলযোগ্য কোম্পানির প্রতিনিধি গণ্য করে।

প্রতিদান দেখা দেয় তিন জায়গায়: পরিচালনগত লিভারেজ (একটি দল পুরো বহর চালায়), দ্রুততর সরবরাহ (একটি সমাধান সব টেন্যান্টের কাছে একসঙ্গে যায়, তাই গ্রাহক যোগ করলে গতি ক্ষয় হয় না), এবং মূল্য নির্ধারণের বিকল্প (দীর্ঘ লেজের জন্য একটি ভাগ করা প্ল্যান এবং এন্টারপ্রাইজের জন্য একটি প্রিমিয়াম বিচ্ছিন্ন প্ল্যান, একই কোডবেস থেকে)। এগুলো সৎভাবে অর্থায়ন করতে হওয়া খরচের বিপরীতে রাখুন: প্রয়োগ করা টেন্যান্ট বিচ্ছিন্নতা, কোটা, জীবনচক্র স্বয়ংক্রিয়তা ও প্রতি-টেন্যান্ট অবজার্ভেবিলিটি গড়ার প্রকৌশল, সঙ্গে সীমানা অক্ষত রাখার শৃঙ্খলা। ভুল হওয়ার খরচ অসমমিত ও গুরুতর, কারণ একটি একক টেন্যান্ট-জোড়া ডেটা ভাঙন নিয়ন্ত্রক জরিমানা, গণ গ্রাহক হারানো এবং সুনামের ক্ষতি ট্রিগার করতে পারে যা ভাগাভাগি করে আপনি যে অবকাঠামো বাঁচিয়েছেন তাকে বামন করে। নেতৃত্বের কাছে যুক্তি ফ্রেম করুন ঊর্ধ্বমুখী মার্জিন ও স্কেলেবিলিটি এবং নিম্নমুখী অস্তিত্বগত ঝুঁকি হিসেবে। সেবা-স্তরের চুক্তি ও চুক্তিগত ডেটা নিশ্চয়তা আপনি প্রকৃতই দিতে পারেন এমন টেন্যান্সি মডেলে নোঙর করুন, কারণ আপনার স্থাপত্য রাখতে পারে না এমন প্রতিশ্রুতি একটি দায়, বিক্রয় নয়।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• রীতিতে টেন্যান্ট সীমাবদ্ধতা। ডেটাবেস-স্তর বা ডেটা-অ্যাক্সেস-স্তরের ব্যাকস্টপ ছাড়া প্রতিটি কোয়েরিতে টেন্যান্ট ফিল্টার মনে রাখতে ডেভেলপারদের ওপর নির্ভর; একটি বাদ পড়া মানে ভাঙন।
• ক্লায়েন্ট-দেওয়া টেন্যান্ট শনাক্তকারীতে বিশ্বাস। প্রমাণীকৃত পরিচয় থেকে বের না করে অনুমোদনের জন্য অনুরোধ ইনপুট থেকে টেন্যান্ট গ্রহণ, যা কলারকে অন্য কারও ডেটা চাইতে দেয়।
• অসীমিত ব্যাকগ্রাউন্ড কাজ। জব, ক্যাশ, ওয়েবহুক ও এক্সপোর্ট যা টেন্যান্ট প্রসঙ্গ হারায় কারণ কেউ কেবল সিঙ্ক্রোনাস অনুরোধ পথ সীমিত করেছিল।
• প্রতি-টেন্যান্ট কোড ফর্ক। একটি বড় গ্রাহককে কোড পথে বিশেষ-কেস করা যতক্ষণ না আপনি একটি নামের নিচে অনেক ভিন্নমুখী পণ্য রক্ষণাবেক্ষণ করছেন এবং প্রতিটি পরিবর্তন দশ গুণ খরচ করে।
• কোলাহলপূর্ণ-প্রতিবেশী প্রতিরক্ষা নেই। প্রতি-টেন্যান্ট কোটা বা ন্যায্যতা ছাড়া একটি ভাগ করা পুল চালানো, তাই স্পাইক করা প্রথম টেন্যান্ট সবাইকে নামিয়ে দেয়।
• পরবর্তী ভাবনা হিসেবে অফবোর্ডিং। ডেটা এক্সপোর্ট ও প্রমাণযোগ্য মুছে ফেলা ছাড়া গড়া, তারপর একজন গ্রাহকের প্রস্থান ধারা বা গোপনীয়তা-আইন অনুরোধে ব্যর্থ হওয়া কারণ ভাগ করা স্কিমা নিষ্কাশন যন্ত্রণাদায়ক।
• প্রতি টেন্যান্টে অন্ধ উড়া। টেন্যান্ট মাত্রা ছাড়া লগ, মেট্রিক ও খরচ, তাই বলতে পারেন না এটি কার ঘটনা বা কোন টেন্যান্ট অলাভজনক।

পরিপক্বতা মডেল

• স্তর ১, সূচনা: মাল্টি-টেন্যান্সি উদ্ভাবিত ও প্রতিক্রিয়াশীল। টেন্যান্ট বিভাজন ব্যাকস্টপ ছাড়া হাতে-লেখা ফিল্টারের ওপর দাঁড়ায়, মডেল একমাপ-সবার-জন্য, কোনো কোটা নেই, অনবোর্ডিং হাতে-করা, এবং লগ ও খরচে কোনো টেন্যান্ট মাত্রা নেই। দল কোলাহলপূর্ণ প্রতিবেশী ও প্রায়-ফাঁস ঘটনা থেকে জানে।
• স্তর ২, বিকাশ: মৌলিক চর্চা দেখা দেয় কিন্তু দল জুড়ে অসঙ্গত। একটি টেন্যান্সি মডেল বাছা, মূল অনুরোধ পথে টেন্যান্ট প্রসঙ্গ প্রচারিত, একটি ডেটাবেস-স্তর বা ডেটা-অ্যাক্সেস ব্যাকস্টপ মূল টেবিলে সীমাবদ্ধতা প্রয়োগ করে, এবং মৌলিক প্রতি-টেন্যান্ট কোটা আছে। অনবোর্ডিং আংশিক স্বয়ংক্রিয় এবং লগ একটি টেন্যান্ট শনাক্তকারী বহন করে, কিন্তু ব্যাকগ্রাউন্ড পথ, এক্সপোর্ট ও খরচ আরোপ সার্ভিস থেকে সার্ভিসে ভিন্ন এবং কোথাও লেখা নেই।
• স্তর ৩, মানসম্মতকরণ: টেন্যান্সি পদ্ধতি প্রতিষ্ঠান জুড়ে নথিবদ্ধ ও প্রয়োগ করা। স্তরিত টেন্যান্সি মূল্যের সঙ্গে মেলে, ছোট টেন্যান্টের জন্য ভাগ করা পুল ও এন্টারপ্রাইজ এবং নিয়ন্ত্রিতদের জন্য বিচ্ছিন্ন ডিপ্লয়মেন্টসহ, টেন্যান্ট সীমাবদ্ধতা গভীরে প্রয়োগ ও ইচ্ছা করে পরীক্ষিত, কোটা ও ন্যায্য শিডিউলিং কোলাহলপূর্ণ প্রতিবেশী সীমিত করে, এক্সপোর্ট ও প্রমাণযোগ্য মুছে ফেলাসহ টেন্যান্ট জীবনচক্র স্বয়ংক্রিয়, এবং অবজার্ভেবিলিটি ও খরচ প্রতি টেন্যান্টে ভাগ করা। প্রতিটি দল নিজস্ব নয়, একই টেন্যান্সি মান অনুসরণ করে।
• স্তর ৪, ব্যবস্থাপনা: টেন্যান্সি সম্পত্তি ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত। প্রতি-টেন্যান্ট বিচ্ছিন্নতা, ন্যায্যতা, লেটেন্সি ও খরচ সম্মত লক্ষ্যসহ মেট্রিক হিসেবে অনুসরণ করা হয়: টেন্যান্ট-জোড়া টেস্ট কভারেজ, কোটা-লঙ্ঘন ও কোলাহলপূর্ণ-প্রতিবেশী ঘটনার হার, অনবোর্ডিং ও অফবোর্ডিং সময়, এবং প্রতি-টেন্যান্ট মার্জিন ভিত্তিরেখার বিপরীতে প্রতিবেদিত, এবং একটি টেন্যান্টকে স্তরের মধ্যে উন্নীত করা বা অলাভজনককে পুনর্মূল্য দেওয়ার সিদ্ধান্ত উপাখ্যানের বদলে সেই প্রমাণে নেওয়া হয়। আবাসন ও শ্রেণিবিন্যাস সামঞ্জস্য নিরন্তর পর্যবেক্ষিত, এবং মান থেকে সরে যাওয়া একটি নথিবদ্ধ সাড়া ট্রিগার করে।
• স্তর ৫, সমন্বয়: টেন্যান্সি নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে একীভূত। টেন্যান্ট-জোড়া সীমানা রুটিন রেড-টিম অনুশীলনে চর্চা করা হয়, টেন্যান্ট বাড়লে বা তাদের সম্মতি প্রয়োজন বদলালে ডাউনটাইম ছাড়া স্তরের মধ্যে সরে, প্রতি-টেন্যান্ট মার্জিন মূল্য ও সক্ষমতা পরিকল্পনায় জোগান দেয়, এবং আবাসন ও শ্রেণিবিন্যাস নিয়ম পর্যালোচনার বদলে নীতি দ্বারা প্রয়োগ হয়। গ্রাহক মিশ্রণ ও নিয়ন্ত্রক চিত্র সরলে মডেল খাপ খায়, এবং শিক্ষা পণ্য, নিরাপত্তা ও অর্থে একটি চক্র হিসেবে জোগান দেয়।

আলোচনার ভাবনা

1. আজ আপনার প্রতিটি গ্রাহক স্তর বিচ্ছিন্নতা-বনাম-দক্ষতা বর্ণালীর কোথায় বসে, এবং কোনো স্তর কি আপনি যে নিশ্চয়তা বেচেছেন বা যে মার্জিন দরকার তার জন্য ভুল মডেলে?
2. একজন নিরীক্ষকের কাছে টেন্যান্ট A টেন্যান্ট B-র ডেটা অ্যাক্সেস করতে পারে না প্রমাণ করতে হলে, আপনি এখনই কী প্রমাণ দিতে পারতেন, এবং তার কতটা স্বয়ংক্রিয় বনাম দাবি করা?
3. আপনার কোন অ্যাসিনক্রোনাস পথ (জব, ক্যাশ, ওয়েবহুক, এক্সপোর্ট, অনুসন্ধান ইনডেক্স) টেন্যান্ট প্রসঙ্গ পুনঃপ্রতিষ্ঠা করে, আর কোনগুলো কেবল তা উত্তরাধিকার পায় বা কলারকে বিশ্বাস করে?
4. কোনো টেন্যান্ট ন্যায্য ভাগাভাগি ছাড়িয়ে গেলে আপনার কি একটি ব্রিজ বা নিবেদিত ডিপ্লয়মেন্টে একটি সমর্থিত, মূল্য-নির্ধারিত উন্নীতকরণ পথ আছে, নাকি উত্তর ডিফল্টে একটি ঘটনা?
5. আপনার সবচেয়ে কম লাভজনক গ্রাহকের নাম বলতে পারার মতো যথেষ্ট ভালোভাবে কি আপনি প্রতি টেন্যান্টে অবকাঠামো খরচ আরোপ করতে পারেন, এবং তা কি আপনার মূল্য নির্ধারণ বদলাত?
6. একটি সরকারি বা নিয়ন্ত্রিত টেন্যান্টের জন্য আপনি কি নীতি দ্বারা ডেটা আবাসন ও শ্রেণিবিন্যাস-চালিত বিচ্ছিন্নতা প্রয়োগ করতে এবং প্রত্যয়িত এক্সপোর্ট ও প্রমাণযোগ্য মুছে ফেলাসহ অফবোর্ড করতে পারেন?

প্রধান শিক্ষা

• মাল্টি-টেন্যান্সি, একটি ইনস্ট্যান্স অনেক টেন্যান্টকে সেবা দেওয়া, SaaS-এর অর্থনৈতিক ইঞ্জিন: এটি আপনার মার্জিন চালায় এবং টেন্যান্ট-জোড়া বিচ্ছিন্নতাকে আপনার স্থাপত্যের কেন্দ্রে বসায়।
• বিচ্ছিন্নতা বনাম দক্ষতাকে বর্ণালী গণ্য করে স্তর করুন: ছোট টেন্যান্টদের দক্ষ ভাগ করা পুলে প্যাক করুন, বড় ও নিয়ন্ত্রিত টেন্যান্টদের ব্রিজ বা সাইলো ডিপ্লয়মেন্টে বিচ্ছিন্ন করুন যার জন্য তারা অর্থ দেবে।
• টেন্যান্ট সীমাবদ্ধতা কখনো হাতে-লেখা ফিল্টারের ওপর রাখবেন না; রো-লেভেল সিকিউরিটি বা ডেটা-অ্যাক্সেস স্তর দিয়ে গভীরে প্রয়োগ করুন এবং সীমানা ইচ্ছা করে পরীক্ষা করুন।
• প্রতিটি অনুরোধ, জব, ক্যাশ ও লগের মধ্য দিয়ে টেন্যান্ট প্রসঙ্গ প্রচার করুন, এবং যেখানে ফাঁস লুকায় সেই অ্যাসিনক্রোনাস পথ রক্ষা করুন।
• প্রতি-টেন্যান্ট কোটা, হার সীমা ও ন্যায্য শিডিউলিং দিয়ে কোলাহলপূর্ণ প্রতিবেশী নিয়ন্ত্রণ করুন, এবং পুলের চেয়ে বড় হওয়া টেন্যান্টদের তা অবনমিত করতে না দিয়ে উন্নীত করুন।
• প্রতি-টেন্যান্ট কোডের বদলে প্রতি-টেন্যান্ট কনফিগারেশন দিয়ে পণ্য বাঁকান, এবং টেন্যান্ট জীবনচক্র ও প্রতি-টেন্যান্ট অবজার্ভেবিলিটি ও খরচ আরোপ প্রথম-শ্রেণির করুন।

তথ্যসূত্র ও আরও পড়ার জন্য

• Tom Kwok, Thao Nguyen ও 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 ও Gianpaolo Carraro, Architecture Strategies for Catching the Long Tail (Microsoft)
• Amazon Web Services, SaaS Lens, AWS Well-Architected Framework এবং SaaS Tenant Isolation Strategies
• Microsoft, Multitenant SaaS architecture and patterns (Azure Architecture Centre)
• Google Cloud, Architecture for Multi-tenant SaaS Applications
• Cor-Paul Bezemer ও 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 (অ্যাক্সেস-নিয়ন্ত্রণ ও মাল্টি-টেন্যান্সি প্রয়োজন)
• Martin Kleppmann, Designing Data-Intensive Applications (বিভাজন, শার্ডিং ও ডেটা বিচ্ছিন্নতা)