Docker Compose না Kubernetes—এক server পেরোলেই জটিলতার দাম শুরু

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

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

এক সার্ভারে Compose কোথায় যথেষ্ট

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

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

নতুন সংস্করণ স্থাপনের সময় Compose সংশ্লিষ্ট সেবার কনটেইনার পুনর্নির্মাণ করতে পারে। অ্যাপের বিন্যাস অনুযায়ী এতে সাময়িক বিরতি হতে পারে; ব্যবহারকারীর কাছে সেই বিরতি গ্রহণযোগ্য কি না, সেটি স্থাপনার ঘনত্বের চেয়ে বেশি কার্যকর প্রশ্ন। খুব ঘন ঘন পরিবর্তন প্রকাশ করলেও যদি নির্ধারিত স্বল্প বিরতি চলে, শুধু সেই কারণে ক্লাস্টার দরকার হয় না।

বহু নোডে পুনরুদ্ধার কী শর্তে কাজ করে

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

সব প্রতিলিপি একই নোডে থাকলে তাদের সংখ্যা বাড়িয়েও সেই নোডের ব্যর্থতা সামলানো যায় না। অন্য নোডে খালি সক্ষমতা না থাকলে প্রতিস্থাপন পডও সেখানে চালু হবে না। ফলে প্রয়োজন শুধু ‘একাধিক সার্ভার’ নয়; প্রতিলিপি কোথায় থাকবে, একটি নোড বাদ পড়লে বাকি সক্ষমতা কতটা থাকবে এবং অনুরোধ কোন সুস্থ প্রতিলিপিতে যাবে, সেসবও স্থির করতে হয়।

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

স্বয়ংক্রিয় স্কেলিং কখন বাড়তি মূল্য দেয়

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

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

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

জটিলতার দাম কোথায় জমে

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

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

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

Kubernetes নেওয়ার আগে পাঁচ প্রশ্নের স্কোরকার্ড

নিচের নম্বরগুলো সম্পাদকীয় সিদ্ধান্ত-সহায়ক সূচক, পরীক্ষায় প্রতিষ্ঠিত সীমা বা শিল্পমান নয়। প্রতিটি প্রশ্নে ০, ১ অথবা ২ দিন। সার্ভারসংখ্যা ও ট্রাফিকের পাশাপাশি সেবা-বিরতি এবং দায়িত্বে থাকা দলের বাস্তব সক্ষমতা ধরুন।

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

মোট ০–৩ হলে Compose দিয়ে একক সার্ভারে চালানোর যুক্তি শক্তিশালী। ৪–৬ হলে কোন প্রয়োজনটি সীমা তৈরি করছে দেখুন: ব্যাকআপ, স্থাপনার পদ্ধতি বা হোস্টের সক্ষমতা বদলালেই সমস্যা মিটতে পারে। ৭–১০ হলে বহু নোডের নকশা ও Kubernetes পরিচালনার খরচ হিসাব করার যথেষ্ট কারণ আছে। তবে দলের সক্ষমতায় ০ পেলে বেশি মোট নম্বরও নিজস্ব ক্লাস্টার নিরাপদে চালানোর লোক তৈরি করে না; সে ক্ষেত্রে পরিচালিত সেবা ও দায়িত্বপ্রাপ্ত জনবলের খরচ সিদ্ধান্তে ধরুন।

আরও পড়ুন:

• MCP server নিরাপদ করতে OAuth যথেষ্ট নয়—৮ ধাপের deployment audit
• Elastic কিনল Deductive AI—দাম গোপন, লক্ষ্য incident তদন্ত স্বয়ংক্রিয় করা
• N-central-এ login ছাড়াই server দখল—HF4 না দিলে ঝুঁকি সক্রিয়