بسیاری از استارت‌آپ‌ها این را پشت سر گذاشته‌اند: انبوهی از کاربران جدید هر روز ثبت‌نام می‌کنند، و تیم توسعه‌دهنده تلاش می‌کند تا سرویس را ادامه دهد.

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

بیایید سعی کنیم اطلاعات را فیلتر کنیم و فرمول اصلی را بنویسیم. ما می‌خواهیم سایت جدید اشتراک‌گذاری عکس Graminsta را گام به گام از 1 به 100 کاربر افزایش دهیم.

بیایید بنویسیم که وقتی مخاطب به 10، 100، 1000، 10،000 و 100،000 نفر افزایش می یابد، چه اقدامات خاصی باید انجام شود.

1 کاربر: 1 دستگاه

تقریباً هر برنامه ای، چه یک وب سایت یا یک برنامه تلفن همراه، دارای سه جزء کلیدی است:

• API
• پایگاه داده
• مشتری (خود برنامه تلفن همراه یا وب سایت)

پایگاه داده داده های پایدار را ذخیره می کند. API درخواست‌هایی را به این داده‌ها و اطراف آن ارائه می‌کند. مشتری داده ها را به کاربر منتقل می کند.

من به این نتیجه رسیدم که اگر از نظر معماری، کلاینت و موجودیت های API کاملاً از هم جدا باشند، صحبت در مورد مقیاس بندی یک برنامه بسیار ساده تر است.

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

در تئوری، می‌توانیم آن را در فضای ابری روی یک نمونه DigitalOcean Droplet یا AWS EC2 اجرا کنیم، همانطور که در زیر نشان داده شده است:

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

10 کاربر: انتقال پایگاه داده به سطح جداگانه

تقسیم پایگاه داده به خدمات مدیریت شده مانند Amazon RDS یا پایگاه داده مدیریت شده اقیانوس دیجیتال برای مدت طولانی به ما کمک خواهد کرد. کمی گران‌تر از میزبانی خود روی یک دستگاه یا نمونه EC2 است، اما با این خدمات افزونه‌های مفید زیادی را دریافت می‌کنید که در آینده به کار خواهند آمد: پشتیبان‌گیری چند منطقه‌ای، خواندن کپی‌ها، خودکار پشتیبان گیری و موارد دیگر.

اکنون سیستم به این صورت است:

100 کاربر: انتقال مشتری به سطح جداگانه

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

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

به عنوان مثال، اکنون کاربران ما اغلب درخواست انتشار یک برنامه تلفن همراه را دارند. اگر کلاینت و موجودیت های API را از هم جدا کنید، این کار آسان تر می شود.

چنین سیستمی به نظر می رسد:

1000 کاربر: متعادل کننده بار اضافه کنید

همه چیز رو به جلو است. کاربران Graminsta عکس های بیشتری را آپلود می کنند. تعداد ثبت نام ها نیز در حال افزایش است. سرور API تنها ما به سختی می تواند با تمام ترافیک همراه باشد. به آهن بیشتری نیاز دارید!

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

ما قرار است بار متعادل کننده های جداگانه ای را در جلوی وب کلاینت و جلوی API قرار دهیم. این بدان معنی است که می توانید چندین نمونه را با کد API و کد مشتری وب اجرا کنید. متعادل کننده بار درخواست ها را به سروری که کمتر بارگذاری شده است هدایت می کند.

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

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

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

توجه داشته باشید. در حال حاضر سیستم ما بسیار شبیه به چیزی است که شرکت‌های PaaS مانند Heroku یا Elastic Beanstalk در AWS خارج از جعبه ارائه می‌دهند (به همین دلیل است که آنها بسیار محبوب هستند). Heroku پایگاه داده را روی یک میزبان جداگانه قرار می دهد، یک بار متعادل کننده خودکار مقیاس را مدیریت می کند، و به شما اجازه می دهد تا مشتری وب را جداگانه از API میزبانی کنید. این یک دلیل عالی برای استفاده از Heroku برای پروژه‌های مرحله اولیه یا استارت‌آپ‌ها است - شما تمام خدمات اولیه را از جعبه دریافت می‌کنید.

10 کاربر: CDN

شاید از همان ابتدا باید این کار را می کردیم. پردازش درخواست‌ها و پذیرش عکس‌های جدید فشار زیادی به سرورهای ما وارد می‌کند.

در این مرحله، شما باید از یک سرویس ابری برای ذخیره محتوای ثابت - تصاویر، ویدیوها و موارد دیگر (AWS S3 یا Digital Ocean Spaces) استفاده کنید. به طور کلی، API ما باید از رسیدگی به مواردی مانند ارائه تصاویر و آپلود تصاویر در سرور اجتناب کند.

مزیت دیگر میزبانی ابری CDN است (AWS این افزونه را Cloudfront می نامد، اما بسیاری از ارائه دهندگان ذخیره سازی ابری آن را خارج از جعبه ارائه می دهند). CDN به طور خودکار تصاویر ما را در مراکز داده مختلف در سراسر جهان ذخیره می کند.

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

100 کاربر: مقیاس بندی لایه داده

CDN کمک زیادی کرده است: ترافیک با سرعت کامل در حال رشد است. ویدئو بلاگر معروف Mavid Mobrick به تازگی در ما ثبت نام کرده و همانطور که می گویند "داستان" خود را پست کرده است. به لطف بار متعادل کننده، استفاده از CPU و حافظه در سرورهای API کم نگه داشته می شود (ده نمونه API در حال اجرا است)، اما ما شروع به دریافت زمان های زیادی در درخواست ها کرده ایم... این تاخیرها از کجا می آیند؟

با کاوش در معیارها، می بینیم که CPU در سرور پایگاه داده 80-90٪ بارگذاری شده است. ما در مرز هستیم

مقیاس بندی لایه داده احتمالاً سخت ترین بخش معادله است. سرورهای API درخواست‌های بدون حالت را ارائه می‌کنند، بنابراین ما به سادگی نمونه‌های API بیشتری اضافه می‌کنیم. بینی اکثریت پایگاه های داده نمی توانند این کار را انجام دهند. ما در مورد سیستم های مدیریت پایگاه داده رابطه ای محبوب (PostgreSQL، MySQL و غیره) صحبت خواهیم کرد.

ذخیره سازی

یکی از ساده ترین راه ها برای افزایش عملکرد پایگاه داده ما، معرفی یک جزء جدید است: لایه کش. متداول‌ترین روش ذخیره‌سازی ذخیره‌سازی رکورد با مقدار کلید در حافظه است، مانند Redis یا Memcached. اکثر ابرها یک نسخه مدیریت شده از این خدمات دارند: Elasticache در AWS و Memorystore در Google Cloud.

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

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

ما نتایج را از پایگاه داده در Redis با کلید کش می کنیم user:id با مدت اعتبار 30 ثانیه حالا وقتی شخصی به پروفایل Mobrik می رود، ابتدا Redis را بررسی می کنیم و اگر داده وجود دارد، آن را مستقیماً از Redis منتقل می کنیم. اکنون درخواست ها به محبوب ترین نمایه در سایت عملاً پایگاه داده ما را بارگذاری نمی کنند.

یکی دیگر از مزایای بیشتر سرویس های کش این است که مقیاس پذیری آنها نسبت به سرورهای پایگاه داده آسان تر است. Redis دارای یک حالت Redis Cluster داخلی است. شبیه به یک بار متعادل کننده1، به شما امکان می دهد کش Redis خود را در چندین ماشین (در صورت نیاز در هزاران سرور) توزیع کنید.

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

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

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

اکنون سیستم ما اینجاست:

مراحل بعدی

همانطور که برنامه به مقیاس‌بندی ادامه می‌دهد، ما به جداسازی سرویس‌ها برای مقیاس‌بندی مستقل ادامه می‌دهیم. به عنوان مثال، اگر شروع به استفاده از Websockets کنیم، منطقی است که کد پردازش Websockets را به یک سرویس جداگانه بکشیم. ما می‌توانیم آن را در نمونه‌های جدید پشت بار متعادل‌کننده خودمان قرار دهیم، که می‌تواند بر اساس اتصالات Websockets باز و بدون توجه به تعداد درخواست‌های HTTP، افزایش یا کاهش یابد.

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

ما همچنین می خواهیم یک سرویس نظارت و تجزیه و تحلیل مانند New Relic یا Datadog را نصب کنیم. این به شما کمک می کند پرس و جوهای کند را شناسایی کنید و بفهمید کجا به بهبود نیاز است. همانطور که مقیاس می‌گیریم، می‌خواهیم روی یافتن گلوگاه‌ها و حذف آنها تمرکز کنیم - اغلب با استفاده از برخی از ایده‌های بخش‌های قبلی.

منابع

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

پانویسها و منابع

1. اگرچه از نظر توزیع بار در چندین نمونه مشابه است، پیاده سازی زیربنایی یک خوشه Redis بسیار متفاوت از یک متعادل کننده بار است. [برگشت]

منبع: www.habr.com