تحلیل جیپسن روی اورکست کانداکتور: بررسی رفتار توزیع‌شده و خطاهای همگام‌سازی

مقدمه و زمینه

ابزارهای ارکستراسیون ورک‌فلو نقش کلیدی در معماری‌های مدرن نرم‌افزاری ایفا می‌کنند. این سیستم‌ها وظیفه اجرای محاسبات متشکل از تسک‌های کوچک، مدیریت حالت (State)، و هدایت ورک‌فلوها تا رسیدن به نقطه پایان را بر عهده دارند. Conductor یک سیستم ارکستراسیون ورک‌فلو است که نخستین بار توسط Netflix توسعه یافت و در سال ۲۰۱۶ متن‌باز شد. نسخه متن‌باز آن یعنی Conductor OSS اکنون توسط بنیان Conductor و شرکت Orkes رهبری می‌شود. شرکت Orkes همچنین نسخه تجاری و میزبانی‌شده‌ای به نام Orkes Conductor ارائه می‌دهد که تحلیل امنیتی و استقامتی اخیر Jepsen روی نسخه ۵.۳.۲ و نسخه‌های نزدیک به آن متمرکز بر همین محصول است.

معماری و تضمین‌ها

سیستم Conductor از اجزای اصلی زیر تشکیل شده است:

• سرورهای Conductor: فرآیندهای بدون حالت (Stateless) برای مدیریت ورک‌فلوها و زمان‌بندی.
• پایگاه داده: مانند Postgres برای ذخیره تعاریف، وضعیت اجرا و نتایج تسک‌ها.
• صف پیام (Queue): معمولاً Redis برای ارسال کارها به فرآیندها و ذخیره وضعیت‌های موقت.
• استخرهایWorker: تسک‌های استاندارد داخلی و تسک‌های سفارشی که توسط توسعه‌دهندگان نوشته می‌شوند.

این سیستم تضمین می‌کند که پیام‌ها «حداقل یک‌بار» (At-least-once) تحویل داده شوند و ورک‌فلوها در نهایت به یکی از وضعیت‌های پایانی (مانند COMPLETED یا FAILED) برسند.

جزئیات فنی و نتایج تست‌های جیپسن

تیم Jepsen با استفاده از هنس‌تست اختصاصی خود و SDK جاوا، نسخه‌های ۵.۳.۲، ۵.۴.۰ و ۵.۵.۰ را روی خوشه‌هایی شامل Postgres و Redis زیر تیغ جراحی بردند. یافته‌های کلیدی این ارزیابی شامل موارد زیر است:

• اجرای هم‌زمان تسک‌ها (#1): در کلاستر کاملاً سالم و عادی، گاهی یک تسک واحد برای یک ورک‌فلو روی دو Worker مختلف به صورت هم‌زمان اجرا شد. به دلیل ذات شبکه‌های توزیع‌شده، قفل‌گذاری توزیع‌شده می‌تواند میزان این اتفاق را کاهش دهد اما نمی‌تواند آن را کاملاً حذف کند. باگ موجود در فرآیند Sweeper (که تسک‌های متوقف‌شده را مجدداً وارد صف می‌کند) نیز به این مشکل دامن می‌زد که البته در نسخه ۵.۵.۶ برطرف شد.
• توقف پیش از اجرا (#2): در نسخه ۵.۳.۲ با استفاده از Postgres و Redis، گاهی تعدادی از ورک‌فلوها پیش از اجرای تسک متوقف (Stall) می‌شدند. وضعیت به گونه‌ای بود که تسک در دیتابیس به صورت IN_PROGRESS دیده می‌شد اما متد execute() روی Worker هرگز فراخوانی نمی‌گردد. این حالت تا زمان سررسید تایم‌اوت پاسخ ادامه داشت و سپس تسک مجدداً زمان‌بندی می‌شد.
• شناسه‌های نال ورک‌فلو (#3): در شرایط خاص مانند قطع شدن Redis، کلاینت جاوا گاهی در پاسخ به متد startWorkflow() مقدار null برمی‌گرداند.
• خطای سینتکس (#4): در کلاسترهای کاملاً سالم و بدون تزریق خطای خاصی، گاهی درخواست‌های استاندارد startWorkflow با خطای نامعتبر مواجه می‌شدند.

چرا این بررسی برای مهندسان اهمیت دارد؟

برای تیم‌هایی که از Conductor در سیستم‌های مقیاس‌پذیر و حیاتی (Mission-critical) استفاده می‌کنند، آگاهی از این مرزهای رفتاری بسیار ضروری است. فرض اینکه تسک‌ها به هیچ وجه به صورت موازی اجرا نمی‌شوند یا اینکه صف‌ها بدون تأخیر عمل می‌کنند، می‌تواند منجر به باگ‌های پنهان در لایه بیزینس شود. این گزارش نشان می‌دهد که چگونه سیستم‌های توزیع‌شده در مواجهه با قطعی‌های شبکه یا توقف پراکنده گره‌ها رفتار می‌کنند و چرا مکانیزم‌های Idempotency در طراحی تسک‌ها نباید فراموش شوند.