জানুন কীভাবে মাল্টি-টেন্যান্ট ডাটাবেস নিরাপত্তা ও পারফরম্যান্স প্রভাবিত করে, প্রধান ঝুঁকি (আইসোলেশন, শোরগোলকারী প্রতিবেশী সমস্যা) এবং টেন্যান্টদের নিরাপদ ও দ্রুত রাখার ব্যবহারিক নিয়ন্ত্রণ।
মাল্টি-টেন্যান্ট ডাটাবেস হচ্ছে এমন একটি সেটআপ যেখানে অনেক গ্রাহক (টেন্যান্ট) একই ডাটাবেস সিস্টেম শেয়ার করে—একই ডাটাবেস সার্ভার, একই আন্ডারলায়িং স্টোরেজ, এবং প্রায়শই একই স্কিমা—এবং অ্যাপ্লিকেশন নিশ্চিত করে যে প্রতিটি টেন্যান্ট শুধুমাত্র তাদের নিজস্ব ডেটা অ্যাক্সেস করবে।
এটাকে ভাবুন একটি অ্যাপার্টমেন্ট বিল্ডিংয়ের মতো: সবাই বিল্ডিং-এর স্ট্রাকচার ও ইউটিলিটি শেয়ার করে, কিন্তু প্রত্যেক টেন্যান্টের নিজের লক করা ইউনিট আছে।
সিংগেল-টেন্যান্ট পদ্ধতিতে প্রতিটি গ্রাহককে ডেডিকেটেড ডাটাবেস রিসোর্স দেওয়া হয়—উদাহরণস্বরূপ, তাদের নিজস্ব ডাটাবেস ইন্সট্যান্স বা সার্ভার। আইসোলেশন বোঝা সহজ, কিন্তু গ্রাহক বাড়লে সাধারণত বেশি খরচ এবং অপারেশনাল ওজন থাকে।
মাল্টি-টেন্যান্ট-এ টেন্যান্টরা ইনফ্রা শেয়ার করে, যা দক্ষ হতে পারে—কিন্তু এর মানে হল আপনার ডিজাইনের মাধ্যমে সেই বাউন্ডারি ইন্টেনশনালি প্রয়োগ করতে হবে।
SaaS কোম্পানিগাńকরা প্রায়শই বাস্তব কারণে মাল্টি-টেন্যান্সি ব্যবহার করে:
মাল্টি-টেন্যান্সি নিজে থেকেই “নিরাপদ” বা “দ্রুত” নয়। ফলাফল নির্ভর করে সিদ্ধান্তগুলোর ওপর—কীভাবে টেন্যান্ট আলাদা করা হচ্ছে (স্কিমা, রো, বা ডাটাবেস), কীভাবে অ্যাক্সেস কন্ট্রোল প্রয়োগ করা হচ্ছে, কীভাবে এনক্রিপশন কী হ্যান্ডেল হচ্ছে, এবং কীভাবে একটি টেন্যান্টের ওয়ার্কলোড অন্যদের ধীর করে দেওয়া থেকে প্রতিরোধ করা হচ্ছে।
এই গাইডের বাকি অংশ সেই ডিজাইন পছন্দগুলোর ওপর ফোকাস করবে—কারণ মাল্টি-টেন্যান্ট সিস্টেমে নিরাপত্তা এবং পারফরম্যান্স এমন ফিচার যেগুলো আপনাকে তৈরি করতে হবে, না যে আপনি স্বয়ংক্রিয়ভাবে পেয়ে যাবেন।
মাল্টি-টেন্যান্সি একক ডিজাইন নয়—এটি এমন একটি স্পেকট্রাম যেখানে আপনি কতটা ঘনিষ্টভাবে ইনফ্রা শেয়ার করবেন তা নির্ধারিত হয়। আপনি যে মডেলটি বেছে নেবেন তা আপনার আইসোলেশন বাউন্ডারি (কোনটুকু কখনও শেয়ার করা চলবে না) নির্ধারণ করে, এবং সেটাই সরাসরি ডাটাবেস নিরাপত্তা, পারফরম্যান্স আইসোলেশন এবং দৈনন্দিন অপারেশনকে প্রভাবিত করে।
প্রতিটি টেন্যান্টকে তাদের নিজস্ব ডাটাবেস দেওয়া হয় (প্রায়শই একই সার্ভার বা ক্লাস্টারে)।
আইসোলেশন বাউন্ডারি: ডাটাবেস নিজেই। এটা সাধারণত সবচেয়ে পরিষ্কার টেন্যান্ট আইসোলেশন কারণ ক্রস-টেন্যান্ট অ্যাক্সেস সাধারণত ডাটাবেস বাউন্ডারি ক্রস করার প্রয়োজন করে।
অপারেশনাল ট্রেড-অফ: স্কেলে অপারেশন করা ভারী। আপগ্রেড এবং স্কিমা মাইগ্রেশন অনেকবার চালাতে হতে পারে, এবং কানেকশন পুলিং জটিল হয়ে যেতে পারে। ব্যাকআপ/রিস্টোর সুবিধাজনক হলেও স্টোরেজ ও ম্যানেজমেন্ট ওভারহেড দ্রুত বৃদ্ধি পেতে পারে।
নিরাপত্তা ও টিউনিং: গ্রাহক অনুযায়ী সিকিউর করা ও টিউন করা সহজ, এবং যখন টেন্যান্টদের আলাদা কমপ্লায়েন্স প্রয়োজন হয় তখন এটি ভাল ফিট।
টেন্যান্টরা একটি ডাটাবেস শেয়ার করে, কিন্তু প্রতিটির নিজস্ব স্কিমা থাকে।
আইসোলেশন বাউন্ডারি: স্কিমা। তা যৌক্তিক আলাদা, কিন্তু সঠিক পারমিশন এবং টুলিংয়ের ওপর নির্ভর করে।
অপারেশনাল ট্রেড-অফ: আপগ্রেড ও মাইগ্রেশন এখনও পুনরাবৃত্তিপূর্ণ, কিন্তু ডাটাবেস-প্রতি মডেলে তুলনামূলকভাবে হালকা। ব্যাকআপ একটু জটিল: অনেক টুল ডাটাবেসকে ব্যাকআপ ইউনিট হিসেবে ধরে, তাই টেন্যান্ট-লেভেল অপারেশন করতে স্কিমা-লেভেল এক্সপোর্ট লাগতে পারে।
নিরাপত্তা ও টিউনিং: শেয়ার টেবিলের চেয়ে আলাদা করার দিক থেকে সহজ, কিন্তু প্রিভিলেজ ও ভুল কুয়েরি অন্য স্কিমা রেফার না করে তা নিশ্চিত করা জরুরি।
সব টেন্যান্ট একটি ডাটাবেস ও স্কিমা শেয়ার করে, কিন্তু প্রতিটি টেন্যান্টের আলাদা টেবিল থাকে (যেমন orders_tenant123).
আইসোলেশন বাউন্ডারি: টেবিল সেট। এটি কিছু সংখ্যার টেন্যান্টের জন্য কাজ করতে পারে, কিন্তু স্কেল করতে খারাপ: মেটাডেটা বমট, মাইগ্রেশন স্ক্রিপ্ট জটিল হয়ে ওঠে, এবং কুয়েরি প্ল্যানিং খারাপ হতে পারে।
নিরাপত্তা ও টিউনিং: পারমিশন নিখুঁতভাবে নির্ধারণ করা যায়, তবু অপারেশনাল জটিলতা বেশি এবং নতুন টেবিল বা ফিচার যোগ করার সময় সহজেই ভুল হতে পারে।
সব টেন্যান্ট একই টেবিল শেয়ার করে, tenant_id কলামের মাধ্যমে আলাদা করা হয়।
আইসোলেশন বাউন্ডারি: আপনার কুয়েরি ও অ্যাক্সেস-কন্ট্রোল লেয়ার (সাধারণত রো-লেভেল সিকিউরিটি)। এই মডেল অপারেশনালি দক্ষ—একই স্কিমা মাইগ্রেট করে, একাধিক ইন্ডেক্স স্ট্র্যাটেজি মেইনটেইন—but এটি ডাটাবেস নিরাপত্তা ও পারফরম্যান্স আইসোলেশনের জন্য সবচেয়ে ডিমান্ডিং।
নিরাপত্তা ও টিউনিং: প্রতিটি কুয়েরি টেন্যান্ট-অ্যাওয়ার হতে হবে; না হলে noisy neighbor সমস্যা বেশি হবে যদি আপনি রিসোর্স থ্রটলিং এবং সাবধানে ইন্ডেক্স না যোগ করেন।
একটি উপকারী নিয়ম: আপনি যত বেশি শেয়ার করবেন, আপগ্রেডগুলি তত সহজ হবে—তবে টেন্যান্ট আইসোলেশন কন্ট্রোল ও পারফরম্যান্স আইসোলেশনে আপনাকে তত বেশি কঠোর হতে হবে।
মাল্টি-টেন্যান্সি কেবল "একাধিক গ্রাহক একটি ডাটাবেসে" মানে নয়। এটি আপনার থ্রেট মডেল বদলে দেয়: সবচেয়ে বড় ঝুঁকি হয়ে ওঠে অনুমোদিত ব্যবহারকারীরা ত্রুটিভবাে (বা ইচ্ছাকৃতভাবে) অন্য টেন্যান্টের ডেটা দেখা।
অথেনটিকেশন উত্তর দেয় “আপনি কে?” অথরাইজেশন উত্তর দেয় “আপনি কী অ্যাক্সেস করতে পারবেন?” মাল্টি-টেন্যান্ট ডাটাবেসে টেন্যান্ট কনটেক্সট (tenant_id, account_id, org_id) কে অথরাইজেশনের সময় জোরালোভাবে প্রয়োগ করতে হবে—এটাকে ঐচ্ছিক ফিল্টার ভাববেন না।
সাধারণ ভুল হলো ধরে নেওয়া যে একজন ব্যবহারকারী অথেনটিকেট হলে এবং আপনি তাদের টেন্যান্ট জানেন, তবে অ্যাপ স্বাভাবিকভাবেই কুয়েরিগুলো আলাদা রাখবে। প্রকৃতপক্ষে, আলাদা রাখা স্পষ্ট এবং ধারাবাহিক কন্ট্রোল পয়েন্টে (যেমন ডাটাবেস পলিসি বা একটি ম্যান্ডেটরি কুয়েরি লেয়ার) প্রয়োগ করা প্রয়োজন।
সবচেয়ে সহজ নিয়মটাই সবচেয়ে গুরুত্বপূর্ণ: প্রতিটি SELECT ও WRITE কেবল একটি নির্দিষ্ট টেন্যান্টের জন্য স্কোপড হতে হবে।
এটি প্রযোজ্য:
যদি টেন্যান্ট স্কোপিং ঐচ্ছিক করা হয়, এটি অবশেষে বাদ পড়ে যাবে।
ক্রস-টেন্যান্ট লিক ছোট, রুটিন ভুল থেকে আসে:
tenant_id বেঁধে দেওয়া হয়টেস্ট সাধারণত ক্ষুদ্র ডেটাসেট ও পরিষ্কার অনুমান নিয়ে চলে। প্রোডাকশনে কনকারেন্সি, রিট্রাই, ক্যাশ, মিক্সড টেন্যান্ট ডেটা ও রিয়াল এজ কেস আসে। একটি ফিচার টেস্ট পাস করতে পারে কারণ টেস্ট ডাটাবেসে মাত্র একটি টেন্যান্ট আছে, বা ফিক্সচারে ওভারল্যাপিং আইডি নেই। সবচেয়ে নিরাপদ ডিজাইনগুলো এমনভাবে যে আনস্কোপড কুয়েরি লেখা কঠিন হয়—রিভিউয়ারদের উপর নির্ভর না করে।
মাল্টি-টেন্যান্ট ডাটাবেসের মূল নিরাপত্তা ঝুঁকি সোজা: একটি কুয়েরি যদি টেন্যান্ট ফিল্টার ভুলে যায় তবে অন্য কারোর ডেটা প্রকাশ পেতে পারে। শক্তিশালী আইসোলেশন কন্ট্রোলগুলো থোড়াই ভুলকে ঘটে যেতে দেয়না এবং ভুল হলে সেটাকে নির্দোষ করে দেয়।
প্রতিটি টেন্যান্ট-মালিকানাধীন রেকর্ডে একটি টেন্যান্ট আইডেন্টিফায়ার (উদাহরণ: tenant_id) থাকা উচিত এবং আপনার অ্যাক্সেস লেয়ার সবসময় এটি দিয়ে রিড ও রাইট স্কোপ করবে।
একটি বাস্তবিক প্যাটার্ন হলো “টেন্যান্ট কনটেক্সট প্রথম”: অ্যাপ সাবডোমাইন, org ID বা টোকেন ক্লেইম থেকে টেন্যান্ট নির্ধারণ করে, সেটি রিকোয়েস্ট কনটেক্সটে রাখে, এবং ডেটা অ্যাক্সেস কোড সেই কনটেক্সট ছাড়া চলবে না।
গার্ডরেইল:
tenant_id বাধ্যতামূলক করুন (টেন্যান্ট-অন্তরীণ সংঘাতে প্রতিরোধ করতে)।tenant_id অন্তর্ভুক্ত করে যাতে ক্রস-টেন্যান্ট সম্পর্ক আনজানেই তৈরি না হয়।যেখানে সমর্থিত (বিশেষত PostgreSQL), রো-লেভেল সিকিউরিটি টেন্যান্ট চেকগুলো ডাটাবেসের ভিতরে নিয়ে যেতে পারে। পলিসি প্রতিটি SELECT/UPDATE/DELETE রেস্ট্রিক্ট করে শুধুমাত্র বর্তমান টেন্যান্টের মিল থাকা রো দেখায়।
এটি "প্রত্যেক ডেভেলপার WHERE লিখবে"-এর ওপর নির্ভরতা কমায়, এবং কিছু ইনজেকশন বা ORM মিসইউজ সিচুয়েশন থেকেও রক্ষা করে। RLS-কে একটি দ্বিতীয় লক হিসেবে বিবেচনা করুন—এটি একমাত্র লক করা উচিত নয়।
যদি টেন্যান্টদের সংবেদনশীলতা বা কড়া কমপ্লায়েন্স প্রয়োজন থাকে, স্কিমা (বা এমনকি ডাটাবেস) আলাদা করলে ব্লাস্ট রেডিয়াস কমে। ট্রেডঅফ হচ্ছে অপারেশনাল ওভারহেড বাড়া।
পারমিশন এমনভাবে ডিজাইন করুন যে ডিফল্ট "অ্যাক্সেস নেই":
এই কন্ট্রোলগুলো একসাথে কাজ করে: শক্ত টেন্যান্ট স্কোপিং, ডাটাবেস-এ জোর করা পলিসি যেখানে সম্ভব, এবং সংরক্ষিত প্রিভিলেজ যা কিছু ঝলকলে ক্ষতি সীমিত করে।
এনক্রিপশন এমন কিছু কন্ট্রোলগুলোর মধ্যে যা অন্য আইসোলেশন লেয়ার ব্যর্থ হলেও কাজ করে। শেয়ারড ডেটাস্টোরে লক্ষ্য হলো ডেটা চলমান অবস্থায়, বসার অবস্থায়, এবং অ্যাপ কী টেন্যান্ট হিসেবে কাজ করছে তা সুরক্ষিত রাখা।
ট্রানজিটে ডেটার জন্য, ক্লায়েন্ট → API, API → ডাটাবেস, এবং যেকোনো ইন্টারনাল সার্ভিস কলের জন্য TLS বাধ্যতামূলক করুন। সম্ভব হলে ডাটাবেস স্তরে TLS আরোপ করুন (উদাহরণ: নন-TLS কানেকশন প্রত্যাখ্যান) যাতে "অস্থায়ী ব্যতিক্রম" স্থায়ী হয়ে না ওঠে।
অ্যাট-রেস্টে, ডাটাবেস বা স্টোরেজ-লেভেল এনক্রিপশন (ম্যানেজ্ড ডিস্ক এনক্রিপশন, TDE, এনক্রিপ্টেড ব্যাকআপ) ব্যবহার করুন। এটি লসড মিডিয়া, স্ন্যাপশট এক্সপোজার এবং কিছু ইনফ্রা-কমপ্রোমাইজ থেকে রক্ষা করে—তবে এটি বাগযুক্ত কুয়েরি থেকে অন্য টেন্যান্টের রো ফিরিয়ে আনা বন্ধ করতে পারবে না।
একটি শেয়ার করা এনক্রিপশন কী পরিচালনা সহজ করে (কম কী রোটেশন, কম ত্রুটি মোড)। তবে কী এক্সপোজ হলে ব্লাস্ট রেডিয়াস বড়।
প্রতি-টেন্যান্ট কী ব্লাস্ট রেডিয়াস কমায় এবং গ্রাহক চাহিদা মেটাতে সাহায্য করে (কিছু এন্টারপ্রাইজ গ্রাহক টেন্যান্ট-নির্দিষ্ট কী চায়)। ট্রেডঅফটি জটিলতা: কী লাইফসাইকেল ম্যানেজমেন্ট, রোটেশন শিডিউল, এবং সাপোর্ট ওয়ার্কফ্লো (উদাহরণ: যদি টেন্যান্ট তাদের কী নিষ্ক্রিয় করে কী হবে)।
একটি বাস্তবিক মিডল গ্রাউন্ড হলো এনভেলপ এনক্রিপশন: একটি মাস্টার কী প্রতিটি টেন্যান্ট ডেটা কী-কে এনক্রিপ্ট করে, রোটেশন পরিচালনা সহজ রাখে।
ডাটাবেস ক্রেডেনশিয়ালস সিক্রেট ম্যানেজারে রাখুন, দীর্ঘস্থায়ী কনফিগে এনভায়রনমেন্ট ভ্যারিয়েবল নয়। স্বল্প-জীবিত ক্রেডেনশিয়াল বা স্বয়ংক্রিয় রোটেশন পছন্দ করুন এবং সার্ভিস রোল অনুযায়ী অ্যাক্সেস স্কোপ করুন যাতে একটি কম্প্রোমাইজড কম্পোনেন্ট সব ডাটাবেসে পৌঁছাতে না পারে।
টেন্যান্ট পরিচয়কে সিকিউরিটি-ক্রিটিক্যাল হিসেবে বিবেচনা করুন। ক্লায়েন্ট থেকে কাঁচা tenant_id কখনোই ট্রাস্ট করবেন না। টেন্যান্ট কনটেক্সটকে সাইনড টোকেন এবং সার্ভার-সাইড অথরাইজেশন চেকের সাথে বাইন্ড করুন, এবং প্রতিটি অনুরোধে ডাটাবেস কলের আগে এটি যাচাই করুন।
মাল্টি-টেন্যান্সি "নরমাল" কীরকম তা বদলে দেয়। আপনি কেবল একটি ডাটাবেস মনিটর করছেন না—আপনি অনেক টেন্যান্টকে এক সিস্টেমে শেয়ার করা দেখতে পাচ্ছেন, যেখানে একটি ভুল ক্রস-টেন্যান্ট এক্সপোজারের কারণ হতে পারে। ভাল অডিটযোগ্যতা ও মনিটরিং ইনসিডেন্টের সম্ভাবনা ও বিস্তার উভয়ই কমায়।
কমপক্ষে, প্রতিটি অ্যাকশন লগ করুন যা টেন্যান্ট ডেটা পড়তে, পরিবর্তন করতে বা অ্যাক্সেস দিতে পারে। সবচেয়ে ব্যবহারযোগ্য অডিট ইভেন্টগুলো উত্তর দেয়:
অ্যাডমিন অ্যাকশনও লগ করুন: টেন্যান্ট তৈরি, আইসোলেশন পলিসি পরিবর্তন, RLS পলিসি মোডিফাই, কী রোটেশন, কানেকশন স্ট্রিং পরিবর্তন ইত্যাদি।
মনিটরিং এমন প্যাটার্ন শনাক্ত করা উচিত যা স্বাভাবিক SaaS ব্যবহার নয়:
অ্যালার্টগুলোকে অ্যাকশনেবল রানবুকের সাথে বেঁধে রাখুন: কী চেক করতে হবে, কীভাবে কন্টেইন করতে হবে, কাকে পেজ করতে হবে।
প্রিভিলেজড অ্যাক্সেসকে প্রোডাকশন চেঞ্জ হিসেবে বিবেচনা করুন। লিস্ট-প্রিভিলেজ রোল, স্বল্প-জীবিত ক্রেডেনশিয়াল, এবং সংবেদনশীল অপারেশনের অনুমোদনের জন্য প্রক্রিয়া ব্যবহার করুন (স্কিমা চেঞ্জ, ডেটা এক্সপোর্ট, পলিসি এডিট)। জরুরি অবস্থার জন্য একটি ব্রেক-গ্লাস অ্যাকাউন্ট রাখুন: আলাদা ক্রেডেনশিয়াল, বাধ্যতামূলক টিকিট/অনুমোদন, সময়-সীমাবদ্ধ অ্যাক্সেস, এবং অতিরিক্ত লগিং।
রিটেনশন নির্ধারণ করুন কমপ্লায়েন্স ও তদন্তের চাহিদা অনুযায়ী, কিন্তু দেখাশোনা করুন যাতে সাপোর্ট স্টাফ কেবল তাদের টেন্যান্টের লগ দেখতে পারে। যখন গ্রাহক অডিট এক্সপোর্ট চায়, রড-ফিল্টারড রিপোর্ট দিন কাঁচা শেয়ারড লগ না দিয়ে।
মাল্টি-টেন্যান্সি দক্ষতা বাড়ায় কারণ অনেক গ্রাহক একই ডাটাবেস ইনফ্রা ব্যবহার করে। ট্রেডঅফ হচ্ছে পারফরম্যান্সও শেয়ার করা হয়: এক টেন্যান্ট যা ভারি কাজ করে সেটা অন্যদের প্রভাবিত করতে পারে, যদিও তাদের ডেটা আলাদা।
একটি “শোরগোলকারী প্রতিবেশী” হল এমন টেন্যান্ট যার কার্যকলাপ এতটাই ভারি বা স্পাইকযুক্ত যে এটি শেয়ার করা রিসোর্সের আলোচ্যাংশ বেশি নেয়। ডাটাবেস “ভাঙেনি”—তাকত তার কাজ করছে কেবল সেই টেন্যান্টের অনুরোধ সামলাতে বেশি ব্যস্ত, ফলে অন্যরা অপেক্ষা করে।
এটাকে ভাবুন একটি অ্যাপার্টমেন্ট বিল্ডিংয়ের শেয়ার করা ওয়াটার প্রেসার-এর মতো: এক ইউনিট একসাথে একাধিক শাওয়ার ও ওয়াশিং মেশিন চালালে বাকিরা কম ফ্লো অনুভব করবে।
যদিও প্রতিটি টেন্যান্ট আলাদা রো বা স্কিমা রাখে, অনেক পারফরম্যান্স-ক্রিটিক্যাল উপাদান শেয়ার করা থাকে:
এই শেয়ার করা পুলগুলো স্যাচুরেট হলে প্রত্যেকের জন্য ল্যাটেন্সি বাড়ে।
অনেক SaaS ওয়ার্কলোড ব্রাস্টি: একটি ইম্পোর্ট, মাসের শেষে রিপোর্ট, মার্কেটিং ক্যাম্পেইন, বা ঘড়ির শীর্ষে ছোটি ক্রন জব।
স্পাইকগুলো ডাটাবেসের ভিতরে “ট্রাফিক জ্যাম” সৃষ্টি করে:
চাইলে স্পাইক কয়েক মিনিটের হলেও কিউ গুলো যখন খালি হবে তখন নক-অন ডিলে দেখা যায়।
গ্রাহকের পারস্পেকটিভে শোরগোলকারী প্রতিবেশী সমস্যা র্যান্ডম ও অন্যায় মনে হয়। সাধারণ সিম্পটমগুলো:
এই লক্ষণগুলো পারফরম্যান্স আইসোলেশন টেকনিক দরকার আছে বলে ইঙ্গিত দেয়—শুধু “আরও হার্ডওয়্যার” নয়।
মাল্টি-টেন্যান্সি ভাল কাজ করে যখন একটি গ্রাহক অন্যদের থেকে বেশি তাদের ন্যায্য অংশের চেয়ে বেশি নিতে পারে না। রিসোর্স আইসোলেশন হলো সেই গার্ডরেইল যা ভারি টেন্যান্টকে সবার ধীর করে ফেলা থেকে রোধ করে।
একটি সাধারণ ব্যর্থ মোড হল অনিয়ন্ত্রিত কনেকশন: একটি টেন্যান্ট ট্রাফিক স্পাইক হলে শত শত সেশন খোলে এবং ডাটাবেসকে স্টাভ করে।
দুই জায়গায় হার্ড ক্যাপ সেট করুন:
যদি আপনার ডাটাবেস সরাসরি “প্রতি টেন্যান্ট কানেকশন” Enforce না করে, আপনি আলাদা পুল বা পুল পার্টিশনিং ব্যবহার করে আনুমানিকভাবে এটি বাস্তবায়ন করতে পারেন।
রেট লিমিটিং হচ্ছে সময়ভিত্তিক ন্যায্যতা। এটি এজ (API গেটওয়ে/অ্যাপ) কাছে প্রয়োগ করুন এবং যেখানে সমর্থিত, ডাটাবেসের ভিতরে (রিসোর্স গ্রুপ/ওয়ার্কলোড ম্যানেজমেন্ট)।
উদাহরণ:
ডাটাবেসকে “রানঅ্যাওয়ে” কুয়েরি থেকে রক্ষা করুন:
এই কন্ট্রোলগুলো গ্রেসফুলি ব্যর্থ করা উচিত: স্পষ্ট ত্রুটি ফেরত দিন এবং রিট্রাই/ব্যাকঅফ পরামর্শ দিন।
রিড-ভারী ট্রাফিক প্রাইমারির বাইরে সরান:
লক্ষ্য কেবল গতি নয়—লোকক প্রেসার ও CPU কনটেনশন কমানো যাতে শোরগোলকারী টেন্যান্টের পাস একজনাধিক পথ না থাকে অন্যদের প্রভাবিত করার।
মাল্টি-টেন্যান্ট পারফরম্যান্স সমস্যা প্রায়শই “ডাটাবেস ধীর” দেখায়, কিন্তু মূল কারণ সাধারণত ডেটা মডেল: টেন্যান্ট ডেটা কীভাবে কীড, ফিল্টার, ইনডেক্স এবং ফিজিক্যালি সাজানো হয়েছে। ভালো মডেলিং টেন্যান্ট-স্কোপড কুয়েরিগুলোকে প্রাকৃতিকভাবে দ্রুত করে; খারাপ মডেলিং ডাটাবেসকে বেশি কাজ করাতে বাধ্য করে।
অনেক SaaS কুয়েরি টেন্যান্ট আইডি অন্তর্ভুক্ত করে। এটিকে স্পষ্টভাবে মডেল করুন (উদাহরণ: tenant_id) এবং এমন ইনডেক্স ডিজাইন করুন যা এটিকে শুরুতে রাখে। বাস্তবে, (tenant_id, created_at) বা (tenant_id, status) এর মতো কম্পোজিট ইনডেক্স আলাদাভাবে created_at বা status ইনডেক্স করার তুলনায় অনেক বেশি কার্যকর।
এটিই ইউনিকনেসেও প্রযোজ্য: যদি ইমেইলগুলো কেবল টেন্যান্ট-ভিত্তিক ইউনিক হয়, তাহলে (tenant_id, email) দিয়ে এনফোর্স করুন, গ্লোবাল email কনস্ট্রেইন্ট নয়।
একটি সাধারণ ধীর-কুয়েরি প্যাটার্ন হল অনিচ্ছাকৃত ক্রস-টেন্যান্ট স্ক্যান: টেন্যান্ট ফিল্টার ভুলে গিয়ে একটি বিশাল অংশ টেবিল অটেন্ড করে।
নিরাপদ পথটিকে সহজ করুন:
পার্টিশনিং কমায় প্রতিটি কুয়েরির বিবেচ্য ডেটার পরিমাণ। বড় ও অসম টেন্যান্টগুলোর জন্য টেন্যান্ট-ভিত্তিক পার্টিশন করা যেতে পারে। যখন অ্যাক্সেস বেশি সাম্প্রতিক, তখন টাইম-বাই পার্টিশন কাজ করে—সাধারণত প্রতিটি পার্টিশনে tenant_id-কে লিডিং ইনডেক্স কলাম হিসেবে রাখুন।
যখন একটি একক ডাটাবেস পিক থ্রুপুট পূরণ করতে পারে না বা একটি টেন্যান্ট অন্য সবাইকে হুমকি করে, তখন শার্ডিং বিবেচনা করুন।
“হট টেন্যান্ট” গুলো disproportionate রিড/রাইট, লক কনটেনশন বা oversized ইনডেক্স হিসেবে প্রকাশ পায়।
প্রতি-টেন্যান্ট কুয়েরি টাইম, রো রিড, এবং রাইট রেট ট্র্যাক করে হট টেন্যান্ট শনাক্ত করুন। যখন কেউ ডমিনেট করে, তাদের আলাদা করুন: আলাদা শার্ড/ডাটাবেসে সরান, বড় টেবিলগুলো টেন্যান্ট অনুযায়ী বিভক্ত করুন, বা ডেডিকেটেড ক্যাশ ও রেট লিমিট যোগ করুন যাতে অন্যরা সাধারণ গতিতে থাকে।
মাল্টি-টেন্যান্সি শীঘ্রই ব্যর্থ হয় না কারণ ডাটাবেস "পরে চলে না"; এটি ব্যর্থ হয় যখন দৈনন্দিন অপারেশন ছোট অনিয়মগুলোকে বরফের স্লাইডার করে বড় নিরাপত্তা ফাঁক বা পারফরম্যান্স রিগ্রেশন তৈরি করে। লক্ষ্য: প্রতিটি চেঞ্জ, জব ও ডেপ্লয়ের জন্য নিরাপদ পথকে ডিফল্ট বানানো।
একটি একক ক্যানোনিক্যাল টেন্যান্ট আইডি (উদাহরণ: tenant_id) বাছুন এবং সেটি টেবিল, ইনডেক্স, লগ, ও API-তে ধারাবাহিকভাবে ব্যবহার করুন। ধারাবাহিকতা সিকিউরিটি ভুল (ভুল টেন্যান্ট কুয়েরি) ও পারফরম্যান্স আচমকা (ভুল কম্পোজিট ইনডেক্স) দুইকেই কমায়।
বাস্তব রক্ষাবল:
tenant_id বাধ্য করুনtenant_id দিয়ে শুরু হওয়া কম্পোজিট ইনডেক্স যোগ করুনtenant_id সহ ফরেনকি বা চেক কনস্ট্রেইন্ট) যাতে খারাপ রাইট দ্রুত ধরা পড়েঅ্যাসিঙ্ক ওয়ার্কাররা ক্রস-টেন্যান্ট ঘটনার সাধারণ উৎস কারণ তারা রিকোয়েস্ট কেবল কনটেক্সট ছাড়া আউট-অফ-ব্যান্ড চলে।
অপারেশনাল প্যাটার্ন:
tenant_id পাস করুন; অ্যাম্বিয়েন্ট কনটেক্সট নির্ভর করবেন নাtenant_id লগ করুন যাতে তদন্ত দ্রুত টেন্যান্ট স্কোপ করা যায়স্কিমা ও ডেটা মাইগ্রেশনগুলো এমনভাবে হওয়া উচিত যে সমন্বিত, সিঙ্কড রোলআউট ছাড়া চালানো যায়।
রোলিং চেঞ্জ ব্যবহার করুন:
অটোমেটেড নেগেটিভ টেস্ট যোগ করুন যা ইচ্ছাকৃতভাবে অন্য টেন্যান্টের ডেটা অ্যাক্সেস করতে চায় (রিড ও রাইট)। এগুলো রিলিজ ব্লকার হিসেবে বিবেচনা করুন।
উদাহরণ:
tenant_id দিয়ে হার্ড ফেল নিশ্চিত করাব্যাকআপ বর্ণনা করা সহজ—“ডাটাবেস কপি কর” বলা সহজ—কিন্তু মাল্টি-টেন্যান্ট ডাটাবেসে নিরাপদভাবে বাস্তবায়ন করা চমৎকারভাবে কঠিন। যখন অনেক গ্রাহক টেবিল শেয়ার করে, তখন একটি পরিকল্পনা দরকার কিভাবে একটি টেন্যান্টের ডেটা পুনরুদ্ধার করবেন অন্যদের এক্সপোজ বা ওভাররাইট না করে।
ফুল-ডাটাবেস ব্যাকআপ এখনও ডিজাস্টার রিকভারি জন্য বেস, কিন্তু এটা ডে-টু-ডে সাপোর্ট কেসের জন্য যথেষ্ট নয়। সাধারণ পদ্ধতিগুলি:
tenant_id ফিল্টার করে লজিকাল ডাম্প) একটি একক টেন্যান্ট পুনরুদ্ধারের জন্যযদি আপনি লজিকাল এক্সপোর্টে নির্ভর করেন, তখন এক্সপোর্ট জবকে প্রোডাকশন কোডের মতো বিবেচনা করুন: এটি টেন্যান্ট আইসোলেশন জোর করে (উদাহরণ: RLS ব্যবহার করে) বদলে একটি একবারের WHERE ক্লজে বিশ্বাস করবেন না।
প্রাইভেসি রিকোয়েস্ট (এক্সপোর্ট, ডিলিট) হলো টেন্যান্ট-লেভেল অপারেশন যা নিরাপত্তা ও পারফরম্যান্স উভয়কে স্পর্শ করে। পুনরাবৃত্তিযোগ্য, অডিটেড ওয়ার্কফ্লো তৈরি করুন:
সবচেয়ে বড় ঝুঁকি হ্যাকার নয়—একটা তাড়াহুড়ো অপারেটর। মানব ত্রুটি কমাতে গার্ডরেইল:
tenant_id ডিস্ট্রিবিউশন যাচাই করুনডিজাস্টার রিকভারি ড্রিলের পরে শুধু “অ্যাপ আপ আছে” বলা বন্ধ করবেন না। অটোমেটেড চেক চালান যা টেন্যান্ট আইসোলেশন নিশ্চিত করে: টেন্যান্ট-ওয়াইজ স্যাম্পল কুয়েরি, অডিট লগ রিভিউ, এবং এনক্রিপশন কী ও অ্যাক্সেস রোল সঠিকভাবে স্কোপড আছে কি না যাচাই করা।
মাল্টি-টেন্যান্সি প্রায়শই SaaS-এর জন্য ডিফল্ট সেরা, কিন্তু এটি স্থায়ী সিদ্ধান্ত নয়। আপনার পণ্য ও গ্রাহক মিশ বিকশিত হওয়ার সঙ্গে “একটি শেয়ারড ডেটাস্টোর” কৌশল ব্যবসায়িক ঝুঁকি সৃষ্টি করতে বা ডেলিভারিতে ধীরতা আনতে পারে।
আরও আইসোলেশন বিবেচনা করুন যখন:
“সব শেয়ার” এবং “সব ডেডিকেটেড”–এর মধ্যে বেছে নিতে হবে না। সাধারণ হাইব্রিড পন্থা:
বেশি আইসোলেশন সাধারণত ইনফ্রাস্ট্রাকচার খরচ বাড়ায়, অপারেশনাল ওভারহেড বাড়ায় (মাইগ্রেশন, মনিটরিং, অন-কল) এবং রিলিজ সমন্বয় বাড়ায় (একাধিক পরিবেশে স্কিমা চেঞ্জ) । ট্রেডঅফ হলো স্পষ্ট পারফরম্যান্স গ্যারান্টি এবং সহজতর কমপ্লায়েন্স কথোপকথন।
আপনি যদি আইসোলেশন অপশনগুলো মূল্যায়ন করছেন, /blog-এ সম্পর্কিত গাইডগুলো দেখুন বা /pricing-এ পরিকল্পনা ও ডেপ্লয়মেন্ট অপশন তুলনা করুন।
যদি দ্রুত একটি SaaS প্রোটোটাইপ তৈরি করে মাল্টি-টেন্যান্ট অনুমানগুলো (টেন্যান্ট স্কোপিং, RLS-ফ্রেন্ডলি স্কিমা, থ্রটলিং, অপারেশনাল ওয়ার্কফ্লো) প্রেসার-টেস্ট করতে চান, তখন vibe-coding ধরনের প্ল্যাটফর্ম যেমন Koder.ai আপনাকে চ্যাট থেকে React + Go + PostgreSQL অ্যাপ স্পিন-আপ করতে সাহায্য করতে পারে—প্ল্যানিং মোডে ইটারেট করা এবং স্ন্যাপশট ও রোলব্যাকের সাথে ডেপ্লয় করা সম্ভব—তারপর প্রস্তুত হলে সোর্স কোড এক্সপোর্ট করতে পারবেন।
একটি মাল্টি-টেন্যান্ট ডাটাবেস হল এমন একটি কনফিগারেশন যেখানে একাধিক গ্রাহক একই ডাটাবেস ইনফ্রাস্ট্রাকচার (প্রায়শই একই স্কিমা) শেয়ার করে, এবং অ্যাপ্লিকেশন/ডাটাবেস নিশ্চিত করে যে প্রতিটি টেন্যান্ট শুধুমাত্র তাদের নিজস্ব ডেটা অ্যাক্সেস করতে পারে। মূল শর্ত হল প্রতিটি রিড ও রাইটে কঠোর টেন্যান্ট স্কোপিং থাকা।
মাল্টি-টেন্যান্সি সাধারণত নেওয়া হয় কারণ:
ট্রেডঅফ হলো—আপনাকে ইন্টেনশনালি আইসোলেশন ও পারফরম্যান্স গার্ডরেইল বানাতে হবে।
সাধারণ মডেলগুলো (বেশি আইসোলেশন থেকে বেশি শেয়ারিং পর্যন্ত):
আপনার পছন্দ আইসোলেশন বাউন্ডারি ও অপারেশনাল ভূমিকা নির্ধারণ করে।
বড় ঝুঁকি হয়ে ওঠে ক্রস-টেন্যান্ট অ্যাক্সেস — রুটকেই বদলে দেয়। টেন্যান্ট প্রসঙ্গ (যেমন tenant_id) কে অনুমোদনের অংশ হিসেবে বিবেচনা করতে হবে, এটাকে অপশনাল ফিল্টার মনে করা যাবে না। উৎপাদনে কনকারেন্সি, ক্যাশ, ব্যাকগ্রাউন্ড জব থাকে—এসবকে মাথায় রেখে ডিজাইন করতে হয়।
সর্বাধিক সাধারণ কারণগুলো:
tenant_id বেঁধে দেওয়া প্রস্তুত স্টেটমেন্টগার্ডরেইল ডিজাইন করুন যাতে আনস্কোপড কেরি চালানো কঠিন বা অসম্ভব হয়।
রো-লেভেল সিকিউরিটি (RLS) তখন ব্যবহার করুন যেখানে ডাটাবেস এটি সাপোর্ট করে (উদাহরণ: PostgreSQL)। RLS নীতিগুলো SELECT/UPDATE/DELETE-কে বর্তমান টেন্যান্টের সাথে মিলিয়ে সীমাবদ্ধ করে। এটি "সবাই WHERE লিখবে" ভরসাকে কমায়, কিন্তু RLS-কে একমাত্র লক হিসেবে দেখতে হবে না—অ্যাপ-লেয়ার স্কোপিং, লিস্ট প্রিভিলেজ এবং শক্তিশালী টেস্টিং-এর সাথে মিলিয়ে ব্যবহার করুন।
প্রায়োগিক বেসলাইন:
tenant_idtenant_id সহ কম্পোজিট ইউনিকনেস এবং ফরেনকিলক্ষ্য: ভুল হলে সেটি নিরাপদে ব্যর্থ করানো।
এনক্রিপশন সহায়তা করে, কিন্তু ভিন্ন ধরনের ঝুঁকি কভার করে:
টেন্যান্ট পরিচয়কে সিকিউরিটি-ক্রিটিক্যাল হিসেবে ধরুন: কাস্টমারের দেয়া কাঁচা -কে টলারেট করবেন না; সেটি সাইনড টোকেন ও সার্ভার-সাইড চেক দিয়ে বাউন্ড করুন।
শোরগোলকারী প্রতিবেশী তখন ঘটে যখন একটি টেন্যান্ট শেয়ার করা রিসোর্স (CPU, মেমরি, I/O, কানেকশন) বেশি ব্যবহার করে, ফলে অন্যদের latency বাড়ে। ব্যবস্থাপনা:
লক্ষ্য: কেবলমাত্র থ্রুপুট নয়, ন্যায্যতা নিশ্চিত করা।
যখন একাধিক গ্রাহক একইভাবে শেয়ার করা থাকে, কিন্তু কয়েকটি টেন্যান্ট ট্রাফিক/স্টোরেজ/ব্যাকগ্রাউন্ড জব অনেকাংশে দখল করে এবং অন্যান্যদের জন্য কনটেনশন সৃষ্টি করে। সাধারণ সমাধানগুলো:
আইসোলেশন বাড়লে খরচ ও জটিলতা বাড়ে—কিন্তু পারফরম্যান্স ও কমপ্লায়েন্স স্পষ্ট হয়।
tenant_id