‏Cloudflare دیگه برای هر تغییر DNS کل زون رو نمی‌سازه

تو بلاگ Cloudflare اومده که بخش Zone Builder الان حدود ۷۰۰ تغییر رکورد DNS در ثانیه دریافت می‌کنه، تقریباً سه برابر سال ۲۰۲۲. ولی به گفته‌ی نویسنده مشکل تعداد رویدادها نبود؛ مشکل این بود که بعضی رویدادها کل زون (یعنی همه‌ی رکوردها و تنظیمات یه دامنه) رو دوباره می‌ساختن، و بعضی زون‌ها الان بیش از ۲۰ میلیون رکورد دارن. هر build وضعیت دیتابیس رو می‌خونه، به فرمت سرورهای لبه تبدیل می‌کنه و فقط تغییرات رو تو Quicksilver (key-value store توزیع‌شده‌ی Cloudflare) می‌نویسه.

سال ۲۰۲۲ build تک‌رکوردی اضافه شد که به‌طور میانگین ۱۵۰ برابر از build کامل سریع‌تر بود. سختی کار با تنظیمات زون بود: این رویدادها از محصولات مختلف میان، همیشه نمی‌گن چی عوض شده و ممکنه داده‌ای رو تغییر بدن که چندتا زون هم‌اسم با هم شریکن. مثلاً روشن کردن Universal SSL می‌تونه رکوردهای CAA رو روی apex (یعنی خود دامنه مثل example.com) عوض کنه. اگه کار کمتر از لازم انجام بشه، داده‌ی کهنه یا غلط روی لبه می‌مونه.

راه‌حل یه planner هدفمند با پنج نوع build هست: فقط رکوردهای یه اسم خاص، اسم خاص به‌اضافه‌ی metadata، apex به‌اضافه‌ی metadata، purge (حذف زونی که نباید منتشر بشه) و build کامل. قانونش ساده‌ست: هر کلیدی که build هدفمند می‌نویسه باید بایت‌به‌بایت با خروجی build کامل یکی باشه، وگرنه build کامل انجام می‌شه. planner هیچ‌وقت ابهام رو به کار کمتر تبدیل نمی‌کنه. فقط برای زون‌های خیلی بزرگ که اصلاً تو حافظه جا نمی‌شن، build کامل انجام نمی‌شه و به‌جاش apex، metadata و اسم‌های درگیر ساخته می‌شن.

برنامه‌ریزی دو بار انجام می‌شه. یه بار از روی رویداد، و یه بار درست قبل از اجرا با یه snapshot تازه از دیتابیس. چون Kafka و replicaهای دیتابیس جدا از هم جلو می‌رن، رویداد ممکنه زودتر از تغییر دیتابیس برسه؛ برای همین replicaیی که عقب افتاده رد می‌شه. دو scheduler قدیمی هم با یه scheduler یکپارچه عوض شدن که کارهای یه زون رو فقط با اضافه کردن ادغام می‌کنه و با soft commit مطمئن می‌شه هیچ پیام Kafkaیی گم نمی‌شه.

برای انتشار امن، تست‌های هم‌ارزی خروجی build کامل و هدفمند رو بایت‌به‌بایت مقایسه کردن. یه Zone Builder آینه‌ای هم همون جریان Kafka production رو می‌خونه ولی تو یه Quicksilver جدا می‌نویسه و ۲۰ درصد زون‌ها مقایسه می‌شن. rollout هم بر اساس hash اسم زون انجام شد تا زون‌های هم‌اسم همیشه رو یه scheduler بمونن.

نتیجه: ۹۲.۹۵ درصد buildها دیگه کل زون رو نمی‌سازن. p99 تأخیر از ۱۴.۶ دقیقه به ۱.۲۱ دقیقه رسید، حافظه‌ی میانگین از 49 GiB به 7 GiB و اوج اون از 79 GiB به 12 GiB افتاد. این فضای خالی اجازه داد فاصله‌ی rebuild و صبر برای replicaها کوتاه بشه، و میانه‌ی تأخیر از ۷.۷ به ۳.۳ ثانیه رسید. نویسنده می‌گه حذف کامل build کامل نه واقع‌بینانه‌ست نه لازم، چون زون تازه‌منتشرشده به هر حال همه‌ی رکوردهاش رو لازم داره.

نکات کلیدی:

• Zone Builder حدود ۷۰۰ تغییر رکورد در ثانیه می‌گیره و بعضی زون‌ها بیش از ۲۰ میلیون رکورد دارن.
• planner پنج نوع build داره و خروجی build هدفمند باید بایت‌به‌بایت با build کامل یکی باشه.
• ۹۲.۹۵ درصد buildها دیگه کل زون رو نمی‌سازن و تعداد build کامل حدود ۴۰ درصد کم شد.
• p99 بدترین تأخیر از ۱۴.۶ به ۱.۲۱ دقیقه و میانه از ۷.۷ به ۳.۳ ثانیه رسید.
• حافظه‌ی میانگین از 49 GiB به 7 GiB و اوج از 79 GiB به 12 GiB کم شد.
• یه Zone Builder آینه‌ای با ترافیک production و مقایسه‌ی ۲۰ درصد زون‌ها، قبل از rollout امنیت تغییر رو تأیید کرد.