با رشد برنامهها از MVP به محیطهای تولیدی با ترافیک بالا، معماری اولیه «سرور واحد» به بنبست میخورد. برای معماران و توسعهدهندگان ارشد، تصمیم بین مقیاسبندی افقی (افزایش نودها) و مقیاسبندی عمودی (ارتقای نودهای موجود) تنها یک انتخاب پیکربندی نیست—بلکه یک تعیینکننده بنیادین معماری است. در حالی که مقیاسبندی عمودی یک راهحل سریع برای افزایشهای ناگهانی ارائه میدهد، مقیاسبندی افقی انعطافپذیری مورد نیاز برای سیستمهای توزیعشده مدرن را فراهم میکند. این پست به بررسی ملاحظات فنی میپردازد تا به شما در انتخاب مسیر درست کمک کند.
مقیاسبندی عمودی: مسیر کمترین مقاومت
مقیاسبندی عمودی، که اغلب به عنوان «مقیاسبندی به بالا» شناخته میشود، شامل افزایش قدرت محاسباتی یک ماشین واحد با افزودن هستههای بیشتر CPU، RAM یا ذخیرهسازی است. این رویکرد شهودی است و اغلب به تغییرات کد حداقلی نیاز دارد. برای برنامههای حالتدار یا مونولیتهای قدیمی که برای توزیع طراحی نشدهاند، مقیاسبندی عمودی میتواند عملیترین راهحل کوتاهمدت باشد.
با این حال، مقیاسبندی عمودی محدودیتهای سختی دارد. شما توسط مشخصات حداکثری یک ماشین فیزیکی یا مجازی واحد محدود میشوید. علاوه بر این، این رویکرد یک نقطه شکست واحد (SPOF) ایجاد میکند. اگر آن سرور بزرگ خراب شود، کل سرویس از دسترس خارج میشود. علاوه بر این، سرورهای رده بالا به دلیل محدودیتهای سختافزاری و منحنیهای هزینه نمایی، با بازده نزولی مواجه میشوند.
مقیاسبندی افقی: استاندارد بومی ابری
مقیاسبندی افقی، یا «مقیاسبندی به بیرون»، شامل افزودن نمونههای بیشتر از برنامه شما به یک گروه از سرورها است. این اصل بنیادین معماریهای بومی ابری و میکروسرویسها است. به جای تکیه بر یک ماشین قدرتمند، شما بر بسیاری از ماشینهای استاندارد و معمولی که به صورت هماهنگ کار میکنند، تکیه میکنید.
مزایای کلیدی
- انعطافپذیری: اگر یک نود شکست بخورد، نودهای دیگر به پردازش ترافیک ادامه میدهند و در دسترس بودن بالا را تضمین میکنند.
- مقیاسپذیری نامحدود: از نظر نظری، میتوانید به تعداد نودهایی که توزیعکننده بار و زیرساخت شما پشتیبانی میکنند، نود اضافه کنید.
- کارایی هزینه: استفاده از سختافزار معمولی اغلب ارزانتر از خرید ابررایانهها است.
ملاحظات پیچیدگی
عیب اصلی مقیاسبندی افقی، افزایش پیچیدگی است. شما باید کشف سرویس، توزیع بار و مهمتر از همه، مدیریت حالت را مدیریت کنید. میکروسرویسها باید به گونهای طراحی شوند که بدون حالت (Stateless) باشند، به این معنی که نباید دادههای جلسه را به صورت محلی ذخیره کنند. در عوض، حالت باید به پایگاههای داده خارجی یا لایههای کش مانند Redis منتقل شود.
پیادهسازی مقیاسبندی افقی با کوبرنیتیز
در یک محیط مدرن کوبرنیتیز، مقیاسبندی افقی اغلب از طریق مقیاسدهنده خودکار پود افقی (HPA) به صورت خودکار انجام میشود. در زیر یک نمونه پیکربندی YAML وجود دارد که یک استقرار را بر اساس استفاده از CPU به صورت خودکار مقیاس میدهد.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-microservice-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-microservice
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
این پیکربندی تضمین میکند که وقتی استفاده از CPU از 70٪ فراتر میرود، کوبرنیتیز به طور خودکار پادهای جدید تا حداکثر 10 provision میکند. وقتی ترافیک کاهش مییابد، آن را برای صرفهجویی در منابع به پایین برمیگرداند.
نتیجهگیری: انتخاب درست
پاسخی برای همه وجود ندارد. اگر یک ابزار داخلی ساده و حالتدار با ترافیک پایین قابل پیشبینی اجرا میکنید، مقیاسبندی عمودی ممکن است کافی باشد و شما را از سردرد مدیریت سیستم توزیعشده نجات دهد. با این حال، برای میکروسرویسهای عمومی با ترافیک بالا، مقیاسبندی افقی برای دستیابی به قابلیت اطمینان و کشش غیرقابل مذاکره است.
برای نیازهای فوری و نمونهسازی سریع با مقیاسبندی عمودی شروع کنید، اما معماری خود را از روز اول با در نظر گرفتن مقیاسبندی افقی طراحی کنید. جداسازی حالت، پیادهسازی بررسیهای سلامت و استفاده از توزیعکنندههای بار با رشد پایگاه کاربران شما، سود خواهد داد. هدف نه تنها مدیریت ترافیک بیشتر، بلکه ساخت سیستمی است که در شرایط عدم قطعیت شکوفا میشود.