راهکار ULL گوگل‌کلاد حالا به‌صورت عمومی در دسترس است و خانوادهٔ U4 را برای workloadهایی معرفی می‌کند که در آن‌ها چند میکروثانیه تأخیر یا نوسان زمانی می‌تواند روی نتیجه اثر بگذارد. این خبر برای بازارهای مالی، سامانه‌های دادهٔ بلادرنگ، پردازش جریان‌های پرترافیک و تیم‌هایی که به اجرای بسیار قابل‌پیش‌بینی نیاز دارند اهمیت دارد. گوگل‌کلاد می‌گوید این سرویس در مناطق خصوصی منتخب ارائه می‌شود و جایگزین عمومی برای همهٔ workloadها نیست.
در این مطلب، راهکار ULL گوگل‌کلاد را از زاویهٔ معماری، انتخاب ماشین و هزینهٔ عملیاتی بررسی می‌کنیم تا تصمیم‌گیری فقط بر اساس وعدهٔ سرعت انجام نشود.
راهکار ULL گوگل‌کلاد دقیقاً چه چیزی را تغییر می‌دهد؟
در معماری‌های ابری معمولی، مجازی‌سازی، سوئیچ‌های نرم‌افزاری و اشتراک منابع می‌توانند باعث نوسان زمان پاسخ شوند. راهکار ULL گوگل‌کلاد با ترکیب شبکهٔ multicast در سطح سخت‌افزار، پردازش قطعی و مشاهده‌پذیری دقیق شبکه تلاش می‌کند این نوسان را کاهش دهد. هدف فقط رسیدن به یک عدد کم برای latency نیست؛ مهم‌تر از آن، تکرارپذیر بودن زمان پردازش و قابل‌پیش‌بینی ماندن رفتار سیستم در بارهای سنگین است.
طبق اعلام رسمی، سه ستون اصلی این معماری عبارت‌اند از:
گوگل همچنین از همگام‌سازی با UTC و timestampگذاری در سطح زیر ۱۰ نانوثانیه در شبکه صحبت می‌کند. این عدد را نباید با زمان کامل اجرای یک معامله یا پاسخ یک برنامه یکی دانست؛ timestamp شبکه فقط یکی از اجزای زنجیرهٔ پردازش است. برای تحلیل دقیق، تیم باید latency کل مسیر، queueing، زمان پردازش برنامه و زمان رفت‌وبرگشت تا سرویس مقصد را جداگانه اندازه‌گیری کند.
خانوادهٔ U4 چه گزینه‌هایی دارد؟
راهکار ULL گوگل‌کلاد از سه سری اصلی استفاده می‌کند. U4P و U4C نمونه‌های bare metal دو سوکته هستند و برای مسیرهایی طراحی شده‌اند که دسترسی مستقیم به منابع فیزیکی و کمینه‌کردن jitter اهمیت دارد. طبق جدول گوگل، این نمونه‌ها ۱۲۰ هستهٔ فیزیکی، ۵۱۲ یا ۷۶۸ گیگابایت حافظه و سه کارت شبکهٔ فیزیکی دارند؛ دو کارت برای شبکهٔ ULL و یک کارت برای مسیر استاندارد و سرویس‌های مدیریتی استفاده می‌شود.
U4S یک ماشین مجازی با مقیاس‌پذیری بیشتر است. این سری برای کارهایی مانند اعتبارسنجی پیش از معامله، تحلیل بلادرنگ و سرویس‌هایی مناسب است که به انعطاف منابع نیاز دارند اما لزوماً در حساس‌ترین مسیر اجرای معامله قرار نمی‌گیرند. U4S از ۲ تا ۲۸۸ vCPU و حداکثر ۲۲۳۲ گیگابایت حافظه پشتیبانی می‌کند و می‌تواند در کنار نمونه‌های bare metal قرار بگیرد.
در لایهٔ ذخیره‌سازی، Titanium SSD برای ثبت سریع داده‌های لحظه‌ای و tick log در نظر گرفته شده و Hyperdisk برای آرشیو، backtesting و داده‌های تاریخی کاربرد دارد. پشتیبانی از OpenOnload و DPDK نیز به تیم‌ها اجازه می‌دهد مسیر packet processing را با تغییر محدود در کدهای موجود به فضای کاربر نزدیک‌تر کنند.
آیا این سرویس برای هر تیمی مناسب است؟
پاسخ کوتاه منفی است. راهکار ULL گوگل‌کلاد برای سازمانی جذاب است که هزینهٔ تأخیر و jitter در مدل کسب‌وکارش قابل‌اندازه‌گیری باشد؛ برای مثال صرافی، کارگزار، ارائه‌دهندهٔ market data یا پلتفرمی که تصمیم‌های بلادرنگ با حجم بالا می‌گیرد. اگر bottleneck اصلی در الگوریتم، پایگاه داده، صف پیام یا سرویس بیرونی باشد، انتقال صرف workload به سخت‌افزار سریع‌تر الزاماً نتیجهٔ محسوسی ایجاد نمی‌کند.
به همین دلیل، راهکار ULL گوگل‌کلاد باید به‌عنوان یک معماری تخصصی ارزیابی شود، نه یک ارتقای عمومی برای همهٔ سرورها.
پیش از مهاجرت، ابتدا workload واقعی را benchmark کنید: p50 و p99 latency، jitter، نرخ packet loss، زمان warm-up، هزینهٔ ذخیره‌سازی و رفتار سیستم در peak را ثبت کنید. سپس همان سناریو را روی U4P، U4C یا U4S مقایسه کنید. تفاوت bare metal و VM باید با هزینهٔ عملیاتی، سرعت استقرار، ظرفیت رزرو و نیازهای انطباقی سنجیده شود؛ نه فقط با یک عدد تبلیغاتی.
محدودیت مهم دیگر، عرضه در مناطق خصوصی منتخب است. بنابراین باید region، مسیر اتصال، قرارداد دسترسی، الزامات داده و امکان انتقال سرویس‌های جانبی را پیش از طراحی نهایی بررسی کرد. برای آشنایی با سرویس‌های مرتبط، راهنمای Compute Engine در تکتاز مگ را ببینید و جزئیات فنی را در مقالهٔ رسمی Google Cloud بررسی کنید.
جمع‌بندی
راهکار ULL گوگل‌کلاد نشان می‌دهد ابر عمومی در حال نزدیک‌شدن به نیازهای سخت‌گیرانهٔ بازارهای حساس به latency است؛ اما این به معنی حذف trade-offها نیست. U4P و U4C کنترل و پیش‌بینی‌پذیری bare metal را هدف می‌گیرند و U4S انعطاف ماشین مجازی را ارائه می‌دهد. تصمیم درست زمانی گرفته می‌شود که تیم، هزینه، region در دسترس و benchmark workload واقعی را کنار هم بگذارد. برای بسیاری از سازمان‌ها، یک تست محدود و قابل‌اندازه‌گیری در staging بهترین قدم قبل از هر مهاجرت production است.
