مقیاس‌دهی منابع ابری بدون قطعی؛ راهنمای عملی ارتقای زیرساخت

مقیاس‌دهی بدون قطعی؛ چرا این مسئله حیاتی است؟

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

در این مقاله قصد داریم به صورت عملی و بدون حاشیه، دو روش اصلی مقیاس دهی را بررسی کنیم: مقیاس عمودی (Vertical Scaling) که به معنای تقویت همان سرور فعلی است و مقیاس افقی (Horizontal Scaling) که شامل افزودن نودهای جدید به زیرساخت می‌شود. برای هر دو روش، دستورالعمل‌های مشخص، مثال‌های واقعی و نکات عیب‌یابی ارائه خواهیم داد تا بتوانید زیرساخت خود را بدون حتی یک ثانیه قطعی ارتقا دهید.

مقیاس عمودی؛ سریع‌ترین راه اما با محدودیت‌های جدی

مقیاس عمودی یعنی افزایش منابع یک سرور واحد: رم بیشتر، CPU قوی‌تر، یا دیسک پرسرعت‌تر. در فضای ابری، این کار معمولاً با تغییر Flavor یا Instance Type انجام می‌شود. مثلاً اگر در یک پنل ابری، سروری با ۴ گیگابایت رم و ۲ هسته CPU دارید، می‌توانید آن را به ۸ گیگابایت رم و ۴ هسته ارتقا دهید.

مراحل انجام مقیاس عمودی بدون قطعی

بسیاری از پنل‌های مدیریت ابری، امکان تغییر سایز سرور را به صورت آنلاین (Live Resize) ارائه می‌دهند. اما این قابلیت همیشه در دسترس نیست و در برخی موارد نیاز به ری‌استارت دارد. برای اینکه این کار را بدون قطعی انجام دهید، مراحل زیر را دنبال کنید:

1. بررسی پشتیبانی از Live Resize: ابتدا مستندات پنل خود را بررسی کنید. اگر پنل شما از OpenStack استفاده می‌کند، دستور openstack server resize را می‌توانید امتحان کنید. اما توجه داشته باشید که این دستور در برخی توزیع‌ها نیاز به ری‌استارت دارد.
2. انتقال بار به سرور موقت: اگر Live Resize پشتیبانی نمی‌شود، بهترین راه این است که یک سرور جدید با منابع بالاتر بسازید، داده‌ها را منتقل کنید و سپس ترافیک را به آن سوییچ کنید. این کار با استفاده از DNS و کاهش TTL انجام می‌شود.
3. استفاده از Snapshot: قبل از هر اقدامی، یک Snapshot از سرور بگیرید. این کار به شما امکان بازگشت به حالت قبل را در صورت بروز مشکل می‌دهد.

محدودیت‌های مقیاس عمودی

مقیاس عمودی یک سقف مشخص دارد. شما نمی‌توانید یک سرور را تا بی‌نهایت بزرگ کنید. در هر زیرساخت ابری، حداکثر اندازه Instance محدود است. به عنوان مثال، اگر حداکثر رم قابل تخصیص ۶۴ گیگابایت باشد، بعد از آن دیگر راهی برای مقیاس عمودی ندارید. علاوه بر این، مقیاس عمودی یک نقطه شکست واحد (Single Point of Failure) ایجاد می‌کند؛ اگر آن سرور دچار مشکل سخت‌افزاری شود، کل سرویس از دست می‌رود.

مقیاس افقی؛ راهکار بلندمدت برای رشد پایدار

مقیاس افقی به معنای افزودن نودهای جدید به زیرساخت است. به جای یک سرور بزرگ، چند سرور کوچک‌تر را در کنار هم قرار می‌دهید و بار ترافیک را بین آنها توزیع می‌کنید. این روش نه‌تنها محدودیت مقیاس عمودی را ندارد، بلکه قابلیت اطمینان (Reliability) زیرساخت را نیز افزایش می‌دهد؛ اگر یک نود از کار بیفتد، بقیه نودها همچنان سرویس را ارائه می‌دهند.

آماده‌سازی اپلیکیشن برای مقیاس افقی

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

• انتقال Session به حافظه مشترک: به جای ذخیره Session در فایل یا حافظه محلی، از Redis یا Memcached استفاده کنید. به عنوان مثال، در PHP می‌توانید با تنظیم session.save_handler = redis در فایل php.ini، Sessionها را به Redis منتقل کنید.
• آپلود فایل‌ها به فضای ذخیره‌سازی مشترک: فایل‌های آپلودی کاربران را روی دیسک محلی ذخیره نکنید. از Object Storage مانند S3 یا سرویس‌های مشابه استفاده کنید.
• مدیریت کانفیگ‌ها: کانفیگ‌های اپلیکیشن را در متغیرهای محیطی (Environment Variables) قرار دهید تا هر نود بتواند به راحتی تنظیمات را دریافت کند.

افزودن نود جدید به زیرساخت

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

1. ایجاد Image از سرور پایه: یک Image از سرور اصلی که اپلیکیشن و تنظیمات اولیه روی آن نصب است، تهیه کنید. این Image را می‌توانید در پنل ابری خود ذخیره کنید.
2. راه‌اندازی نود جدید: از روی Image، یک Instance جدید ایجاد کنید. مطمئن شوید که نود جدید در همان شبکه داخلی (VPC) قرار دارد تا بتواند با دیتابیس و Redis ارتباط برقرار کند.
3. اتصال به Load Balancer: نود جدید را به Load Balancer اضافه کنید. اگر از Nginx به عنوان Load Balancer استفاده می‌کنید، کافی است در فایل کانفیگ، آدرس IP نود جدید را به upstream اضافه کنید:

upstream backend {
    server 10.0.0.11:8080 weight=3;
    server 10.0.0.12:8080 weight=3;
    server 10.0.0.13:8080 weight=3;  # نود جدید
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

بعد از اعمال تغییرات، Nginx را با دستور nginx -s reload ری‌لود کنید. این کار بدون قطعی سرویس انجام می‌شود و ترافیک به تدریج بین نودها توزیع می‌شود.

مدیریت دیتابیس در مقیاس افقی

دیتابیس معمولاً چالش‌برانگیزترین بخش مقیاس افقی است. اگر اپلیکیشن شما از MySQL استفاده می‌کند، می‌توانید از Replication استفاده کنید: یک سرور اصلی (Master) برای نوشتن و چند سرور خواندن (Replica). در این حالت، اپلیکیشن باید بین این دو نوع سرور تفکیک قائل شود. به عنوان مثال، در کانفیگ اتصال دیتابیس در Laravel می‌توانید به این شکل عمل کنید:

'mysql' => [
    'read' => [
        'host' => ['10.0.0.21', '10.0.0.22'],
    ],
    'write' => [
        'host' => ['10.0.0.20'],
    ],
    'driver' => 'mysql',
    'database' => 'app_db',
    'username' => 'app_user',
    'password' => 'secret',
    'charset' => 'utf8mb4',
]

برای راه‌اندازی Replication در MySQL، ابتدا روی سرور اصلی فایل کانفیگ را ویرایش کنید:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = app_db

سپس روی سرور Replica تنظیمات زیر را اعمال کنید:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log

و در نهایت، Replication را با دستورات زیر شروع کنید:

CHANGE MASTER TO MASTER_HOST='10.0.0.20', MASTER_USER='replica_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS= 107;
START SLAVE;

اشتباهات رایج در مقیاس دهی و راه‌حل آن‌ها

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

• تغییر همزمان چند متغیر: اگر همزمان مقیاس عمودی انجام دهید و کد اپلیکیشن را تغییر دهید، نمی‌دانید کدام تغییر باعث مشکل شده است. همیشه یک تغییر را در یک زمان اعمال کنید.
• فراموش کردن Health Check: وقتی نود جدیدی به Load Balancer اضافه می‌کنید، حتماً Health Check را فعال کنید. اگر نود جدید به درستی راه‌اندازی نشده باشد، Load Balancer باید به طور خودکار آن را از چرخه خارج کند. در Nginx می‌توانید از ماژول nginx_upstream_check_module استفاده کنید.
• نادیده گرفتن ظرفیت شبکه: مقیاس افقی ممکن است باعث افزایش ترافیک شبکه داخلی شود. اگر از شبکه‌ای با پهنای باند محدود استفاده می‌کنید، ممکن است با گلوگاه شبکه مواجه شوید. قبل از افزودن نودهای زیاد، پهنای باند شبکه داخلی را بررسی کنید.

جمع‌بندی؛ استراتژی هوشمندانه مقیاس دهی

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

• ابتدا با ابزارهای مانیتورینگ مانند Prometheus و Grafana، نقاط گلوگاه را شناسایی کنید.
• اپلیکیشن را از ابتدا برای مقیاس افقی طراحی کنید؛ حتی اگر فعلاً به آن نیاز ندارید.
• همیشه Snapshot بگیرید و فرآیند بازگشت به حالت قبل (Rollback) را تمرین کنید.
• تغییرات را در ساعات کم‌ترافیک اعمال کنید و از ابزارهای Load Balancer برای توزیع تدریجی ترافیک استفاده کنید.

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