زیرساخت مقیاس‌پذیر؛ وقتی ترافیک ناگهان بالا می‌رود

همه‌چیز عادی است.

سایت سریع باز می‌شود، CPU آرام است و دیتابیس هم مشکلی ندارد.

بعد یک کمپین شروع می‌شود.

یک محصول وایرال می‌شود.

پیامک برای چندصد هزار نفر ارسال می‌شود.

فروش ویژه آغاز می‌شود.

یا یک خبر باعث می‌شود تعداد کاربران در چند دقیقه چند برابر شود.

ناگهان Response Time بالا می‌رود، Connectionهای دیتابیس پر می‌شوند، Queueها عقب می‌افتند و بخشی از کاربران با Error مواجه می‌شوند.

اولین واکنش معمولاً این است:

سرور قوی‌تری لازم داریم.

گاهی درست است.

اما در بسیاری از سیستم‌ها، سرور بزرگ‌تر فقط نقطه شکست را کمی عقب‌تر می‌برد.

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

Microsoft در اصول معماری Cloud توصیه می‌کند Applicationها تا جای ممکن برای Horizontal Scaling طراحی شوند؛ یعنی با افزایش بار بتوان Instance اضافه کرد، به‌جای اینکه همیشه به یک ماشین بزرگ‌تر وابسته باشند. همین راهنما تأکید می‌کند Bottleneckها و نقاط Coordination معمولاً چیزی هستند که مقیاس‌پذیری واقعی را محدود می‌کنند.

پس مسئله واقعی این نیست که:

«سرور ما چقدر قوی است؟»

سؤال بهتر این است:

«وقتی تعداد درخواست‌ها پنج برابر شد، کدام بخش سیستم اول کم می‌آورد؟»

قبل از Scaling، ظرفیت واقعی سیستم را بشناسید

اگر نمی‌دانید سیستم امروز چند Request را تحمل می‌کند، نمی‌توانید برای فردا ظرفیت درستی طراحی کنید.

باید حداقل تصویری از Throughput و Latency داشته باشید.

مثلاً بدانید در شرایط عادی چند Request per Second دریافت می‌کنید، P95 و P99 Latency چقدر است، چند Connection هم‌زمان به دیتابیس وجود دارد، CPU و Memory در Peak چه وضعیتی دارند و Error Rate در چه نقطه‌ای شروع به افزایش می‌کند.

این اعداد به شما یک Capacity Baseline می‌دهند.

Google SRE توصیه می‌کند نسبت میان Resource و Capacity با Load Testing اندازه‌گیری شود، نه با فرضیات یا تجربه چند ماه قبل؛ چون هر تغییر در Application می‌تواند ظرفیت واقعی سیستم را تغییر دهد.

مثلاً اینکه:

چهار سرور قبلاً ۴۰۰۰ Request در ثانیه جواب می‌دادند

به این معنی نیست که بعد از اضافه‌شدن چند Feature جدید هم هنوز همین ظرفیت وجود دارد.

Capacity چیزی نیست که یک بار اندازه بگیرید و برای همیشه بدانید.

Scale Up یا Scale Out؟

دو روش اصلی برای افزایش ظرفیت وجود دارد.

در Vertical Scaling یا Scale Up همان سرور را قوی‌تر می‌کنیم؛ CPU بیشتر، RAM بیشتر یا ماشین بزرگ‌تر.

در Horizontal Scaling یا Scale Out تعداد Instanceها را افزایش می‌دهیم.

مثلاً به‌جای یک Application Server بسیار بزرگ، چند Instance داریم که Traffic بین آن‌ها تقسیم می‌شود.

برای بسیاری از Workloadهای Cloud، Scale-out انعطاف بیشتری ایجاد می‌کند، چون Instanceها می‌توانند با افزایش و کاهش Demand اضافه یا حذف شوند. Microsoft نیز این مدل را پایه Elastic Scaling می‌داند.

اما یک شرط دارد:

Application باید واقعاً اجازه Scale-out بدهد.

اگر تمام Sessionها فقط داخل Memory یک Server نگهداری شوند، اضافه‌کردن Server جدید مسئله ایجاد می‌کند.

اگر هر Request باید به همان Instance قبلی برگردد، آزادی Load Balancer کم می‌شود.

اگر چند Instance برای دسترسی به یک Resource مشترک دائماً منتظر یکدیگر باشند، تعداد بیشتر Instance الزاماً Throughput بیشتری ایجاد نمی‌کند.

برای همین Stateless بودن لایه Application تا جای ممکن، یکی از پایه‌های مهم Scale-out است.

Load Balancer بار را تقسیم می‌کند؛ ظرفیت خلق نمی‌کند

وقتی چند Instance داریم، باید درخواست‌ها بین آن‌ها توزیع شوند.

اینجا Load Balancer وارد معماری می‌شود.

Load Balancing کمک می‌کند Traffic بین چند Backend تقسیم شود، Resourceها بهتر استفاده شوند و یک Server به‌تنهایی زیر تمام بار قرار نگیرد. همچنین Health Check می‌تواند Backend ناسالم را از مسیر Traffic خارج کند. Microsoft و Google هر دو Load Balancing را یکی از اجزای اصلی معماری‌های مقیاس‌پذیر و مقاوم می‌دانند.

اما Load Balancer یک نکته مهم دارد:

اگر پشت آن فقط یک Bottleneck مشترک وجود داشته باشد، مشکل حل نشده است.

مثلاً ده Application Server دارید، اما همه آن‌ها روی یک Database کوچک فشار می‌آورند.

Frontend مقیاس گرفته است.

Backend نه.

در این حالت Load Balancer فقط کمک کرده سریع‌تر به Bottleneck بعدی برسید.

هر Requestی نباید تا Origin برسد

یکی از مؤثرترین راه‌های تحمل Traffic بالا این است که اصلاً اجازه ندهیم تمام Requestها به Application اصلی برسند.

برای محتوای مناسب، CDN می‌تواند فایل‌های Static و Cacheable را از Edge Locationهای نزدیک‌تر به کاربر Serve کند.

مثلاً تصاویر، CSS، JavaScript، فایل‌های Download و حتی بعضی Responseهای Cacheable می‌توانند بدون مراجعه دوباره به Origin تحویل داده شوند.

AWS در مستندات CloudFront توضیح می‌دهد هرچه Cache Hit Ratio بیشتر باشد، تعداد Requestهایی که Origin باید مستقیماً پاسخ دهد کمتر می‌شود و در نتیجه هم Latency و هم فشار روی Origin کاهش پیدا می‌کند. Origin Shield نیز می‌تواند Requestهای مشابه را بیشتر Consolidate کند و در Peak Traffic فشار هم‌زمان روی Origin را کاهش دهد.

فرض کنید در یک فروش ویژه صد هزار کاربر تقریباً هم‌زمان تصویر و جزئیات یک محصول را می‌بینند.

اگر هر Request برای تصویر مستقیماً به Application Server و Storage مرکزی برسد، بخشی از ظرفیت صرف کاری شده که Edge Cache می‌توانست انجام دهد.

بهترین Request برای سرور شما، Requestی است که اصلاً لازم نباشد به آن برسد.

Cache فقط برای فایل‌های Static نیست

درون Application هم می‌توان بسیاری از Readهای تکراری را Cache کرد.

فرض کنید صفحه محصول برای هر Request باید اطلاعات دسته‌بندی، تنظیمات، موجودیت‌های کم‌تغییر یا یک Query سنگین را از Database دریافت کند.

اگر هزاران کاربر یک داده تقریباً یکسان را در چند ثانیه بخواهند، اجرای دوباره همان Query برای هر کاربر هزینه زیادی دارد.

الگوی Cache-Aside یکی از روش‌های متداول است: Application ابتدا Cache را بررسی می‌کند و فقط در صورت Cache Miss سراغ Data Store می‌رود، سپس نتیجه را برای درخواست‌های بعدی در Cache قرار می‌دهد. Microsoft این الگو را برای داده‌های Read-heavy که تغییرات نسبتاً محدودی دارند مناسب می‌داند.

البته Cache رایگان نیست.

TTL اشتباه می‌تواند داده قدیمی نشان دهد.

Invalidation می‌تواند پیچیده شود.

Cache بیش از حد کوچک Eviction زیادی ایجاد می‌کند.

و Cache کردن اطلاعات حساس بدون طراحی درست خطر امنیتی دارد.

هدف این نیست که:

همه‌چیز را Cache کنیم.

هدف این است که:

Readهای گران و پرتکرار را از مسیر اصلی Database برداریم، جایی که Consistency موردنیاز اجازه می‌دهد.

هر کاری لازم نیست همان لحظه تمام شود

یکی از دلایل فروپاشی سیستم در Peak Traffic این است که هر Request می‌خواهد تمام مراحل کار را همان لحظه انجام دهد.

مثلاً کاربر سفارش ثبت می‌کند و Request باید تا پایان این کارها منتظر بماند:

ثبت سفارش، تولید PDF، ارسال ایمیل، ارسال SMS، Sync با CRM، ثبت در سیستم حسابداری و به‌روزرسانی چند گزارش.

اگر هرکدام از این سرویس‌ها کند شود، Response اصلی هم کند می‌شود.

بسیاری از این کارها می‌توانند Asynchronous باشند.

در این مدل Request اصلی کار ضروری را انجام می‌دهد و Workهای بعدی وارد Queue می‌شوند.

Workerها بعداً آن‌ها را با سرعتی که ظرفیت دارند پردازش می‌کنند.

Microsoft این الگو را Queue-Based Load Leveling می‌نامد: Queue بین Producer و Consumer Buffer ایجاد می‌کند و Burstهای ناگهانی را به جریان قابل‌کنترل‌تری تبدیل می‌کند.

فرض کنید در ۳۰ ثانیه ۲۰ هزار سفارش ایجاد می‌شود.

لازم نیست ۲۰ هزار ایمیل تأیید هم در همان ۳۰ ثانیه ارسال شوند.

سفارش باید ثبت شود.

ایمیل می‌تواند چند ثانیه بعد برسد.

همین تصمیم ساده می‌تواند تفاوت میان یک سیستم پایدار و یک Cascading Failure باشد.

Database معمولاً دیر یا زود خودش را نشان می‌دهد

Application Serverها اغلب نسبتاً ساده Scale-out می‌شوند.

Database داستان پیچیده‌تری دارد.

در Traffic بالا ممکن است مشکل از CPU دیتابیس نباشد.

ممکن است Connection Pool پر شده باشد.

Lock افزایش پیدا کرده باشد.

Query بدی Table Scan انجام دهد.

Index مناسب وجود نداشته باشد.

Storage IOPS به سقف برسد.

یا صدها Application Instance هم‌زمان یک Query مشابه را اجرا کنند.

پس قبل از اینکه Database را صرفاً بزرگ‌تر کنیم، باید بفهمیم Bottleneck واقعی چیست.

برای Workloadهای Read-heavy، یکی از ابزارها Read Replica است. AWS توضیح می‌دهد Read Replica می‌تواند Queryهای خواندنی را از Primary Database جدا کند و Load مربوط به Read را بین Instanceهای دیگر پخش کند. البته Replication معمولاً Asynchronous است و ممکن است مقدار کمی Lag وجود داشته باشد.

برای برخی سیستم‌ها Cache کافی است.

برای بعضی Read Replica.

برای بعضی Partitioning یا Sharding.

و برای بسیاری، اولین راه‌حل فقط اصلاح Query و Index است.

Scaling دیتابیس قبل از Optimization می‌تواند فقط هزینه یک Query بد را بیشتر کند.

Autoscaling را به Metric درست وصل کنید

Autoscaling یعنی سیستم بر اساس Demand ظرفیت را کم یا زیاد کند.

اما سؤال مهم این است:

بر اساس چه چیزی؟

CPU یکی از Metricهای رایج است.

اما همیشه بهترین Metric نیست.

مثلاً ممکن است CPU پایین باشد ولی Request Queue در حال رشد باشد.

یا CPU Application مناسب باشد ولی Database Connection Pool تقریباً پر شده باشد.

برای Workerها ممکن است Queue Length بهتر باشد.

برای Web Server شاید Request Count per Instance.

برای بعضی Workloadها Latency یا Concurrent Request مفیدتر است.

AWS در Target Tracking امکان Scale بر اساس Metricهایی مثل CPU یا Request Count per Target را فراهم می‌کند و تأکید دارد Metric انتخابی باید رابطه معناداری با Load و Capacity داشته باشد. Microsoft نیز Autoscaling را بر اساس Metricهایی مثل CPU یا Queue Length توصیه می‌کند.

Autoscaling زمانی خوب عمل می‌کند که Metric واقعاً نشان دهد سیستم به ظرفیت بیشتری نیاز دارد.

نه صرفاً چون Dashboard آن عدد را راحت‌تر نمایش می‌دهد.

Autoscaling سریع است؛ فوری نیست

این نکته در Traffic Spike بسیار مهم است.

وقتی Metric از Threshold عبور می‌کند، سیستم تصمیم می‌گیرد ظرفیت جدید ایجاد کند.

اما Instance جدید باید:

• ساخته شود،
• Boot شود،
• Application را Load کند،
• Dependencyها را آماده کند،
• Health Check را Pass کند،
• و بعد Traffic بگیرد.

این فرایند زمان دارد.

AWS برای همین مفهوم Instance Warmup دارد و حتی Warm Pool را برای Applicationهایی ارائه می‌کند که Startup طولانی دارند، تا Instanceهای از قبل آماده‌شده سریع‌تر وارد سرویس شوند.

بنابراین اگر سیستم شما ظرفیت ۱۰۰۰ Request در ثانیه دارد و در دو ثانیه Traffic به ۱۰ هزار می‌رسد، نباید انتظار داشته باشید Autoscaling به‌تنهایی تمام فاصله را جبران کند.

اینجاست که CDN، Cache، Queue، ظرفیت پایه و Load Shedding کنار Autoscaling اهمیت پیدا می‌کنند.

اگر Peak قابل پیش‌بینی است، قبل از کاربران Scale کنید

همه Traffic Spikeها ناگهانی نیستند.

اگر می‌دانید:

• فروش ویژه ساعت ۱۰ شروع می‌شود،
• کمپین پیامکی ساعت ۱۸ ارسال خواهد شد،
• Registration ساعت مشخصی باز می‌شود،
• یا یک Event قرار است پخش شود،

چرا باید منتظر بمانیم CPU بالا برود تا سیستم تازه متوجه شود ظرفیت بیشتری لازم است؟

برای Workloadهای قابل پیش‌بینی می‌توان Scheduled یا Predictive Scaling داشت.

Microsoft توصیه می‌کند برای Patternهای منظم از Scheduled Scaling استفاده شود، در حالی که Workloadهای غیرقابل‌پیش‌بینی می‌توانند بر اساس Runtime Metric Scale شوند.

در Eventهای مهم، چند دقیقه ظرفیت اضافه بسیار ارزان‌تر از چند دقیقه Down بودن سرویس است.

حداقل Capacity را بیش از حد پایین نگذارید

Scale-to-zero یا Capacity بسیار کم می‌تواند برای بعضی Workloadها از نظر Cost جذاب باشد.

اما برای سرویس حساس به Latency، همیشه بهترین انتخاب نیست.

اگر Traffic ناگهان بیاید، سیستم نیاز دارد از نقطه‌ای Scale را شروع کند.

پس Minimum Capacity باید با Risk و SLA هماهنگ باشد.

Resource بدون استفاده هزینه دارد.

Capacity ناکافی هم هزینه دارد.

هدف Autoscaling کمترین Infrastructure Cost ممکن نیست.

کمترین هزینه‌ای است که SLO موردنیاز را حفظ کند.

تمام اجزای سیستم را با یک Policy Scale نکنید

یک Application واقعی ممکن است چند بخش داشته باشد:

• Frontend
• API
• Background Worker
• Search
• Image Processing
• Recommendation
• Database
• Cache
• Queue Consumer

هرکدام رفتار متفاوتی دارند.

مثلاً با افزایش کاربر ممکن است API Instance بیشتری نیاز داشته باشید، اما Workerها هنوز Queue را به‌خوبی کنترل کنند.

یا برعکس، Frontend سالم باشد اما Jobهای Background عقب افتاده باشند.

Microsoft نیز توصیه می‌کند بخش‌های مختلف Workload بر اساس نیاز خودشان و با Policyهای جداگانه Scale شوند.

Scalability خوب یعنی هر Bottleneck بتواند مستقل از اجزای دیگر ظرفیت بگیرد.

Rate Limiting فقط ابزار امنیت نیست

اگر یک Client بتواند در هر ثانیه ده هزار Request بفرستد، حتی Requestهای کاملاً معتبر هم می‌توانند سرویس را از دسترس خارج کنند.

Rate Limiting یا Throttling کمک می‌کند Consumption کنترل شود.

مثلاً Limit می‌تواند بر اساس User، API Key، Tenant، IP یا Operation تعریف شود.

Microsoft در Throttling Pattern توضیح می‌دهد سیستم بالغ باید Overload را یک حالت قابل‌مدیریت بداند و بتواند با Rate Limit، Load Leveling یا کاهش قابلیت‌های غیرضروری از خودش محافظت کند.

Rate Limit برای همه کاربران هم الزاماً یکسان نیست.

یک API سبک با یک Endpoint تولید گزارش سنگین هزینه مشابهی ندارد.

و یک Tenant Enterprise ممکن است SLA متفاوتی از کاربر رایگان داشته باشد.

وقتی ظرفیت تمام شد، همه‌چیز را با هم خراب نکنید

هیچ Infrastructureای ظرفیت بی‌نهایت ندارد.

حتی اگر Autoscaling، CDN و Cache عالی باشند، بالاخره نقطه‌ای وجود دارد که Demand از Capacity بیشتر می‌شود.

در آن نقطه رفتار سیستم بسیار مهم است.

یک سیستم ضعیف تلاش می‌کند همه Requestها را قبول کند.

Latency بالا می‌رود.

Timeout بیشتر می‌شود.

Clientها Retry می‌کنند.

Retryها Traffic را بیشتر می‌کنند.

Dependencyها یکی‌یکی تحت فشار قرار می‌گیرند.

و در نهایت یک مشکل ظرفیت تبدیل به Cascading Failure می‌شود.

Google SRE توصیه می‌کند سیستم در شرایط Overload بتواند بخشی از Load را Reject کند یا Response ساده‌تر و ارزان‌تری ارائه دهد تا سرویس اصلی زنده بماند.

این همان Graceful Degradation است.

مثلاً در Peak شدید ممکن است:

• Recommendation شخصی‌سازی‌شده موقتاً خاموش شود.
• صفحه از داده Cache شده استفاده کند.
• گزارش سنگین به Queue منتقل شود.
• تصویر با Resolution پایین‌تر Serve شود.
• Search Result ساده‌تری نشان داده شود.
• اما Checkout همچنان کار کند.

اینجا معماری یک تصمیم Business می‌گیرد:

کدام قابلیت باید تحت هر شرایطی زنده بماند؟

Retry بدون کنترل می‌تواند حمله‌ای از طرف خود سیستم باشد

فرض کنید Backend کند شده است.

هر Client بعد از Timeout بلافاصله دوباره Request می‌فرستد.

Backend حالا علاوه بر Traffic اصلی باید Retryها را هم پردازش کند.

Timeout بیشتر می‌شود.

Retry بیشتر می‌شود.

و چرخه ادامه پیدا می‌کند.

Google SRE هشدار می‌دهد Retry می‌تواند Error کوچک را به افزایش شدید Traffic و Cascading Failure تبدیل کند و توصیه می‌کند Retry Budget محدود و Exponential Backoff همراه با Jitter استفاده شود.

پس:

Retry یعنی دوباره تلاش کن، نه اینکه بی‌وقفه حمله کن.

Scalability و Availability یک چیز نیستند

یک سیستم ممکن است حجم Traffic زیادی را تحمل کند ولی Single Point of Failure داشته باشد.

مثلاً ۲۰ Application Instance دارید، اما همه در یک Availability Zone هستند.

اگر آن Zone از دسترس خارج شود، تعداد Instanceها کمکی نمی‌کند.

برای Workloadهای Critical، Redundancy باید کنار Scaling طراحی شود.

Microsoft توصیه می‌کند Load Balancer، چند Instance، Database Replica و در صورت نیاز استقرار در چند Zone یا Region برای حذف Single Point of Failure در نظر گرفته شوند.

به زبان ساده:

Scalability می‌پرسد چند کاربر را تحمل می‌کنیم.

Reliability می‌پرسد وقتی بخشی از سیستم خراب شد، هنوز کار می‌کنیم یا نه.

هر دو مهم‌اند، اما مسئله یکسانی نیستند.

Observability باید قبل از Traffic Spike وجود داشته باشد

وقتی سیستم کند شد، زمان مناسبی برای این سؤال نیست:

حالا چطور بفهمیم مشکل کجاست؟

قبل از Production باید Metrics، Logs و Traceها وجود داشته باشند.

برای یک سیستم پرترافیک، Dashboard فقط CPU و RAM نیست.

باید بتوانیم ارتباط بین User Experience و Infrastructure را ببینیم.

مثلاً:

Traffic بیشتر شد.

P95 Latency بالا رفت.

Cache Hit Ratio افت کرد.

Database Connection زیاد شد.

Query خاصی کند شد.

Queue Backlog رشد کرد.

Autoscaler Instance اضافه کرد.

و Error Rate دوباره پایین آمد.

این زنجیره همان چیزی است که Observability باید قابل مشاهده کند.

اگر فقط بدانیم:

CPU روی ۹۰٪ است

هنوز نمی‌دانیم چرا.

Average می‌تواند شما را گول بزند

فرض کنید Average Response Time برابر با ۲۵۰ میلی‌ثانیه است.

عالی به نظر می‌رسد.

اما شاید ۹۵ درصد کاربران ۱۵۰ میلی‌ثانیه پاسخ بگیرند و ۵ درصد دیگر سه ثانیه منتظر بمانند.

در سیستم‌های پرترافیک Percentileها معمولاً تصویر بهتری از تجربه کاربران نشان می‌دهند.

به همین دلیل Metricهایی مثل:

• P50
• P95
• P99

در کنار Average اهمیت پیدا می‌کنند.

برای Peak Traffic، Tail Latency مهم است؛ چون همان درصد کوچک کاربران ناراضی ممکن است در مقیاس میلیون Request، تعداد بسیار بزرگی باشد.

Load Test باید تا جایی ادامه پیدا کند که سیستم کم بیاورد

اگر Test فقط تا Traffic عادی انجام شود، چیز زیادی درباره رفتار سیستم در Crisis نمی‌دانیم.

یک Load Test خوب باید چند سؤال را جواب دهد:

• سیستم تا چه RPSای SLO را حفظ می‌کند؟
• اولین Bottleneck کجاست؟
• Autoscaling چقدر زمان می‌برد؟
• در چه نقطه‌ای Latency جهش می‌کند؟
• Queue تا چه اندازه قابل‌تحمل است؟
• وقتی ظرفیت رد می‌شود، سیستم Gracefully Degrade می‌کند یا Crash؟
• بعد از برگشت Load، سیستم Recovery دارد؟

Google SRE صریحاً توصیه می‌کند هم Capacity Limit و هم Failure Mode هنگام Overload تست شوند، چون بدون آزمایش واقعی پیش‌بینی دقیق Resource Exhaustion دشوار است.

هدف Load Testing این نیست که ثابت کنیم سیستم سریع است.

هدف این است که بفهمیم:

کجا می‌شکند و وقتی می‌شکند چه رفتاری دارد.

یک معماری منطقی برای Traffic بالا چه شکلی است؟

نسخه واحدی برای همه پروژه‌ها وجود ندارد، اما جریان معمول می‌تواند شبیه این باشد:

User → DNS / CDN → WAF / Gateway → Load Balancer → Stateless Application Instances → Cache / Queue → Database & Services

در کنار آن:

• Autoscaling
• Monitoring
• Distributed Tracing
• Centralized Logging
• Rate Limiting
• Health Checks
• Backup
• Multi-zone Redundancy
• و Alerting

قرار می‌گیرند.

نکته مهم این نیست که همه این Technologyها را داشته باشید.

مهم این است که هرکدام مشکل مشخصی را حل کنند.

اگر برای ۲۰۰ کاربر روزانه Kubernetes، پنج Region و ده Service اضافه کنید، Infrastructure شاید مقیاس‌پذیر باشد؛ اما احتمالاً غیرضروری پیچیده است.

معماری باید برای Demand واقعی طراحی شود، نه برای نمایش تعداد ابزارها.

چک‌لیست زیرساخت قبل از یک Traffic Spike

مقیاس‌پذیری یعنی ظرفیت بی‌نهایت؟

نه.

هیچ سیستمی ظرفیت بی‌نهایت ندارد.

حتی بزرگ‌ترین سرویس‌ها هم Budget، Quota، Bottleneck و Failure Mode دارند.

هدف معماری مقیاس‌پذیر این نیست که بگوییم:

«هر تعداد کاربری آمد، مشکلی نداریم.»

هدف این است که بدانیم:

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

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

اما سیستم‌های واقعاً مقیاس‌پذیر معمولاً با ترکیب چند تصمیم ساده‌تر ساخته می‌شوند:

درخواست‌هایی که لازم نیست به Origin برسند، Cache می‌شوند.

کاری که لازم نیست همان لحظه انجام شود، وارد Queue می‌شود.

Traffic بین چند Instance پخش می‌شود.

ظرفیت با Demand تغییر می‌کند.

Database جداگانه مراقبت می‌شود.

و وقتی دیگر ظرفیت کافی نیست، سیستم یاد گرفته است چگونه محترمانه «نه» بگوید.

زیرساخت خوب فقط وقتی همه‌چیز آرام است سریع نیست؛ وقتی همه با هم وارد می‌شوند هم می‌داند چطور آرام بماند.

→بازگشت به مقالات