‏Continuity؛ راهی که کرسر برای میزبانی Git انتخاب کرد

میزبانی مخزن Git در مقیاس بزرگ سخته و ریشه‌ش تو خود طراحی Gitه. همه‌ی داده‌ها توی packfile ذخیره می‌شن، یعنی فایل‌های باینری فشرده‌ای که آبجکت‌ها اغلب به‌شکل delta روی همدیگه توشون چیده شدن، و پروتکل شبکه هم چیزی جز packfile قبول نمی‌کنه. نویسنده می‌گه همین باعث می‌شه هر عملیات ساده‌ی Git به یه پرش تصادفی روی گیگابایت‌ها داده تبدیل بشه، و این الگوی خوندن با فایل‌سیستم شبکه‌ای اصلاً جور درنمیاد.

تو این مقاله اومده که گیت‌هاب اول سراغ توزیع فایل‌سیستم رفت، از NFS تا GFS و DRBD، و همه‌شون به دیوار خوردن. چیزی که موند Spokes بود که از ۲۰۱۳ عملاً استاندارد صنعت شده: مخزن‌ها به‌شکل مخزن معمولی Git روی NVMe محلی می‌مونن، چند کپی ازشون نگه داشته می‌شه و هر push با اجماع سه‌فازی یا 3PC بین رپلیکاها هماهنگ می‌شه. packfile موازی پخش می‌شه و فقط reference transaction که کوچیکه از اجماع رد می‌شه.

به گفتهٔ نویسنده ضعف اصلی Spokes همون 3PCه. تأخیر هر مرحله به کندترین سرور کلاستر گره خورده، پس هرچی رپلیکا اضافه کنی throughput پوش بدتر می‌شه. برای مونوریپوهای بزرگ امروزی سه رپلیکا کمه، و برای میلیون‌ها مخزن ریزی که ایجنت‌ها می‌سازن سه رپلیکا زیادیه. مشکل دوم اینم هست که چون مخزن روی دیسک منبع حقیقته، هر کپی حکم pet رو داره: جدول مسیریابی، چک‌سام دائمی و جاب تعمیر می‌خواد.

Continuity منبع حقیقت رو از دیسک برمی‌داره و می‌ذاره روی یه write-ahead log توی S3. هر push به‌شکل یه آبجکت جدا آپلود می‌شه و تا کامل persist نشه اصلاً ack نمی‌گیره. انتشارش هم با یه compare-and-swap اتمیک روی فایل ایندکس WAL انجام می‌شه، پس همه‌ی پوش‌ها linearizable می‌مونن. مخزن روی NVMe فقط یه کش گرمه و اگه روی دیسک نبود، دوباره از WAL ساخته می‌شه.

چون state ماندگاری نمونده، نه جدول مسیریابی لازمه نه دیتابیس رابطه‌ای نه انتخاب primary؛ مسیر مخزن با rendezvous hashing حدس زده می‌شه و هر سروری می‌تونه primary باشه. رپلیکاها با گاسیپ روی UDP خبردار می‌شن و گم‌شدن بسته مهم نیست، چون هر رپلیکا قبل از سرو کردن یه GET شرطی با ETag به S3 می‌زنه و جواب 304 یعنی به‌روزه.

نکات کلیدی:

• packfile هم واحد ذخیره‌سازی Gitه هم واحد انتقال شبکه، و همین سقف مقیاس‌پذیری میزبانی رو تعیین می‌کنه
• Spokes از حدود ۲۰۱۳ با 3PC و سه رپلیکا کار می‌کنه، ولی تأخیر هر مرحله به کندترین نود بنده
• توی Continuity منبع حقیقت یه write-ahead log روی S3ـه و مخزن روی دیسک فقط کش گرمه
• تست فشار تا ۱۰۰ رپلیکا مقیاس‌پذیری خطی برای خوندن نشون داده، بدون افت throughput پوش
• ingest حدود ۱۲۰ پوش در ثانیه روی S3 Standard و بیش از ۳۰۰ پوش در ثانیه روی S3 Express One Zone بوده
• compaction فقط روی primary انجام می‌شه و بقیه پک فشرده‌شده رو از S3 می‌گیرن، یعنی پهنای باند می‌دن و CPU می‌خرن