রবলোক্স কীভাবে তাদের কাফকা প্ল্যাটফর্মকে দিনে ১৮ ট্রিলিয়নেরও বেশি বার্তা পর্যন্ত স্কেল করেছে

গত দুই বছরে, আমরা প্রতি বছর আমাদের অভ্যন্তরীণ মেসেজ কুই প্ল্যাটফর্মকে ২.৫ গুণ করে প্রতিদিন ১৮ ট্রিলিয়ন বার্তার বেশি পরিমাণে বৃদ্ধি করেছি। বর্তমানে আমরা প্রতি সেকেন্ডে ৩০০ মিলিয়নেরও বেশি বার্তা প্রক্রিয়া করি এবং ৯৯.৯৯৫% উপলব্ধতা বজায় রাখি। এই মেসেজ কুইউ প্ল্যাটফর্মটি, যা Apache Kafka-তে নির্মিত, কোম্পানির মধ্যে ডেটা স্থানান্তরের একটি গুরুত্বপূর্ণ অংশ হয়ে উঠেছে। এটি অ্যানালিটিক্স ইভেন্ট, মডারেশন পাইপলাইন, ম্যাচমেকিং সিস্টেম এবং আরও অনেক কাজের লোড সমর্থন করে। এই সংখ্যাগুলো উত্তেজনাপূর্ণ, তবে আরও গুরুত্বপূর্ণ গল্পটি হলো আমরা কীভাবে সেখানে পৌঁছেছি। 

এন্ড-টু-এন্ড অপ্টিমাইজেশনের প্রভাব 

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

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

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

সব ট্র্যাফিক সমান নয়

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

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

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

হার্ডওয়্যার এখনও গুরুত্বপূর্ণ

আমরা RAID10 HDD মেশিনে Kafka চালিয়ে শুরু করেছিলাম। ট্রাফিক ভলিউম বাড়ার সাথে সাথে, আমাদের মেশিনের ডিস্ক I/O ক্ষমতা প্রতি-সার্ভার Kafka থ্রুপুট সীমিত করার প্রধান বাধা হয়ে দাঁড়ায়। এটি সমাধান করতে, আমরা দুটি অপ্টিমাইজেশন করেছি। আমরা ব্রোকারগুলোকে যতটা সম্ভব SSD ব্যবহার করতে রূপান্তরিত করেছি, ফলে বাধা ডিস্ক I/O ক্ষমত থেকে নেটওয়ার্ক থ্রুপুট বা ডিস্ক স্পেস (যেহেতু আমরা যে SSDগুলো নিয়েছিলাম সেগুলোর ডিস্ক স্পেস কম ছিল) এ স্থানান্তরিত হয়েছে। এতে ডিস্ক I/O থ্রুপুট ১০ গুণ বৃদ্ধি পেয়েছে। আমরা আমাদের বাকি HDD-গুলো RAID10 থেকে RAID0-তে রূপান্তর করতে শুরু করেছি। এতে ডিস্ক I/O সক্ষমতা প্রায় দ্বিগুণ হয়েছে, কারণ RAID0-তে প্রতিটি লেখার জন্য দুইটির পরিবর্তে মাত্র একটি ডিস্ক লেখার প্রয়োজন হয়। 

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

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

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

নির্ভরযোগ্যতার জন্য নির্মাণ

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

আমরা এমন ফেইলওভার প্রক্রিয়াও ডিজাইন ও বাস্তবায়ন করেছি যা নির্ভরশীল ব্যবহারের ক্ষেত্রে কুই (queue) কার্যকারিতা দ্রুত পুনরুদ্ধার করতে পারে। এমনকি একটি ক্লাস্টারের সম্পূর্ণ ব্যর্থতার ক্ষেত্রেও, আমরা ক্লায়েন্টদের পর্যাপ্ত ক্ষমতার একটি সুস্থ ক্লাস্টারে স্থানান্তর করতে সক্ষম হই। পর্যাপ্ত অব্যবহৃত ক্ষমতা নিশ্চিত করার জন্য, আমরা একটি স্ট্যান্ডবাই Kafka ক্লাস্টার রক্ষণাবেক্ষণ করি। এটি লাইভ ক্লাস্টারগুলির মধ্যে ট্র্যাফিক স্থানান্তর করার সময় 'নয়েজি নেবার' (noisy neighbor) সমস্যার যে কোনো ঝুঁকি দূর করতে সাহায্য করে।

নিচের ডায়াগ্রামটি একটি ফেইলওভার সম্পাদনের উচ্চ-স্তরের ধাপগুলি দেখায়। প্রথমে, একজন অপারেটর ফেইলওভারের পরিধি নির্ধারণ করে। তারপর, স্বয়ংক্রিয় বাল্ক অপারেশনের মাধ্যমে স্ট্যান্ডবাই ক্লাস্টারে টপিক এবং অ্যাক্সেস কন্ট্রোল লিস্ট (ACL) তৈরি করা হয়। অবশেষে, অপারেটর আমাদের কন্ট্রোল প্লেন সার্ভিস কনফিগগুলো আপডেট করে, যেগুলো ক্লায়েন্টরা পুনঃসংযোগের প্রয়োজন আছে কিনা তা নির্ধারণ করতে পোল করে। নিচের চিত্রটি সাধারণ রিয়েল-টাইম ব্যবহারের ক্ষেত্রে জন্য। আমাদের কাছে অন্যান্য ব্যবহারের ক্ষেত্রে এবং পরিস্থিতিতে অতিরিক্ত কৌশল ও টুলিং রয়েছে, যেমন Mirror Maker 2 ব্যবহার করে টপিক মিররিং, ডেটা ব্যাকফিল টুলিং, এবং আরও অনেক কিছু।

Roblox-এর নিরাপত্তার জন্য কঠোর শর্তাবলী রয়েছে, যা নির্ভরযোগ্যতার একটি গুরুত্বপূর্ণ অংশ। আমরা পরিবহনের সময় এনক্রিপশন (mTLS সহ), বিশ্রামকালীন এনক্রিপশন (এনক্রিপ্টেড ডিস্ক সহ), ডেটা সংরক্ষণ সময়সীমা সংক্রান্ত শর্তাবলী, এবং Kafka প্রিন্সিপাল ও ACL-এর মাধ্যমে প্রমাণীকরণ/অনুমতি বাস্তবায়ন করেছি। আমরা নিরাপত্তার আরও উন্নতির জন্য স্বয়ংক্রিয়ভাবে আমাদের ব্যবহারকারীদের ক্রেডেনশিয়াল রোটেশন করি।

এছাড়াও, আমরা আমাদের কন্ট্রোল প্লেনে দ্রুত OS প্যাচিং এবং র‌্যাক ড্রেন সুবিধার্থে কাস্টম হ্যান্ডলিং তৈরি করেছি। OS প্যাচিংয়ের সময়, আমরা ডিস্কে ডেটা সংরক্ষণ করি যাতে প্যাচ করা মেশিনগুলো Kafka ক্লাস্টারে পুনরায় যোগদানের পর দ্রুত সুস্থতা ফিরে পেতে পারে। এভাবে, আমাদের ফ্লিট বাড়তেই থাকলেও ৩০ দিনের মধ্যে পুরো ফ্লিট প্যাচ করতে পারি। Cruise Control-এর মতো টুল ব্যবহার করে আমরা আমাদের ডেটা র‌্যাক-সচেতনভাবে প্রতিলিপি করি, যাতে রক্ষণাবেক্ষণ এবং নেটওয়ার্ক প্যাচিংয়ের জন্য পুরো র‌্যাকগুলো ডেটার উপলব্ধতায় কোনো প্রভাব ছাড়াই অফলাইনে নেওয়া যায়।

আগামী পথ

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

Kafka স্কেল করা শুধুমাত্র ক্লাস্টারের সংখ্যা ও আকার বৃদ্ধি করার ব্যাপার নয়। এটি সেই প্রকৌশলগত শৃঙ্খলা, বিমূর্ততা এবং অপারেশনাল মডেল গড়ে তোলার বিষয়, যা Roblox-কে প্রতিদিন এক বিলিয়ন মানুষকে আশাবাদ ও ভদ্রতার সঙ্গে সংযুক্ত করার যাত্রায় এগিয়ে যেতে সাহায্য করে।