طراحی اپلیکیشن های Large Scale | تکنیک های تخصصی

تصور کن اپلیکیشنی ساخته ای که امروز ۵۰ هزار کاربر دارد و همه چیز خوب پیش می رود؛ سرعت قابل قبول است، لاگ های خطا تمیزند و زیرساخت بدون فشار کار می کند. اما فردا یک کمپین بازاریابی، یک همکاری جدید یا یک ترند ناگهانی باعث می شود همان ۵۰ هزار کاربر در عرض چند روز به ۵ میلیون نفر برسند. حالا داستان عوض می شود. هر درخواست به جای پاسخ در میلی ثانیه، چند ثانیه معطل می ماند، دیتابیس صف می زند، سرورها داغ می کنند، لاگ ها پر از ۵۰۰ و Timeout می شوند و اولین موج ریزش کاربر شروع می شود. دقیقا همین لحظه است که سرچ می کنی: Fundamentals of Designing Large Scale Applications. چون می خواهی مطمئن شوی این بار نه فقط اپلیکیشن بسازی، بلکه سیستمی طراحی کنی که حتی وقتی رشد مثل سونامی وارد شد، همچنان پاسخ گو، سریع، مقاوم و بدون Downtime باقی بماند. این جستجو برای کسی است که می خواهد بفهمد چطور قبل از وقوع بحران، معماری درست، شاردینگ دیتابیس، Load Balancing، کشینگ هوشمند و High Availability را مثل ستون های یک ساختمان بلندمرتبه، از همان ابتدا درست قرار دهد تا زیر فشار مقیاس، فرو نریزد.

ساده ترین شکل معماری یک اپلیکیشن

قبل از ورود به جزئیات، بیایید ساده ترین شکل معماری یک اپلیکیشن امروزی را بررسی کنیم. یک توسعه دهنده، اپلیکیشنی را ساخته و آن را روی یک سرور مستقر (deploy) می کند. این اپلیکیشن برای خواندن و نوشتن داده با یک سیستم ذخیره سازی در ارتباط است. همچنین، برای تشخیص مشکلات، به یک سیستم ثبت وقایع (Logging) نیاز دارد. سرور باید برای نظارت بر معیارهای سیستمی با یک سرویس متریک (Metrics) در ارتباط باشد و یک سرویس هشدار (Alerting) نیز لازم است تا بر اساس مقادیر آستانه (Threshold) این متریک ها، هشدار تولید کند.

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

1. مقیاس پذیری عمودی (Vertical Scaling): افزایش منابعی مانند RAM و CPU در همان سرور.
2. مقیاس پذیری افقی (Horizontal Scaling): افزایش تعداد سرورها برای توزیع درخواست ها.

 برای توزیع متعادل ترافیک بین سرورها، از یک متعادل کننده بار (Load Balancer) استفاده می کنیم. این خلاصه ای کلی از توپولوژی یک اپلیکیشن است.

ارکان یک طراحی خوب

هنگام طراحی اپلیکیشن، باید سه موضوع اساسی را در نظر بگیرید: داده چگونه منتقل می شود، چگونه ذخیره می شود و چگونه پردازش می شود. وقتی این سه نیاز اساسی را در سطح بهینه برآورده کنید، یک سیستم خوب طراحی کرده اید. اما طراحی خوب چیست؟ یک طراحی خوب ترکیبی از در دسترس بودن (Availability)، قابلیت اطمینان (Reliability)، توان عملیاتی (Throughput) و تأخیر کم (Low Latency) است.

   تأخیر (Latency) به مدت زمانی که طول می کشد تا یک عملیات کامل شود، گفته می شود. فاصله جغرافیایی کاربر تا سرور و عدم استفاده از کش (Cache) از عوامل اصلی افزایش تأخیر هستند.

 مفاهیم پایه شبکه

 شبکه های کامپیوتری از پروتکل های مختلفی برای انتقال داده استفاده می کنند. IP، TCP و UDP پایه های این پروتکل ها را تشکیل می دهند.

•  IP (Internet Protocol): پروتکل بنیادی برای شناسایی دستگاه ها در شبکه و مسیریابی داده بین آن ها است. هر دستگاه یک آدرس IP منحصربه فرد دارد.
•   TCP (Transmission Control Protocol): یک پروتکل اتصال گرا (Connection-Oriented) است که انتقال مطمئن، کامل و به ترتیب بسته های داده را تضمین می کند. برای کاربردهایی مانند وب (HTTP/HTTPS) و ایمیل (SMTP) ایده آل است. 
•  UDP (User Datagram Protocol): یک پروتکل بدون اتصال (Connectionless) و سریع تر است. UDP صحت و ترتیب بسته ها را بررسی نمی کند و برای انتقال هایی که سرعت در آن ها حیاتی است (مانند پخش زنده ویدئو، بازی های آنلاین و DNS) مناسب است.
•    پورت (Port): یک شماره منطقی برای شناسایی اپلیکیشن ها یا سرویس های خاص روی یک دستگاه است. برای مثال، HTTP معمولاً از پورت 80 و HTTPS از پورت 443 استفاده می کند.

 پروتکل های اپلیکیشن

  تکنیک های تخصصی برای بهبود عملکرد

 ۱. کَشینگ (Caching)

کشینگ یک تکنیک حیاتی برای دسترسی سریع به داده و بهبود عملکرد سیستم است. با این حال، منابع ما نامحدود نیستند و به یک سیاست خروج (Eviction Policy) نیاز داریم:

 LRU (Least Recently Used)

داده ای که برای طولانی ترین زمان استفاده نشده، از کش حذف می شود. برای مثال در طراحی سایت اختصاصی یا اپلیکیشنی مانند توییتر، توییت های قدیمی که دیگر دیده نمی شوند، با این روش حذف می شوند که بسیار کارآمد است.

 LFU (Least Frequently Used)

داده ای که کمترین تعداد دفعات به آن دسترسی داشته ایم، حذف می شود.

 ۲. شبکه توزیع محتوا (CDN - Content Delivery Network)

CDN برای تحویل سریع تر محتوای ثابت (Static) مانند تصاویر و ویدئوها به کاربران استفاده می شود. CDN این محتوا را روی سرورهای مختلف در سراسر جهان کش کرده و آن را از نزدیک ترین سرور به کاربر تحویل می دهد.

 ۳. پروکسی (Proxy)

پروکسی یک سرور واسطه است که ارتباط بین کلاینت ها و سرورها را مدیریت می کند.

•   Forward Proxy: هویت کلاینت را از سرور پنهان می کند (مانند VPN).
•   Reverse Proxy: هویت سرور را از کلاینت پنهان می کند (مانند CDN و Load Balancer).

 ۴. متعادل کننده بار (Load Balancer)

یک Reverse Proxy است که درخواست های ورودی را بین چندین سرور توزیع می کند.

•  انواع توزیع: Round Robin (توزیع مساوی)، Weighted Round Robin (بر اساس قدرت سرورها)، Least Connection (به سمت سرور با کمترین اتصال).
•  انواع لایه: L4 (سریع تر، بر اساس IP و پورت) و L7 (هوشمندتر، بر اساس محتوای HTTP).

 ۵. هشینگ سازگار (Consistent Hashing)

تکنیکی برای توزیع بهینه داده در سیستم های توزیع شده. با افزودن یا حذف یک نود (سرور)، تنها بخش کوچکی از داده ها نیاز به جابجایی دارند که این امر پایداری و عملکرد سیستم را به شدت بهبود می بخشد.

سیستم های پایگاه داده

 دو نوع اصلی پایگاه داده وجود دارد: SQL و NoSQL.

 پایگاه داده SQL (رابطه ای)

این پایگاه داده ها از اصول ACID پیروی می کنند که یکپارچگی و امنیت داده را تضمین می کند:

•     Atomicity (تجزیه ناپذیری): تراکنش یا به طور کامل انجام می شود یا اصلاً انجام نمی شود.
•    Consistency (یکپارچگی): پایگاه داده همیشه در یک وضعیت معتبر باقی می ماند.
•    Isolation (ایزوله سازی): تراکنش های همزمان روی یکدیگر تأثیر نمی گذارند.
•    Durability (ماندگاری): نتایج یک تراکنش موفق، حتی در صورت خرابی سیستم، دائمی هستند.

 پایگاه داده NoSQL (غیر رابطه ای)

این پایگاه داده ها مدل سازی انعطاف پذیر و مقیاس پذیری بالایی ارائه می دهند و برای داده های بدون ساختار یا حجیم مناسبند.

•     Document-based (مانند MongoDB): داده ها را در قالب JSON/BSON ذخیره می کنند.
•    Key-Value (مانند Redis): داده ها را به صورت زوج های کلید-مقدار ذخیره می کنند و دسترسی بسیار سریعی دارند.
•    Column-based (مانند Apache Cassandra): برای مجموعه داده های بزرگ و تحلیل داده بهینه شده اند.
•    Graph (مانند Neo4j): برای مدل سازی روابط پیچیده (مانند شبکه های اجتماعی) استفاده می شوند.

 مقیاس پذیری پایگاه داده

   صف پیام (Message Queue)

 صف پیام یک ساختار حیاتی برای مدیریت ارتباطات ناهمزمان (Asynchronous) بین اجزای مختلف سیستم است. این سیستم پیام ها را در یک صف قرار می دهد تا به ترتیب پردازش شوند. این کار باعث می شود اجزای سیستم در ساخت اپ تحت وب به طور مستقل از هم کار کنند، از اتلاف داده جلوگیری شود و در زمان ترافیک بالا، بار سیستم متعادل گردد.

 مدل Publish/Subscribe (Pub/Sub): یک الگوی پیام رسانی است که در آن، یک ناشر (Publisher) پیام ها را به یک تاپیک (Topic) ارسال می کند و مشترکین (Subscribers) بدون نیاز به ارتباط مستقیم با ناشر، آن پیام ها را دریافت می کنند. این مدل وابستگی بین کامپوننت ها را کاهش و انعطاف پذیری سیستم را افزایش می دهد.

 نتیجه گیری

 هر سیستمی و طراحی سایت، نیازمندی ها و الزامات منحصربه فرد خود را دارد. بنابراین، طراحی سیستم ها به کارآمدترین شکل ممکن و ارائه راه حل هایی که به بهترین نحو این نیازها را برآورده کنند، امروزه از اهمیت بالایی برخوردار است. در این مقاله، اطلاعات پس زمینه ضروری در مورد طراحی سیستم را ارائه دادم و امیدوارم این اطلاعات شما را در فرآیند طراحی راهنمایی کند.