# Cloudflareの100TBメモリ強奪作戦

> エンジニアたちは、新しいチップを1枚も購入することなく、130台のサーバーを稼働させるのに十分なRAMを解放しました。しかし、真の驚きはコスト削減ではなく、その過程で何が高速化したかという点にあります。

- Source: https://www.stork.ai/blog/ja/cloudflares-100tb-memory-heist
- Publisher: Stork.AI editorial team
- Published: 2026-09-11
- Updated: 2026-09-11
- Language: ja
- Reading time: 6 min

## 100テラバイトの課題

Cloudflareは最近、驚くべき**メモリ**の強奪作戦を実行し、グローバルネットワーク全体で100テラバイトの運用容量を解放しました。この目覚ましい最適化は、新しいハードウェアを1台も導入することなく、最新のGen 13サーバー130台分のRAM容量をインフラに追加したことに相当します。これほど大規模なメモリの回収は、低レベルなソフトウェア効率化がもたらす甚大な影響を浮き彫りにしています。

1.1.1.1、Gateway DNS、DNS Firewallといった重要なサービスを支えるCloudflareの**Big Pineapple**プラットフォームは、膨大な規模を管理しています。このシステムは常に2,500億件以上のDNSキャッシュエントリを保持しており、各エントリはインターネットルーティング情報の重要な断片として、毎日数十億件ものグローバルリクエストを処理しています。この巨大な規模ゆえに、わずかな非効率性が運用やコスト面で大きな課題へと変貌してしまいます。

Cloudflareにとっての核心的な課題は、一見些細なオーバーヘッドが積み重なることで生じる影響でした。2,500億件のDNSエントリにおいて、エントリあたりわずか1バイトの無駄が、**global fleet**全体では数百ギガバイトもの不要なメモリ消費へと膨れ上がります。このような広大なシステム全体で拡大される微細な非効率性は、貴重なリソースを消費するだけでなく、パフォーマンスに悪影響を及ぼし運用コストを増大させるため、データ構造の根本的な見直しが求められました。

## 5つの削減、1つの巨大な成果

Cloudflareは5つの精密なRustレベルの最適化を実行しました。それぞれがメモリ肥大化に対する外科手術のようなアプローチであり、最終的に100TBという巨大な成果をもたらしました。まず、エンジニアは不変のキャッシュエントリに対して、`Vec<T>`や`String`を`Box<[T]>`や`Box<str>`に置き換えました。これにより、事前割り当てされた容量や不要なヒープオーバーヘッドが排除され、エントリあたり64バイト、全体で15TB以上のメモリが即座に解放されました。

2つ目の重要な変更は、DNSレコードを完全に解析されたRustの構造体としてではなく、**raw wire-format bytes**として保存することでした。これにより、システムは冗長な解析やシリアライズを回避できるため、処理が効率化されました。また、より多くの関連データを少ないキャッシュラインに詰め込むことで、**cache locality**も大幅に向上しました。

さらに、レイアウトの工夫によってメモリの無駄を防ぎました。Cloudflareは`RecordData` enum内の`NAPTR`のような大きな**enum variants**をボックス化し、`A`や`AAAA`といった一般的で小さなレコードタイプが過剰なパディングを確保するのを防ぎました。これにより、メモリ割り当てが実際のデータサイズとより正確に一致するようになりました。

エンジニアはまた、3つに分かれていたDNS応答レコードリスト（answer、authority、additional）を1つの統合リストにまとめました。2バイトの`u16`オフセットを2つ使用してセクションを区切ることで、より大きなポインタ/長さのペアを置き換え、エントリあたり28バイトを節約しました。この統合により、データ構造が大幅に引き締まりました。

最後に、条件付きオーナー保存が5つ目の削減策となりました。Cloudflareは現在、オーナー名をキャッシュキーから推論できる場合は保存せず、クエリされたドメインと異なる場合のみ保存するようにしています。これらの粒度の細かい最適化を組み合わせることで、エントリあたりのフットプリントは953バイトから420バイトへと56%削減され、Cloudflareのメモリ環境を一変させました。

## 小さくすることで高速化

データ構造を縮小することは、多くの場合パフォーマンスとのトレードオフを意味しますが、Cloudflareの最適化は稀な二重の勝利をもたらしました。キャッシュ挿入のスループットは、毎秒625,000エントリから893,000エントリへと**43%**も大幅に向上しました。同時に、ルックアップレイテンシも828 nsから670 nsへと**19%**改善しました。

この高速化は魔法ではなく、メモリ密度の直接的な結果です。DNSキャッシュエントリあたりのメモリフットプリントを56%削減（953バイトから420バイトへ）することで、Cloudflareのデータ構造はよりコンパクトになりました。データが小さくなれば占有スペースも減り、CPUのより高速なL1、L2、L3キャッシュにより多くのキャッシュエントリを収めることが可能となり、**CPUキャッシュの局所性**が向上しました。

これはパントリーの整理に例えられます。パッケージが小さければ、頻繁に使うアイテムを手が届きやすい棚の前面により多く並べることができます。プロセッサは、低速なメインメモリ（RAM）からデータを取得する時間を減らし、これらの高速キャッシュから直接処理する時間を増やすことで、待機状態を劇的に短縮します。

リソース消費と処理速度の両面におけるこのような大幅な改善は、エンジニアリングの世界では稀であり、メモリ使用量と実行時間の典型的なトレードオフを覆すものです。Cloudflareは100テラバイトのメモリを解放しただけでなく、DNSリゾルバを明らかに高速化させました。技術的な詳細については、Cloudflareによる解説記事をご覧ください：[How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache](https://blog.cloudflare.com/dns-cache-memory-optimization-1111/)

## 効率化による波及効果

Cloudflareは、この解放された100TBの**メモリ**を遊ばせておくことはしません。その代わりに、この膨大な容量をグローバルネットワークに直接再投資し、特に1.1.1.1のようなサービスのDNSキャッシュを拡張します。この戦略的な割り当てにより、メモリ回収の効果を最大化し、技術的な成功を即座に運用上のアップグレードへと変えています。

DNSキャッシュの拡大は、世界中の数百万人のユーザーにとって直接的なメリットとなります。キャッシュヒット率の向上は、**DNS応答の高速化**を意味します。Cloudflareのサーバーは、アップストリームのルックアップを開始する代わりに、ローカルメモリからより多くのクエリを解決できるためです。これにより、インターネット体験の応答性と回復力が直接的に強化されます。

Cloudflareの成果は、業界に重要な教訓を与えています。それは、深いシステム最適化が依然として効率化のための強力な手段であるということです。**AIワークロード**の需要によりサーバーのメモリコストが上昇する中、ハードウェアを変更することなく既存のインフラを最適化して100テラバイトのメモリを回収することは、単なるエンジニアリングの偉業ではなく、戦略的な必須事項です。この緻密なRustレベルでの取り組みは、システムプログラミングにおける精密さの永続的な価値を強調しています。

## よくある質問

### Cloudflareは実際にどれくらいのメモリを節約しましたか？

Cloudflareは、1.1.1.1 DNSキャッシュを最適化することで、グローバルサーバー群全体で約100テラバイト（TB）のRAMを節約しました。これは、同社のサーバー130台分のメモリ容量に相当します。

### 最適化にはどのプログラミング言語が使用されましたか？

最適化はRustで実装されました。Rustが選ばれた理由は、そのメモリ効率、パフォーマンス、そしてデータ構造に対する低レベルな制御能力にあります。

### メモリを節約したことでDNSリゾルバの速度は低下しましたか？

いいえ、直感に反して、この最適化はパフォーマンスも向上させました。キャッシュ挿入のスループットは43%向上し、ルックアップのレイテンシは19%低下しました。

### どのようにしてメモリを節約したのですか？

節約は、DNSデータの保存方法に対する5つの主な変更によって実現されました。これには、ベクター内の未使用メモリ容量の排除、データリストの統合、レコードをrawバイトとしてより効率的に保存することなどが含まれます。

### Cloudflareは節約した100TBのメモリをどうしますか？

解放されたメモリは、DNSキャッシュのサイズを拡大するために再投資されます。これによりキャッシュヒット率が向上し、アップストリームへのクエリが削減されることで、ユーザーにとって1.1.1.1サービスがさらに高速化されることが期待されます。