One self-hosted console to run your entire business — commerce, ERP, HRM, CRM & manufacturing

SMB-র জন্য ক্লাউড রিপ্যাট্রিয়েশন: হাইপারস্কেলার ছাড়লে কখন টাকা বাঁচে, আর কখন বাঁচে না

কম্পিউট, ম্যানেজড ডাটাবেস, egress, ব্যাকআপ আর ops ঘণ্টার লাইন ধরে হিসাব, সঙ্গে 37signals-এর অঙ্ক, থাকবেন না সরবেন তার সিদ্ধান্ত-গাছ, আর শেষ ধাপ পর্যন্ত রোলব্যাকের পথ খোলা রাখা মাইগ্রেশন পরিকল্পনা।

Author

Anichur Rahaman

4 দিন আগে10 min read1 views
SMB-র জন্য ক্লাউড রিপ্যাট্রিয়েশন: হাইপারস্কেলার ছাড়লে কখন টাকা বাঁচে, আর কখন বাঁচে না

cloud-এর invoice-এ অঙ্কটা $৯,৪০০। ৪০ জনের একটি অনলাইন রিটেইল ব্যবসার মালিক মাসের তিন তারিখে সেটি খুলেছেন। গত অক্টোবরে ছিল $৬,১০০, অথচ traffic বেড়েছে মোটে এক-তৃতীয়াংশ, অর্ধেকও নয়। "data transfer out" লাইনটা দ্বিগুণ হয়ে $১,১৫০ হয়েছে, কোন feature-এর কারণে তা টিমের কেউ বলতে পারছে না।

তিনি ভাবতে শুরু করেন, পুরো system ভাড়া-server-এ নিলে কি সস্তা হতো? অর্ধেক মানুষ বলে হ্যাঁ। বাকি অর্ধেক বলে, এভাবেই কোম্পানি রাত ৩টায় server ডাউন নিয়ে বসে থাকে, ফোন করার মতো কেউ থাকে না।

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

রিপ্যাট্রিয়েশন বলতে কী বোঝায়, আর প্রমাণ কী বলে

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

সবচেয়ে ভালোভাবে নথিবদ্ধ উদাহরণ 37signals, Basecamp আর HEY-এর প্রতিষ্ঠান। ২০২৫ সালের মে মাসে The Register-এর প্রতিবেদন অনুযায়ী তারা Dell server-এ খরচ করেছে প্রায় $৭,০০,০০০ এবং cloud বিল কমিয়েছে বছরে প্রায় $২০ লাখ। এরপর প্রায় ১৮ পেটাবাইট স্টোরেজ Amazon S3 থেকে সরিয়ে নিয়েছে Pure Storage অ্যারেতে, যার দাম প্রায় $১৫ লাখ; আশা, বছরে আরও $১৩ লাখ সাশ্রয়। বের হওয়ার সময় AWS প্রায় $২,৫০,০০০ egress ফি মওকুফ করেছে, আর কোম্পানির হিসাবে পাঁচ বছরে সাশ্রয় হবে $১ কোটি। তাদের CTO বলেছেন, বাড়তি লোক নিতে হয়নি।

এটা মন দিয়ে পড়ুন। 37signals-এর বার্ষিক বিল ছিল $৩২ লাখ, বছরের পর বছর অপারেশনের অভিজ্ঞতা ছিল, আর চাহিদাও ছিল সমতল ও আগাম অনুমান করা যায় এমন। অঙ্কগুলো সত্যি, কিন্তু এই তিনটি বৈশিষ্ট্যওয়ালা কোম্পানির জন্যই সত্যি। বিস্তারিত জানতে The Register-এর প্রতিবেদন পড়ে দেখতে পারেন।

চাপটা শুধু দামের নয়, অপচয়েরও। ৭৫০-এর বেশি cloud সিদ্ধান্তগ্রহণকারী ও ব্যবহারকারীর ওপর করা Flexera-র ২০২৬ State of the Cloud report-এর হিসাবে cloud খরচের ২৯% অপচয় হচ্ছে। পাঁচ বছরে এই প্রথম এটা বাড়ল, আর AI workload এর একটি কারণ। একই জরিপে ৮৫% উত্তরদাতা cloud খরচ সামলানোকে বড় চ্যালেঞ্জ বলেছেন (Flexera-র প্রেস বিজ্ঞপ্তি)। cloud-এর ভেতরেই যে অপচয় ঠিক করা যায়, সেটাই সবচেয়ে সস্তা সাশ্রয়, আর সেটা সরে যাওয়ার আগের কাজ।

টাকা কোথায় চুঁইয়ে যায়

cloud-এর invoice আর server ভাড়ার ফারাকের বেশির ভাগ চারটি খরচের উৎসে ব্যাখ্যা করা যায়।

Egress

cloud-এ data ঢোকানো বিনামূল্যে, কিন্তু ইন্টারনেটে বের করলে মিটার চলে। AWS-এর তালিকায় প্রতি মাসে প্রথম ১০০ GB ফ্রি, তারপর প্রথম ১০ TB-র জন্য প্রতি GB $০.০৯, এর ওপরে ধাপে ধাপে কম। product-এর ছবি, invoice PDF আর API রেসপন্স দেওয়া একটা স্টোর টেরও না পেয়ে ৮ TB পেরিয়ে যেতে পারে। ডেডিকেটেড server-এ সাধারণত মাসিক ভাড়ার মধ্যেই ২০ TB বা তার বেশি traffic ধরা থাকে।

ম্যানেজড সার্ভিসের বাড়তি দাম

দ্বিতীয় জোনে স্ট্যান্ডবাই রেপ্লিকাসহ একটা ম্যানেজড database-এর দাম ভেতরের কাঁচা কম্পিউটের কয়েক গুণ। আপনি দাম দিচ্ছেন স্বয়ংক্রিয় failover, প্যাচিং আর point-in-time recovery-র জন্য। টিমে এসব করার মতো কেউ না থাকলে দামটা ন্যায্য, কেউ থাকলে ব্যয়বহুল।

অলস ক্ষমতা

সবচেয়ে ব্যস্ত দিনের মাপে বানানো ইনস্ট্যান্স বাকি দিনগুলোয় ১৫% লোডে চলে। app ঠিকভাবে scale out করতে পারলে তবেই autoscaling কাজে দেয়। পিক-মাপের একটা স্থির server-এও একই অলসতা থাকে, কিন্তু ইউনিট-দাম অনেক কম।

AI workload

GPU ইনস্ট্যান্স, ভেক্টর স্টোরেজ আর তাদের তৈরি traffic-এর বিল ঘণ্টা ও গিগাবাইট ধরে আসে। Flexera অপচয় বাড়ার সঙ্গে ঠিক এই workload-গুলোকেই জড়িয়েছে। পরীক্ষা-নিরীক্ষা cloud-এ চালান, যেখানে চাইলেই বন্ধ করা যায়, আর স্থির inference লোডের দাম আলাদা করে কষুন।

মাসিক খরচের একটি হিসাব

একটা কাল্পনিক দোকান ধরা যাক: একটি ওয়েব app, ব্যাকগ্রাউন্ড worker, একটি PostgreSQL database আর মাসে প্রায় ৮ TB আউটবাউন্ড traffic। অঙ্কগুলো হিসাব বোঝানোর জন্য গোল করা, কোনো কোটেশন নয়। ops-এর সময় ধরা হয়েছে ঘণ্টায় $৭৫।

খাত (উদাহরণমূলক)হাইপারস্কেলার, on-demandদুটি ডেডিকেটেড server + database-এর জন্য আরও দুটি
কম্পিউট (app ও worker)$৯০০$২৩০
database (প্রাইমারি + replica)$১,১০০ ম্যানেজড$২৩০ নিজে চালানো
Egress, ৮ TB$৭১১$০ (ভাড়ার মধ্যেই)
backup ও স্ন্যাপশট$১৯০$৬০ অফ-সাইট অবজেক্ট স্টোরেজ
লোড ব্যালেন্সার, লগ, monitoring$৪৫০$৯০
Ops ঘণ্টা২৫ ঘণ্টা = $১,৮৭৫৪৫ ঘণ্টা = $৩,৩৭৫
মাসে মোট$৫,২২৬$৩,৯৮৫

Egress লাইনটা সোজা অঙ্ক: ৮,০০০ GB থেকে ফ্রি ১০০ GB বাদ দিলে ৭,৯০০ GB, গুণ $০.০৯ করলে $৭১১। মাসিক সাশ্রয় $১,২৪১, অর্থাৎ প্রায় ২৪%, বছরে $১৪,৮৯২।

খুশি হওয়ার আগে শেষ সারিটা দেখুন। হার্ডওয়্যার আর ব্যান্ডউইথ খরচ $৩,৩৫১ থেকে নেমে $৬১০ হয়েছে, কিন্তু ops-এর সময় ২০ ঘণ্টা বেড়েছে। ব্রেক-ইভেন সেখানে, যেখানে $৬১০ আর $৭৫ গুণ ঘণ্টা মিলে $৫,২২৬ হয়, মানে মাসে প্রায় ৬১ ঘণ্টা। এর বেশি লাগলে cloud-ই সস্তা ছিল।

এবার cloud-এর কম্পিউট আর database-এ এক বছরের কমিটমেন্টে ৩০% ছাড় ধরুন। cloud-এর মোট দাঁড়ায় $৪,৬২৬, ফারাক নামে $৬৪১-এ, আর ব্রেক-ইভেন নেমে আসে প্রায় ৫৪ ঘণ্টায়। ২০০ ইঞ্জিনিয়ারিং-ঘণ্টার মাইগ্রেশনে খরচ $১৫,০০০। আগের ফারাকে সেই খরচ উঠে আসতে প্রায় বারো মাস লাগে; ছোট ফারাকে লাগে আরও অনেক বেশি।

০.২৫x, ১x, ২x ও ৪x traffic-এ হাইপারস্কেলার বনাম ডেডিকেটেড server-এর উদাহরণমূলক মাসিক খরচের বার চার্ট; ০.২৫x আর ১x-এর মাঝখানে ক্রসওভার
একই দোকান চার আকারে: ছোট থাকতে cloud সস্তা, traffic আর data বাড়তে থাকলে হিসাব উল্টে যায়।

থাকবেন নাকি সরবেন: চারটি প্রশ্ন

সিদ্ধান্ত খুব কমই শুধু দামে আটকায়। এই ক্রমে চারটি প্রশ্ন বেশির ভাগ ব্যবসাকে আলাদা করে ফেলে।

প্রথম, লোড কি স্থির, আর বিল কি এমন বড় যে সাশ্রয়ে কিছু আসে-যায়? মাসে মোটামুটি $৩,০০০-এর নিচে সাশ্রয় বাড়তি মনোযোগের খরচ তুলতে পারে না। তখন অপচয় ছাঁটুন আর committed ক্যাপাসিটি কিনুন।

দ্বিতীয়, traffic কি হঠাৎ লাফায়, বা সত্যিই বিশ্বজোড়া? এক ঘণ্টার ফ্ল্যাশ সেলে traffic দশ গুণ হয়ে গেলে ইলাস্টিক ক্যাপাসিটি ঠিক সে জন্যই। সারা বছর পিকের মাপে ভাড়া নেওয়া মানে পিকের কয়েক ঘণ্টার cloud-দামের চেয়ে বেশি দেওয়া। এমন স্পাইক system কীভাবে সামলায়, তা এই সিরিজের autoscaling নিয়ে লেখায় আছে। বিশ্বজোড়া অংশের বড় ভাগ সামলে দেয় স্থির origin-এর সামনে বসানো CDN।

তৃতীয়, প্যাচিং, backup আর on-call কি নির্দিষ্ট কারও দায়িত্বে? নাম ধরে কেউ না থাকলে সাশ্রয়টা আসল নয়। তখন মাঝামাঝি ম্যানেজড বিকল্প বেছে নিন।

চতুর্থ, গ্রাহক বা নিয়ন্ত্রক কি ঠিক করে দেন data কোথায় থাকবে? হ্যাঁ হলে উত্তর একটি আঞ্চলিক বা দেশীয় হোস্ট, যা আপনার এখনকার প্রোভাইডার নাও হতে পারে।

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

মাঝামাঝি বিকল্পগুলো

পছন্দ শুধু হাইপারস্কেলার আর নিজের র‍্যাকের মধ্যে সীমাবদ্ধ নয়।

  • VPS ও ডেডিকেটেড server হোস্টিং প্রোভাইডারের কাছ থেকে। মাসিক দাম স্থির, ব্যান্ডউইথ ধরা, software আপনি চালান। উপরের হিসাবে এটাই ধরা হয়েছে।
  • আঞ্চলিক বা sovereign cloud প্রোভাইডার, যারা পরিচিত বিল্ডিং ব্লক দেয়, যেমন ভার্চুয়াল মেশিন, অবজেক্ট স্টোরেজ আর ম্যানেজড database, কম দামে এবং স্পষ্ট আইনি ঠিকানায়।
  • ম্যানেজড হোস্টিং, যেখানে প্রোভাইডার server চালায় আর অ্যাপ্লিকেশনের root-level নিয়ন্ত্রণ থাকে আপনার হাতে। খরচ খালি server-এর চেয়ে বেশি, নিজের টিম গড়ার চেয়ে কম।
  • কলোকেশন, যেখানে হার্ডওয়্যার আপনার, র‍্যাকের জায়গা, বিদ্যুৎ আর network পোর্ট ভাড়া। 37signals-এর মতো বড়, স্থির আর লোকবলওয়ালা ব্যবসার জন্য এটা মানানসই।

সরানো কত সস্তা হবে, তা ঠিক করে পোর্টেবিলিটি। container আর একটিমাত্র compose ফাইলে প্যাকেজ করা app, StoreConsole-এর মতো self-hosted platform যেমন, এসবের যেকোনোটিতে একটা বিকেলেই সরে যায়। মালিকানাধীন queue আর serverless ফাংশনে আটকে থাকা app-এ আগে নতুন করে কোড লিখতে হয়।

data-র সার্বভৌমত্ব আর গ্রাহকের প্রশ্ন

বড় ক্রেতারা এখন জিজ্ঞেস করেন data কোথায় থাকে, কে আইনত তাতে প্রবেশাধিকার দাবি করতে পারে, আর তারা কি চাইলে সরে যেতে পারবেন। এগুলো প্রকিউরমেন্টের প্রশ্ন, আর উত্তর দিতে না পারলে ডিল হাতছাড়া হয়।

নিয়মকানুনও সরে যাওয়ার খরচ কমিয়ে আনছে। EU Data Act অনুযায়ী ট্রানজিশন সময়ে প্রোভাইডার সুইচ করার জন্য শুধু নিজেদের সরাসরি খরচ নিতে পারে, আর egress-সহ সব সুইচিং চার্জ উঠে যাবে ১২ জানুয়ারি ২০২৭ থেকে। আপনার EU গ্রাহক বা EU চুক্তি থাকলে এই তারিখ পরিকল্পনায় রাখুন। EU-র বাইরে শুরুর আগেই লিখিতভাবে exit-ফি মওকুফ চেয়ে নিন, যেমনটা 37signals করেছে।

অবস্থান মানেই নিরাপত্তা নয়। নিজের দেশের server ঠিকমতো সাজানো cloud রিজিয়নের চেয়ে বেশি নিরাপদ নয়। এটা আইনি প্রশ্নের উত্তর, প্রযুক্তিগত নয়।

রোলব্যাক পয়েন্টসহ মাইগ্রেশন পরিকল্পনা

রিপ্যাট্রিয়েশন কোনো সপ্তাহান্তের ঘটনা নয়, ছোট ছোট ফেরানো-যায় এমন ধাপের ধারা। নিচের প্রতিটি ধাপে শেষটা পর্যন্ত ফেরার পথ খোলা থাকে।

  1. আগে মাপুন। বিল খাত ধরে এক্সপোর্ট করুন, প্রতিটি সার্ভিসের তালিকা বানান, data-র আকার আর পিক traffic লিখে রাখুন। অলস রিসোর্স এখনই ছাঁটুন, কারণ হয়তো দেখবেন সরার দরকারই নেই।
  2. টার্গেট বানান, restore পরীক্ষা করুন। server, প্যাচিং, monitoring আর backup সাজান। যে backup কখনও restore করা হয়নি, তা শুধু ভরসা। কিছু সরানোর আগে একটা backup শুরু থেকে শেষ পর্যন্ত restore করে দেখুন।
  3. stateless অংশ সরান। স্ট্যাটিক ফাইল, app আর worker CDN-এর পেছনে যাবে। কয়েক দিন আগে DNS TTL ৬০ সেকেন্ডে নামিয়ে রাখুন। রোলব্যাক একটা DNS বদল।
  4. database রেপ্লিকেট করুন। logical replication-এ নতুন প্রাইমারিতে পরিবর্তন স্ট্রিম করুন, সবচেয়ে ব্যস্ত টেবিলগুলোর রো-সংখ্যা আর চেকসাম মিলিয়ে দেখুন। রোলব্যাক মানে replica বন্ধ করা।
  5. শান্ত সময়ে কাটওভার করুন। রাইট থামান, replica-কে ধরে ফেলতে দিন, প্রোমোট করুন, DNS বদলান। reverse replication চালু রাখুন, যাতে cloud-এর কপি হালনাগাদ থাকে।
  6. ৩০ দিন দুটোই চালান, তারপর বন্ধ করুন। পুরো একটা বিলিং সাইকেল আর নতুন পক্ষে সফল মাস-শেষের ক্লোজের পরেই cloud-এর রিসোর্স মুছুন।
১৩ সপ্তাহের মাইগ্রেশনের টাইমলাইন: মাপা থেকে কাটওভার হয়ে cloud বন্ধ করা পর্যন্ত, প্রতিটি ধাপের নিচে একটি রোলব্যাক পয়েন্ট
শেষ সহজ রোলব্যাক কাটওভারের সপ্তাহে; এরপর প্রতিটি ধাপ ফেরাতে বেশি খরচ হয়।

সহজে খাটো করে দেখা ঝুঁকি

প্রধান ঝুঁকি অপারেশনের দক্ষতা: কার্নেল ও database প্যাচিং, সার্টিফিকেট নবায়ন, ডিস্ক-ভরে-যাওয়ার alert আর failover ড্রিল এখন আপনার কাজ। দ্বিতীয় ঝুঁকি monitoring, কারণ যে cloud কনসোলের ওপর ভরসা ছিল তা আর নেই। কোনো critical CVE এলে সিকিউরিটি প্যাচের সময়সীমা দিনে মাপা হয়। অন্তত দুজনের on-call রোটেশন ঠিক করুন, নইলে একটা ম্যানেজড স্তর কিনুন।

সরার পরে কী মাপবেন

প্রতি মাসে পাঁচটি সংখ্যা দেখুন। এক, ops ঘণ্টাসহ মোট অবকাঠামো খরচ, কারণ শ্রম বাদ দিলে খরচ ফুলিয়ে দেখায়। দুই, মাসে ops ঘণ্টা, ব্রেক-ইভেনের সঙ্গে মিলিয়ে। তিন, শেষ restore ড্রিলের recovery time, মিনিটে। চার, প্যাচের বয়স, মানে জানা সবচেয়ে পুরনো সিকিউরিটি আপডেট কত দিন আগে বসানো হয়েছে। পাঁচ, প্রধান গ্রাহক-অঞ্চল থেকে p95 latency, কারণ বিশ্বজোড়া network ছাড়লে কিছু মিলিসেকেন্ড হারাতে পারেন।

ops ঘণ্টা ব্রেক-ইভেন ছাড়িয়ে গেলে বা restore ড্রিল ব্যর্থ হলে সরে আসা লাভ দিচ্ছে না, আর সেই ফল দেখে ব্যবস্থা নেওয়াই কাজের।

invoice-এ ফিরে আসা

ফিরে যাই সেই মালিক আর তাঁর $৯,৪০০-এর invoice-এ। লাইন ধরে ভাগ করে তিনি দেখেন, egress আর ম্যানেজড database মিলে বিলের ৪০%, আর egress-এর বেশির ভাগ আসছে origin থেকে সরাসরি দেওয়া product-এর ছবি থেকে।

প্রথমে তিনি সামনে একটা CDN বসান, যাতে এই দৃশ্যকল্পে এক সপ্তাহের মধ্যে egress অর্ধেকের বেশি কমে। তারপর ১৩ সপ্তাহের পরিকল্পনায় স্থির database আর worker ডেডিকেটেড server-এ সরান, স্টোরফ্রন্টের edge আর সেল-দিনের বাড়তি ক্ষমতা cloud-এই রাখেন, আর restore ড্রিল ক্যালেন্ডারে তুলে দেন। invoice এখন লাইন ধরে ব্যাখ্যা করার মতো একটা দলিল, আর পরের বাড়তির পাশে একটা নাম লেখা থাকবে।

মূল কথাগুলো

  • স্থির, data-ভারী কাজ, যার অপারেশনের একজন মালিক আছে, তার জন্য রিপ্যাট্রিয়েশন লাভজনক। 37signals-এর সাশ্রয় এসেছে $৩২ লাখের বিল আর বছরের অভিজ্ঞতা থেকে।
  • Flexera-র ২০২৬ report-এর হিসাবে cloud খরচের ২৯% অপচয়, তাই কিছু সরানোর আগে অপচয়, কমিটমেন্ট আর egress ঠিক করুন।
  • ops ঘণ্টার দাম বাস্তব হারে ধরুন। উদাহরণে সরালে ২৪% বাঁচে, আর মাসে প্রায় ৬১ ঘণ্টা ops কাজে ব্রেক-ইভেন হয়।
  • হঠাৎ-লাফানো আর বিশ্বজোড়া অংশ cloud-এ রাখুন, স্থির অংশ সরান; মাঝখানে CDN আর আঞ্চলিক বা ডেডিকেটেড হোস্ট কাজে লাগান।
  • ফেরানো-যায় এমন ধাপে মাইগ্রেট করুন: restore-পরীক্ষিত backup, রেপ্লিকেট করা data, শান্ত কাটওভার, reverse replication আর ৩০ দিনের ওভারল্যাপ।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।

About the Author

Anichur Rahaman

Continue Reading