Cloudflareは現在6年目であり、権威あるDNSサーバーを提供することは最初から私たちのコアインフラストラクチャでした。 それ以来、私たちはインターネット上で最大かつ最速のDNSサービスプロバイダーに成長し、 Alexトップ1Mサイトのリストから約100,000サイト、600万以上のDNSゾーンにサービスを提供しています。

現在、当社のDNSサービスは、グローバルエニーキャストネットワークを使用して、攻撃中にトラフィックをカウントせずに、毎秒約100万のクエリに応答します。 もちろん、成長しつつある新興企業として数年前に数百、数千のゾーンにサービスを提供していたテクノロジーは、現在の数百万に対応できなくなっています。 昨年、DNSインフラストラクチャの2つの重要な要素を置き換えることにしました。権限のあるクエリに応答するDNSサーバーの一部と、世界中の境界サーバーでユーザーの変更を取得して更新するシステムです。

アーキテクチャのサンプル画像を上の図に示します。 ユーザーのDNSレコードおよびその他の元の情報を中央データベースに保存し、生データをサーバーが使用できる形式に変換してから、 100以上のデータセンターに配布します （PoP-Point of Presents（ "Points of Presence"と呼びます） ））KV（キー/値）ストアを使用します。

クエリ自体は、数年前から開発および使用している独自のDNSサーバーrrDNSによって処理されます。 Cloudflareの初期には、DNSソリューションはPowerDNSに基づいていましたが、2013年にrrDNSに完全に置き換えられました。

したがって、Cloudflare DNSチームは、システムの2つの要素（サーバー間のデータ転送システムとrrDNS）を担当します。 最初のアイデアは、5年以上前のインフラストラクチャのように、現在のソリューションが廃止されたため、データ伝送システムを完全に新しいソリューションに置き換えることでした。 現在のソリューションは、PowerDNS上で動作するように構築され、徐々に開発されました。 DNSレコードをPowerDNS形式に変換するために最初に作成されたため、十分な欠陥と隠された機能を蓄積しました。

新しいデータモデル

古いシステムでは、データモデルは非常に単純でした。 DNSレコードは、グラフィカルインターフェイスまたはAPIとほぼ同じ形式（リソースレコード（RR）ごとに1レコード）で保存しました。 つまり、サーバー間のデータ転送サービスは、境界データをゾーンサーバーに送信する必要があるときに、単純なシリアル化のみを処理する必要がありました。

ゾーンメタデータとRRは、JSONとプロトコルバッファーの混合を使用してシリアル化されましたが、これらのプロトコルの概略的な性質は特に使用していませんでした。その結果、スキームが肥大化し、最終データが必要以上になりました。 データベース内のリソースレコードの数が1億に増加したため、この一見小さなサイズの違いが非常に顕著になったという事実は言うまでもありません。

DNSは、要求に応答するときにリソースレコードのレベルで実際に動作しないことを思い出してください。 名前とタイプ（たとえば、 example.com



やAAAA



）を要求すると、代わりにRRSetが返されます。これは、複数のRRのコレクションです。 古いデータモデルでは、RRSetsはRRの複数のレコード（レコードごとに1つのキー）に分割されました。これは通常、単一のDNSクエリに応答するためのKVリポジトリへの複数の呼び出しを意味しました。 これを修正し、RRSetの周りのデータをグループ化して、1つのリクエストでKVリポジトリへのアクセスが1回だけ必要になるようにしました。 CloudflareがDNSパフォーマンスを最適化することが重要であるため、KVリポジトリへの複数のリクエストにより、rrDNSを可能な限り高速にすることが非常に困難になりました。

同様に、A / AAAA / CNAMEのようなクエリの場合、RRSetの1つのキーではなく、「アドレス」によって1つのキーにデータをグループ化することにしました。 これは、多くの場合、リポジトリへの追加のアクセスを取り除くのに役立ちます。 キーの組み合わせは、KVストレージに使用するキャッシュのメモリ使用量を削減するのにも役立ちます。1つのキーにより多くの情報を保存するためです。

新しいデータモデルを決定したら、データをシリアル化してエッジサーバーに送信する方法を決定する必要がありました。 すでに述べたように、以前はJSONバッファーとプロトコルバッファーの混合を使用していましたが、これを完全なMessagePack実装に置き換えることにしました。

MessagePackを選ぶ理由

MessagePackはバイナリタイプのデータシリアル化形式ですが、データを回路に厳密にバインドしません。 この意味では、JSONに少し似ています。 送信者と受信者の両方が追加フィールドを追加または無視できます-これはアプリケーション次第です。

比較のために、プロトコルバッファー（またはCap'n Protoなどの他の形式）では、最初に言語に依存しない形式でデータスキームを定義してから、特定の実装用のコードを生成する必要があります。 DNSにはすでに大規模な構造化スキームがあるため、別の言語での実装を繰り返してサポートすることは避けました。 プロトコルバッファの以前の実装では、このサポートの必要性を回避するために、すべてのタイプのDNSのスキームを適切に説明していませんでした。その結果、rrDNSのデータモデルは非常に混乱しました。

そして、新しいフォーマットを検討したときに、高速で使いやすいものが必要であり、コードベースや使用したライブラリと簡単に統合できるものが必要でした。 rrDNSはGoでmiekg / dnsライブラリを積極的に使用します。これは、たとえば、各RRタイプの構造の大規模なコレクションで動作します。

 type SRV struct { Hdr RR_Header Priority uint16 Weight uint16 Port uint16 Target string `dns:"domain-name"` }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスからrrDNSにデータをデコードするとき、RRをこれらの構造に変換する必要があります。 そして、私たちが試したtinylib / msgpライブラリは、コード生成の良い機会を提供することがわかりました。 これにより、異なる形式のスキーマ定義をサポートする必要なく、これらの構造記述から効率的なGoコードを自動的に生成できます。

これは、miekg（すでにrrDNSに精通している）のRR構造を引き続き使用し、それらをバイナリデータに直接シリアル化し、その後、必要な構造に直接境界サーバーで逆シリアル化できることを意味しました。 構造のセットを別の構造と一致させることを心配する必要がなくなり、作業が大幅に簡素化されました。

MessagePackは、他の形式と比較して非常に高速です。 Goのさまざまな形式でのシリアル化速度の比較からの抜粋です。 他のクロスプラットフォームソリューションよりも大幅に高速であり、これも選択に大きく影響していることがわかります。

新しいモデルへの移行後、境界サーバー上のデータが占有するスペースを実際に9倍削減したことは驚きでした。これは予想をはるかに上回りました。 これは、肥大化したデータモデルがシステム上でどれほど強力であるかを再び証明します。

新しいデータサービス

Cloudflare DNSのもう1つの重要な機能は、数分や数時間ではなく、数秒で地球全体の変更を更新できることです。 既存のデータ伝送システムは、増え続けるゾーンにほとんど対応できず、1秒あたり5つのゾーンを変更する場合でも、最も静かな期間に新しいソリューションが必要でした。

世界中のデータを更新するのは簡単ではありません

最近、このプロセスを監視しており、世界中で変更が更新される時間を視覚化できます。 以下のグラフは、エンドツーエンドの監視からのデータを示しています。まず、APIを使用してDNSに変更を加え、世界のさまざまな地域でデータが更新される速さを監視します。 グラフ上の各ポイントは、PoP（プレゼンスポイント）の1つをテストする個別のサンプルを表し、APIを介した実際の変更から世界に表示されるまでの遅延が測定されます。

キャッシュにはいくつかのレベルがあり、内部と私たちが制御していないため、10秒間隔で分布を見ることができ、値は1分未満であり、常に変化しています。 この許可は、監視と通知には十分ですが、改善する予定です。 通常の状態では、99％のケースの新しいDNS情報が5秒以内に利用可能になります。

最初のグラフでは、接続の問題により少数のPoPで数分の遅延が見られるいくつかのインシデントがありますが、一般に、すべてのサンプルで非常に安定した結果が示されました。

対照的に、同じ期間の古いデータシステムのグラフを次に示します。 すべてのPoPで遅延が大きくなるのは簡単です。

クエリパターンにより適した新しいデータモデルを使用して、中央データベースからゾーンの変更を取得し、必要な処理を行い、KVリポジトリにデータを送信する新しいサービスを実装しました。

新しいサービス（お気に入りのGo言語で記述）は、2016年7月から実稼働で使用されており、現在、すべてのユーザーゾーンの99％以上を移行しています。 ネットワークの問題による遅延のあるケースを削除すると、新しいデータ転送システムはこれまでゼロ遅延を示しました。

信頼できるrrDNS v2

rrDNSは、特定の種類の要求の処理を別のコードに転送できるさまざまな「フィルター」を作成できるモジュラープログラムです。 信頼できるフィルターは、着信DNSクエリを受け取り、クエリが属するゾーンを調べて、RRSetを見つけてクライアントに返すために必要なすべてのロジックを実行します。

境界サーバーの基盤となるDNSデータモデルを完全に改訂したため、rrDNSの「Authoritative Filter」を大幅にやり直す必要がありました。 これも、コードベースの暗いコーナーの1つであり、長年にわたって変更されていません。 古くなったコードベースと同様に、変更は簡単な作業ではなかったため、このフィルターを最初から完全に書き直すことにしました。 これにより、生産性に目を向け、現在のDNSトラフィックの量と形式に適したソリューションを使用して、新しいデータモデルに基づいてゼロから始めることができました。 また、ゼロから書き直すという決定により、テストでの高いコードカバレッジや優れたドキュメントなど、ベストプラクティスを使用した開発がはるかに容易になりました。

信頼できるフィルターの新しいバージョンは、2016年末から実稼働で使用されており、新しい負荷分散ソリューションの DNSとの連携で既に重要な役割を果たしています 。

新しいフィルターへの移行の結果に満足しました。以前より平均3倍速くDNSクエリに応答し始めました。これはお客様にとって朗報であり、大規模なDNS攻撃をバイパスする能力を向上させました。 このグラフでは、移行されたゾーンの数が増えると、平均応答時間が大幅に減少したことがわかります。

その場で靴

プロジェクトの最も時間のかかる部分は、古いバージョンから新しいバージョンへの顧客の移行でした。そのため、誰も問題を経験せず、私たちが何かをしていることさえ知りませんでした。 これを実現するために、Cloudflareは、カスタマーリレーションシップおよびサポート部門の多くの人々の多大な努力を必要としました。 Cloudflareにはさまざまなタイムゾーン（ロンドン、サンフランシスコ、シンガポール、オースティン）に多くのオフィスがあり、すべての同期が成功の重要な要素となっています。

新しいrrDNSのリリースプロセスの要素の1つとして、新旧のコードで実稼働システムからの要求を自動的に収集して繰り返し、予期しない違いを検出しました。 ゾーンの移行にも同じ手法を使用することにしました。 いずれかのゾーンがテストに合格するために、古いシステムと新しいシステムの間でゾーン全体の可能な回答を比較しました。 その結果、わずかな違いが自動的にゾーンを移行プロセスから除外しました。

これにより、ゾーンの移行を一貫してテストし、発生した欠陥を修正して、定期的にリリースすることができました。 古いシステムから新しいシステムに切り替えるという恐ろしい方法ではなく、それらを並行して起動し、ゾーンを徐々に移行して同期を維持することにしました。 これは、何かが起こった場合にいつでも移行できることを意味します。

プロセスを開始するとすぐに、1日に数十万のゾーンを静かに移行し始め、99％の初期目標にどれだけ近づいているかを注意深く観察しました。 特定の複雑な構成では常に顧客エンゲージメントの要素があるため、ラストマイルはまだ処理中です。

私たちは何を達成しましたか？

Cloudflareコアインフラストラクチャの一部を交換するには、多数のチームがかなりの労力を必要としました。 私たちは何を達成しましたか？

• DNSクエリへの回答のパフォーマンスが3倍向上
• 世界中のDNS更新のより高速で信頼性の高い配布
• 現在のトラフィックの現実とエッジサーバーの動作に関する優れたドキュメントに基づいた、より完全な機能セット
• テスト範囲の拡大、メトリックスの向上、コードに対する信頼性の向上により、自信を持って変更を行い、DNSソリューションを開発できます。

DNSクライアントにより迅速にサービスを提供できるようになったので、近々数種類の新しいタイプのRRといくつかの新しい興味深い機能のサポートをロールアウトします。