Cloudflare memangkas jeda antara perubahan DNS dan data yang siap dibaca server otoritatif menjadi separuh, sekaligus menurunkan puncak pemakaian memori sebesar 85 persen. Caranya bukan menambah mesin, tapi berhenti membangun ulang seluruh zona setiap kali satu pengaturan berubah. Pipeline mereka kini menerima sekitar 700 perubahan record per detik, hampir tiga kali lipat angka 250 pada 2022, dan sebagian zona sudah melewati 20 juta record. Rincian arsitekturnya dipublikasikan tim engineering Cloudflare pada 2 November 2026.
TL;DR
- Puncak memori pipeline turun 85 persen karena zona besar tidak lagi dibangun penuh untuk perubahan pengaturan.
- Waktu dari perubahan DNS sampai datanya tertulis di Quicksilver dipotong separuh.
- Pada 2022 tercatat per-record build 150 kali lebih cepat dari full build; di zona uji 1 juta record selisihnya 4.250 kali.
- Planner baru sengaja memilih full build ketika event tidak cukup jelas, jadi ketidakpastian tidak dipakai untuk mengurangi kerja.
- Beban masuk hari ini sekitar 700 perubahan record per detik ditambah kira-kira 100 event pengaturan per detik.
Apa itu build di pipeline DNS Cloudflare?
Build adalah proses membaca kondisi database sebuah zona, mengubahnya menjadi format yang dipakai server DNS otoritatif di edge, lalu menuliskan selisihnya ke Quicksilver. Setiap event memulai stopwatch: berapa lama perubahan pelanggan berubah menjadi data yang bisa dilayani di ratusan lokasi jaringan.
Alurnya berlapis. Pelanggan mengubah record lewat API atau dashboard, atau layanan Cloudflare lain mengubah pengaturan zona. Perubahan itu masuk database, lalu sistem memproduksi event Kafka. DNS Kafka Aggregator menggabungkan event dari beberapa topik dan mengirimkannya ke Zone Builder. Zone Builder membaca data zona yang dibutuhkan, menerjemahkannya menjadi key yang dipahami server otoritatif, membandingkannya dengan isi Quicksilver, dan hanya menuliskan yang berubah.
Dokumentasi API DNS tersedia publik di Cloudflare Developer Docs, sementara format zona dan record yang jadi acuan semua implementasi DNS dijelaskan di RFC 1034. Yang tidak dipublikasikan adalah mesin internalnya, dan justru bagian itu yang jadi pelajaran.
Kenapa full build berhenti skalanya?
Full build punya satu kelebihan besar: ia tidak perlu tahu kenapa sebuah zona berubah. Ia cukup membangun ulang keadaan yang diinginkan dari kondisi database saat itu, sehingga tidak ada kasus tepi yang perlu ditebak.
Masalahnya ada di biaya baca. Full build membaca zona beserta seluruh pengaturannya, membaca setiap record, mengubah semuanya jadi key Quicksilver, lalu membandingkan dengan isi penyimpanan. Penulisan akhirnya memang hanya berisi key yang berubah, tapi proses membaca, meng-encode, dan membandingkan tetap menyentuh seluruh record. Seluruh zona juga harus muat di memori selama proses berjalan.
Untuk zona berisi puluhan juta record, syarat terakhir itu tidak lagi masuk akal. Menambah RAM per worker bukan penyelesaian, karena yang dibutuhkan adalah membatasi jumlah data yang diproses, bukan memperbesar ruang tunggu. Di titik itu pilihannya menyempit: bangun lebih sedikit, atau bangun lebih sering dengan biaya yang sama besar.
| Aspek | Full build | Targeted build |
|---|
| Data yang dibaca | Seluruh record dan pengaturan zona | Hanya nama dan bagian yang mungkin terpengaruh |
| Kebutuhan memori | Seluruh zona harus muat | Sebagian zona saja |
| Ketergantungan pada isi event | Tidak perlu tahu penyebab perubahan | Wajib tahu field dan nilai yang berubah |
| Risiko utama | Boros kapasitas pada zona besar | Data basi kalau perencanaan terlalu sempit |
| Perilaku saat event ambigu | Tidak relevan | Jatuh kembali ke full build |
Apa yang membuat targeted build sulit dibuktikan aman?
Yang sulit bukan menulis plannernya, tapi membuktikan bahwa pilihan yang lebih kecil tetap benar. Event record biasanya jelas menyebut apa yang berubah. Event pengaturan zona tidak: ia bisa datang dari banyak produk Cloudflare, tidak selalu menjelaskan alasannya, dan bisa mengubah data yang dipakai bersama oleh beberapa zona dengan nama yang sama.
Contoh yang dipakai di posting itu adalah Universal SSL. Menyalakan atau mematikan fitur tersebut mengubah metadata dan bisa mengubah record CAA di apex zona, yaitu domain telanjang seperti contoh.com. Record CAA memberi tahu otoritas sertifikat apakah mereka boleh menerbitkan sertifikat untuk domain tersebut. Kalau planner tidak tahu bahwa perubahan satu toggle menyentuh CAA, data di edge bisa tertinggal.
Karena itu setiap targeted build harus menjawab tiga pertanyaan sebelum dijalankan: nama DNS mana yang mungkin berubah, apakah metadata bersama atau daftar zona terbit bisa berubah, dan keadaan lama mana yang harus dihapus dari Quicksilver. Ketiga jawaban itu yang menentukan batas pekerjaan, bukan perkiraan.
Berapa besar dampaknya pada latensi dan memori?
Dampaknya terukur di dua sisi. Puncak pemakaian memori turun 85 persen, dan sisa kapasitas itu dipakai untuk memperpendek jeda yang selama ini disimpan demi ketahanan pipeline. Hasil akhirnya, waktu dari perubahan DNS sampai datanya tertulis ke Quicksilver terpangkas separuh.
Angka pembanding dari 2022 memberi konteks kenapa arah ini masuk akal. Saat itu per-record build tercatat rata-rata 150 kali lebih cepat daripada full build, dan pada zona uji berisi satu juta record selisihnya mencapai 4.250 kali. Artinya bahkan sebelum masalah memori muncul, membaca satu record jauh lebih murah daripada membaca satu zona. Yang belum diselesaikan waktu itu adalah perpanjangan logikanya ke pengaturan zona, dan butuh beberapa tahun untuk membuktikan kapan pendekatan itu aman.
Perlu dicatat, ketiga angka itu tidak sebanding. 150 kali adalah rata-rata pada 2022, 4.250 kali adalah hasil satu zona uji berukuran satu juta record, dan 85 persen adalah penurunan puncak memori setelah planner baru dipasang. Membandingkannya sebagai satu metrik tunggal akan menyesatkan.
Kapan tim tetap membangun zona penuh?
Setiap kali kejelasan event tidak cukup. Kalau produsen event hanya memperbarui timestamp untuk mengatakan "ada yang berubah di zona ini", planner tidak bisa membedakan antara pembaruan administratif yang tidak berbahaya dan perubahan data sungguhan di tempat lain. Dalam kondisi itu, full build tetap dijalankan.
Aturan yang sama berlaku untuk event tak dikenal, detail yang hilang, dan perubahan apa pun yang berpotensi menyentuh record di seluruh zona. Prinsipnya ditulis eksplisit: planner tidak pernah mengubah ketidakpastian menjadi lebih sedikit kerja. Ini pembalikan dari kebiasaan optimasi yang biasanya memilih asumsi paling murah.
Konsekuensinya, biaya sistem jadi tidak seragam. Sebagian besar perubahan selesai dengan pekerjaan kecil, sebagian kecil lainnya tetap mahal. Bagi tim yang menjual janji propagasi cepat, sebaran itu lebih aman daripada rata-rata cepat yang sesekali menghasilkan data salah.
Bagian mana yang bisa ditiru tim kecil?
Pelajaran paling mudah dipakai bukan soal Quicksilver, tapi soal kontrak event. Selama produsen event hanya bilang "ada perubahan", konsumennya tidak punya pilihan selain membaca semuanya. Begitu event menyebut field, nilai lama, dan nilai baru, konsumen bisa membatasi diri pada bagian yang relevan.
Pelajaran kedua adalah penggabungan kerja. Scheduler Cloudflare menggabungkan pekerjaan untuk zona yang sama, sehingga beberapa perubahan berdekatan tidak memicu beberapa build terpisah. Untuk sistem yang menerima event dari Kafka, ini penting karena semantik pengiriman yang umum adalah at-least-once: pesan bisa datang dua kali, dan penggabungan harus dilakukan tanpa kehilangan satu pun.
Pelajaran ketiga adalah menyimpan jalur mundur. Targeted build tetap punya full build sebagai jaring pengaman, dan justru karena jaring itu ada, optimasi boleh agresif. Sistem yang menghapus jalur lambat sepenuhnya kehilangan cara memperbaiki diri saat asumsinya salah.
Pelajaran keempat menyangkut pengukuran. Yang dilaporkan Cloudflare bukan rata-rata, tapi puncak memori dan waktu tunggu yang sengaja dikorbankan untuk ketahanan. Metrik puncak lebih jujur untuk sistem yang gagal karena kehabisan memori, karena rata-rata bisa terlihat sehat sementara ekornya sudah menabrak dinding.
Terakhir, urutan pengerjaannya layak ditiru: kumpulkan dulu bukti bahwa perubahan kecil aman, baru kurangi pekerjaan. Membalik urutannya, yaitu memangkas pekerjaan lalu berharap tidak ada yang rusak, adalah cara termurah untuk menghasilkan insiden DNS yang sulit dilacak karena cache di mana-mana.
Apa arti penurunan 85 persen bagi biaya infrastruktur?
Yang turun bukan tagihan listrik, tapi kebutuhan kapasitas per worker. Kalau satu proses sebelumnya harus menampung seluruh zona di memori, kini ia hanya menampung bagian yang direncanakan berubah. Pada zona berisi puluhan juta record, selisih itu menentukan apakah pekerjaan bisa berjalan pada instance yang ada atau menuntut instance yang lebih besar.
Ada efek berantai yang jarang dibahas. Memori puncak menentukan seberapa agresif sebuah sistem boleh menggabungkan pekerjaan. Kalau satu build sudah menghabiskan sebagian besar memori mesin, menggabungkan dua build berarti risiko kehabisan memori. Setelah puncaknya turun 85 persen, ruang untuk menggabungkan pekerjaan terbuka, dan dari situ waktu tunggu bisa dipendekkan tanpa menambah mesin.
Efek lain muncul di jalur pemulihan. Pipeline yang menyimpan jeda untuk ketahanan biasanya menahan perubahan lebih lama dari yang sebenarnya dibutuhkan, semata karena kapasitas tidak cukup untuk memproses lebih cepat. Begitu kapasitas lengang, jeda itu bisa dipendekkan. Inilah kenapa angka 85 persen dan "separuh waktu" muncul di posting yang sama: keduanya berasal dari satu perubahan arsitektur.
FAQ
Apakah ini fitur baru yang bisa dipakai pelanggan?
Bukan. Ini perubahan internal pada pipeline propagasi DNS Cloudflare, bukan tombol atau opsi baru di dashboard. Pelanggan hanya merasakan efeknya berupa waktu propagasi yang lebih pendek.
Berapa ukuran zona terbesar yang disebut?
Posting itu menyebut sebagian zona kini berisi lebih dari 20 juta record, dan perkiraan ke depan menuju ratusan juta record. Angka itu yang membuat full build kehabisan ruang memori.
Apakah 150 kali dan 4.250 kali mengukur hal yang sama?
Tidak. 150 kali adalah rata-rata per-record build dibanding full build pada 2022. 4.250 kali adalah hasil pada satu zona uji berisi satu juta record, jadi bukan angka umum.
Apa itu Quicksilver?
Penyimpanan key-value terdistribusi milik Cloudflare yang menyimpan data siap saji untuk server otoritatif di edge. Tidak ada dokumentasi publik soal detail internalnya, dan artikel ini tidak mengklaim lebih dari yang tertulis.
Apakah pendekatan ini berisiko meninggalkan data basi?
Risiko itu justru yang dijaga. Kalau event tidak cukup jelas, sistem kembali ke full build, sehingga data basi hanya mungkin terjadi bila perencanaan salah menilai cakupan perubahan.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬