Cloudflare, hedefli zone build'leriyle DNS build gecikmesini yarıya indirdi ve tepe bellek kullanımını yüzde 85 azalttı

Cloudflare neyi değiştirdi

Cloudflare, DNS yayma (propagation) hattının merkezindeki Zone Builder'ı yeniden ele aldı; böylece zone ayarlarına ait değişiklikler artık tüm bir zone'un yeniden oluşturulmasını zorunlu kılmıyor. Cloudflare blog'a göre bunun sonucu, tepe bellek kullanımında yüzde 85'lik bir azalma ve müşterinin DNS değişikliği ile ilgili verinin Quicksilver'a — DNS verisini Cloudflare ağı boyunca taşıyan dağıtık key-value deposuna — yazılması arasındaki sürenin yarıya inmesi.

Bu çalışmanın arkasındaki baskı büyüme. 2022'de Zone Builder saniyede yaklaşık 250 DNS kaydı değişikliği alıyordu; bugün bu sayı kabaca 700, ayrıca zone ayarı değişiklikleri gibi yaklaşık 100 başka olay daha yaşanıyor. Cloudflare'a göre olay hacmi aslında hiçbir zaman gerçek sorun değildi — sorun, bazı olayların zone büyüklüğüyle ölçeklenen işler gerektirmesiydi ve bazı zone'lar artık 20 milyondan fazla kayıt tutuyor; şirketin beklentisine göre bu rakam yüz milyonlara doğru tırmanacak. Cloudflare'ın daha önceki kayıt başına hedefleme yaklaşımı kazancın kanıtını zaten göstermişti: 2022'de bu build'ler ortalama olarak tam build'lerden 150 kat, bir milyon kayıtlı test zone'unda ise 4.250 kat daha hızlıydı. Açık soru, aynı şeyi zone ayarları için yapmaktı.

DNS değişiklikleri edge'e nasıl ulaşıyor

Cloudflare çok aşamalı bir hat tarif ediyor. Bir müşteri DNS Records API'si ya da dashboard üzerinden bir kaydı düzenler ya da başka bir Cloudflare servisi bir zone ayarını değiştirir. Değişiklik bir veritabanına düşer ve bu da bir Kafka olayı üretir. Bir DNS Kafka Aggregator, birçok topic'ten gelen olayları birleştirip Zone Builder'a aktarır; o da gereken zone verisini okur, DNS sunum kurallarını uygular, sonucu yetkili (authoritative) DNS sunucularının anladığı anahtarlara dönüştürür, bunları Quicksilver ile karşılaştırır ve yalnızca değişen kısmı yazar.

Tam build'ler neden ölçeklenemez hale geldi

Orijinal builder'ın bir artısı vardı: bir zone'un neden değiştiğini bilmek zorunda değildi. Zone'u ve ayarlarını okur, her kaydı kodlar, Quicksilver ile karşılaştırır, bayat anahtarları kaldırır ve güncellenmişlerini yazardı. Son yazım işlemi zaten asgari düzeydeydi, ancak süreç bu arada her kaydı okuyor, kodluyor ve bellekte tutuyordu — en büyük zone'lar için ise zone'un tamamı hiç belleğe sığmıyordu.

Zone ayarları hedeflemeyi zorlaştırdı. Cloudflare Universal SSL'ye işaret ediyor: açılıp kapatılması metadata'yı güncelliyor ve zone tepesindeki (apex) CAA kayıtlarını değiştirebiliyor. Bu yüzden hedefli bir build, hangi DNS isimlerinin değişebileceğini, paylaşılan metadata'nın ya da yayımlanan zone listesinin değişip değişemeyeceğini ve Quicksilver'dan hangi eski durumun kaldırılması gerektiğini yanıtlamak zorunda.

En küçük güvenli build'i seçmek

Cloudflare beş sorunu çözdüğünü bildiriyor: olayların neyin değiştiğini belirtmesi, her değişikliği en küçük doğru build ile eşlemek, aynı isimli zone'ların paylaştığı veriyi hesaba katmak, olay ile build arasında değişebilen bir veritabanıyla başa çıkmak ve Kafka mesajları kaybolmadan işleri birleştirmek.

Olay üreticileri artık değişen zone alanlarını ve ayarlarını, mümkünse eski ve yeni değerleriyle birlikte içeriyor; Cloudflare her ayarı DNS çıktı kodunda izleyerek etkilerini sınıflandırdı. Belirsizlik durumunda yine pahalı yola dönülüyor: yalnızca zaman damgası güncellemeleri, bilinmeyen olaylar ya da zone'un herhangi bir yerindeki kayıtları etkileyebilecek değişiklikler hâlâ tam build tetikliyor. Belirsizlik her zaman daha fazla iş, asla daha az iş demek.

Planlayıcı beş build türü arasından seçim yapıyor: yalnızca kaynaklar (A, AAAA, TXT ve CNAME değişikliklerinde olağan yol), kaynaklar artı paylaşılan metadata (nameserver ve wildcard değişiklikleri), apex artı metadata (Universal SSL gibi ayarlar), yayımlanması durdurulacak zone'lar için bir purge ve daha küçük hiçbir şeyin güvenli olduğu kanıtlanamadığında tam zone yeniden oluşturma. Güvenlik kuralı katı — hedefli bir build'in yazdığı her anahtar, tam build'in üreteceğiyle bayt bayt aynı olmalı, yoksa builder tam build'e geri döner.

Bilinçli tek bir istisna var. Belirli bir kayıt sayısı eşiğinin üzerindeki zone'lar için builder asla tam build'e yükseltme yapmıyor; çünkü bu zone'ların tam build'i tamamlanamıyor ve yeniden deneme sırasında Kafka partition'ındaki diğer tüm değişiklikleri engelliyor. Bunun yerine apex'i, metadata'yı ve kuyruktaki olaylarda adı geçen tüm isimleri yeniden oluşturuyor; kalan riski ise zone hold'ları sınırlıyor.

Neden önemli

Altyapı uygulayıcıları için bu, olay güdümlü bir hattı, kanıtlanabilir biçimde gerekli olan işe küçülterek ölçeklendirmenin bir vaka çalışması. Bayt bayt eşdeğerlik değişmezi optimizasyonu güvenli kılan şey ve bunun yarattığı bellek payı ikinci bir kazanç sağladı: Cloudflare, hattın her zaman bel bağladığı dayanıklılık bekleme sürelerini güvenle kısaltabildi ve uçtan uca gecikmeyi yarıya indiren de buydu. Tasarım aynı zamanda belirsizlikle dürüstçe başa çıkmanın — tahmin etmek yerine tam build'lere geri dönmenin — ve bir zone yeniden oluşturulamayacak kadar büyük olduğunda pragmatik bir istisnayı kabul etmenin de örneğini gösteriyor.