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

یک پایگاه داده توزیع‌شده نمی‌تواند هم‌زمان تضمین کند که هر خوانش جدیدترین نوشته را دریافت می‌کند و هر درخواست پاسخی بدون خطا می‌گیرد، آن هم وقتی شبکه‌ای که سرورهایش را به هم متصل می‌کند پیام‌ها را گم می‌کند. از آنجا که خرابی‌های شبکه یک اجبار فیزیکی و گریزناپذیرند، مهندسان باید انتخاب کنند که هنگام قطع ارتباط، کدام‌یک از دو ویژگی دیگر را رها کنند. این مرز ریاضیاتی بر تمام اپلیکیشن‌های ابری بزرگ امروزی حاکم است و دیکته می‌کند که آیا یک سیستم باید دقت بی‌نقص را در اولویت قرار دهد یا آپتایم بدون وقفه را.

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

فرمول‌بندی این محدودیت در سال ۲۰۰۰ آغاز شد، زمانی که اریک برور (Eric Brewer)، دانشمند علوم کامپیوتر، آنچه را که اصل CAP می‌نامید در سمپوزیوم اصول محاسبات توزیع‌شده ارائه کرد. برور مطرح کرد که یک ذخیره‌ساز داده توزیع‌شده می‌تواند حداکثر دو مورد از سه تضمین زیر را ارائه دهد: یکپارچگی (Consistency)، در دسترس بودن (Availability) و تحمل قطعی (Partition tolerance). این مفهوم واژگانی را برای مصالحه‌هایی فراهم کرد که مهندسان از قبل در میدان عمل انجام می‌دادند.[1]

دو سال بعد، در سال ۲۰۰۲، پژوهشگرانی به نام‌های ست گیلبرت (Seth Gilbert) و نانسی لینچ (Nancy Lynch) اثبات ریاضیاتی رسمی حدس برور را در نشریه SIGACT News منتشر کردند. اثبات آن‌ها قضیه CAP را از یک قاعده سرانگشتی به یک قانون سخت فیزیکی در علوم کامپیوتر تبدیل کرد. گیلبرت و لینچ با اثبات غیرممکن بودن دستیابی به هر سه تضمین در یک مدل شبکه ناهمگام، معماران پایگاه داده را مجبور کردند تا حالت‌های خرابی سیستم خود را صراحتاً بپذیرند.[2]

از آنجا که قطعی‌های شبکه ناشی از قطع کابل‌ها، پیکربندی اشتباه روترها یا قطعی برق در سیستم‌های مقیاس‌بزرگ اجتناب‌ناپذیرند، تحمل قطعی یک ویژگی اختیاری نیست. این یک واقعیت پایه‌ای است. در نتیجه، انتخاب واقعی پیش روی معماران پایگاه داده، انتخاب دو مورد از سه مورد نیست، بلکه تصمیم‌گیری درباره نحوه رفتار سیستم در زمان وقوع قطعیِ حتمی است. یک سیستم باید یا یکپارچه و دارای تحمل قطعی باشد و در دسترس بودن را فدا کند، یا در دسترس و دارای تحمل قطعی باشد و یکپارچگی را فدا کند.[2]

پایگاه داده Dynamo آمازون، که جزئیات آن در مقاله‌ای جریان‌ساز در سال ۲۰۰۷ شرح داده شد، به‌طور مشهودی مسیر دوم را انتخاب کرد. تیم مهندسی خاطرنشان کرد که حتی کوچک‌ترین قطعی، پیامدهای مالی قابل‌توجهی دارد و به اعتماد مشتری لطمه می‌زند. برای جلوگیری از از کار افتادن سبدهای خرید در هنگام قطعی شبکه، آمازون Dynamo را طوری مهندسی کرد که در دسترس بودن بالایی داشته باشد و توافق‌نامه‌های سطح خدمات با تأخیر صدک ۹۹.۹ را هدف قرار داد.[6]

همان‌طور که نویسندگان Dynamo نوشتند، برای دستیابی به این سطح از در دسترس بودن، Dynamo در سناریوهای خرابی خاصی یکپارچگی را فدا می‌کند. این سیستم نوشتن روی سرورهای ایزوله را می‌پذیرد و برای ادغام داده‌های متناقض پس از ترمیم شبکه، به فرآیندهای پس‌زمینه مانند ساعت‌های برداری و ترمیم خوانش متکی است. این مدل که به عنوان یکپارچگی نهایی شناخته می‌شود، تضمین می‌کند که سیستم همیشه پاسخ خواهد داد، حتی اگر این پاسخ موقتاً به‌روز نباشد.[6]

با این حال، چارچوب‌بندی صفر و یکی قضیه CAP برای توصیف عملیات روزمره پایگاه‌های داده مدرن ناکافی بود. در سال ۲۰۱۲، دنیل آبادی (Daniel Abadi)، دانشمند علوم کامپیوتر دانشگاه ییل، مقاله‌ای در مجله انجمن کامپیوتر IEEE منتشر کرد و استدلال نمود که CAP تنها بخشی از ماجراست. آبادی اشاره کرد که CAP فقط رفتار سیستم را در طول خرابی شبکه توصیف می‌کند و مصالحه‌هایی را که در طول عملیات عادی وجود دارند نادیده می‌گیرد.[3]

آبادی مدل PACELC را معرفی کرد که این قضیه را برای در نظر گرفتن این واقعیت‌های روزمره بسط داد. PACELC بیان می‌کند که اگر یک قطعی (P) وجود داشته باشد، سیستم باید بین در دسترس بودن (A) و یکپارچگی (C) یکی را انتخاب کند؛ در غیر این صورت (E)، زمانی که شبکه به طور عادی کار می‌کند، سیستم باید بین تأخیر (L) و یکپارچگی (C) یکی را انتخاب کند.[3][5]

این مصالحه بین تأخیر و یکپارچگی دیکته می‌کند که حتی بدون خرابی شبکه، همگام‌سازی داده‌ها در سرورهایی که صدها مایل از هم فاصله دارند، نیازمند زمان فیزیکی است. اگر سیستمی نیازمند یکپارچگی بی‌نقص باشد، باید کاربران را مجبور کند تا برای تکمیل این همگام‌سازی منتظر بمانند، که این امر تأخیر پاسخ را افزایش می‌دهد. اگر سیستم سرعت را در اولویت قرار دهد، باید یک نسخه محلی و احتمالاً قدیمی از داده‌ها را برگرداند.[3]

پژوهشگرانی مانند مارتین کلپمن (Martin Kleppmann) از آن زمان نقدهایی بر قضیه CAP منتشر کرده‌اند و در مقاله arXiv سال ۲۰۱۵ استدلال کردند که اتکای صنعت به مخفف CAP اغلب واقعیت‌های ظریف و عملی اجماع توزیع‌شده را پنهان می‌کند. کلپمن خاطرنشان کرد که تعاریف سخت‌گیرانه در دسترس بودن و یکپارچگی که در اثبات سال ۲۰۰۲ استفاده شده‌اند، به‌ندرت با تعاریف منعطف‌تری که مهندسان نرم‌افزار در محیط‌های عملیاتی استفاده می‌کنند، مطابقت دارند.[4]

با وجود این نقدها، این محدودیت فیزیکی بنیادین همچنان پابرجاست. چه یک تیم در حال ساخت یک دفتر کل مالی جهانی باشد که برای جلوگیری از خرج کردن مضاعف نیازمند یکپارچگی سخت‌گیرانه است، و چه در حال ساخت فید شبکه‌های اجتماعی باشد که برای اطمینان از اسکرول بدون وقفه به در دسترس بودن بالا متکی است، سرعت نور و شکنندگی شبکه‌ها یک مصالحه را تحمیل می‌کنند.[7]

تکامل از حدس سال ۲۰۰۰ برور تا مدل PACELC آبادی در سال ۲۰۱۲، نشان‌دهنده بلوغ این رشته است. مهندسی سیستم‌های توزیع‌شده از کشف محدودیت‌های مطلق ریاضیاتی به سمت هدایت طیف پیوسته‌ای از مصالحه‌هایی حرکت کرده است که این محدودیت‌ها بر برنامه‌های کاربردی در دنیای واقعی تحمیل می‌کنند. سوال دیگر این نیست که آیا یک سیستم مصالحه خواهد کرد یا خیر، بلکه دقیقاً این است که کدام مصالحه به بهترین شکل به کاربرانش خدمت می‌کند.[1][3][7]