০৩. ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন (Back-of-the-envelope Estimation) বা খসড়া হিসাব

সিস্টেম ডিজাইন ইন্টারভিউতে অনেক সময় আপনাকে ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন (খসড়া হিসাব) ব্যবহার করে কোনো সিস্টেমের ধারণক্ষমতা (capacity) বা পারফরম্যান্সের প্রয়োজনীয়তা অনুমান করতে বলা হতে পারে। গুগলের সিনিয়র ফেলো জেফ ডিনের মতে, “ব্যাক-অফ-দ্য-এনভেলপ ক্যালকুলেশন হলো এমন এক ধরণের অনুমান, যা আপনি বিভিন্ন থট এক্সপেরিমেন্ট (thought experiments) এবং প্রচলিত পারফরম্যান্স ডেটার সমন্বয়ে তৈরি করেন। এর মাধ্যমে আপনি সহজেই বুঝতে পারেন যে কোন ডিজাইনটি আপনার সিস্টেমের চাহিদাগুলো ভালোভাবে মেটাতে পারবে” [১]।

সঠিকভাবে এই ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন করার জন্য আপনার স্কেলেবিলিটির (scalability) প্রাথমিক বিষয়গুলো সম্পর্কে খুব ভালো ধারণা থাকতে হবে। বিশেষ করে নিচের বিষয়গুলো ভালোভাবে বুঝতে হবে:

• পাওয়ার অফ টু বা ২-এর ঘাত (power of two) [২]
• ল্যাটেন্সি নাম্বার (latency numbers) যা প্রতিটি প্রোগ্রামারের জানা উচিত
• অ্যাভেইলেবিলিটি নাম্বার বা সিস্টেমের প্রাপ্যতার হিসাব (availability numbers)

পাওয়ার অফ টু (Power of two) বা ২-এর ঘাত

ডিস্ট্রিবিউটেড সিস্টেম (distributed systems) নিয়ে কাজ করার সময় ডেটার পরিমাণ অনেক বিশাল হতে পারে, কিন্তু সব হিসাব-নিকাশ দিনশেষে একদম মৌলিক বিষয়গুলোর ওপরই নির্ভর করে। নির্ভুল হিসাব পাওয়ার জন্য ‘পাওয়ার অফ ২’ (২-এর ঘাত) ব্যবহার করে ডেটা ভলিউমের এককগুলো (data volume units) জানা অত্যন্ত গুরুত্বপূর্ণ।

একটি বাইট (byte) হলো ৮টি বিটের (bits) সমষ্টি। একটি আসকি (ASCII) ক্যারেক্টার মেমোরিতে এক বাইট (৮ বিট) জায়গা দখল করে। নিচে ডেটা ভলিউমের এককগুলো ব্যাখ্যা করার জন্য একটি সারণী (Table 1) দেওয়া হলো:

ল্যাটেন্সি নাম্বার যা প্রতিটি প্রোগ্রামারের জানা উচিত (Latency numbers every programmer should know)

গুগলের ড. ডিন ২০১০ সালে সাধারণ কম্পিউটার অপারেশনের সময়কালের একটি তালিকা প্রকাশ করেন [১]। কম্পিউটার আরও দ্রুতগতিসম্পন্ন ও শক্তিশালী হওয়ার কারণে এর মধ্যে কিছু নাম্বার বা ডেটা এখন পুরোনো হয়ে গেছে। তবে, এই নাম্বারগুলো এখনও আমাদের বিভিন্ন কম্পিউটার অপারেশনের গতি (কোনটা কত দ্রুত বা ধীর) সম্পর্কে একটি ভালো ধারণা দিতে পারে।

সারণী ১ (Table 1)

সারণী ২: নোট (Table 2 Notes)

• ns = ন্যানোসেকেন্ড (nanosecond), µs = মাইক্রোসেকেন্ড (microsecond), ms = মিলি সেকেন্ড (millisecond)
• 1 ns = 10^-9 সেকেন্ড
• 1 µs = 10^-6 সেকেন্ড = 1,000 ns
• 1 ms = 10^-3 সেকেন্ড = 1,000 µs = 1,000,000 ns

গুগলের একজন সফটওয়্যার ইঞ্জিনিয়ার ড. ডিনের এই নাম্বারগুলো ভিজ্যুয়ালাইজ করার জন্য একটি টুল তৈরি করেছেন। টুলটি সময়ের পরিবর্তনের বিষয়টিও বিবেচনায় রাখে। চিত্র ১-এ (Figure 1) ২০২০ সাল পর্যন্ত এই ল্যাটেন্সি নাম্বারগুলোর ভিজ্যুয়ালাইজেশন দেখানো হয়েছে (ছবির উৎস: রেফারেন্স ম্যাটেরিয়াল [৩])।

চিত্র ১-এর ডেটা বিশ্লেষণ করে আমরা নিচের সিদ্ধান্তগুলোতে পৌঁছাতে পারি:

• মেমরি অনেক দ্রুত কাজ করে, কিন্তু ডিস্ক অনেক ধীরগতির।
• যতটা সম্ভব ডিস্ক সিক (disk seeks) এড়িয়ে চলা উচিত।
• সাধারণ কম্প্রেশন অ্যালগরিদমগুলো (compression algorithms) বেশ দ্রুত কাজ করে।
• ইন্টারনেটে ডেটা পাঠানোর আগে সম্ভব হলে তা কমপ্রেস (compress) করে নেওয়া উচিত।
• ডেটাসেন্টারগুলো সাধারণত বিভিন্ন অঞ্চলে (regions) অবস্থিত থাকে, তাই এদের মধ্যে ডেটা আদান-প্রদান করতে বেশ খানিকটা সময় লাগে।

অ্যাভেইলেবিলিটি নাম্বার (Availability numbers) বা প্রাপ্যতার হিসাব

হাই অ্যাভেইলেবিলিটি (High availability) হলো কোনো সিস্টেমের দীর্ঘ সময় ধরে নিরবচ্ছিন্নভাবে কাজ বা অপারেশনাল থাকার ক্ষমতা। এটি সাধারণত শতাংশে (percentage) পরিমাপ করা হয়। ১০০% মানে হলো এমন একটি সার্ভিস যার কোনো ডাউনটাইম (downtime) বা বন্ধ থাকার সময় নেই। তবে বেশিরভাগ সার্ভিসই ৯৯% থেকে ১০০%-এর মধ্যে থাকে।

সার্ভিস লেভেল অ্যাগ্রিমেন্ট (Service Level Agreement বা SLA) হলো সার্ভিস প্রোভাইডারদের জন্য একটি বহুল ব্যবহৃত শব্দ। এটি মূলত আপনার (সার্ভিস প্রোভাইডার) এবং আপনার গ্রাহকের মধ্যে একটি চুক্তি, যা আনুষ্ঠানিকভাবে নির্ধারণ করে যে আপনার সার্ভিস ঠিক কতটা আপটাইম (uptime) দেবে। অ্যামাজন (Amazon) [৪], গুগল (Google) [৫] এবং মাইক্রোসফটের (Microsoft) [৬] মতো ক্লাউড প্রোভাইডাররা তাদের SLA ৯৯.৯% বা তার ওপরে রাখে। আপটাইম ঐতিহ্যগতভাবে “নাইনস” (nines বা ৯) দিয়ে পরিমাপ করা হয়। ৯-এর সংখ্যা যত বেশি, সার্ভিস তত ভালো। সারণী ৩-এ দেখানো হয়েছে কীভাবে ৯-এর সংখ্যা সিস্টেমের সম্ভাব্য ডাউনটাইমের সাথে সম্পর্কিত।

সারণী ৩ (Table 3)

উদাহরণ: টুইটারের QPS এবং স্টোরেজের প্রয়োজনীয়তা অনুমান করা (Estimate Twitter QPS and storage requirements)

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

অনুমান বা ধারণা (Assumptions):

• মাসিক সক্রিয় ব্যবহারকারী (monthly active users) ৩০০ মিলিয়ন।
• ৫০% ব্যবহারকারী প্রতিদিন টুইটার ব্যবহার করেন।
• ব্যবহারকারীরা গড়ে প্রতিদিন ২টি করে টুইট করেন।
• ১০% টুইটে মিডিয়া (ছবি/ভিডিও) থাকে।
• ৫ বছরের জন্য ডেটা সংরক্ষণ করা হয়।

হিসাব (Estimations):

১. প্রতি সেকেন্ডে কুয়েরি বা কিউপিএস (QPS) এর হিসাব:

• ডেইলি অ্যাক্টিভ ইউজার বা দৈনিক সক্রিয় ব্যবহারকারী (DAU) = ৩০০ মিলিয়ন * ৫০% = ১৫০ মিলিয়ন।
• টুইট QPS = ১৫০ মিলিয়ন * ২ টুইট / ২৪ ঘণ্টা / ৩৬০০ সেকেন্ড = ~৩৫০০
• পিক (Peak) বা সর্বোচ্চ QPS = ২ * QPS = ~৭০০০

২. মিডিয়া স্টোরেজের হিসাব (আমরা এখানে শুধুমাত্র মিডিয়া স্টোরেজের হিসাব করব):

• একটি টুইটের গড় সাইজ:
  • tweet_id: ৬৪ বাইট (64 bytes)
  • text: ১৪০ বাইট (140 bytes)
  • media: ১ মেগাবাইট (1 MB)
• মিডিয়া স্টোরেজ: ১৫০ মিলিয়ন * ২ * ১০% * ১ এমবি = প্রতিদিন ৩০ টেরাবাইট (30 TB)
• ৫ বছরের মিডিয়া স্টোরেজ: ৩০ টিবি * ৩৬৫ দিন * ৫ বছর = ~৫৫ পেটাবাইট (55 PB)

টিপস (Tips)

ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশনের পুরো ব্যাপারটাই হলো এর প্রক্রিয়া (process)। নিখুঁত ফলাফল পাওয়ার চেয়ে সমস্যাটি আপনি কীভাবে সমাধান করছেন সেটি বেশি গুরুত্বপূর্ণ। ইন্টারভিউয়াররা মূলত আপনার প্রবলেম সলভিং স্কিল (problem-solving skills) যাচাই করতে চান। এখানে অনুসরণ করার মতো কিছু টিপস দেওয়া হলো:

• রাউন্ডিং এবং অ্যাপ্রক্সিমেশন (Rounding and Approximation): ইন্টারভিউ চলাকালীন জটিল গাণিতিক হিসাব করা বেশ কঠিন। যেমন ধরুন, “৯৯৯৮৭ / ৯.১” এর ফলাফল কী? এই ধরনের জটিল অঙ্কের পেছনে আপনার মূল্যবান সময় নষ্ট করার কোনো প্রয়োজন নেই। আপনার কাছে নিখুঁত নির্ভুলতা (Precision) আশা করা হয় নিয়োগকর্তারা। তাই রাউন্ড নাম্বার (round numbers) এবং আনুমানিক হিসাব (approximation) ব্যবহার করুন। ওপরের ভাগের অঙ্কটিকে সহজভাবে এভাবে হিসাব করতে পারেন: “১০০,০০০ / ১০”।
• আপনার অনুমানগুলো (assumptions) লিখে রাখুন: আপনি যেসব অনুমান ধরে নিচ্ছেন সেগুলো লিখে রাখা একটি ভালো অভ্যাস, যাতে পরে প্রয়োজন হলে রেফারেন্স হিসেবে ব্যবহার করতে পারেন।
• একক বা ইউনিটগুলো (units) উল্লেখ করুন: আপনি যখন খাতায় “৫” লিখছেন, তখন এটি দিয়ে কি ৫ কিলোবাইট (5 KB) নাকি ৫ মেগাবাইট (5 MB) বোঝাচ্ছেন? এগুলো না লিখলে আপনি নিজেই কনফিউজড হয়ে যেতে পারেন। তাই একক লিখে রাখুন, কারণ “5 MB” লিখলে কোনো দ্বিধা (ambiguity) থাকে না।
• সাধারণত যেসব ব্যাক-অফ-দ্য-এনভেলপ এস্টিমেশন বেশি জিজ্ঞাসা করা হয়: QPS, পিক QPS, স্টোরেজ, ক্যাশ (cache), সার্ভারের সংখ্যা ইত্যাদি। ইন্টারভিউয়ের প্রস্তুতির সময় আপনি এই হিসাবগুলো অনুশীলন করতে পারেন। প্র্যাকটিস আপনাকে নিখুঁত করবে (Practice makes perfect)।

অভিনন্দন, আপনি এতদূর পর্যন্ত পড়ে শেষ করেছেন! দারুণ কাজ করেছেন, এবার নিজের পিঠ একটু চাপড়ে দিন!