پردازش میلیونها سند برای آموزش یک مدل هوش مصنوعی، چالشی است که هر مهندس نرمافزاریِ کرکرهای را به استفاده از همان الگوهای آشنا سوق میدهد: یک سرویس دانلود، یک صف پیام، چند هماهنگکننده پراکنده و یک مدل AI در انتهای خط. اما وقتی یکی از این حلقهها میشکند، کل زنجیره فلج میشود و پیدا کردن نقطه شکست، خودش یک کابوس مستقل میشود.
جرمی ادبرگ، مهندس ارشد سابق Netflix و Reddit، در ارائه اخیر خود طرحی متفاوت را روی میز گذاشت: بهجای پراکنده کردن وضعیت و گردشکارها در دهها سرویس مختلف، پایگاه دادهای که از قبل دارید را در مرکز معماری قرار دهید و تمام state و workflow را در همانجا مدیریت کنید.
چرا راهحلهای فعلی میشکنند؟
بیشتر توسعهدهندگان برای مقیاسپذیری به سمت ابزارهایی مانند RabbitMQ یا Kafka میروند. Kafka با استریمهای متعدد و قابلیت شاردبندی، انعطافپذیری قابلتوجهی ارائه میدهد، اما هیچکدام از این ابزارها مشکل بنیادین را حل نمیکنند: عدم شفافیت در وضعیت گردشکار.
وقتی یک آیتم در صف شکست میخورد، چه اتفاقی میافتد؟ کدام مرحله دقیقاً خراب شده؟ چند بار تلاش مجدد انجام شده است؟ برای پاسخ به این سوالات، یا باید حجم زیادی کد اضافی بنویسید تا لاگها را جداگانه ذخیره کنید، یا باید چشمبسته پیش بروید و امیدوار باشید سیستم خودش را بازیابی کند. در دنیایی که هوش مصنوعی در حال تصمیمگیریهای واقعی روی انسانهای واقعی است، این سطح از عدم قطعیت قابلپذیرش نیست.
هزینه پنهان جابهجایی دادهها
گرانترین عملیات در هر سیستم توزیعشده، انتقال داده بین سرویسهاست. در معماریهای رایج میکروسرویسی، دادهها مدام بین هماهنگکنندهها، صفها، پایگاههای داده متعدد و مدلهای AI در حال پرواز هستند. هر بار که دادهای از یک سرویس به سرویس دیگر منتقل میشود، هزینه شبکه، تأخیر و احتمال خطا افزایش مییابد.
جرمی ادبرگ بهدرستی اشاره میکند که وقتی شما چندین هماهنگکننده و چندین پایگاه داده دارید، دادهها در همهجا پراکندهاند و مدیریت یکپارچگی آنها به یک کابوس عملیاتی تبدیل میشود. راهحل او ساده اما بنیادی است: دادهها را در همان جایی که تولید میشوند نگه دارید و گردشکار را به دادهها بیاورید.
پایگاه داده بهعنوان سیستمعامل گردشکار
ایده مرکزی این معماری، پروژهای به نام DBOS است که توسط کیان، دانشجوی سابق کارشناسی ارشد دانشگاه استنفورد، توسعه یافته است. مفهوم DBOS پایگاه داده را از یک انبار داده منفعل به یک پلتفرم اجرای گردشکار تبدیل میکند.
در این رویکرد، هر مرحله از گردشکار بهصورت یک تراکنش پایگاه داده ثبت میشود. این یعنی:
- قابلیت مشاهده کامل: هر مرحله، هر شکست و هر تلاش مجدد بهصورت شفاف در پایگاه داده ثبت میشود و نیاز به ابزارهای مانیتورینگ جداگانه را از بین میبرد.
- اجرای دقیقاً یکباره (Exactly-Once Execution): چون هر مرحله درون یک تراکنش اجرا میشود، تکرار یا گم شدن یک مرحله بهطور ساختاری غیرممکن میشود.
- بازیابی خودکار: اگر سرویسی از کار بیفتد، بازیابی از همان نقطهای که متوقف شده بود از سر گرفته میشود، بدون نیاز به منطق بازیابی پیچیده.
- حذف لایههای واسط: نیازی به RabbitMQ، Kafka یا هماهنگکنندههای جداگانه نیست؛ پایگاه داده خودش این نقشها را ایفا میکند.
چرا این معماری نباید کار کند؟ (و چرا میکند)
نخستین واکنش بسیاری از مهندسان به این ایده، شکاکیت است. پایگاه دادهها برای ذخیره داده طراحی شدهاند، نه برای اجرای منطق برنامه. اما ادبرگ استدلال میکند که دقیقاً همین نگاه محدودکننده است که ما را در تله معماریهای پیچیده نگه داشته است.
پایگاه دادههای مدرن — بهویژه PostgreSQL و سیستمهای سازگار با ACID — سالهاست که قابلیتهایی فراتر از ذخیرهسازی ساده ارائه میدهند: تriggers، stored procedures، قابلیت replication و پشتیبانی از تراکنشهای توزیعشده. DBOS این قابلیتها را در یک لایه abstraction منسجم گرد میآورد تا گردشکار را به یک شهروند درجهیک در پایگاه داده تبدیل کند.
چالش جهانی: صبر کاهشیافته کاربران
فشار اصلی برای تغییر معماری از سوی کاربران نهایی میآید. تحمل کندی، پاسخهای اشتباه یا قطعی سرویس بهشدت کاهش یافته است. وقتی یک پردازش پرداختی شکست میخورد یا یک مدل AI پاسخ اشتباه میدهد، کاربر فقط یک اخطار فنی نمیبیند؛ او اعتماد خود را به کل پلتفرم از دست میدهد.
مسئله اجرای دقیقاً یکباره در این contexto اهمیت ویژهای پیدا میکند. اگر یک گردشکار پردازش پرداخت را دو بار اجرا کند، کاربر دو بار هزینه میکند. اگر اجرا نشود، تراکنش گم میشود. در هر دو حالت، خسارت قابلجبران نیست و راهحلهای سنتی صفبندی بهسختی میتوانند این تضمین را ارائه دهند.
آینده معماری مبتنی بر داده
پروژه DBOS نشان میدهد که میتوان پیچیدگی سیستمهای توزیعشده را بهجای اضافه کردن لایههای هماهنگی بیشتر، با بازگشت به یک ابزار قابلاعتماد و آشنا کاهش داد. همانطور که ادبرگ توضیح میدهد، هدف غایی این نیست که پایگاه داده همهچیز را انجام دهد؛ بلکه این است که جابهجایی غیرضروری دادهها را به حداقل برسانیم و وضعیت سیستم را در یک نقطه شفاف و قابلاتکا نگه داریم.
در سالهای پیش رو، با گسترش استفاده از AI در پردازشهای حساس، تقاضا برای گردشکارهای قابلاعتماد و قابلمشاهده فقط افزایش مییابد. معماریای که امروز عجیب بهنظر میرسد، شاید فردا استاندارد جدید صنعت باشد.
