DNSビルド遅延を半減、メモリ使用量を85%削減

DNSビルド遅延を半減、メモリ使用量を85%削減

2022年にDNS伝播パイプラインについて最後に書いたとき、Zone Builderは毎秒約250件のDNSレコード変更を受け取っていました。現在、それは約700件、つまり3倍近くのイベントを受け取っており、さらにゾーン設定変更などの他のイベントも約100件あります。しかし、イベントの数が問題の根本ではありませんでした。問題は、それらのイベントの一部が必要とする作業の種類と、その作業がゾーンのサイズとともにどのように増加するかでした。一部のゾーンは現在2000万件以上のレコードを保持しており、さらに数億件に達すると予想されています。

各イベントは、その変更を権威DNSサーバーが使用できるデータに変換するのにかかる時間を測定する時計を開始します。私たちはその作業をビルドと呼びます。ビルドは現在のデータベース状態を読み取り、エッジで使用される形式に変換し、変更をQuicksilverに書き込みます。

2022年には、レコードごとのビルドはフルビルドよりも平均で150倍高速でした。100万レコードを持つテストゾーンでは、レコードごとのビルドは4,250倍高速でした。その投稿は、当然の次のステップで締めくくられました：ゾーン設定についても同じことを行うことです。

なぜZone Builderは変更された設定を再構築しないのでしょうか？

そうすべきであり、それが私たちの最終的な到達点でした。しかし、それが安全であることを証明することがほとんどの作業でした。レコードイベントは、何が変更されたかを特定します。ゾーンイベントは多くのCloudflare製品から来る可能性があり、ゾーンが変更された理由を示さない場合があり、同じ名前を持つ複数のゾーンで共有されるデータを変更する可能性があります。多すぎる作業を選択すると、容量が無駄になります。少なすぎる作業を選択すると、エッジに古い、または不正確なDNSデータが残る可能性があります。

私たちは、安全であることが証明できる最小限のビルドを選択するターゲットビルドプランナーと、同じゾーンの作業を組み合わせる新しいスケジューラを構築しました。ゾーン設定の変更は、数千万レコードを持つゾーンを再構築しなくなりました。これらを組み合わせることで、ピークメモリ使用量を85%削減し、追加のヘッドルームにより、パイプラインが常に必要としていたレジリエンスのための待機時間を安全に短縮でき、DNS変更からQuicksilverへのデータ書き込みまでの時間を半減させました。

DNS変更がエッジに到達する方法

DNSゾーンは、ドメインのレコードと設定のコレクションです。Cloudflareは、そのゾーンへの変更をグローバルネットワーク全体で利用可能なデータに変換するために、多段階のパイプラインを使用しています。

1. 顧客は、DNS Records APIまたはダッシュボードを通じてDNSレコードを変更するか、他のCloudflareサービスがゾーン設定を変更します。
2. 変更はデータベースに保存されます。
3. データベースの変更または別のシステムがKafkaイベントを生成します。
4. DNS Kafka Aggregatorは、複数のKafkaトピックからのイベントを結合し、Zone Builderに送信します。
5. Zone Builderは必要なゾーンデータを読み取り、権威DNSサーバーが理解できるキーに変換します。
6. Zone Builderは、これらのキーを、Quicksilver、当社の分散キーバリューストアと比較します。変更されたもののみを書き込み、Quicksilverはその変更をCloudflareのネットワーク全体に伝播させます。

［画像: image7.png］

DNS伝播パイプラインの図：DNS Records API、ゾーン設定、および内部サービスがデータベースまたはKafkaトピックに書き込み、DNS Kafka Aggregatorがそれらを結合し、DNS Zone BuilderがQuicksilverに書き込みます。

これは簡略化されたビューです。Zone Builderはデータベース行をエッジに直接コピーしません。ゾーン設定とレコードを組み合わせ、DNSサービングルールを適用し、権威DNSサーバーが迅速に読み取れるように結果を整理します。

フルビルドがスケーリングを停止した理由

元のZone Builderには1つの有用な特性がありました：なぜゾーンが変更されたかを知る必要がなかったことです。現在のデータベース状態から望ましい状態を再構築しました。

1. 現在のゾーンとその設定を読み取ります。
2. ゾーン内のすべてのDNSレコードを読み取ります。
3. それらのレコードをQuicksilverキーに変換します。
4. 新しいキーを既に保存されているキーと比較します。
5. 古いキーを削除し、変更されたキーを書き込み、ゾーンメタデータを更新します。

最終的な書き込みには変更されたキーのみが含まれます。しかし、フルビルドは依然としてすべてのレコードを読み取り、エンコードし、比較し、その間、ゾーン全体をメモリに保持します。これは小さなゾーンでは安価です。数千万レコードを持つ最大のゾーンでは、ゾーンはメモリに全く収まりません。その処理方法については後述します。

ゾーン設定はターゲット設定をより困難にしました。ユニバーサルSSLはその一例です。それを有効または無効にすると、メタデータが更新され、ゾーンの頂点（example.comのようなベアドメイン）の証明書認証局承認（CAA）レコードが変更される可能性があります。CAAレコードは、証明書発行局にドメインの証明書を発行できるかどうかを伝えます。

フルビルドはゾーンが変更されたことを知るだけでよかった。ターゲットビルドは3つの質問に答える必要があります：

1. どのDNS名が変更される可能性がありますか？
2. 共有メタデータまたは公開されるゾーンのリストが変更される可能性がありますか？
3. Quicksilverから削除する必要がある以前の状態は何ですか？

これらの質問を安全に答えるには5つの問題を解決する必要があり、その残りの部分は順に説明します：

1. イベントは、何が変更されたかを伝える必要がありました。
2. 各変更は、依然として正しい最小限のビルドにマッピングされる必要がありました。
3. ビルドは、同じ名前を持つすべてのゾーンによって共有されるデータを考慮する必要がありました。
4. イベントとビルドの間にデータベースが変更される可能性がありました。
5. 作業の結合はKafkaメッセージを失うことはできませんでした。

イベントに何が変更されたかを伝えるようにする

イベントプロデューサーを変更し、変更されたゾーンフィールドと設定を含め、利用可能な場合は以前の値と新しい値を含めるようにしました。次に、DNS出力生成コードを介して各設定をトレースし、それが影響を与える可能性のあるものを分類しました。

すべてのイベントがそれほど具体的だったわけではありません。一部のデータベース関数はタイムスタンプのみを更新し、実質的に「このゾーンの何かが変更された」と伝えます。時にはそれは無害なブックキーピングです。時にはそれは他の場所でデータが変更されたことを意味し、再読み取りする必要があります。

これらのケースはイベントでは同じように見えます。呼び出し元とその目的を特定できるようになるまで、タイムスタンプのみの更新は依然としてフルビルドを引き起こします。同じルールが、詳細の欠落、不明なイベント、またはゾーン内のどこかのレコードに影響を与える可能性のある変更にも適用されます。プランナーは不確実性を減らす作業に決して変えません。

最小限の安全なビルドを選択する

Quicksilver出力には、ここで重要な2つの部分があります。レコードキーには、1つのゾーンと名前のDNS応答が含まれます。より小さな共有メタデータキーは、名前サーバーやワイルドカードなどの特別なレコードの場所を含む、ゾーンの使用方法を権威DNSサーバーに指示します。一部のイベントはレコードキーのみを変更し、他のイベントは両方を更新する必要があります。

この区別により、プランナーは5つのビルドタイプのいずれかを選択できます：

1. リソースのみ：ゾーンメタデータを変更せずに、特定のDNS名のレコード（リソースと呼びます）を再構築します。通常のA、AAAA、TXT、CNAMEの変更は通常このパスを取ります。
2. リソースとメタデータ：特定の名前と共有メタデータを再構築します。ネームサーバーとワイルドカードの変更はこのパスを使用します。
3. 頂点とメタデータ：ゾーンの頂点とメタデータを再構築します。ユニバーサルSSLなどの設定はこのパスを使用できます。
4. パージ：公開されなくなったゾーンを削除します。
5. フルゾーン：より小さな作業が安全であることが証明できない場合に、すべてのレコードを再構築します。

ルールは単純です：ターゲットビルドが書き込むすべてのキーは、フルビルドが書き込むものとバイト単位で同一である必要があります。それが証明できない場合は、フルビルドを実行します。

古い状態の削除は、2022年のレコードごとのビルドと同様に機能します。レコードイベントには、削除されたレコードと更新されたレコードの以前のバージョンが含まれます。次に、Zone Builderは、再構築する各名前の下にある既存のキーをQuicksilverでスキャンし、新しいビルドが書き込まなかったキーを削除します。

フルビルドは、変更がゾーン内のどこかのレコードに影響を与える可能性がある場合、またはゾーンが初めて公開される必要がある場合に依然として必要です。

1つの意図的な例外があります。フルビルドは、データベースからすべてのレコードと、ゾーンのすべての既存のQuicksilverキーを一度にメモリに保持しますが、最大のゾーンは収まりません。固定レコード数しきい値を超えると、Zone Builderは決してフルビルドにエスカレートしません。代わりに、頂点、メタデータ、およびキューに入れられたイベントによって特定されたすべての名前を再構築します。私たちはこのトレードオフを受け入れます。なぜなら、それらのゾーンのフルビルドは完了できず、再試行中にKafkaパーティションの他のすべての変更をブロックするからです。フルビルドを必要とするケースの多くは、同じ名前を共有する複数のゾーンに関係しており、ゾーンロックはそのリスクを軽減します。同じ名前が別のアカウントに追加されるのを防ぐことで。残りのまれなケース（たとえば、別のネットワークでゾーンを有効にするなど）では、ゾーン内の個々の名前を手動で再構築できます。

1つの名前が複数のゾーンを意味する場合

Quicksilverは各ゾーンのレコードキーを個別に保存します。また、そのドメイン名を持つすべてのCloudflareゾーンで共有される1つのメタデータキーも保存します。この共有キーはディレクトリのように機能します。権威DNSサーバーに、クエリに応答するときに使用できる内部ゾーンIDを指示します。

なぜ1つの名前が複数のゾーンIDを持つことができるのでしょうか？顧客のオンボーディング、オフボーディング、およびその他のライフサイクル変更中に、同じ公開ドメインに対して複数のCloudflareゾーンオブジェクトが一時的に存在する可能性があります。私たちは優先順位ポリシーを使用して、小さく制限されたセットを選択して公開します。

example.comの4つの内部ゾーンを検討してください：ゾーン101、ゾーン202、ゾーン303、ゾーン404。メタデータキーには現在、ゾーン101、202、303が含まれています。ゾーン404は存在しますが、選択されていません。数字は個別のCloudflareゾーンオブジェクトを識別します。顧客は依然として1つのドメイン名を見ます。

ゾーン202のwww.example.comのTXTレコードの変更は、ゾーン202のレコードキーのみに影響するため、メタデータキーは変更されません。ネームサーバーとワイルドカードの変更は異なります。なぜなら、メタデータキーがそれらに関する情報を記録するからです。これらのビルドは、ゾーンのレコードとメタデータキーの両方を更新する必要があります。

実行時に、Zone Builderは現在のリストを再度読み取ります。メタデータキーを書き込む場合、古いコピーをパッチするのではなく、その最新のビューからキー全体を再構築します。参照先のメタデータよりも前に、トリガーゾーンのレコードを書き込みます。

イベントから計画し、書き込む前に検証する

イベントは過去に何が起こったかを記述します。ビルドは、より多くのイベントが到着し、データベースが変更されるまで待機する可能性があるため、計画は2回行われます。イベントは最初に保守的な作業リストを作成します。実行の直前に、Zone Builderは最新の公開スナップショットを読み取ります。現在のゾーン設定、このZone Builderがゾーンをネットワークに公開すべきかどうか、およびどの同じ名前のゾーンIDがメタデータキーに含まれるべきかです。ここで、ネットワークは1つの環境のQuicksilverの個別の、分離されたコピーです。各Zone Builderデプロイメントは1つのネットワークに書き込み、ゾーンは一部のネットワークで有効にできますが、他のネットワークでは無効にできます。たとえば、ゾーンはCloudflareのグローバルネットワークから、中国ネットワークからも提供できます。

最新の状態は4つの方法で結果を変更できます：

1. ゾーンが完全なゾーン作業を必要とする機能を持つようになった場合、ターゲットビルドはフルビルドになる可能性があります。
2. ゾーンがこのネットワークに公開されなくなった場合、ビルドはパージになる可能性があります。
3. トリガーゾーンがメタデータキーに含まれなくなった場合、ビルドはスキップされる可能性があります。
4. メタデータビルドは、現在の候補セットから共有キーを再構築できます。

最新の読み取りは、読み取り専用コピーのデータベース（レプリカと呼ばれる）から行われるため、ビルドは顧客の書き込みと競合しません。Kafkaの配信とデータベースのレプリケーションは独立して移動します。イベントは、そのデータベース変更がレプリカで表示される前に到着する可能性があります。DNS Kafka Aggregatorは通常の遅延をカバーするのに十分な長さでイベントを遅延させ、最終的なデータベースチェックはレプリカがまだ遅れている場合に読み取りを拒否します。

1つのスケジューラで変更を結合する

レコード作業とフルゾーン作業は、以前は異なるスケジューラを使用していました。それぞれが独自の作業を結合できましたが、他のスケジューラからの作業は結合できませんでした。それらを1つの統合スケジューラに置き換えました。プランナーは構築する必要があるものを決定し、スケジューラはいつ実行できるかを決定します。

1つのゾーンに対して複数のイベントがビルド開始前に到着した場合、スケジューラはその作業を結合します：

1. www.example.comでAレコードが変更され、その名前が必要になります。
2. *.example.comでワイルドカードが変更され、その名前と共有メタデータが必要になります。
3. スケジューラは、両方の名前とメタデータの更新を1つのビルドに結合します。

［画像: image6.png］

Aレコードの変更とワイルドカードの変更が個別の必要な作業としてビルドプランナーを通過し、その後統合スケジューラによって1つのビルドに結合されることを示す図。

マージは作業を追加するだけです。いずれかのイベントが完全なゾーンを必要とする場合、結合されたビルドはフルビルドになります。パージは、その望ましい結果がゾーンがもはや公開されないことであるため、すべての再構築をオーバーライドします。

スケジューラは、実行する必要があるDNS作業と、確認待ちのKafkaメッセージの2つのものを別々に追跡します。再試行は両方を保持します。フルビルドまたはパージが個々のレコード名を必要としなくなった場合でも、結果が安全に書き込まれるまでメッセージは添付されたままです。

Kafkaを動かし続ける

1つの遅いビルドは、ワーカーが利用可能な場合でも、無関係な顧客を遅延させる可能性があります。Kafkaはメッセージを順序付けられたパーティションに分割します。各パーティションについて、完了したと認識されているすべてのメッセージの前の点であるコミット済みオフセットを1つ保存します。このオフセットを未完了の作業を越えて移動すると、再起動後に顧客の変更が失われる可能性があります。以前にセカンダリDNSの詳細で説明したソフトコミットを使用しています。ビルドは順不同で完了し、メモリ内で完了とマークされる可能性がありますが、Kafkaのコミット済み位置は、それ以前のすべてのメッセージも完了した後でのみ進みます。

［画像: image8.png］

メッセージ1からnまでのKafkaメッセージの図。メッセージ2での大規模なビルドがメッセージ3からnまでのコミットをブロックし、ポッドの再起動がメッセージ2からnを再再生します。

図では、メッセージ2がまだ実行中であるため、メッセージ3からnはコミットできません。Zone Builderが再起動した場合、メモリ内の完了は消え、Kafkaはメッセージ2からnを再再生します。私たちは意図的に変更を失うよりも、繰り返しの作業を選択します。

ターゲットプランは、最も古いメッセージが未完了のままでいる時間を短縮します。スケジューラはまた、1つのビジーゾーンがすべてのワーカーを占有しないようにします。ゾーンがビルドされた後、次のビルドはゾーンごとの再構築間隔を待ちます。これはCloudflareプランによって異なります。その間に到着した変更は、次のビルドにマージされます。スケジューラは通常この間隔を強制しますが、Kafkaパーティションを長時間ブロックする前に古いキューに入れられた作業を実行させます。ゾーンロックと再試行遅延は引き続き適用されるため、失敗したビルドはタイトなループで実行できません。

安全なリリース

小さなビルドは、同じDNSデータが生成されない限り有用ではありません。ネームサーバー、ワイルドカード、および頂点パスの同等性テストを追加しました。各テストは、同じデータベース状態からフルビルドとターゲットビルドを実行し、時間依存の値をピン留めし、ターゲットプランが所有するすべてのQuicksilverキーをバイト単位で比較します。プランナーとスケジューラのテストは、分類、同じ名前のゾーン、マージ、パージ、およびエスカレーションをカバーします。

ロールアウト中、すべてのターゲットビルドの隣でフルビルドを実行し、出力を比較しました。これは意図的に高価であり、毎回完全なゾーンを読み取るため、ミラー比較で同じ信頼が得られるまでのみ使用しました。

テストではすべての顧客の組み合わせを再現できないため、すべてのリリースはミラーZone Builderも通過します。これは本番Kafkaストリームを消費し、本番データベース状態を読み取りますが、顧客トラフィックを提供しない別のQuicksilver環境に書き込みます。

［画像: image12.png］

ミラーセットアップの図：本番Kafkaストリームが本番およびミラーZone Builderの両方に供給され、それぞれが独自のQuicksilverに書き込み、コンパレーターが両方をサンプリングしてDNSミラーダッシュボードにレポートします。

コンパレーターはゾーンの20％サンプルをチェックして、キーの欠落、余分なキー、および値の違いを確認します。2つの環境はゾーンを同時にビルドするとは限らないため、一時的な不一致は自動的にリグレッションではありません。両方のパイプラインが追いついた後も残る新しい種類の違いを探します。これにより、ターゲットビルドが本番と同じ出力を生成することに自信が持てます。

DNSミラーダッシュボードを構築して、それらの違いをグループ化し、調査のために例を保持しました。当然、それはCloudflare Developer Platform上で実行されます。Workerが結果を受け取り、Durable Objectsが状態を維持し、Cloudflare Accessがそれを保護します。下のスクリーンショットの重要なグループは、リリース前にそれぞれチェックされ、安全であることが確認されました。差分率は、本番とミラーが比較時に少なくとも1つのキーで意見が一致しなかった比較済みゾーンの割合です。それらのほとんどはタイミングの違いであり、両方のパイプラインが追いつくと消えるため、2つのことを監視します。そのレートが低く保たれ、新しい種類の違いが現れないことです。

［画像］

本番とミラービルドを比較するDNSミラーダッシュボードのスクリーンショット。234,313の照合済みゾーンで0.31%の差率を示しています。

ミラーの結果が健全なままであった後、ゾーン名のハッシュによってスケジューラをロールアウトしました。ゾーンIDではなく名前をハッシュすることで、同じ名前を共有するすべてのゾーンが同じスケジューラに留まるため、2つのスケジューラが同じメタデータキーを書き込むことはありませんでした。無料ゾーンの割合を増やし、次に有料ゾーンについても同じプロセスを繰り返しました。

結果

24時間で、ビルドの86.81%がリソースのみ、2.54%がリソースとメタデータ、2.30%が頂点とメタデータ、1.30%がパージであることが測定されました。合計で、92.95%のビルドが完全なゾーンの再構築を回避しました。フルビルドは残りの7.04%でした。

2つのメタデータビルドタイプは以前はフルビルドでしたが、大規模なゾーンでも同様でした。合計で、それらはビルドの4.84%を占めます。依然としてフルビルドである7.04%と合わせると、これは11.88%であり、フルビルドは約40%減少しました。カウントにおけるそのシェアは、それらが最大のゾーンを含むため、回避された作業を過小評価しています。残っているフルビルドは平均0.35秒です。なぜなら、ゾーンが初めて公開されるなどのイベントは、主にレコードが少ない新しいゾーンに影響するためです。

［画像］

24時間のビルドタイプの表：リソースのみ86.81%、フルゾーン7.04%、リソースとメタデータ2.54%、頂点とメタデータ2.30%、パージ1.30%。

2022年には、バッチシステムを計画するとも述べました。統合スケジューラはそれを不要にします。バッチを形成するために待機せず、同じゾーンで既にキューに入れられた作業がある場合にのみイベントをマージします。以前は、長いフルビルドがパーティションのコミット済みオフセットをブロックしていました。それらが減少したことで、イベントが到着する速度でKafkaを消費するようになり、遅れてバーストで最大1,550メッセージ/秒までキャッチアップするのではなく、それらの遅延がなくなりました。

［画像］

変更前のKafkaの生産と消費のチャート：消費は毎秒約300から1,550の間で変動し、生産は約600から800の間にとどまります。

［画像］

変更後のKafkaの生産と消費のチャート：消費は毎秒約600から800で生産に密接に従います。

ビルド完了遅延も測定しました。DNSレコードまたはゾーン設定の変更からZone BuilderがQuicksilverへの書き込みを完了するまでの時間です。これには、ネットワーク全体へのQuicksilverの配布は含まれていません。これは場所によって異なり、この作業の影響を受けません。本番環境は古いスケジューラを実行し、ミラーは同じ24時間で同じイベントに対して統合スケジューラを実行しました。2つの環境はコード以外は同一です。同じKafkaイベントを消費し、同じデータベースから読み取り、Quicksilverに同等のデータを書き込みます。これにより、これは制御されたサイドバイサイド比較になります。これらの数値は、すべてのビルドタイプと顧客プランを組み合わせているため、個々のゾーンのレイテンシ保証ではありません。この時間の大部分は前述の再構築間隔であり、ビルド作業ではありません。各測定ポイントで、p99は99%のイベントが完了した時間です。典型的な遅延はほとんど変わりませんでした。なぜなら、ほとんどのビルドはすでに小さかったからです。違いはテールにあります。最大のp99スパイクは14.6分から1.21分に減少しました。これは12倍の削減です。チャートは対数スケールを使用しています。

［画像］

24時間のp99ビルド完了遅延のチャート（対数スケール）：レガシースケジューラは最大14.6分にスパイクしますが、統合スケジューラは1.21分でピークに達します。

ターゲットビルドは、完全な大規模ゾーンをロードする頻度もはるかに低くなりました。集計ワーキングセットメモリ（デプロイメントによってアクティブに使用されるメモリ）は、平均49 GiBから7 GiBに、86%削減されました。ピークは79 GiBから12 GiBに、85%削減されました。

［画像］

ロールアウト後、総Zone Builderメモリが50〜79 GiBから約7 GiBに低下したチャート。

これらは新しいスケジューラによる直接的な結果でした。また、2つの保護策を見直すこともできました。1つ目は再構築間隔です。これは、1つのビジーゾーンが絶えず再構築して他のすべての容量を奪うのを防ぎます。ビルドは現在安価になり、完全なゾーンを読み取るビルドははるかに少なくなったため、ほとんどのプランでその間隔を安全に短縮できました。2つ目は、データベースレプリカが読み取る前にキャッチアップしていることを確認するために、DNS Kafka Aggregatorが各イベントを保持する時間です。データベースが遅れているレプリカからの読み取りを拒否し始めたら、そのバッファは安全に小さくすることができました。これらを組み合わせることで、中央値ビルド完了遅延が約7.7秒から約3.3秒に半減しました。下のチャートでは、最初のステップダウンはDNS Kafka Aggregatorの変更です。赤い帯は、より短い再構築間隔を持つZone Builderのリリースを示しています。そのリリースはサーバー全体に徐々にロールアウトされたため、遅延は一度にすべてではなく、さらに2つのステップで減少します。

［画像］

ほぼ2時間にわたるビルド完了遅延のチャート（粗いヒストグラムバケットで測定）：中央値は約7.7秒から約6.4秒に低下し、DNS Kafka Aggregatorの変更後、その後2つのステップでZone Builderのリリース（赤い帯でマーク）後に約3.3秒になります。p90は10秒から約7.4秒に低下し、p99は27秒近くにとどまります。

そのチャートのp90とp99の線は、見た目ほど正確ではありません。ヒストグラムには1、5、10、30秒のバケットがあり、エッジ間に位置するパーセンタイルは、遅延がその範囲全体に均等に分散されていると仮定して推定されます。ほとんどの遅延はその範囲の下部に近いため、これらの推定値は高くなります。p99は30秒近く、p90は7秒強になります。正確な平均（バケットに依存しない）は、半減を確認します。その後、細かいバケットを自動的に選択するネイティブヒストグラムに切り替えました。これにより、p90は約5.5秒、p99は約12秒になります。

［画像］

約4時間にわたるビルド完了遅延のチャート（ネイティブヒストグラムで測定）：中央値は約3.4秒、p90は約5.5秒、p99はほとんど10〜14秒の間です。

フルビルドが依然として存在する理由

2022年には、フルビルドを完全に排除する計画だと述べました。それは現実的でも有用でもないことがわかりました。ゾーンが初めて公開される場合、すべてのレコードを書き込む必要があります。ゾーン内のどこかのレコードに影響を与える可能性のある変更は、すべてのレコードをチェックする必要があります。何が変更されたかを伝えないイベントは、プランナーが不確実性を減らす作業に決して変えないため、依然としてフルビルドを取得します。小さなゾーンの場合、フルビルドも安価です。

より多くのイベントが何を変更するかを学ぶにつれて、それらをターゲットビルドに移行し続けます。しかし、最大の利点はすでに達成されています。かつて最大のゾーンを再構築していたイベントは、もはやそうではなくなり、残っているフルビルドは、主に新しい小さなゾーンに影響する最初の公開などのイベントによってトリガーされます。

Zone Builderが変更を書き込んだ後に何が起こるか知りたいですか？Quicksilverが構成を配布する方法をすべてのCloudflareデータセンターに数秒で配布する方法を読んでください。

---