要約:
Cloudflare は最近、1.1.1.1 パブリック DNS リゾルバーによって使用されるキャッシュ メモリを大幅に削減し、ネットワーク全体で約 100 TB のメモリを解放しました。この最適化には、サーバー ハードウェアの交換やメモリ モジュールの取り外しは含まれませんが、DNS データをキャッシュするソフトウェア ストレージ方法を改善することによって実現されます。
この作品は主にビッグ パイナップルを中心に展開します。 Big Pineapple は、1.1.1.1 リゾルバー、DNS ファイアウォール、その他多くの DNS サービスをサポートする Cloudflare のキャッシュ プラットフォームです。 CloudflareのシステムエンジニアであるSebastiaan Neuteboom氏は、Rustのコードベースに対する5つの調整を技術ブログで紹介し、これにより一般的な単一のDNSキャッシュレコードが占有するスペースを953バイトから420バイトに削減しました。
最適化されたシステムの実行速度も向上しました。 Cloudflareによると、キャッシュ挿入のスループットは1秒あたり62万5,000アイテムから89万3,000アイテムに増加し、クエリのレイテンシは828ナノ秒から670ナノ秒に低下したという。 5 月中旬から 7 月上旬までのデプロイメントの過程で、インスタンスあたりの 99 パーセンタイルのメモリ使用量は 9.3 GB から 5.3 GB に減少しました。
Cloudflare は、Big Pineapple は常に 2,500 億を超える DNS レコードをキャッシュしていると主張しています。このような大規模な場合、レコードごとにわずかな量のメモリが浪費されるだけでも、合計するとかなりの量になります。同社は、キャッシュ エントリ内で占有される不要なバイトごとに、サーバー クラスタ全体で 250 GB 以上の追加メモリを消費すると推定しています。
重要な変更の 1 つは、Rust の Vec 型と String 型に関係します。これらのコンテナは動的に拡張するように設計されているため、実際のデータに加えて、容量などの追加情報も保存されます。ただし、DNS レコードはキャッシュに入力された後に展開する必要はありません。 Cloudflareはその後、これらの構造を固定サイズのボックス化されたスライスに置き換え、不要になったメタデータを削除しました。同社によれば、この調整だけで15TB以上のメモリが節約されたという。
エンジニアは、DNS 応答をメモリ内で配置する方法も再設計しました。以前は、Big Pineapple は応答ごとに 3 セットのレコード リストを保存していました。新しい設計では、すべてのレコードを同じバッファーに配置し、2 バイトのオフセットを使用して各レコードの位置を識別します。
また、所有者名がクエリ対象のドメイン名の単なる複製である場合、キャッシュは所有者名を保持しなくなり、代わりに応答が返されたときに再構築されます。さらに、システムは代わりに、長さのプレフィックスを含む生の DNS 行フォーマット バイトを使用してレコード データを保存し、以前の設計での無駄なスペースの問題を解決します。以前は、IPv4 A レコードは 4 バイトしか使用しませんでしたが、Cloudflare によってキャッシュされる最大の DNS レコード タイプである比較的まれな NAPTR レコードと同様に、144 バイトを使用しました。可変長の生データ形式に切り替えると、短いレコードが最長のレコードと同じスペースを予約する必要がなくなります。
Cloudflare がサーバー クラスター全体で再利用した 100 TB のメモリは、第 13 世代サーバー 130 台のメモリ容量にほぼ相当します。これらの各サーバーには 768GB DDR5-6400 メモリが搭載されています。 Cloudflareは、この世代のサーバー向けに1152GBのメモリ構成を検討しましたが、より大容量のメモリのコストを評価した結果、最終的には断念しました。
このメモリ空間を利用して、Cloudflare は DNS キャッシュ サイズを拡張する予定です。より多くのレコードをローカルに保持すると、キャッシュ ヒット率が向上し、権威 DNS サーバーへのリクエスト トラフィックが削減されることが期待されます。
Cloudflareが大規模なメモリ効率の最適化を実行したのはこれが初めてではありません。同社は昨年、リクエストの処理を担当する FL2 レイヤーも Rust コードに書き直した。サーバーのメモリ価格が上昇しているため、ソフトウェアの最適化を通じて既存のインフラストラクチャの可能性を引き出すことは、単にハードウェアを追加するよりもコスト効率が高い可能性があります。
コメント