ধাপ ৩ - ডিজাইনের গভীর বিশ্লেষণ (Design deep dive)

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

ফিড পাবলিশিং গভীর বিশ্লেষণ (Feed publishing deep dive)

চিত্র ৪ ফিড পাবলিশিংয়ের বিস্তারিত ডিজাইন রূপরেখা দেয়। আমরা উচ্চ-স্তরের ডিজাইনের বেশিরভাগ উপাদান নিয়ে আলোচনা করেছি, এবং আমরা দুটি উপাদানের ওপর ফোকাস করব: ওয়েব সার্ভার এবং ফ্যানআউট সার্ভিস।

চিত্র ৪ (Figure 4) — ফিড পাবলিশিং ডিপ ডাইভ: ফ্যানআউট সার্ভিসের সম্পূর্ণ ফ্লো। ①গ্রাফ DB থেকে বন্ধুদের ID, ②User Cache থেকে ডেটা, ③মেসেজ কিউ, ④Fanout Workers, ⑤News Feed Cache।

ওয়েব সার্ভার (Web servers)

ক্লায়েন্টদের সাথে যোগাযোগ করার পাশাপাশি, ওয়েব সার্ভারগুলো প্রমাণীকরণ (authentication) এবং রেট-লিমিটিং (rate-limiting) কার্যকর করে। শুধুমাত্র বৈধ auth_token দিয়ে সাইন ইন করা ব্যবহারকারীদেরই পোস্ট করার অনুমতি দেওয়া হয়। সিস্টেমটি একটি নির্দিষ্ট সময়ে একজন ব্যবহারকারী কতগুলো পোস্ট করতে পারেন তার সংখ্যা সীমিত করে, যা স্প্যাম এবং অপব্যবহারমূলক কন্টেন্ট প্রতিরোধ করতে অত্যন্ত গুরুত্বপূর্ণ।

ফ্যানআউট সার্ভিস (Fanout service)

ফ্যানআউট হলো সমস্ত বন্ধুদের কাছে একটি পোস্ট পৌঁছে দেওয়ার প্রক্রিয়া। দুই ধরনের ফ্যানআউট মডেল আছে: রাইট-এ ফ্যানআউট (fanout on write, যাকে পুশ মডেলও বলা হয়) এবং রিড-এ ফ্যানআউট (fanout on read, যাকে পুল মডেলও বলা হয়)। উভয় মডেলেরই সুবিধা এবং অসুবিধা রয়েছে। আমরা তাদের ওয়ার্কফ্লো ব্যাখ্যা করব এবং আমাদের সিস্টেম সমর্থন করার জন্য সেরা পদ্ধতিটি অন্বেষণ করব।

রাইট-এ ফ্যানআউট (Fanout on write): এই পদ্ধতির সাথে, রাইট করার সময়ই নিউজ ফিড প্রি-কম্পিউট (pre-compute) করা হয়। একটি নতুন পোস্ট পাবলিশ হওয়ার সাথে সাথেই বন্ধুদের ক্যাশে তা পৌঁছে দেওয়া হয়।

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

রিড-এ ফ্যানআউট (Fanout on read): রিড করার সময় নিউজ ফিড তৈরি করা হয়। এটি একটি অন-ডিমান্ড (on-demand) মডেল। একজন ব্যবহারকারী যখন তার হোম পেজ লোড করে তখন সাম্প্রতিক পোস্টগুলো পুল (pull) করা হয়।

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

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

আসুন চিত্র ৫-এ দেখানো ফ্যানআউট সার্ভিসের দিকে একটু গভীরভাবে তাকাই।

চিত্র ৫ — উপরের ফ্লো চার্টটিতেই ফ্যানআউট ওয়ার্কফ্লো (①–⑤) দেখানো হয়েছে।

ফ্যানআউট সার্ভিস নিম্নরূপে কাজ করে: ১. গ্রাফ ডাটাবেস থেকে বন্ধুদের আইডি (friend IDs) নিয়ে আসা হয়। গ্রাফ ডাটাবেসগুলো বন্ধুত্বের সম্পর্ক এবং বন্ধু সুপারিশ পরিচালনার জন্য উপযুক্ত। এই ধারণা সম্পর্কে আরও জানতে আগ্রহী পাঠকরা রেফারেন্স ম্যাটেরিয়াল [2] দেখতে পারেন। ২. ইউজার ক্যাশ থেকে বন্ধুদের তথ্য নেওয়া হয়। সিস্টেমটি তখন ব্যবহারকারীর সেটিংসের ওপর ভিত্তি করে বন্ধুদের ফিল্টার করে। উদাহরণস্বরূপ, যদি আপনি কাউকে মিউট (mute) করেন, তবে আপনি তার বন্ধু হওয়া সত্ত্বেও তার পোস্টগুলো আপনার নিউজ ফিডে দেখাবে না। পোস্ট না দেখার আরেকটি কারণ হলো একজন ব্যবহারকারী নির্বাচিতভাবে নির্দিষ্ট বন্ধুদের সাথে তথ্য শেয়ার করতে পারেন বা অন্যদের কাছ থেকে তা লুকিয়ে রাখতে পারেন। ৩. বন্ধুদের তালিকা এবং নতুন পোস্ট আইডি মেসেজ কিউ-তে (message queue) পাঠানো হয়। ৪. ফ্যানআউট ওয়ার্কাররা (fanout workers) মেসেজ কিউ থেকে ডেটা নিয়ে আসে এবং নিউজ ফিড ক্যাশে নিউজ ফিড ডেটা সংরক্ষণ করে। আপনি নিউজ ফিড ক্যাশকে একটি <post_id, user_id> ম্যাপিং টেবিল হিসাবে ভাবতে পারেন। যখনই একটি নতুন পোস্ট করা হয়, এটি চিত্র ৬-এ দেখানো হিসাবে নিউজ ফিড টেবিলে যুক্ত করা হবে। যদি আমরা সম্পূর্ণ ইউজার এবং পোস্ট অবজেক্ট ক্যাশে সংরক্ষণ করি তবে মেমরি খরচ অনেক বেড়ে যেতে পারে। তাই, শুধুমাত্র আইডিগুলো সংরক্ষণ করা হয়। মেমরির আকার ছোট রাখতে, আমরা একটি কনফিগারযোগ্য সীমা (configurable limit) নির্ধারণ করি। নিউজ ফিডে হাজার হাজার পোস্ট স্ক্রল করার সম্ভাবনা একজন ব্যবহারকারীর জন্য খুবই কম। বেশিরভাগ ব্যবহারকারী কেবল সাম্প্রতিক কন্টেন্টে আগ্রহী হন, তাই ক্যাশ মিসের (cache miss) হার কম থাকে। ৫. নিউজ ফিড ক্যাশে <post_id, user_id> সংরক্ষণ করা হয়। চিত্র ৬ ক্যাশে নিউজ ফিডটি কেমন দেখায় তার একটি উদাহরণ দেখায়।

চিত্র ৬

নিউজফিড রিট্রিভাল গভীর বিশ্লেষণ (Newsfeed retrieval deep dive)

চিত্র ৭ নিউজ ফিড পুনরুদ্ধারের বিস্তারিত ডিজাইন চিত্রিত করে।

চিত্র ৭ (Figure 7) — সম্পূর্ণ নিউজ ফিড সিস্টেম: CDN, LB, Web Servers, News Feed Service, Feed Cache, User Cache, User DB, Post Cache, Post DB।

চিত্র ৭-এ দেখানো হয়েছে, মিডিয়া কন্টেন্ট (ছবি, ভিডিও ইত্যাদি) দ্রুত পুনরুদ্ধারের জন্য সিডিএন (CDN)-এ সংরক্ষণ করা হয়। আসুন দেখি কীভাবে একজন ক্লায়েন্ট নিউজ ফিড পুনরুদ্ধার করে। ১. একজন ব্যবহারকারী তার নিউজ ফিড পুনরুদ্ধার করার জন্য একটি রিকোয়েস্ট পাঠায়। রিকোয়েস্টটি এমন দেখায়: /v1/me/feed ২. লোড ব্যালেন্সার রিকোয়েস্টগুলো ওয়েব সার্ভারগুলোতে পুনরায় বিতরণ করে। ৩. ওয়েব সার্ভারগুলো নিউজ ফিড আনতে নিউজ ফিড সার্ভিসকে কল করে। ৪. নিউজ ফিড সার্ভিস নিউজ ফিড ক্যাশ থেকে পোস্ট আইডিগুলোর একটি তালিকা পায়। ৫. একজন ব্যবহারকারীর নিউজ ফিড শুধুমাত্র ফিড আইডিগুলোর একটি তালিকা নয়। এতে ইউজারনেম, প্রোফাইল ছবি, পোস্টের কন্টেন্ট, পোস্টের ছবি ইত্যাদি থাকে। তাই, নিউজ ফিড সার্ভিস সম্পূর্ণরূপে হাইড্রেটেড (fully hydrated) নিউজ ফিড তৈরি করতে ক্যাশ (ইউজার ক্যাশ এবং পোস্ট ক্যাশ) থেকে সম্পূর্ণ ইউজার এবং পোস্ট অবজেক্ট নিয়ে আসে। ৬. সম্পূর্ণরূপে হাইড্রেটেড নিউজ ফিডটি রেন্ডার করার জন্য ক্লায়েন্টে JSON ফরম্যাটে ফেরত পাঠানো হয়।

ক্যাশ আর্কিটেকচার (Cache architecture)

একটি নিউজ ফিড সিস্টেমের জন্য ক্যাশ অত্যন্ত গুরুত্বপূর্ণ। আমরা চিত্র ৮-এ দেখানো হিসাবে ক্যাশ টিয়ারকে ৫টি স্তরে ভাগ করি।

[চিত্র ৮-এর বর্ণনা: ছবিটি একটি নিউজ ফিডের জন্য একটি সিস্টেম ডিজাইন উপস্থাপন করে, যা পাঁচটি সারি এবং তিনটি কলাম সহ একটি টেবিল হিসাবে গঠিত। প্রথম কলামটি সারিগুলোকে লেবেল করে: ‘নিউজ ফিড’, ‘কন্টেন্ট’, ‘সোশ্যাল গ্রাফ’, ‘অ্যাকশন’, এবং ‘কাউন্টার’। বাকি দুটি কলাম ডেটা ক্যাটেগরি নির্দেশ করে। ‘নিউজ ফিড’ সারিতে ‘news feed’ লেবেলযুক্ত একটি একক বাক্স রয়েছে। ‘কন্টেন্ট’ সারিতে ‘hot cache’ এবং ‘normal’ লেবেলযুক্ত বাক্স রয়েছে, যা কন্টেন্টের জন্য বিভিন্ন ক্যাশিং কৌশল নির্দেশ করে। ‘সোশ্যাল গ্রাফ’ সারিতে ‘follower’ এবং ‘following’ লেবেলযুক্ত বাক্স দেখায়, যা ব্যবহারকারীদের মধ্যে সম্পর্ক নির্দেশ করে। ‘অ্যাকশন’ সারিতে ‘liked’, ‘replied’, এবং ‘others’-এর জন্য বাক্স প্রদর্শন করে, যা বিভিন্ন ব্যবহারকারীর মিথস্ক্রিয়া নির্দেশ করে। পরিশেষে, ‘কাউন্টার’ সারিতে প্রতিটি অ্যাকশনের জন্য সংশ্লিষ্ট কাউন্টার দেখায়: ‘like counter’, ‘reply counter’, এবং ‘other counters’। ড্যাশ করা রেখাগুলো সিস্টেমের মধ্যে সম্পর্কিত ডেটার লজিক্যাল গ্রুপিং নির্দেশ করে। বাক্সগুলোর মধ্যে কোনো স্পষ্ট সংযোগ বা ডেটা ফ্লো দেখানো হয়নি, তবে বিন্যাসটি প্রতিটি সারির ডেটার মধ্যে একটি সম্পর্ক বোঝায়, যা বোঝায় যে সিস্টেমটি নিউজ ফিড কন্টেন্ট, ব্যবহারকারীর সম্পর্ক, ব্যবহারকারীর অ্যাকশন এবং সম্পর্কিত কাউন্ট ট্র্যাক করে।] চিত্র ৮

• নিউজ ফিড (News Feed): এটি নিউজ ফিডের আইডিগুলো সংরক্ষণ করে।
• কন্টেন্ট (Content): এটি প্রতিটি পোস্টের ডেটা সংরক্ষণ করে। জনপ্রিয় কন্টেন্ট হট ক্যাশে (hot cache) সংরক্ষণ করা হয়।
• সোশ্যাল গ্রাফ (Social Graph): এটি ব্যবহারকারীর সম্পর্কের ডেটা সংরক্ষণ করে।
• অ্যাকশন (Action): এটি একজন ব্যবহারকারী কোনো পোস্টে লাইক করেছেন, রিপ্লাই দিয়েছেন, নাকি পোস্টে অন্য কোনো অ্যাকশন নিয়েছেন সে সম্পর্কিত তথ্য সংরক্ষণ করে।
• কাউন্টার (Counters): এটি লাইক, রিপ্লাই, ফলোয়ার, ফলোয়িং ইত্যাদির কাউন্টার সংরক্ষণ করে।