Cloudflare এত বড় পরিসরে কাজ করে যে এখানে বছরের পর বছর কাজ করার পরেও এটি বাস্তব মনে হয় না। বিশ্বজুড়ে আমাদের হাজার হাজার সার্ভার রয়েছে যাতে পেটাবাইট RAM এবং লক্ষ লক্ষ CPU কোর আছে, এবং সবকিছুই সর্বোচ্চ সীমা পর্যন্ত ব্যবহৃত হয়। এই সম্পদগুলি যত বিশালই মনে হোক, এগুলি তবুও সীমিত, এবং যখন আপনার প্রতিটি নোডে প্রতিটি পরিষেবা চালানোর প্রয়োজন হয়, তখন অপচয়ের জায়গা থাকে না। এই পরিসরে, ছোট উন্নতিগুলি ব্যাপকভাবে বেড়ে যায়, তাই একবারে ১% উন্নতিও উদযাপনের যোগ্য। এবং কিছু পরিবর্তন মিলে অনেক বেশি হয়: এই পোস্টে, আমরা দেখব কীভাবে একটি মাত্র অ্যালগরিদমে ছোট পরিবর্তনগুলি আমাদের Pingora-ভিত্তিক পরিষেবাগুলির একটির মেমরি ব্যবহার উল্লেখযোগ্যভাবে কমিয়েছে। এটি আমাদের বিশ্বব্যাপী 100TB-এর বেশি RAM পুনরুদ্ধার করতে সাহায্য করেছে, এর উপরে DNS দল গত মাসে 100TB মেমরি মুক্ত করতে সক্ষম হয়েছিল।

অপচয় করবেন না দলগুলির মধ্যে ন্যায্য সম্পদ ভাগাভাগি বজায় রাখা সহজ নয়, বিশেষ করে বড় প্রতিষ্ঠানে। Cloudflare ভারসাম্য বজায় রাখার একটি উপায় হল অসাধারণ Performance দলের অক্লান্ত প্রচেষ্টার মাধ্যমে। এই গল্পটি শুরু হয় Ivan দ্বারা দাখিল করা একটি টিকিট দিয়ে, যিনি খুঁজে পেয়েছিলেন: Pingora Backend Router-এ pingora-ketama থেকে অতিরিক্ত মেমরি ব্যবহার। অনুসন্ধানে পাওয়া গেল যে আমাদের অভ্যন্তরীণ লোড-ব্যালান্সিং পরিষেবা, Pingora Backend Router (হ্যাঁ, PBR), প্রত্যাশার চেয়ে অনেক বেশি মেমরি ব্যবহার করছিল — বিশেষত pingora-ketama-এর সাথে যুক্ত কাঠামোতে, যা কনসিস্টেন্ট হ্যাশিং পরিচালনার জন্য আমাদের ওপেন-সোর্স লাইব্রেরি। মেমরির এই আপাত অতিরিক্ত ব্যবহার আমরা কীভাবে সমাধান করেছি তা নিয়ে কথা বলতে হলে, আমাদের বলতে হবে কনসিস্টেন্ট হ্যাশিং আসলে কী, কেন আমরা এটি PBR-এ ব্যবহার করছি, এবং এটি কীভাবে এত মেমরি-ক্ষুধার্ত হয়ে উঠল। পথে, আমরা কিছু Rust শিখব এবং একটু গণিতও।

কনসিস্টেন্ট হ্যাশিং কনসিস্টেন্ট হ্যাশিং হল একাধিক সার্ভারে কাজ বিতরণের একটি বহুল ব্যবহৃত পদ্ধতি, যাতে সার্ভার যোগ বা অপসারণের সময় বড় পরিবর্তনের প্রয়োজন হয় না। অভ্যন্তরীণভাবে আমরা এটি URL অনুযায়ী ক্যাশযোগ্য অনুরোধগুলি সার্ভারে রাউট করতে ব্যবহার করি। এটি আমাদের প্রতিটি ডেটা সেন্টারে একটি ফাইলের শুধুমাত্র একটি অনুলিপি সংরক্ষণ করতে দেয় এবং প্রতিটি ফাইলের অবস্থান খুঁজে পাওয়ার একটি স্থিতিশীল উপায় দেয়। আমরা আগেও এই সিস্টেমের কথা উল্লেখ করেছি, তবে আসুন সময় নিয়ে বুঝি এই অ্যালগরিদম কীভাবে এবং কেন ব্যবহৃত হয় এবং এটি কীভাবে কাজ করে। কনসিস্টেন্ট হ্যাশিংয়ের মূল ধারণা হল যে হ্যাশ ফাংশন যেকোনো ধরনের ইনপুট গ্রহণ করতে পারলেও, তাদের আউটপুট একটি মাত্র আনসাইনড ইন্টিজারে সীমাবদ্ধ (কোন হ্যাশ ফাংশন তার উপর নির্ভর করে 32, 64, বা 128-বিট ইন্টিজার)। এটি আমাদের কাজ এবং সার্ভারগুলিকে একটি সামঞ্জস্যপূর্ণ উপায়ে একে অপরের সাথে সম্পর্কিত করতে দেয়। কনসিস্টেন্ট হ্যাশিংয়ের বেশিরভাগ আলোচনা আপনাকে সেই আউটপুট স্পেসটিকে একটি অবিচ্ছিন্ন, বৃত্তাকার রিং হিসাবে ভাবতে বলে যা তার সর্বোচ্চ মান থেকে শূন্যে গড়িয়ে যায়। এই চিত্রণ কিছু সুন্দর ভিজ্যুয়ালাইজেশন তৈরি করে, তবে এটি ইন্টিজার রেঞ্জের সরল ধারণাটিকে প্রয়োজনের চেয়ে বেশি জটিলও করে তুলতে পারে। আমাদের আলোচনার জন্য, আমরা আমাদের হ্যাশ ফাংশনের 32-বিট আউটপুটকে একটি সংখ্যা রেখা হিসাবে উপস্থাপন করব। এখন, ধরা যাক আমাদের কাছে সার্ভার A, B, এবং C-এর একটি সেট আছে, এবং t-z কাজের একটি সেট আছে। আমরা প্রত্যেকটিকে তাদের প্রতিনিধি মানের হ্যাশের উপর ভিত্তি করে সংখ্যা রেখায় ম্যাপ করতে পারি, যেমন সার্ভারের জন্য IP ঠিকানা এবং কাজের জন্য ক্যাশ কী। কাজগুলিকে সার্ভারে বরাদ্দ করা এখন প্রতিটি কাজের বাম দিকের প্রথম সার্ভার খুঁজে পাওয়ার বিষয় মাত্র। আমরা প্রতিটি সার্ভারের সাথে যুক্ত হ্যাশের অঞ্চল রঙ করে এটি দৃশ্যত উপস্থাপন করতে পারি। লক্ষ্য করুন যে সার্ভার C দ্বারা আচ্ছাদিত পরিসর শুরুতে গড়িয়ে যায়, তাই হ্যাশগুলি একটি রিংয়ে বিদ্যমান এই ধারণা। এবং এটাই। মৌলিক স্তরে, কনসিস্টেন্ট হ্যাশিং এতটাই সহজ — কিন্তু উন্নতির জায়গা আছে তা দেখতে বেশি সময় লাগে না। লক্ষ্য করুন যে আমাদের উদাহরণে সার্ভার A দ্বারা আচ্ছাদিত পরিসর B বা C-এর তুলনায় উল্লেখযোগ্যভাবে বড়। এটি একটি সমস্যা কারণ একটি সার্ভার যে অনুপাতের অনুরোধ পরিচালনা করে তা সংখ্যা রেখায় তার পরিসরের আকারের সমানুপাতিক হবে। আদর্শভাবে আমরা প্রতিটি সার্ভারের সমান আকারের নিশ্চয়তা দিতে চাই, কিন্তু যেহেতু হ্যাশ মূলত এলোমেলো সংখ্যা, আমাদের করতে হবে...