‏turbopuffer: هر روز ده‌ها آپدیت دیتابیس

تو بلاگ turbopuffer، تارون پوتولاپاتی می‌گه تیمشون روزی ده‌ها آپدیت دیتابیس رو روی کل ناوگانشون می‌فرسته، خیلی وقت‌ها همون روزی که PR باز شده. الان بیشتر از ۱۰۰ کلاستر دارن، دو برابر شش ماه پیش، تو سه مدل استقرار: SaaS عمومی، تک‌مستاجر، و BYOC (یعنی نسخه‌ای که کامل داخل حساب ابری خود مشتری بالا میاد).

سخت‌ترین بخش همین BYOC هست. اون کلاسترها تو حساب ابری مشتری زندگی می‌کنن و turbopuffer به‌صورت پیش‌فرض هیچ کلیدی ازشون نداره، پس نه SSH می‌زنه نه kubectl. بعضی شرکت‌ها اینو با گرفتن یه حساب ابری اختصاصی و دسترسی ادمین دائم حل می‌کنن، ولی نویسنده می‌گه هر حساب اضافه یعنی سربار امنیت و انطباق و صورت‌حساب. برای همین یه کنترل‌پلین واحد برای هر سه مدل ساختن.

راه‌حل، کوبرنتیز ساده و معمولیه. روی هر کلاستر یه ایجنت محلی می‌چرخه و یه CRD به اسم TurbopufferOperation همه‌ی نوع عملیات‌ها رو از upgrade تا tidy مدل می‌کنه. یه کنترلر با حلقه‌ی reconciliation (یعنی مدام وضعیت فعلی رو با وضعیت مطلوب می‌سنجه) هر منبع رو تا حالت نهایی جلو می‌بره و وضعیتش هم تو etcd خود کلاستر می‌مونه. یعنی اگه ارتباط با مرکز قطع بشه، کلاستر باز هم کارشو تموم می‌کنه.

نویسنده توضیح می‌ده چرا سراغ Terraform و Helm نرفتن. اول اینکه تیم DevOps جدا ندارن و نمی‌خوان مهندس دیتابیس مجبور بشه با ابزار IaC سروکله بزنه. دوم اینکه terraform apply باید از زیرساخت خودشون روی زیرساخت مشتری اجرا بشه که تو BYOC شدنی نیست، و GitOps هم سوال مالکیت ریپو رو پیش می‌کشه. مهم‌تر از همه، کارهایی مثل reindex یه namespace یا فشرده‌کردن WAL شکل صف کار دارن نه حالت مطلوب.

ایجنت هر کلاستر با یه API key مخصوص خودش مرتب GET می‌زنه و عملیات‌های در انتظارشو می‌گیره، بعد وضعیت‌ها رو POST می‌کنه به API server که پشتش MySQL روی PlanetScale نشسته. چون اسم هر CR همون ID عملیاته، تکرار درخواست چیزی رو دوباره نمی‌سازه. جلوی این API یه داشبورد Remix/React با الهام از Linear نشسته که همه‌چیزش هات‌کی داره و وضعیت هر عملیات هم تو یه ترد Slack پخش می‌شه. تازگی هم fleet operation اضافه شده که رول‌اوت رو موج‌به‌موج جلو می‌بره و با اولین مانیتور قرمز متوقف می‌شه.

نکات کلیدی:

• بیشتر از ۱۰۰ کلاستر تو سه مدل استقرار (SaaS عمومی، تک‌مستاجر، BYOC)، دو برابر شش ماه پیش
• همه‌ی عملیات‌ها با یه CRD واحد به اسم TurbopufferOperation مدل می‌شن
• وضعیت عملیات تو etcd خود کلاستر می‌مونه، پس قطعی کنترل‌پلین کلاستر رو زمین نمی‌زنه
• کنترل‌پلین مرکزی یه API server با MySQL روی PlanetScale هست و انتقال‌های وضعیت رو append-only نگه می‌داره
• fleet controller رول‌اوت رو موج‌به‌موج می‌بره جلو و با اولین مانیتور قرمز متوقف می‌شه