اوبر به عنوان یکی از بزرگ‌ترین پلتفرم‌های حمل‌ونقل جهان، سرویس‌های خود را بر پایه زیرساخت‌های ابری قدرتمندی مدیریت می‌کند. یکی از حیاتی‌ترین این زیرساخت‌ها، کلاسترهای OpenSearch هستند که برای جستجو و تحلیل داده‌ها در مقیاس عظیم استفاده می‌شوند. اما سوال اینجاست: چه اتفاقی می‌افتد وقتی یک منطقه کامل (zone) از کار بیفتد؟ اوبر راهکاری هوشمندانه برای این سناریو ارائه کرده است.

چالش: توزیع نابرابر گره‌ها و حالت زرد کلاستر

مشکل اصلی از جایی شروع شد که مناطق فیزیکی در مراکز داده اوبر اغلب تعداد گره‌های (nodes) متعادلی نداشتند. این عدم توازن، منطق allocation-awareness اپنسرچ را دچار اختلال می‌کرد. نتیجه؟ کلاسترها مدام در حالت «زرد» (yellow) قرار می‌گرفتند و بخشی از shardها تخصیص‌نیافته باقی می‌ماندند. علاوه بر این، نگاشت مستقیم مکان shardها به مناطق فیزیکی باعث بروز پدیده‌هایی مانند disk skew (توزیع نابرابر داده روی دیسک‌ها) و ایجاد گره‌های داغ (hot nodes) می‌شد. دلیل این مشکلات ساده بود: مکانیزم rebalancing اپنسرچ برای کار با مجموعه‌ای یکنواخت از گره‌ها طراحی شده است.

راه‌حل اوبر: گروه‌های ایزوله (Isolation Groups)

برای حل این مشکل، تیم مهندسی اوبر یک لایه منطقی جدید به نام گروه‌های ایزوله (IGs) را بین دامنه‌های شکست فیزیکی و منطق مکان‌یابی اپنسرچ قرار داد. با این کار، صرف‌نظر از تعداد مناطق فیزیکی زیرین، به هر IG تعداد گره‌های دقیقاً مساوی اختصاص داده می‌شود. یک نکته جالب: عضویت یک گره در IG خاص حتی با تعویض سخت‌افزار نیز حفظ می‌شود. این یعنی پایداری طولانی‌مدت.

بیشتر سرویس‌های اوبر، از جمله OpenSearch، از 3 IG استفاده می‌کنند. بنابراین هر منطقه فیزیکی دقیقاً به یک IG نگاشت می‌شود و در صورت ازکارافتادن یک منطقه، حداکثر یک‌سوم از کل ظرفیت از دست می‌رود. برای ایمنی بیشتر، هر ایندکس با حداقل 2 replica (در مجموع 3 نسخه از هر shard) اجرا می‌شود که هر نسخه در یک IG متفاوت قرار می‌گیرد. این طراحی مقاومت پایه‌ای در برابر از دست دادن یک گروه کامل را فراهم می‌کند.

مدیریت هوشمند شکست: جلوگیری از طوفان Rebalancing

مشکل بزرگ‌تر زمانی است که یک شکست واقعی رخ می‌دهد. به طور پیش‌فرض، OpenSearch پس از از دست رفتن نسخه‌های shard، بلافاصله فرآیند rebalancing را در گره‌های باقی‌مانده شروع می‌کند. این کار می‌تواند I/O دیسک، CPU و شبکه را اشباع کرده و منجر به بی‌ثباتی در مناطق سالم شود. اوبر برای مقابله با این مشکل، از تکنیک forced shard allocation awareness استفاده کرده است.

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

حفظ Quorum با معماری 5 گره مدیریتی

برای افزایش تاب‌آوری، اوبر به جای 3 گره مدیر کلاستر معمول، از 5 گره استفاده می‌کند. این پیکربندی با قابلیت cluster.auto_shrink_voting_configuration اپنسرچ کار می‌کند. در سناریوی یک شکست منطقه‌ای، حداکثر 2 گره مدیر از دست می‌روند و 3 گره باقی می‌مانند. سیستم به‌طور خودکار پیکربندی رأی‌گیری را به آن 3 گره کاهش می‌دهد و با یک quorum دو از سه، یک primary جدید انتخاب می‌شود. حتی اگر بعد از آن یک گره دیگر نیز از کار بیفتد، 2 گره باقی‌مانده همچنان quorum را حفظ کرده و کلاستر قابل نوشتن باقی می‌ماند. این سطح از تاب‌آوری با معماری استاندارد 3 گره‌ای امکان‌پذیر نیست.

معماری 5 گره مدیریتی اوبر برای حفظ quorum در شرایط بحرانی
معماری 5 گره مدیریتی اوبر برای حفظ quorum در شرایط بحرانی

نتایج چشمگیر و درس‌های عمومی

اوبر گزارش می‌دهد که پیاده‌سازی انتزاع IG، مشکلات مربوط به حالت زرد و تخصیص shard را به‌طور کامل برطرف کرده است. اکنون تخصیص shard 100% است و سلامت کلاستر به طور مداوم «سبز» باقی می‌ماند. همچنین مسائلی مانند disk skew و گره‌های داغ که ناشی از عدم تقارن مناطق بودند، به کلی از بین رفته‌اند. این روش برای تمام کلاسترهای OpenSearch و Elasticsearch رده Tier 3 و بالاتر در اوبر کار می‌کند و نیازی به موتور جستجوی سفارشی یا نسخه fork شده ندارد.

نکته مهم این است که مهندسان سایر سازمان‌ها نیز می‌توانند این الگوی forced-awareness را بدون نیاز به ابزارهای اختصاصی اوبر (مانند Odin) پیاده‌سازی کنند. الزامات کلیدی عبارتند از:

  • توزیع یکنواخت گره‌ها در یک مجموعه ثابت و به‌صراحت اعلام‌شده از مقادیر ویژگی awareness
  • حداقل 3 نسخه shard که یک‌به‌یک به دامنه‌های شکست نگاشت شده‌اند
  • تعداد فردی از گره‌های مدیر کلاستر (5 به جای 3) با ویژگی auto-shrink voting فعال
الگوی forced-awareness اوبر برای کلاسترهای OpenSearch
الگوی forced-awareness اوبر برای کلاسترهای OpenSearch

جمع‌بندی: یک روند صنعتی

روش اوبر نشان‌دهنده یک روند گسترده‌تر در صنعت فناوری است: تعبیه‌سازی آگاهی از دامنه شکست (failure-domain awareness) در لایه داده به جای تکیه صرف بر failover در سطح زیرساخت. اوبر پیش از این نیز از یک مدل مشابه گروه‌های ایزوله برای Apache Pinot استفاده کرده بود. این رویکرد، استاندارد جدیدی برای ساخت سرویس‌های داده‌ای مقاوم و قابل اعتماد در ابر تعریف می‌کند.

برای مطالعه بیشتر در مورد معماری OpenSearch و Elasticsearch، می‌توانید به مستندات رسمی OpenSearch و Elasticsearch مراجعه کنید.