মাল্টিটেন্যান্সি সম্পর্কে

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

আমরা যখন 1C:Enterprise-এর জন্য ক্লাউড (পরিষেবা) অপারেটিং মডেলের একটি পদ্ধতি ডিজাইন করা শুরু করি, ঠিক তখনই মাল্টিটেনেন্সি সম্পর্কে আমাদের ধারণা তৈরি করতে শুরু করি। সেটা বেশ কয়েক বছর আগের কথা। এবং তখন থেকে, আমাদের এই ধারণা ক্রমাগত প্রসারিত হচ্ছে। আমরা প্রতিনিয়ত এই বিষয়ের নতুন নতুন দিক (সুবিধা, অসুবিধা, জটিলতা, বিশেষত্ব ইত্যাদি) আবিষ্কার করছি।

কখনও কখনও ডেভেলপাররা মাল্টিটেনেন্সিকে একটি খুব সহজ ধারণা হিসেবে ব্যাখ্যা করেন: "একাধিক সংস্থার ডেটা একটি একক ডেটাবেসে সংরক্ষণ করার জন্য, সমস্ত টেবিলে সংস্থার আইডি সহ একটি কলাম যুক্ত করতে হবে এবং সেটির উপর একটি ফিল্টার সেট করতে হবে।" আমরাও স্বাভাবিকভাবেই এই বিষয়টি নিয়ে আমাদের কাজ সেই দৃষ্টিকোণ থেকেই শুরু করেছিলাম। কিন্তু আমরা দ্রুতই বুঝতে পারলাম যে এটি ছিল মাত্র একটি ফিল্ড (এবং প্রসঙ্গত, একটি জটিল ফিল্ড)। আসলে, এটি "একটি গোটা দেশ"।

বহুভাড়াটে আবাসনের মূল ধারণাটি মোটামুটিভাবে নিম্নরূপভাবে বর্ণনা করা যেতে পারে। একটি সাধারণ আবাসন হলো একটি একক পরিবারের জন্য নির্মিত একটি ছোট বাড়ি, যেখানে তারা এর অবকাঠামো (দেয়াল, ছাদ, জল সরবরাহ, হিটিং ইত্যাদি) ভাগাভাগি করে ব্যবহার করে। অন্যদিকে, একটি বহুভাড়াটে আবাসন হলো একটি অ্যাপার্টমেন্ট বিল্ডিং। প্রতিটি পরিবার একই অবকাঠামো ব্যবহার করে, কিন্তু এই অবকাঠামোটি পুরো বিল্ডিংয়ের জন্যই তৈরি করা হয়।

মাল্টিটেনেন্সি কি একটি ভালো নাকি খারাপ পদ্ধতি? এই বিষয়ে মতামতের ব্যাপক ভিন্নতা রয়েছে। মনে হচ্ছে, 'ভালো বা খারাপ' বলে কিছু নেই। যে নির্দিষ্ট চ্যালেঞ্জগুলো মোকাবেলা করা হচ্ছে, তার পরিপ্রেক্ষিতে সুবিধা-অসুবিধাগুলো বিচার-বিশ্লেষণ করা প্রয়োজন। কিন্তু সেটা অন্য একটি বিষয়...

সহজ কথায় বলতে গেলে, মাল্টিটেনেন্সির লক্ষ্য হলো অবকাঠামোগত খরচকে "সামাজিকীকরণের" মাধ্যমে অ্যাপ্লিকেশন রক্ষণাবেক্ষণের খরচ কমানো। এটি একটি কাস্টম সমাধান তৈরি করার পরিবর্তে একটি স্ট্যান্ডার্ড সমাধান (সম্ভবত কাস্টমাইজেশন এবং পরিমার্জন সহ) ব্যবহার করে অ্যাপ্লিকেশনের খরচ কমানোর পদ্ধতির মতোই। পার্থক্য হলো, একটি ক্ষেত্রে উন্নয়নকে সামাজিকীকরণ করা হয়, এবং অন্যটিতে পরিচালনাকে।

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

বলা যেতে পারে, মাল্টিটেনেন্সি শুধু ডেটা স্টোরেজ সংগঠিত করার একটি বিষয় নয়। এটি সম্পূর্ণ অ্যাপ্লিকেশনটির পরিচালনার একটি মডেল (যার মধ্যে এর আর্কিটেকচার, ডেপ্লয়মেন্ট মডেল এবং রক্ষণাবেক্ষণ ব্যবস্থার গুরুত্বপূর্ণ দিকগুলো অন্তর্ভুক্ত)।

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

1C:Enterprise-এ মাল্টিটেনেন্সি মডেলটি বিভিন্ন প্রযুক্তির স্তরে প্রয়োগ করা হয়। এগুলো হলো 1C:Enterprise প্ল্যাটফর্মের কার্যপ্রণালী, কার্যপ্রণালীগুলো1C:1cফ্রেশ সলিউশন পাবলিশিং টেকনোলজি"এবং"১সি:১সি ফ্রেশ সলিউশন ডেভেলপমেন্ট টেকনোলজি», প্রক্রিয়া বিএসপি (প্রমিত উপ-সিস্টেমগুলোর লাইব্রেরি)।

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

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

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

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

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

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

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

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

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

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

উত্স: www.habr.com