Cloudflare、ターゲットを絞った計画によりDNSビルド遅延を半減

CloudflareはDNS伝播パイプラインを大幅に最適化し、変更内容をグローバルネットワークへ反映させるのに必要な時間を半分に短縮しました。エンジニアリングチームは、広範でリソースを大量に消費するゾーン全体の再ビルドを廃止し、各変更に対して安全な最小作業単位を特定する新しい「ターゲットビルドプランナー」に置き換えることでこれを達成しました。このアーキテクチャの変更によりピーク時のメモリ消費量も85%減少し、システムは数千万件のレコードを含むゾーンをより効率的に処理できるようになりました。

何が起きたか

根本的な課題は、Cloudflareのネットワーク上のDNSゾーンの規模拡大にありました。2022年以降、イベント発生量は毎秒250件から約700件へと増加しましたが、主なボトルネックはスループットではなく、大規模ゾーンを処理するための計算コストでした。現在では一部のゾーンが2,000万件以上のレコードを含んでおり、今後数億件に達すると予想されています。従来は、ゾーン設定やレコードへのあらゆる変更がしばしばフルビルドを引き起こしていました。フルビルドではデータベース内のすべてのレコードを読み込み、エッジ形式に変換し、既存の状態と比較します。巨大なゾーンの場合、このプロセスは極めて高コストであり、メモリに収めること自体が不可能なこともありました。

この問題を解決するため、Cloudflareのエンジニアはターゲットビルドプランナーと統合スケジューラを開発しました。プランナーは受信したイベントを分析し、ゾーン全体を再ビルドするのではなく、具体的なDNS名や共有メタデータなど、ゾーンのどの部分が変化したのかを正確に判断します。その後、スケジューラは同一ゾーンに関する複数の保留中のイベントを単一の実行ウィンドウにまとめます。このアプローチにより、数千万件のレコードを持つゾーンにおいて、ゾーン設定の変更がフル再ビルドを引き起こすことがなくなりました。その結果、DNS変更からCloudflareの分散キーバリューストアであるQuicksilverへのデータ書き込みまでの時間が50%短縮され、ピーク時のメモリ使用量も85%低下しました。

仕組み

この最適化は、異なる種類のDNS変更を区別し、それらを特定のビルドスコープにマッピングすることに基づいています。システムはビルドを次の5つのカテゴリーに分類します。リソースのみ（AレコードやCNAMEなどの標準的なレコード変更用）、リソースとメタデータ（ネームサーバーやワイルドカード変更用）、アペックスとメタデータ（Universal SSLなどの設定変更用）、パージ（未公開ゾーン用）、そしてフルゾーン（安全性を保証できない場合）です。プランナーは、ターゲットビルドがフルビルドとバイト単位で完全に一致する出力を生成することを保証します。もしシステムが小規模なビルドが安全であることを証明できない場合は、フルビルドにフォールバックしますが、極端に大きなゾーンではメモリ枯渇を防ぐためにフルビルドを完全に回避します。

このシステムの重要な構成要素は、共有メタデータの処理です。Cloudflareのアーキテクチャでは、オンボーディングなどのライフサイクルイベント中に、同じ公開ドメイン名に対して複数の内部ゾーンオブジェクトが存在することがあります。Quicksilver内の共有メタデータキーはディレクトリとして機能し、権威サーバーに対してアクティブな内部ゾーンIDを通知します。ネームサーバーの更新など、このメタデータに影響する変更が発生した場合、ビルダーは共有キー全体を更新する必要があります。整合性を確保するため、システムは実行直前にデータベースレプリカからの新規読み取りを行います。この「二重プランニング」アプローチにより、初期イベントと実際のビルドの間で発生したデータベース変更に対応し、古いデータや誤ったデータがエッジへ伝播することを防ぎます。

主要な詳細

• 大規模データセットに対する不要なフルゾーン読み取りを排除したため、ピーク時のメモリ使用量が85%低下しました。
• DNS伝播遅延が半減し、変更からQuicksilverへの書き込みまでの時間が50%短縮されました。
• システムは2,000万件以上のレコードを持つゾーンを処理でき、今後数億件への成長が見込まれています。
• リソースのみ、リソースとメタデータ、アペックスとメタデータ、パージ、フルゾーンの5種類のビルドタイプが使用されます。
• 統合スケジューラにより、同一ゾーンに関する複数のイベントを単一のビルドにバッチ処理し、効率を向上させます。
• レプリケーション遅延に対処するため、実行直前に最新の真実の情報源から状態を検証します。

なぜ重要なのか

インフラストラクチャエンジニアやプラットフォームチームにとって、このケーススタディは大規模システムにおける増分処理の重要性を浮き彫りにしています。データセットが成長するにつれ、フル再ビルドのような線形演算は持続不可能になります。「すべてを再ビルドする」モデルから「変更された部分のみを再ビルドする」モデルへの移行は、精密な依存関係トラッキングがいかにして顕著なパフォーマンス向上をもたらすかを示しています。これは特に、整合性と速度の両方が不可欠な大規模な設定ストアやステートフルサービス管理を行うチームに関連しています。作業を最小限に抑えつつ安全性を証明できる能力により、システムは計算リソースの比例増加なしにスケールアウトできます。

また、このアプローチは結果整合性や競合状態の処理についても教訓を提供します。実行直前にレプリカから最新の状態を読み取ることで、Cloudflareは取り込みパイプラインをブロックせずに、陳腐化した情報に基づく行動を取るリスクを軽減しています。保守的なプランニングを行った後に最後の瞬間に検証を行うというこのパターンは、イベント順序付けやデータベースレプリケーション遅延が本質的な課題となる分散システムにおいて堅牢な戦略です。レジリエンスを実現するために必ずしも待ち時間を追加する必要はなく、時には行動時点でのよりスマートな検証が必要であることを示しています。

実践できること

• データパイプラインを監査し、部分的な更新だけで済むはずなのにフル再ビルドを実行しているプロセスを特定してください。
• イベントタイプごとに必要とされる最小限の作業スコープを決定するために、変更に対する分類システムを実装してください。
• 関連するイベントをバッチ処理するために統合スケジューラを使用し、繰り返されるコンテキストスイッチやセットアップによるオーバーヘッドを削減してください。
• レプリケーション遅延を安全に処理するために、実行直前に最新の真実の情報源に対して最終状態を検証してください。
• メモリを大量に消費する操作に対してハードリミットを設定し、極端なケースにおける部分的再ビルドなどのフォールバック戦略を定義してください。
• データ整合性の保証を維持するために、ターゲットを絞った更新がフル再ビルドと同一の出力を生成することを確実にしてください。