9.7 ক্ষমতা পরিকল্পনা ও চাহিদা পূর্বাভাস

পরিচিতি ও প্রেরণা

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

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

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

মূল নীতিসমূহ

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

সুপারিশ

ক্ষমতা পরিকল্পনা, অটোস্কেলিং ও কর্মক্ষমতা প্রকৌশল আলাদা করুন

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

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

প্রবণতা, ঋতুভিত্তিকতা, ঘটনা ও ব্যবসায়িক বৃদ্ধি থেকে চাহিদা পূর্বাভাস দিন

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

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

ব্যবহার লক্ষ্য ঠিক করুন এবং সারি-তত্ত্বের খাদ সম্মান করুন

খরচ বাঁচাতে অবকাঠামো ৯০% ব্যবহারে “গরম” চালানোর সহজাত বোধ একটি ফাঁদ, এবং কারণ সারি-তত্ত্ব, যা অধ্যায় 11.3-এ গভীরভাবে ঢাকা। একটি সম্পদ পূর্ণ ব্যবহারের কাছে গেলে অপেক্ষার সময় নরম ও রৈখিকভাবে বাড়ে না; তা বিস্ফোরিত হয়। ৫০% ব্যবহারের একটি সার্ভারের আরামদায়ক হেডরুম আছে; ৯০%-এ একই সার্ভার কয়েকগুণ খারাপ বিলম্ব দেখতে পারে, এবং ৯৫%-এ সারি পুরোপুরি ছুটে যেতে পারে। সম্পৃক্তির কাছে বিলম্ব একটি খাদ, ঢাল নয়, এবং আপনার ব্যবহারকারীরা সম্পদ প্রযুক্তিগতভাবে “পূর্ণ” হওয়ার অনেক আগেই টাইমআউট, পুনঃচেষ্টা ও ত্রুটি হিসেবে সেই খাদ অনুভব করে।

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

লোড টেস্টিং ও বেঞ্চমার্কিংয়ে প্রকৃত সীমা খুঁজুন

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

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

সুচিন্তিতভাবে প্রস্তুতকরণ কৌশল বাছুন

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

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

অটোস্কেল না করা কঠিন বাধা মানচিত্র করুন

অটোস্কেলিং একটি বিপজ্জনক আত্মবিশ্বাস জন্মায়, কারণ অনেক সীমা যা স্কেল করে তার নিম্নধারায় বসে এবং সে সরলে নড়ে না। ডেটাবেস সংযোগ পুল ক্লাসিক উদাহরণ: আপনার স্টেটলেস স্তর ১০ থেকে ১০০ ইনস্ট্যান্সে স্কেল করুন এবং প্রত্যেকে একই ডেটাবেসে সংযোগ খোলে, যার একযোগ সংযোগে কঠিন সীমা আছে এবং নতুনগুলো প্রত্যাখ্যান করা শুরু করবে। ক্লাউড অ্যাকাউন্ট প্রায় সবকিছুতে কোটা বহন করে: প্রতি অঞ্চলে ইনস্ট্যান্স, IP ঠিকানা, প্রতি সেকেন্ডে API কল, ফাংশন একযোগতা। স্থাপত্যের যেকোনো একক বিন্দু, একটি প্রাথমিক ডেটাবেস, একটি লিডার নোড, একটি ভাগ করা ক্যাশ, একটি লাইসেন্সযুক্ত অ্যাপ্লায়েন্স, অন্যত্র অনুভূমিক স্কেলিং যা উঁচু করতে পারে না এমন একটি সীমা।

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

কেবল গড় নয়, সর্বোচ্চ ঘটনার জন্য প্রস্তুত করুন

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

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

ক্ষমতা যন্ত্রসজ্জিত করুন এবং একটি ছন্দে পর্যালোচনা করুন

ক্ষমতা পরিকল্পনা ডেটায় চলে, এবং ডেটা আসে অধ্যায় 9.2-এর পর্যবেক্ষণযোগ্যতা থেকে। প্রতিটি সীমাবদ্ধ সম্পদের (CPU, মেমরি, ডিস্ক, নেটওয়ার্ক, সংযোগ পুল, সারি গভীরতা) ব্যবহার তার সীমার বিপরীতে অনুসরণ করুন, যাতে হেডরুম অদৃশ্য হওয়ার আগে সংকুচিত হতে দেখতে পান। সম্পৃক্তি সংকেত সরাসরি দেখুন: সারি দৈর্ঘ্য, অপেক্ষার সময় ও প্রত্যাখ্যান হার সারি খাদ কাছে আসা প্রকাশ করে। বর্তমান বৃদ্ধি হারে একটি সম্পদ কখন তার সীমায় পৌঁছাবে প্রক্ষেপণ করতে সপ্তাহ ধরে এগুলোর প্রবণতা দেখুন, এবং কেবল বর্তমান মানের বদলে প্রক্ষেপণে সতর্ক করুন, যাতে আপনি দেয়ালে নয়, তার আগে প্রস্তুত করেন।

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

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

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

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

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

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

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

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

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

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

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

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

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

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

উদাহরণ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
• John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
• Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
• Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
• Brendan Gregg, Systems Performance: Enterprise and the Cloud
• Leonard Kleinrock, Queueing Systems, Volume 1: Theory
• J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management