EC2 Spot یا On-Demand؛ ۹۲٪ قطع‌های هم‌زمان ظرف سه دقیقه رخ داد

اگر کار دسته‌ای شما می‌تواند از وضعیت ذخیره‌شده ادامه یابد و مهلت پایان آن انعطاف دارد، EC2 Spot می‌تواند هزینهٔ پردازش را کاهش دهد. برای خدمتی که قطع اجرا یا انتظار برای ظرفیت جایگزین به تعهد آن آسیب می‌زند، On-Demand انتخاب مناسب‌تری است. در پژوهش دسترس‌پذیری نمونه‌های Spot با داده‌های AWS و Azure، تحلیل ۲٬۶۳۵ رویداد وقفه نشان داد بیش از ۹۲٪ قطع‌های هم‌زمانِ نمونه‌های هم‌نوع در یک ناحیهٔ دسترس‌پذیری ظرف سه دقیقه از یکدیگر رخ داده‌اند.

Spot از ظرفیت بلااستفادهٔ EC2 استفاده می‌کند و ممکن است هنگام نیاز AWS به آن ظرفیت قطع شود. در مقایسهٔ رسمی AWS، قیمت Spot متغیر و نرخ On-Demand ثابت است؛ در هر دو مدل، راه‌اندازی نمونهٔ تازه به وجود ظرفیت بستگی دارد و Savings Plans نیز تخفیف اضافه‌ای به مصرف Spot نمی‌دهد. پس تفاوت این دو مدل را باید با هزینه و زمان رسیدن به نتیجهٔ کامل سنجید، نه فقط نرخ ساعتی یک نمونه.

تخفیف ساعتی چقدر از هزینهٔ کار کم می‌کند؟

عبارت «تا ۹۰٪ ارزان‌تر» سقف تخفیف نسبت به On-Demand است، نه قیمتی که برای هر نوع نمونه، ناحیه و زمان اجرا دریافت می‌کنید. راهنمای عملی AWS برای Spot این سقف را در کنار نبود تضمین برای دسترسی فوری، حفظ نمونه تا پایان کار یا تأمین همهٔ ظرفیت درخواستی بیان می‌کند. حتی اگر نرخ Spot بسیار پایین باشد، تکرار پردازش و انتظار برای ظرفیت تازه می‌تواند بخشی از صرفه‌جویی را مصرف کند.

واحد مقایسه، هزینهٔ یک خروجی موفق است: مجموع هزینهٔ همهٔ زمان‌های پردازش، ثبت و بازیابی وضعیت، آماده‌سازی دوباره و اثر مالی تأخیر را در برابر انجام همان کار با On-Demand بگذارید. صرفه‌جویی خالص زمانی شکل می‌گیرد که اختلاف قیمت ظرفیت از این هزینه‌های اضافه بیشتر باشد. میزان پردازش ازدست‌رفته نیز به محل ثبت نتیجه بستگی دارد؛ کاری که فقط در پایان خروجی می‌دهد، در برابر وقفه آسیب‌پذیرتر از کاری است که بخش‌های مستقل را جداگانه تکمیل و ذخیره می‌کند.

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

قطع‌های نزدیک به هم برای کار توزیع‌شده چه معنایی دارند؟

عدد پژوهش، فاصلهٔ زمانی میان قطع یک نمونه و نزدیک‌ترین قطع نمونهٔ هم‌نوع دیگر در همان ناحیه را توصیف می‌کند. این عدد احتمال قطع هر نمونه یا نرخ قطعی کل EC2 نیست؛ اندازه‌گیری نیز داده‌های AWS و Azure را با هم دربر می‌گیرد. پیام آن برای طراحی کار روشن است: چند گرهٔ هم‌نوع در یک ناحیه، الزاماً چند مسیر مستقل برای ادامهٔ اجرا فراهم نمی‌کنند، زیرا به یک مخزن ظرفیت متکی‌اند.

اگر گره‌ها وظایف مستقل را انجام دهند، قطع نزدیک به هم چند وظیفه را برای اجرای دوباره به صف برمی‌گرداند. اگر پیشرفت هر گره به بقیه وابسته باشد، از دست‌رفتن چند گره ممکن است یک مرحلهٔ مشترک را به آخرین وضعیت ذخیره‌شده برگرداند. بنابراین «قابل تحمل بودن وقفه» تنها ویژگی یک نمونه نیست؛ باید دید واحد بازیابی، یک وظیفهٔ کوچک است، یک مرحلهٔ چندگرهی است یا کل پردازش.

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

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

هشدار، فرصت کوتاهی برای واکنش است و جای checkpoint دوره‌ای را نمی‌گیرد. طبق مستندات هشدار وقفهٔ EC2، اعلان توقف یا خاتمهٔ نمونهٔ Spot دو دقیقه پیش از قطع، از راه EventBridge و فرادادهٔ نمونه، بر مبنای تلاش ممکن منتشر می‌شود؛ در حالت hibernation، فرایند فوراً آغاز می‌شود و اعلان دو دقیقه زودتر نمی‌رسد.

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

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

ماتریس انتخاب بر اساس ویژگی بار کاری

چهار معیار زیر تعیین می‌کند که تخفیف Spot به نتیجهٔ ارزان‌تر تبدیل می‌شود یا به ریسک تحویل. آن‌ها را برای همان کاری بسنجید که قرار است اجرا شود؛ میانگین هزینهٔ زیرساخت به‌تنهایی دربارهٔ یک پردازش حساس به زمان چیزی نمی‌گوید.

• حساسیت به زمان: اگر پایان کار می‌تواند تا فراهم‌شدن ظرفیت عقب بیفتد، Spot گزینهٔ مناسبی است. اگر وقفهٔ اجرا یا انتظار برای نمونهٔ تازه تعهد خدمت را نقض می‌کند، بار اصلی به On-Demand نیاز دارد.
• امکان checkpoint: اگر وضعیت در فضای پایدار ذخیره می‌شود و کار واقعاً از همان نقطه ادامه می‌یابد، زیان وقفه به پردازش پس از آخرین ذخیره محدود می‌شود. بدون این امکان، هزینهٔ تکرار کامل کار را وارد مقایسه کنید.
• هزینهٔ شروع دوباره: فقط زمان محاسبهٔ ازدست‌رفته را نشمارید. آماده‌سازی داده، بارگذاری مدل و هماهنگ‌کردن دوبارهٔ گره‌ها نیز می‌توانند زمان و هزینهٔ هر خروجی را افزایش دهند.
• تنوع ظرفیت: محدودشدن به یک نوع نمونه در یک ناحیه، انتخاب‌های جایگزین را کم می‌کند. پشتیبانی از چند نوع سازگار و چند ناحیهٔ دسترس‌پذیری، امکان یافتن ظرفیت را بیشتر می‌کند؛ جابه‌جایی میان منطقه‌های AWS نیز به محل داده، تأخیر مجاز و الزامات نگهداری آن وابسته است.

در بار دسته‌ای با وظایف مستقل، مهلت منعطف و نتیجهٔ ذخیره‌شده برای هر وظیفه، این معیارها معمولاً به سود Spot جمع می‌شوند. در سرویس پیوسته یا پردازش چندگرهی که بازگشت آن پرهزینه است، نرخ پایین‌تر باید در برابر هزینهٔ وقفه و از دست‌رفتن پیشرفت سنجیده شود. می‌توان ظرفیت لازم برای بخش حساس را از پیش با On-Demand اجرا کرد و Spot را به بخش قابل‌تعویق اختصاص داد؛ این چیدمان به راه‌اندازی فوری نمونهٔ جایگزین پس از قطع Spot وابسته نیست.

پخش‌کردن ظرفیت چه چیزی را تغییر می‌دهد؟

وقتی کار به Spot می‌خورد، انتخاب ارزان‌ترین مخزن ظرفیت لزوماً هزینهٔ خروجی را کمینه نمی‌کند. مستندات تخصیص EC2 Fleet راهبرد price-capacity-optimized را برای درنظرگرفتن هم‌زمان ظرفیت در دسترس و قیمت توصیه می‌کند و راهبرد lowest-price را دارای بیشترین خطر وقفه معرفی می‌کند. راهبرد diversified نیز نمونه‌ها را میان مخزن‌های ظرفیت توزیع می‌کند.

پخش ظرفیت، وابستگی به یک ترکیب نوع نمونه و ناحیه را کاهش می‌دهد، اما معماری کار همچنان تعیین‌کننده است. برای وظایف مستقل، نتیجهٔ هر بخش باید جداگانه ثبت شود تا قطع چند نمونه فقط همان بخش‌ها را تکرار کند. برای کار وابستهٔ چندگرهی، checkpoint باید بتواند از دست‌رفتن چند گرهٔ نزدیک به هم را پوشش دهد؛ اگر هزینهٔ چنین بازیابی‌ای از صرفه‌جویی بیشتر شود، سهم کوچک‌تر Spot یا اجرای بار روی On-Demand انتخاب اقتصادی‌تری خواهد بود.

بیشتر بخوانید:

• Paddle یا Lemon Squeezy؛ کارمزد برابر، زمان تسویه متفاوت
• Scrum یا Kanban؛ نصف‌شدن زمان تحویل هنوز حکم عمومی نیست
• جلسه یا کار ناهم‌زمان؛ تصمیم زنده است، گزارش نه