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

আমাদের ক্যাশিং স্তরটি মিলিয়ন মিলিয়ন সমসাময়িক ব্যবহারকারী এবং আমাদের স্থায়ী স্টোরেজের মধ্যে একটি বিশাল শক অ্যাবজরবার হিসেবে কাজ করার জন্য ডিজাইন করা হয়েছে। এটি প্রতি সেকেন্ডে ১.৩৮ বিলিয়ন কোয়েরি (QPS) এর সর্বোচ্চ লোড সামলায়, যেখানে একক যৌক্তিক ক্লাস্টারগুলো ১০০ মিলিয়ন QPS ছাড়িয়ে যায়। এই পোস্টে, আমরা ফেডারেশনকৃত ক্যাশিং সার্ভিস কীভাবে আর্কিটেক্ট করেছি, যা Redis® নোডের সীমা ছাড়িয়ে বিশাল থ্রুপুট নিশ্চিত করে, এবং একই সাথে আমাদের বৃহত্তম ক্লাস্টারে অভূতপূর্ব ১০ গুণ ট্র্যাফিক বৃদ্ধির মোকাবিলা করে, তা উন্মোচন করব।

ক্রমবর্ধমান চাহিদা মেটাতে শিল্প সীমা ছাড়িয়ে স্কেলিং

Roblox-এ, আমাদের ক্যাশিং সার্ভিস Redis® প্রযুক্তির ওপর নির্মিত, এবং একটি Redis® ক্লাস্টার সর্বোচ্চ ১,০০০ নোড সমর্থন করতে পারে। তবে বাস্তব অভিজ্ঞতা ও শিল্পে গৃহীত সীমা অনেক কম—প্রায় ৪০০–৫০০ নোড।¹ এর কারণ হলো Redis®-এর বিকেন্দ্রীকৃত গসিপ প্রোটোকল, যা হেলথ, স্ট্যাটাস এবং শার্ড ম্যাপিং শেয়ার করতে ইন্টারনোড যোগাযোগ ব্যবহার করে। কয়েকশ নোডের চেয়ে বড় ক্লাস্টারে, গসিপ প্রোটোকলের এই বার্তালাপ উল্লেখযোগ্য পরিমাণ CPU এবং নেটওয়ার্ক রিসোর্স ব্যবহার করতে শুরু করে। প্রতিটি নোডকে ক্রমবর্ধমান সংখ্যক পিয়ার থেকে স্ট্যাটাস আপডেট প্রক্রিয়াকরণ করতে হয়, যা কম লেটেন্সিতে ডেটা পরিবেশন করার মূল কাজের জন্য রিসোর্স ছিনিয়ে নেয়। এই কন্ট্রোল প্লেন ওভারহেড অস্থিতিশীলতা এবং অপ্রত্যাশিত কর্মক্ষমতার দিকে নিয়ে যেতে পারে, এজন্যই ম্যানেজড ক্লাউড প্রদানকারীরা নোড সীমা আরোপ করে। এটি একটি ব্যবহারিক সীমা যা নির্ভরযোগ্যতার সাথে আপস না করে অতিক্রম করা যায় না।

এই ব্যবহারিক একক ক্লাস্টার সীমা Roblox-এর মতো স্কেলে চলমান প্ল্যাটফর্মকে সমর্থন করার জন্য যথেষ্ট নয়, যেখানে বৃহত্তম ব্যাকএন্ড সার্ভিস তিন মাসের মধ্যে ১০ মিলিয়ন থেকে শীর্ষে আমাদের একটি যৌক্তিক Redis® ক্লাস্টার থেকে ১০০ মিলিয়নেরও বেশি QPS দাবি করেছিল।

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

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

তিন-পর্যায়ের মাইগ্রেশন প্রক্রিয়া

শত শত সক্রিয় প্রোডাকশন ক্লাস্টার পরিচালনা করার সময় ঐতিহ্যগত সেটআপ থেকে ফেডারেশন আর্কিটেকচারে স্থানান্তর করা ছিল একটি উল্লেখযোগ্য উদ্যোগ। ২০২৪ সালের শেষে, এই ক্লাস্টারগুলির অনেকই ইতিমধ্যেই আমাদের ৪০০-নোড সীমার কাছাকাছি পৌঁছে গিয়েছিল, যা উচ্চ ক্ষমতার মডেলে স্থানান্তরকে জরুরি করে তুলেছিল। প্রধান চ্যালেঞ্জ ছিল যে স্ট্যান্ডার্ড Redis® ইনস্ট্যান্সগুলো বিচ্ছিন্নভাবে কাজ করে এবং অন্যান্য ক্লাস্টারের কোনো অন্তর্নিহিত সচেতনতা থাকে না, ফলে স্থানান্তরের সময় ডেটা অনুলিপি করার জন্য একটি কাস্টম পদ্ধতি প্রয়োজন হয়েছিল।

এই সমস্যার সমাধানে, আমরা একটি স্বচ্ছ, তিন-পর্যায়ের মাইগ্রেশন পাইপলাইন তৈরি করেছি যা কোনো গ্রাহক সম্পৃক্ততা বা অ্যাপ্লিকেশন-সাইড পরিবর্তনের ছাড়াই সেবাগুলো স্থানান্তর করার জন্য ডিজাইন করা হয়েছে।

মিগ্রেশন ওয়ার্কফ্লো

1. দ্বৈত-লেখন: আমরা ক্লায়েন্ট রিভার্স প্রক্সিকে দ্বৈত লেখনের জন্য কনফিগার করেছি, যাতে ইনকামিং ডেটা একযোগে মূল ক্লাস্টার এবং নতুন ফেডারেশন গন্তব্যে পাঠানো হয়।
2. সমতা এবং রিড সুইচ: একবার ডুয়াল-রাইট প্রক্রিয়া নতুন ক্লাস্টারে অভিন্ন ডেটা পূরণ করলে, যেহেতু সমস্ত ডেটা একটি টাইম টু লিভ (TTL) দ্বারা সীমাবদ্ধ, আমরা লিগ্যাসি ক্লাস্টার থেকে নতুন ফেডারেশনযুক্ত স্থাপত্যে রিড ট্র্যাফিক স্থানান্তরিত করি।
3. বর্জন: নতুন ক্লাস্টারের স্থিতিশীলতা নিশ্চিত করার পর, আমরা মূল ক্লাস্টারে সমস্ত লেখার কার্যক্রম বন্ধ করে সেটিকে অবসর দিয়েছি।

আমরা সফলভাবে আমাদের সবচেয়ে গুরুত্বপূর্ণ পরিষেবাগুলিকে একটি ফেডার্টেড মডেলে স্থানান্তর করেছি, যা ৬,০০০টিরও বেশি নোড সমর্থন করে, যা একক Redis® ক্লাস্টারের সীমাবদ্ধতাকে অনেক ছাড়িয়ে গেছে। 

Grow a Garden-এর বিস্ফোরক বৃদ্ধির মোকাবিলা

২০২৫ সালের এপ্রিল থেকে, আমরা এমন এক মাত্রার সক্ষমতা চ্যালেঞ্জের মুখোমুখি হলাম যা খুব কম সেবাই কখনোই মোকাবিলা করে। এর কারণ ছিল Grow a Garden-এর অসাধারণ সাফল্য। লঞ্চের মাত্র কয়েক সপ্তাহের মধ্যেই Grow a Garden শুধুমাত্র Roblox-এর রেকর্ডই ভাঙেনি, বরং সমসাময়িক ব্যবহারকারী (CCU)-এর ক্ষেত্রে গেমিং শিল্পের সর্বকালের রেকর্ডও ভেঙে দিয়েছে। মাত্র তিন মাসে, গেমের দর্শকসংখ্যা আমাদের পূর্বের একক-গেমের CCU রেকর্ড ২.৮ মিলিয়ন খেলোয়াড় ছাড়িয়ে ২১ মিলিয়নেরও বেশি সর্বোচ্চ পর্যায়ে পৌঁছে। এই বিস্ফোরক বৃদ্ধি আমাদের বৃহত্তম Redis® ক্লাস্টারে ১০ গুণ বেশি ট্র্যাফিক এবং সামগ্রিক ক্যাশিংয়ে ৩ গুণ বেশি ট্র্যাফিক প্রেরণ করেছে।

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

বৃদ্ধির সময় দক্ষতা বৃদ্ধি

প্রথমে, আমাদের সিস্টেমে সবচেয়ে প্রভাবশালী বটলনেকগুলো চিহ্নিত করতে হয়েছিল যাতে আমরা অপ্টিমাইজেশন কাজগুলোকে অগ্রাধিকার দিতে পারি। Roblox Caching দুটি ভিন্ন হার্ডওয়্যার পুলে চলে: একটি Redis® ব্যাকএন্ড নোডের জন্য এবং অন্যটি Envoy-এর জন্য। আমাদের Redis® ফ্লিট প্রধানত মেমোরি-বাউন্ড, অন্যদিকে ক্লায়েন্ট প্রক্সি কম্পিউট-বাউন্ড। 

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

সিপিইউ ব্যবহারের উন্নতির জন্য, আমরা আমাদের ক্যাশ সিস্টেমে দুটি মূল অপ্টিমাইজেশন প্রয়োগ করেছি:

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

এই পরিবর্তনগুলির ফলে CPU ব্যবহারে প্রায় ১০% উন্নতি হয়েছে। অবশেষে, আমরা cgroup কন্টেইনার-স্তরের বিচ্ছিন্নতার মাধ্যমে এই দুইটি সম্পূর্ণ ভিন্ন ওয়ার্কলোডকে একই মেশিন পুলে একত্রিত করেছি, যা আমাদের মোট ক্ষমতার প্রয়োজন ২৫% কমিয়েছে।

অটল নির্ভরযোগ্যতার জন্য ইঞ্জিনিয়ারিং

রেকর্ড-ভাঙা চাহিদা মেটাতে আমরা যতই দৌড়াচ্ছিলাম, ততই নির্ভরযোগ্যতা আমাদের শীর্ষ অগ্রাধিকার ছিল। 

এন্ড-টু-এন্ড পর্যবেক্ষণযোগ্যতা

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

ব্যর্থতা মোকাবেলা

এই মাত্রার যেকোনো বিতরণকৃত সিস্টেমে আংশিক ব্যর্থতা মাঝে মাঝে ঘটে। আমরা আমাদের সিস্টেমকে এই ব্যর্থতাগুলো সুন্দরভাবে মোকাবেলা করতে এবং তাদের প্রভাব কমাতে ইঞ্জিনিয়ার করেছি।

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

ক্লায়েন্ট-সাইড স্থিতিস্থাপকতা

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

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

রবলোক্স ক্যাশিং-এর ভবিষ্যত

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

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

স্বীকৃতি: 

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