Roblox ক্লাউডে নেটওয়ার্ক প্যাকেট ক্ষতি ও ল্যাটেন্সি মনিটরিং

Roblox নেটওয়ার্ক ইঞ্জিনিয়ারিং দল বিশ্বজুড়ে বিস্তৃত ডেটা সেন্টার এবং পয়েন্ট অফ প্রেজেন্স (POP) সাইটসহ একটি বড়, দ্রুত বর্ধনশীল নেটওয়ার্ক পরিচালনা করে। Roblox প্ল্যাটফর্মে চমৎকার ব্যবহারকারীর অভিজ্ঞতা প্রদান এই নেটওয়ার্কের কর্মক্ষমতা এবং নির্ভরযোগ্যতার উপর নির্ভর করে। নেটওয়ার্ক অপারেটরদের জন্য নেটওয়ার্কে সমস্যা সমাধান ও সনাক্তকরণ এবং নেটওয়ার্ক কর্মক্ষমতার দৃশ্যমানতা থাকা অত্যন্ত গুরুত্বপূর্ণ। নেটওয়ার্ক মনিটরিং সাধারণত ডিভাইসের পরিসংখ্যান, ত্রুটি পরিমাপক এবং syslogs নিয়মিতভাবে সংগ্রহ করে এবং সেগুলো টাইম সিরিজ বা লগ ডাটাবেসে সংরক্ষণ করার মাধ্যমে সম্পন্ন করা হয়। ডেটা SNMP, Netconf, REST API বা Streaming Telemetry-এর মতো স্ট্যান্ডার্ড প্রোটোকল ব্যবহার করে পুশ বা পুল মডেলের মাধ্যমে সংগ্রহ করা হয়।

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

একটি নেটওয়ার্ক সক্রিয়ভাবে পর্যবেক্ষণের একটি চমৎকার উপায় হল নীচের চিত্রগুলিতে দেখানো অনুযায়ী একটি মেশ জুড়ে নিয়মিতভাবে সংশ্লেষিত প্রব (synthesized probes) প্রেরণ করা।

প্রোডাকশন আউটেজ মেরামতের সময় নেটওয়ার্ক অপারেটরদের প্রায়ই "নেটওয়ার্ক কি প্যাকেট ড্রপ করছে?" বা "কোন চলমান নেটওয়ার্ক ত্রুটি কি সার্ভিস সংযোগে প্রভাব ফেলছে?" এর মতো প্রশ্ন করা হয়। ঐতিহাসিক প্যাকেট লস এবং লেটেন্সি ডেটা ছাড়া এই ধরনের প্রশ্নের উত্তর দিতে তাদের নেটওয়ার্কের লিঙ্ক ও নোডের বিশাল সেট তদন্ত করতে হতো।

একটি নির্ভরযোগ্য এবং স্কেলযোগ্য নেটওয়ার্ক মেশ মনিটরিং সিস্টেম ডিজাইন করা

প্যাকেট লস বা লেটেন্সি স্পাইক সনাক্ত করতে একটি ব্ল্যাক বক্স নেটওয়ার্ক মনিটরিং সিস্টেমকে নেটওয়ার্কের বিভিন্ন অংশে ধারাবাহিকভাবে প্রোবিং করতে হয়। ডেটা সেন্টার নেটওয়ার্কগুলো ব্যবহারকারীর ট্রাফিকের জন্য নোডগুলোর মধ্যে থাকা সব লিঙ্কই ব্যবহার করে। প্রোডাকশন নেটওয়ার্ক ডিভাইসগুলো BGP চালায় এবং একাধিক সমান-খরচ পথের (equal-cost paths) উপর ট্রাফিক লোড-ব্যালেন্স করে। স্বাভাবিক পরিস্থিতিতে, নেটওয়ার্ক টপোলজিতে পরিবর্তন সাধারণত রাউটিং টেবিল আপডেটের মাধ্যমে কয়েক সেকেন্ডের মধ্যেই প্রতিফলিত হয়। নেটওয়ার্ক প্যাকেট লসের সঠিক পরিমাপ পেতে, টেস্ট প্রবগুলো যত বেশি সম্ভব পথে ভ্রমণ করে সমস্ত নেটওয়ার্ক নোড এবং লিঙ্ক কভার করা উচিত। আমাদের মতো একটি বিশাল নেটওয়ার্ক, যা বিশ্বজুড়ে একাধিক সাইটে বিস্তৃত, সেখানে প্রতিটি নোড বা র্যাকের জোড়ার মধ্যে প্রব করা স্কেলযোগ্য নয়। দৃশ্যমানতার স্তরে আপস না করে আমরা যে আরও টেকসই সমাধানটি বেছে নিয়েছি, তা হলো প্রতিটি সাইটের র্যাকগুলোর মধ্যে N² মেష్ এবং সমস্ত সাইটের মধ্যে আরেকটি N² মেష్ প্রব করা।

আমরা নেটওয়ার্কের সাথে কী দিয়ে প্রোব করব?

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

আমরা কোথা থেকে প্রব করি?

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

আমরা কীভাবে নেটওয়ার্ক লস এবং ল্যাটেন্সি পরিমাপ করি?

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

Roblox-এর Ping Mesh সিস্টেম

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

• আমরা আমাদের সিস্টেমের সব উপাদান বাস্তবায়নের জন্য Go ভাষা বেছে নিয়েছিলাম, যা ন্যূনতম সিস্টেম রিসোর্স ব্যবহার করে উচ্চ কর্মক্ষমতা অর্জনে সহায়তা করেছে।
• আমাদের এজেন্টগুলো অত্যন্ত স্থিতিশীল এবং বিভিন্ন ধরনের প্রোডাকশন হোস্টে চলতে পারে, যার মধ্যে রয়েছে Roblox প্ল্যাটফর্মে ট্রাফিক, ক্যাশিং এবং অ্যাপ্লিকেশন সার্ভারের মতো গুরুত্বপূর্ণ সেবা প্রদানকারী হোস্টগুলো।
• এজেন্টটিকে লিনাক্স sendmmsg() এবং recvmmsg() সিস্টেম কলগুলোর উপর Go wrapper ফাংশন ব্যবহার করে প্যাকেট I/O অপারেশনগুলো ব্যাচে করার জন্য অপ্টিমাইজ করা হয়েছে, যা কম ওভারহেডে উচ্চ হারে প্রব্‌স প্রেরণের সক্ষমতা দেয়। আমাদের ডিপ্লয়মেন্টে প্রতিটি এজেন্ট একযোগে সর্বোচ্চ ১০০টি অন্য হোস্টে প্রতি সেকেন্ডে ১০০টি প্যাকেটের (PPS) হারে প্রব্‌স প্রেরণ করে। এজেন্ট প্রতিটি গন্তব্যে প্রতি সেকেন্ডে প্যাকেট বার্স্ট প্রেরণ করে।
• প্রোবগুলো IP হেডারে বিভিন্ন ধরনের সার্ভিস (TOS) ফিল্ড মান নিয়ে প্রতিটি গন্তব্যে পাঠানো হয় এবং নেটওয়ার্কে প্যাকেট ক্ষতি ও ল্যাটেন্সির জন্য পৃথকভাবে হিসাব রাখা হয়। প্রতিটি প্যাকেট বার্স্টে প্রতিটি গন্তব্যের জন্য একাধিক TOS মানের মিশ্রণ থাকে। এটি বিভিন্ন কোয়ালিটি-অফ-সার্ভিস (QoS) শ্রেণির নেটওয়ার্ক কর্মক্ষমতা পর্যবেক্ষণে সহায়তা করে।
• এজেন্ট প্রতিটি প্রোব পথে প্রতি মিনিটে ৬০০০ প্যাকেটের মধ্যে মাত্র ১টি প্যাকেট ড্রপ পর্যন্ত সনাক্ত করতে পারে। নেটওয়ার্কের কোর বা এজে ১ সেকেন্ডেরও কম সময়ের প্যাকেট ক্ষতি, যেমন BGP ফ্ল্যাপের সময়, সনাক্ত করা যায়।
• যখন ত্রুটিগুলো ড্রপের কারণ হয়, তখন প্রোব প্যাকেট ড্রপ চার্টগুলো নেটওয়ার্ক ডিভাইস ইন্টারফেসের ত্রুটি হারের চার্টের মতোই দেখায়। আমরা নেটওয়ার্কে এমন ট্র্যাফিক ব্ল্যাক-হোলিং বাগ খুঁজে বের করতে পেরেছি যা সনাক্ত করা কঠিন।
• এজেন্টগুলো নেটওয়ার্ক লেটেন্সি পরিমাপে উচ্চ নির্ভুলতা অর্জনের জন্য NIC কার্নেল রিড টাইমস্ট্যাম্প ব্যবহার করে। হোস্ট OS-এর শিডিউলিং লেটেন্সি এবং নেটওয়ার্ক ক্লক ড্রিফট বাদ দিয়ে 50–100 মাইক্রোসেকেন্ডের একটি স্থিতিশীল রাউন্ড ট্রিপ ইনট্রা-সাইট লেটেন্সি পরিমাপ করা যায়।
• কম CPU ব্যবহার এবং মেমরি ফুটপ্রিন্ট। এজেন্ট সর্বোচ্চ প্রেরণ ও গ্রহণ হারে (প্রতিটি 5 kpps) একক কোরের 25%-এরও কম ব্যবহার করে। মোতায়েনকৃত অধিকাংশ এজেন্ট একটি কোরের প্রায় 5% ব্যবহার করে। এজেন্টের Tx ও Rx প্যাকெட் বাফার এবং কাউন্টার পরিচালনার জন্য মাত্র 10MB হিপ মেমরি প্রয়োজন। যখন নেটওয়ার্ক বৃদ্ধি পায়, আমরা সীমা সামঞ্জস্য করে বা অতিরিক্ত এজেন্ট যোগ করে উলম্ব বা অনুভূমিকভাবে স্কেল করতে পারি।
• হোস্ট সিস্টেম চাপের মধ্যে থাকলেও এজেন্ট খুব কমই প্রভাবিত হয়। আমরা এমন ফলাফলও পেয়েছি যেখানে হোস্ট CPU লোড একাধিকবার 99% এর কাছাকাছি পৌঁছলেও সঠিক ফলাফল এসেছে।
• প্রত্যেক এজেন্টের স্বাস্থ্যের পর্যবেক্ষণের জন্য টেলিমিট্রি সংগ্রহ করা হয়। এজেন্টগুলো সমস্যাযুক্ত পরিস্থিতি যেমন হোস্ট সিস্টেম রিবুট হলে, এজেন্ট প্রক্রিয়া পুনরায় চালু হলে, অথবা সকেট বাফার ওভারফ্লোয়ের কারণে প্যাকেট ড্রপ হলে সনাক্ত করতে পারে।

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

আমরা প্রথম মোতায়েনে ১৫০টি এজেন্ট নিয়ে শুরু করেছিলাম, এবং এখন সফলভাবে ১০ গুণ বৃদ্ধি করেছি। এই মেশ আমাদের ব্যাকবোন আচ্ছাদন করে, যা বিশ্বজুড়ে ছড়িয়ে থাকা ২৫টি সাইটকে সংযুক্ত করে। আমাদের একটি প্রধান ডেটা সেন্টার সাইটে ইনট্রা-সাইট মেশ রয়েছে যা ২০০+ র‌্যাক জুড়ে বিস্তৃত এবং প্রায় ৩৩,০০০টি স্ট্রিম একত্রিত হয়ে ১.৬৫ মিলিয়ন pps প্রোব রেটে পৌঁছায়। প্রতিটি র‌্যাক অন্যান্য র‌্যাক থেকে ৫–১০ kpps প্রোব গ্রহণ করে। শিডিউলার অ্যাপ্লিকেশনটি হিসাব করে এবং বিভিন্ন সাইটে থাকা আমাদের সকল এজেন্টের মধ্যে ৩৫,০০০-এরও বেশি টার্গেট সমানভাবে বিতরণ করে।

ডেটা সংগ্রহ এবং ভিজ্যুয়ালাইজেশন

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

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

সারসংক্ষেপ এবং পরবর্তী পদক্ষেপ

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

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

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