আমরা কীভাবে Roblox-এর অবকাঠামো আরও দক্ষ ও স্থিতিস্থাপক করে তুলছি

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

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

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

ব্যাকস্টপ তৈরি করা

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

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

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

সেলুলার অবকাঠামোতে স্থানান্তর

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

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

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

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

বড় চ্যালেঞ্জ সমাধান

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

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

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

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

সর্বদা চালু থাকা অবকাঠামো স্থানান্তর

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

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

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

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

স্কেল করার সাথে সাথে ভবিষ্যতের জন্য প্রস্তুতি

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

সারসংক্ষেপে, আজ পর্যন্ত আমরা: 

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

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

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