زیرساختهای پردازش کلانداده همواره با چالشهای بینظیری روبهرو هستند. تیم مهندسی زالاندو (Zalando)، غول مد آنلاین اروپا، موفق به طراحی و پیادهسازی یک متعادلکننده بار (Load Balancer) سمت کلاینت و درونپروسهای شده است که توان عملیاتی خیرهکنندهای در حدود 1 میلیون درخواست در ثانیه دارد. خروجی این معماری جدید، کاهش چشمگیر هزینههای زیرساختی، تأخیر (Latency) بسیار قابل پیشبینیتر و شفافیت کامل در ردیابی ریشه خرابیها بود.
تنگنای مسیریابی درProduct Read API
سیستم Product Read API در زالاندو برای پاسخگویی به 25 بازار جهانی با تأخیری در حد تکمیلیثانیه طراحی شده است. در معماری قبلی، یک نقطه پایانی دستهای (Batch Endpoint)، هر درخواست ورودی را به 100 فراخوانی موازی برای پادهای (Pods) مجزای محصول تقسیم میکرد. تمامی این ترافیک از Skipper، متعادلکننده بار لبه (Edge Load Balancer) مشترک کلاستر عبور میکرد.
چالش اصلی زمانی آشکار میشد که یک درخواست دستهای مجبور بود برای تکمیل پروسه، منتظر کندترین پرش (Hop) در میان 100 زیرسیستم باقی بماند. در این حالت، توسعهدهندگان قادر به تفکیک تأخیرهای مربوط به Skipper از مشکلات اپلیکیشن خود نبودند. کانور گالاگر (Conor Gallagher)، مهندس ارشد زالاندو، به صراحت بیان میکند که تصمیم گرفتند تصمیمگیری مسیریابی برای ترافیک داخلی با گسترش بالا (High fan-out) را مستقیماً به درون خود فرآیند calling منتقل کنند. با این حال، Skipper همچنان برای ترافیک لبه و درخواستهای GET تکی حفظ شد تا از نقاط قوت آن بهرهمند شوند.
هش یکنواخت و جلوگیری از نوسان کش
برای جلوگیری از تقسیم کش (Cache split) در طول فرآیند مهاجرت، تیم مهندسی الگوریتم دقیق Skipper (شامل xxHash64 با 100 گره مجازی برای هر نقطه پایانی) را دقیقاً شبیهسازی کرد. این هماهنگی باعث میشد هر دو مسیر، کلیدهای یکسانی را به پادهای مشابهی ارسال کنند. نتیجه این معماری آن بود که افزودن یا حذف هر نقطه پایانی، تنها حدود 1/N کلیدها را مجدداً نگاشت میکرد که در نتیجه آن نوسان کش (Cache Churn) به کمترین میزان ممکن رسید.
تیم زالاندو فرآیند نظارتچسبانی (Polling) که مستعد کرش کردن صفحه کنترل بود را با یک Kubernetes Informer مبتنی بر Watch جایگزین کرد. خط لوله (Pipeline) استقرار که پیش از این ساعاتی طول میکشید، به یک فرآیند سریع و کاملاً قابلبازگشت (Reversible) تبدیل شد.
کاهش 75 درصدی هزینههای استقرار روزانه
با فعالسازی تدریجی این متعادلکننده بار جدید از 1 درصد تا 100 درصد، توانستند ناوگان Skipper را از بیش از 50 پاد به تنها 8 پاد کاهش دهند. این بهینهسازی زیرساختی باعث شد هزینه استقرار روزانه از 450 دلار به 110 دلار سقوط کند. برای مقابله با جهشهای تأخیر هنگام مقیاسبندی افزایشی (Scale-up)، محو شدن تدریجی N-ring در بازه زمانی 30 ثانیهای روی یک منحنی توانی (^2.5) پیادهسازی شد تا پادهای تازه فقط محصولاتی را گرم کنند (Warm) که قرار است سرویس واقعی ارائه دهند.
واکنشهای جامعه مهندسی به معماری زالاندو
این موفقیت مهندسی نظرات مثبتی از سوی چهرههای شاخص صنعت به همراه داشت. ورنر فوگلز (Werner Vogels)، مدیر فناوری آمازون، با وجود اینکه طرفدار انجام این کار در سمت کلاینت نیست، این دستاورد زالاندو را یک مهندسی چشمگیر توصیف کرد. الکسی کوزنتسوف (Alexey Kuznetsov)، مهندس ارشد AWS نیز اشاره کرد که متعادلسازی بار سمت کلاینت زمانی که از آمازون به گوگل منتقل شد، برای او نوعی کشف بزرگ بود و این تفکر باید بیشتر برجسته شود.
با این حال، مسیر توسعه زالاندو کاملاً هموار نبود. تلاش آنها برای مسیریابی آگاه از منطقه دسترسپذیری (AZ-aware routing) با هدف کاهش هزینههای بینمنطقهای، منجر به تکهتکه شدن کشها و ایجاد انفجار در خواندن پایگاهداده دینامودیبی (DynamoDB) شد. آنها در رویکرد جدید با اضافهکردن تلاش مجدد (Retry) منقطع (Jittered) و FIFO Overload Shedding، این مسیر را مستحکم کردند.
گالاگر در پایان هشدار میدهد که ساخت یک متعادلکننده بار سفارشی فقط زمانی توجیه دارد که شما در یک مورد استثنایی و بسیار پیچیده گیر افتاده باشید. برای اکثر تیمها، استفاده از پراکسیهای بالغ مانند Skipper یا Envoy که توسط هزاران کاربر سختگیری شدهاند، بهترین گزینه محسوب میشود. آیا آینده معماری مایکروسرویسها به سمت انتقال بیشتر منطق شبکه به درون پروسههای اپلیکیشن حرکت خواهد کرد؟
