اگر تا الان چند بار بین دو رجین جابه‌جا شده‌اید و هر بار کاربرهایتان از کندی شکایت کرده‌اند، مشکل جای دیگری است. انتخاب مکان سرور ابری معمولاً به‌عنوان یک تصمیم یک‌باره گرفته می‌شود، در حالی که در عمل یک تصمیم عملیاتی است که باید با عدد سنجیده شود، نه با حدس. این متن برای کسی است که می‌داند دنبال چه می‌گردد و فقط می‌خواهد بداند کدام معیار واقعاً تعیین‌کننده است.
مکان سرور ابری را با تأخیر بسنجید، نه با نقشه
اولین کاری که باید بکنید این است که تأخیر را از خود کاربر اندازه بگیرید، نه از دفتر خودتان. یک سرور موقت در هر کاندید بالا بیاورید و از چند نقطه واقعی ping و mtr بزنید:
mtr -rwzbc 100 -T -P 443 target.example.comفلگ -T مسیر TCP روی پورت ۴۴۳ را می‌سنجد، نه ICMP را. این تفاوت مهم است چون بسیاری از مسیرها ICMP را در اولویت پایین‌تری پردازش می‌کنند و عددی که می‌بینید با تجربه واقعی کاربر فرق دارد. فلگ -c 100 هم صد بسته می‌فرستد تا میانگین و انحراف معیار معنا پیدا کند؛ یک نمونه‌گیری ده‌بسته‌ای هیچ چیز را ثابت نمی‌کند.
عددی که باید دنبالش باشید، تأخیر رفتوبرگشت در صدک ۹۵ است، نه میانگین. اگر میانگین ۴۰ میلیثانیه باشد ولی صدک ۹۵ روی ۱۸۰ میلیثانیه بنشیند، کاربر شما در هر بار بارگذاری صفحه یک وقفه محسوس را تجربه میکند. برای یک اپلیکیشن وب معمولی، تفاوت ۲۰ میلیثانیه و ۶۰ میلیثانیه در TTFB معمولاً بین ۱۵ تا ۴۰ درصد در زمان بارگذاری کامل خودش را نشان می‌دهد، چون هر صفحه ده‌ها درخواست موازی تولید میکند و تأخیر جمع می‌شود.
مسیر شبکه مهمتر از فاصله جغرافیایی است
دو دیتاسنتر می‌توانند صد کیلومتر از هم فاصله داشته باشند و یکی نصف دیگری تأخیر بدهد. دلیلش تعداد هاپ و کیفیت peering است. یک مسیر با هشت هاپ و تبادل ترافیک مستقیم، از یک مسیر با چهار هاپ که ترافیک را از سه شبکه واسط عبور می‌دهد، سریع‌تر و پایدارتر است. خروجی mtr این را نشان می‌دهد: اگر در هاپ‌های میانی افت بسته (packet loss) پایدار می‌بینید، آن مسیر برای بار حساس مناسب نیست، حتی اگر هاپ آخر سالم باشد.
اینجا اشتباه می‌کنند: تیم‌ها یک بار ping می‌زنند، عدد پایین می‌بینند، و تصمیم را قطعی می‌کنند. بعد سه هفته بعد در ساعت اوج ترافیک، همان مسیر به‌خاطر ازدحام uplink یک ISP خاص، افت بسته ۳ تا ۷ درصدی نشان می‌دهد. علامتش هم این است: سایت در ساعات عصر کند می‌شود ولی در لاگ سرور هیچ چیزی غیرعادی نیست، چون گلوگاه بیرون از سرور شماست. اگر این الگو را دیدید، قبل از هر تغییری در منابع، مسیر را دوباره اندازه بگیرید.
معیارهای واقعی انتخاب رجین
چهار معیار در عمل تعیین‌کننده‌اند و بقیه در حاشیه قرار می‌گیرند:
- محل کاربران، نه محل شرکت. اگر ۸۰ درصد ترافیک از داخل ایران می‌آید، رجین دورتر فقط هزینه ترافیک و تأخیر را بالا می‌برد.
- الزامات داده. بعضی بارها باید در محدوده جغرافیایی مشخصی بمانند؛ این محدودیت قبل از هر بهینه‌سازی تأخیر تصمیم را قطعی میکند.
- سرویس‌های وابسته. اگر دیتابیس مدیریت‌شده یا سرویس ذخیره‌سازی در رجین A است و اپلیکیشن در رجین B، هر کوئری یک رفتوبرگشت بین‌قاره‌ای می‌شود. این خطا در معماری‌های چندلایه بسیار رایج است.
- مسیر پشتیبان. رجینی که فقط یک مسیر خروج دارد، در قطعی همان مسیر کاملاً از دسترس خارج می‌شود.
برای بارهایی که چند سرور در یک رجین با هم حرف می‌زنند، ترافیک داخلی را از مسیر عمومی جدا کنید. شبکه خصوصی بین سرورها هم تأخیر را پایین می‌آورد و هم پهنای باند عمومی را برای ترافیک واقعی کاربر آزاد میکند.
چند رجین، یک رجین، یا ترکیب هر دو
پاسخ ساده‌ای وجود ندارد و هر کسی که بگوید «همیشه چند رجین» دارد یک هزینه را نادیده می‌گیرد. مقایسه واقعی این است:
| معیار | تک‌رجین | چندرجین فعال-فعال |
|---|---|---|
| تأخیر برای کاربران پراکنده | برای گروه دور، بد | برای همه، قابل قبول |
| پیچیدگی داده | پایین | بالا؛ نیاز به تکرار و حل تعارض |
| هزینه ترافیک بین‌رجینی | صفر | معمولاً قابل توجه |
| رفتار در قطعی رجین | کاملاً از دسترس | کاهش ظرفیت، نه قطعی |
انتخاب من این است: تا وقتی کاربران شما در یک محدوده جغرافیایی متمرکزند، تک‌رجین با یک رجین پشتیبان غیرفعال (standby) ببرید. چندرجین فعال-فعال را وقتی انتخاب کنید که یا کاربرانتان واقعاً پراکنده‌اند، یا SLA شما اجازه قطعی چندساعته نمی‌دهد. هزینه‌ای که کسی از قبل حساب نمی‌کند، پیچیدگی نوشتن کد است: هر کوئری نوشتن باید بداند کدام رجین منبع حقیقت است، و این تصمیم تا آخر عمر پروژه با شما می‌ماند.
لایه‌ای که تأخیر را از معادله حذف میکند
قبل از اینکه به فکر رجین دوم بیفتید، ببینید چقدر از ترافیک شما اصلاً استاتیک است. اگر تصاویر، فایل‌های JS و CSS از یک شبکه توزیع محتوا سرو شوند، بخش بزرگی از تأخیر درخواست‌های کاربر حذف می‌شود و شاید دیگر نیازی به رجین دوم نداشته باشید. این ارزان‌ترین بهینه‌سازی مکان است و اغلب نادیده گرفته می‌شود.
برای فایل‌های حجیم و بکاپ‌ها هم نگه‌داشتنشان روی همان دیسک سرور اپلیکیشن، هم هزینه ذخیره‌سازی را بالا می‌برد و هم مهاجرت آینده را سخت میکند. جدا کردنشان به فضای ذخیره‌سازی آبجکت این وابستگی را قطع میکند.
چیزهایی که بعد از انتخاب مکان باید تنظیم کنید
انتخاب رجین نصف کار است. نیم دیگر این است که مطمئن شوید می‌توانید بدون قطعی از آن خارج شوید. قبل از هر تغییر پرخطر، از اسنپ‌شات در فضای ابری استفاده کنید تا اگر مهاجرت به رجین دیگر بد پیش رفت، مسیر برگشت داشته باشید.
و پایش را از روز اول جدی بگیرید. اگر تأخیر را اندازه نمی‌گیرید، اولین بار که کاربر شکایت کند تازه می‌فهمید مشکل از کجاست. راهنمای مانیتورینگ ابری و هشدار دقیقاً همین شکاف را پر میکند: هشدار روی صدک ۹۵ تأخیر، نه روی میانگین.
اگر بار شما GPU-محور است، محدودیت مکان شکل دیگری دارد: کارت‌های گرافیکی در همه رجین‌ها موجود نیستند و باید بین دسترسی و تأخیر یکی را انتخاب کنید. در این حالت راهاندازی سرور GPU برای مدل‌های هوش مصنوعی نقطه شروع درستی است.
برای بارهایی که رشد نامنظم دارند، ظرفیت را از قبل در همان رجین انتخابی بزرگ کنید تا مجبور نشوید برای هر جهش ترافیک، مکان را عوض کنید. راهنمای مقیاس‌دهی منابع ابری بدون قطعی همین کار را بدون downtime توضیح می‌دهد. اگر معماری‌تان کانتینری است، کوبرنتیز مدیریت‌شده جابهجایی بین نودها را ساده‌تر میکند، ولی توجه کنید که خود کلاستر هم به یک رجین گره خورده است.
خلاصه عملی: قبل از هر تصمیمی، صد بسته mtr از سه نقطه واقعی بزنید، صدک ۹۵ را ببینید، و بعد انتخاب کنید. اگر عدد قابل قبول بود، همان‌جا بمانید و روی CDN و شبکه خصوصی سرمایه‌گذاری کنید؛ اگر نبود، رجین را عوض کنید، نه اینکه معماری را دور مشکل بپیچید.
پرسش‌های پرتکرار
تأخیر قابل قبول برای کاربران داخل ایران چقدر است؟
برای اپلیکیشن وب، تأخیر رفتوبرگشت زیر ۵۰ میلیثانیه در صدک ۹۵ خوب است و زیر ۸۰ میلیثانیه هنوز قابل قبول. بالای ۱۵۰ میلیثانیه در صدک ۹۵، کاربر در تعاملهای پشتسرهم وقفه را حس میکند.
این اعداد برای API و اپلیکیشنهای تعاملی است. برای دانلود فایل و استریم، پهنای باند و پایداری مسیر مهمتر از تأخیر است.
آیا انتخاب رجین دورتر برای دسترسی به سرویس‌های خاص منطقی است؟
فقط وقتی آن سرویس واقعاً در دسترس نباشد یا الزام قانونی داشته باشید. در غیر این صورت، هر درخواست بین‌قاره‌ای بین ۱۵۰ تا ۳۰۰ میلیثانیه تأخیر اضافه میکند و این عدد در معماری چندلایه ضرب می‌شود.
اگر مجبورید، لایه‌های حساس به تأخیر را نزدیک کاربر نگه دارید و فقط لایه داده را دورتر ببرید.
چطور بفهمم مشکل از مکان سرور است یا از خود اپلیکیشن؟
اگر TTFB در همه نقاط جغرافیایی بهطور یکنواخت بالا باشد، مشکل از اپلیکیشن یا دیتابیس است. اگر فقط از بعضی مناطق بالا باشد، مشکل مسیر شبکه یا مکان است.
یک تست ساده: همان درخواست را از یک سرور در همان رجین بزنید. اگر آنجا سریع بود و از بیرون کند، گلوگاه شبکه است نه کد.
آیا میتوان بدون قطعی سرویس، رجین را عوض کرد؟
بله، ولی نه با جابهجایی مستقیم. الگوی درست این است: رجین جدید را کامل بالا بیاورید، داده را تکرار کنید، ترافیک را با DNS یا لود بالانسر بهتدریج منتقل کنید، و رجین قدیم را مدتی در حالت آماده نگه دارید.
برای این کار به راهاندازی لود بالانسر با health check نیاز دارید تا بتوانید درصد ترافیک را کنترل کنید و در صورت خطا سریع برگردید.