یکی از مهم‌ترین بخش‌های طراحی سیستم که خیلی وقت‌ها نادیده گرفته می‌شه، اتفاقاً ساده‌ترین بخششه: اینکه با چند حساب‌و‌کتاب سرانگشتی بفهمی سیستم قراره چقدر بار بکشه. به این می‌گن «Back-of-the-envelope estimation» یا به زبان ساده‌تر، «برآورد سرانگشتی».

چطور بفهمیم طراحی‌مون واقعاً جواب می‌ده؟

این‌که سیستم قراره چقدر درخواست دریافت کنه، چه میزان دیتا تولید بشه، چقدر حافظه یا پهنای باند نیاز داره، یا حتی چقدر هزینه برات داره، همه اینا رو می‌شه قبل از شروع توسعه، فقط با چند فرض منطقی و یه ضرب و تقسیم ساده، تخمین زد. عجیب نیست که بیشتر مهندسای باتجربه قبل از شروع هر پروژه‌ای، اول این تخمین‌ها رو توی ذهن‌شون می‌زنن. چون کمک می‌کنه بفهمن آیا اصلاً طراحی‌ که توی ذهنشون دارن، شدنی هست یا نه.

بیایم با یه مثال خیلی ساده شروع کنیم. فرض کن داری یه اپ می‌سازی برای ده میلیون کاربر. حالا سوال اینه که این سیستم قراره چند درخواست در ثانیه رو جواب بده؟ اگر هر کاربر در روز فقط ده بار به سیستم درخواست بفرسته، یعنی روزانه ۱۰۰ میلیون درخواست. وقتی این عدد رو تقسیم بر تعداد ثانیه‌های یه روز کنی، میرسی به یه چیزی حدود ۱۱۵۰ درخواست در ثانیه. اما همه چیز همیشه این‌قدر صاف و یکنواخت نیست. در واقع ترافیک توی زمان‌هایی از روز به اوج می‌رسه، مثلاً شب‌ها یا در زمان رویدادهای خاص. پس برای طراحی واقع‌گرایانه، باید برای چند برابر این مقدار آماده باشی، مثلاً ۵۰۰۰ تا ۶۰۰۰ درخواست در ثانیه.

حالا بیا یه سناریوی دیگه رو بررسی کنیم. فرض کن همون کاربران قراره عکس آپلود کنن. اگه هر عکس دو مگابایت باشه و هر کاربر ماهی پنج عکس آپلود کنه، تو فقط برای ذخیره‌سازی این عکس‌ها ماهی حدود ده ترابایت فضا نیاز داری. این تازه بدون احتساب بکاپ‌ها، لاگ‌ها یا فضای کشه. اینجاست که خیلی‌ها تازه متوجه می‌شن انتخاب یه دیتابیس ساده یا یه سرور کوچیک جواب نمی‌ده.

مهم‌تر از خود عددها، نوع نگاه پشت این تخمین‌هاست. وقتی بتونی این محاسبه‌ها رو سریع و تو ذهن انجام بدی، یه درک عمیق‌تر از ابعاد سیستم به‌دست میاری. می‌فهمی که آیا باید سراغ کش بری، آیا نیاز به دیتابیس توزیع‌شده داری، یا حتی اینکه بهتره از اول روی چه زیرساختی بسازی.

جذاب‌تر اینه که منابعی مثل کتاب System Design Interview از آقای Alex Xu این سبک فکر کردن رو یکی از اصلی‌ترین بخش‌های طراحی سیستم می‌دونن. اون‌ها می‌گن بدون این تخمین‌ها، هر چقدر هم طراحیت شیک باشه، در نهایت با واقعیت سخت مقیاس‌پذیری برخورد می‌کنی. نکته‌ش اینه که لازم نیست عدد دقیق به‌دست بیاری، فقط باید بدونی در چه ابعادی صحبت می‌کنی، آیا با گیگابایت طرفی یا ترابایت؟ آیا سیستمت ۱۰۰ درخواست در ثانیه رو جواب می‌ده یا ۱۰ هزار تا؟

یه نکته‌ی مهم اینه که بیشتر مهندس‌ها روی میانگین‌ها تمرکز می‌کنن، ولی سیستم‌ها معمولاً توی «پیک» می‌ترکن، نه میانگین. اگر فقط با میانگین طراحی کنی، احتمالاً توی اولین کمپین یا شب عید کارت تمومه.

در نهایت، مهارت back-of-the-envelope estimation چیزی نیست که با خوندن فقط یاد بگیری. باید تمرینش کنی. باید هر وقت یه ایده به ذهنت رسید، اول قبل از کد زدن، چند تا حساب سرانگشتی بزنی. ببینی واقعاً چه فشارهایی قراره روی سیستم وارد بشه، چه منابعی نیاز داری و آیا راهی برای سبک‌تر کردنش هست یا نه.

اگه این نگاه رو در خودت تقویت کنی، هم مهندس بهتری می‌شی، هم سیستم‌هایی می‌سازی که نه‌تنها اجرا می‌شن، بلکه در مقیاس بزرگ هم دوام میارن.

back-of-the-envelope estimation برای Twitter

فرض کن قراره یه کلون از توییتر بسازی. تمرکزت روی قابلیت tweet زدن و خوندن timeline کاربرهاست.

سناریو

می‌خوای برای 100 میلیون کاربر فعال، سیستم طراحی کنی. حالا سوال اینه: قراره روزانه چند تا توییت ایجاد بشه و چند تا خوندن اتفاق بیفته؟

فرض‌ها

  • هر کاربر به‌طور میانگین روزی 5 توییت می‌فرسته
  • هر توییت حدود 280 کاراکتره، یعنی تقریباً 0.5 KB
  • هر کاربر روزی 100 توییت می‌خونه
  • سیستم 24 ساعته در حال فعالیته، یعنی 86,400 ثانیه در روز

برآورد تولید (write)

100M × 5 = 500M توییت در روز
500M × 0.5KB = 250GB دیتای جدید روزانه

برآورد خواندن (read)

100M × 100 = 10B توییت خوانده‌شده در روز
10B × 0.5KB = 5TB دیتای خوانده‌شده در روز

RPS (تعداد درخواست‌ها در ثانیه)

500M writes/day = ~5800 writes/sec
10B reads/day = ~115,000 reads/sec

یعنی در مقیاس بزرگ، باید سیستمی داشته باشی که در هر ثانیه:

  • بیش از 100 هزار درخواست خواندن
  • و نزدیک به 6000 درخواست نوشتن رو هندل کنه

این مثال‌ها فقط یک هدف دارن: بهت نشون بدن قبل از انتخاب دیتابیس یا معماری، باید بدونی دقیقاً با چه ابعادی طرفی. وقتی بتونی این‌طوری فکر کنی، تصمیم‌هات واقعی‌تر و سیستم‌هات پایدارتر میشن.

دسته بندی شده در: