در این مقاله
صفحه خرید سرور باز است؛ گزینه داخلی پرداخت ساده‌تری دارد و گزینه خارجی به سرویس‌های موردنیاز محصول نزدیک‌تر به نظر می‌رسد. تیم توسعه نگران دریافت وابستگی‌هاست، پشتیبانی از کندی کاربران می‌گوید و شما باید هزینه و ریسک تصمیم را بپذیرید. انتخاب «هاست ایران یا خارج» با مقایسه حافظه و پردازنده تمام نمی‌شود. مسیر دسترسی کاربران، جای دیتابیس، وابستگیهای خارجی و امکان بازیابی سرویس هم تعیین‌کننده‌اند. پیش از خرید روشن کنید کدام اختلال برای کسب‌وکار شما قابل‌تحمل نیست و تیم برای مدیریت آن چه توان و بودجه‌ای دارد.
هاست ایران یا خارج؛ پاسخ کوتاه به چه چیزی بستگی دارد؟
اگر کاربران اصلی شما داخل ایران‌اند و عملیات حیاتی محصول به ارتباط خارجی وابسته نیست، زیرساخت داخلی را در اولویت آزمون قرار دهید. اگر بیشتر کاربران خارج‌اند یا بخش اصلی سرویس به APIها و داده‌های خارجی وابسته است، گزینه خارجی را بررسی کنید. انتخاب قطعی به اندازه‌گیری مسیر واقعی درخواست نیاز دارد.
قدم بعدی: نسخه آزمایشی مشابه محصول را روی گزینه‌های منتخب اجرا کنید و مسیرهای حیاتی را از شبکه کاربران بسنجید. محدودیت قراردادی، محل مجاز نگهداری داده و هزینه خروج از سرویس را هم مشخص کنید.
محل سرور را از مدل مدیریت آن جدا کنید
شما هم‌زمان تصمیم می‌گیرید اپلیکیشن کجا اجرا شود و چه کسی عملیات آن را انجام دهد. سرور داخلی یا خارجی می‌تواند مدیریت‌شده یا کاملاً بر عهده تیم شما باشد. پاستا هم یکی از گزینه‌های مدیریت اجرای برنامه است؛ مناسب‌بودن آن را باید جدا از انتخاب موقعیت جغرافیایی بسنجید.
اگر هنوز بین خرید سرور و استفاده از پلتفرم مردد هستید، راهنمای «انتخاب میان سرور اختصاصی، ابری و پلتفرم» را بخوانید تا مشخص کنید کدام مسئولیت‌های عملیاتی را تیم شما می‌پذیرد و کدام را به ارائهدهنده می‌سپارد.
|
گزینه |
نقطه قوت مشخص |
چه زمانی از پاستا انتخاب بهتری است؟ |
هزینه یا محدودیت |
|
سرور مجازی یا ابری داخلی با مدیریت تیم شما |
در پلن دارای دسترسی مدیریتی، تنظیمات سیستم‌عامل و نرم‌افزارها را خودتان کنترل می‌کنید. |
اگر به تنظیمات سطح سیستم‌عامل و محل اجرای مشخص در ایران نیاز دارید که گزینه فعال پاستا پوشش نمی‌دهد، این گزینه مناسب‌تر است؛ به شرط داشتن توان عملیات. |
به‌روزرسانی، پایش و بازیابی بر عهده تیم شماست. داخلی‌بودن نیز دسترسی به وابستگیهای خارجی را تضمین نمی‌کند. |
|
سرور مجازی یا ابری خارجی با مدیریت تیم شما |
می‌توانید برنامه را در زیرساخت فعلی دیتابیس مستقر کنید و کنترل ماشین را نگه دارید. |
اگر دیتابیس شما در همان زیرساخت است و آزمایش نشان می‌دهد انتقال برنامه به پاستا تأخیر مسیر حیاتی را بیشتر میکند، ماندن در زیرساخت فعلی انتخاب بهتری است؛ مشروط به مجازبودن استفاده. |
شرایط حساب، پرداخت و دسترسی کاربران داخل ایران را جداگانه بررسی کنید. عملیات ماشین هم مسئولیت تیم شماست. |
|
سرور اختصاصی |
سخت‌افزار فیزیکی به استفاده شما اختصاص دارد؛ این ویژگی با جداسازی فضای کاری در یک پلتفرم یکسان نیست. |
اگر قرارداد مشتری سخت‌افزار اختصاصی می‌خواهد، در نبود چنین تعهدی در قرارداد پاستا، سرویس اختصاصی با تعهد مکتوب انتخاب بهتری است. |
ظرفیت و عملیات سرور را باید مدیریت کنید؛ اختصاصی‌بودن سخت‌افزار بهتنهایی دسترس‌پذیری را تضمین نمی‌کند. |
|
پاستا |
جریان Build و استقرار، لاگ و امکانات اجرای برنامه را در محیط فارسی در اختیار شما قرار می‌دهد. |
وقتی نیاز برنامه با امکانات فعال آن سازگار است و نمی‌خواهید مدیریت ماشین را بر عهده بگیرید، ارزش بررسی دارد. |
محدودیت پلن، ناحیه و سطح دسترسی را پیش از انتخاب بررسی کنید؛ طراحی بازیابی همچنان لازم است. |
دسترسی مدیریتی را برای هر پلن جداگانه بررسی کنید. برای نمونه، مستندات DigitalOcean دسترسی SSH و کاربر root را برای ماشین‌های خود توضیح می‌دهد؛ این ویژگی را نمی‌توان به همه پلن‌های ابری تعمیم داد. منبع: مستندات اتصال به ماشین
مستندات Dedicated Hosts در AWS نیز اختصاص سخت‌افزار فیزیکی را صریحاً بیان میکند. این نمونه برای توضیح تفاوت مدل‌هاست؛ شرایط مجازبودن استفاده از هر ارائهدهنده را باید جدا بررسی کنید. منبع: مستندات سخت‌افزار اختصاصی
معیار حذف را زود تعیین کنید. اگر محل داده، دسترسی مدیریتی یا نوع سخت‌افزار الزام شماست، گزینه فاقد آن را کنار بگذارید؛ قیمت یا سرعت بهتر این کمبود را جبران نمی‌کند.
پینگ سرور ایران چه چیزی را نشان نمی‌دهد؟
پینگ سرور ایران سرنخی از تأخیر شبکه می‌دهد، ولی زمان ورود کاربر یا ثبت سفارش را توضیح نمی‌دهد. درخواست واقعی ممکن است منتظر اتصال امن، پردازش برنامه، کوئری دیتابیس یا پاسخ یک API بماند.
اگر اپلیکیشن در ایران و دیتابیس خارج باشد، درخواست‌های وابسته به دیتابیس باید این مسیر را طی کنند. نزدیک‌شدن برنامه به کاربر ممکن است با دورشدن آن از داده خنثی شود.
CDN هم جای بررسی مسیرهای پویا را نمی‌گیرد. کش‌شدن محتوا به تنظیمات و نوع پاسخ وابسته است؛ برای نمونه، Cloudflare به‌صورت پیش‌فرض HTML و JSON را کش نمی‌کند. این رفتار همان سرویس است، نه قابلیت اختصاصی پاستا. منبع: مستندات رفتار کش
پیش از خرید، مسیر واقعی محصول را آزمایش کنید
وابستگیهای ساخت و اجرا را جدا کنید
برای هر وابستگی بنویسید چه زمانی لازم است: دریافت سورس از Git، دریافت Image، نصب بسته‌ها هنگام Build یا فراخوانی سرویس بیرونی هنگام اجرای برنامه.
مشخص کنید با قطع هر اتصال، چه قابلیتی از کار می‌افتد. اگر پاسخ روشن نیست، لاگ ساخت و درخواست‌های خروجی محیط آزمایشی را بررسی کنید. موفق‌شدن استقرار یا Deploy به معنی سالم‌بودن همه قابلیت‌های محصول نیست.
نسخه قابل‌مقایسه بسازید
نسخه یکسان برنامه، داده آزمایشی و تنظیمات مشابه را روی مقصدهای منتخب اجرا کنید. از اطلاعات واقعی مشتری استفاده نکنید.
ورود، جست‌وجو و عملیات اصلی محصول باید در هر دو محیط کامل شوند. اگر رفتار متفاوت است، پیش از مقایسه سرعت، تفاوت منابع، تنظیمات، نسخه دیتابیس و مسیر وابستگی‌ها را پیدا کنید.
زمان پاسخ HTTP را کنار لاگ بسنجید
این نمونه شیوه اندازه‌گیری را نشان می‌دهد. دامنه را با مقصد آزمایشی خود و یک مسیر خواندنیِ بدون اثر جانبی جایگزین کنید:
curl --silent --show-error --output /dev/null \
--write-out 'http=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
https://example.com/
دستور یک درخواست GET می‌فرستد، بدنه پاسخ را کنار می‌گذارد و زمان‌ها را برحسب ثانیه نمایش می‌دهد. تنظیمات زیرساخت را تغییر نمی‌دهد؛ اجرای دوباره، درخواست تازه‌ای ایجاد میکند.
زمان‌ها از شروع درخواست محاسبه می‌شوند؛ آن‌ها را با هم جمع نکنید. first_byte علاوه بر ارتباط، انتظار برای پاسخ سرور را هم شامل میشود. منبع: راهنمای رسمی curl
آزمایش را از شبکه‌های نماینده کاربران و در زمان‌های متفاوت تکرار کنید. باید پاسخ HTTP موردنظر را بگیرید و عملیات کامل شود. در صورت تفاوت، زمان‌ها را با لاگ برنامه تطبیق دهید؛ اندازه‌گیری از لپ‌تاپ تیم جای تجربه کاربران را نمی‌گیرد.
بازیابی را پیش از جابه‌جایی تمرین کنید
از داده آزمایشی بکاپ بگیرید و آن را در محیط جداگانه بازیابی کنید. باید بتوانید داده را بخوانید و از برنامه استفاده کنید.
اگر بازیابی ناقص است، قالب بکاپ، سازگاری نسخه و فایل‌های خارج از دیتابیس را بررسی کنید. تا مشخص‌شدن مسیر بازگشت، ترافیک تولید را منتقل نکنید.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.