Cloudflareはなぜ人気のないアイテムまでメモリにキャッシュするのか
(blog.cloudflare.com)Cloudflareがキャッシュ戦略を変更し、SSDの書き込み負荷を最大25%削減した経験をブログで公開しました。（英語） 通念とは異なり、Cloudflareはアクセス頻度が高くないアイテムもあえてメモリにキャッシュする方式で、この目標を達成しました。
SSDは書き込みに弱い記憶媒体です。SSDでデータを保存するフラッシュメモリセルには再書き込み可能回数の制約があり、一度書き込まれた内容を消去して再度書き込む作業は比較的長い時間がかかるだけでなく、読み取り処理まで巻き添えで遅くしてしまいます。したがってSSDでは、特に書き込み処理を減らすことが重要な最適化となります。
Cloudflareはサーバーに高性能なNVMe SSDを多く使用する事業者であるため、当然この点を検討していました。CloudflareはCDN事業者ですが、CDNとは本質的に巨大なネットワークキャッシュと言えます。CloudflareサーバーのSSDに保存される内容も結局はキャッシュされたアイテムですが、観察の結果、その中には一度キャッシュされたあと二度とアクセスされない内容、いわゆる「ワンヒットワンダー」が非常に多くありました。したがって、このようなアイテムはSSDに書き込まないほうが望ましいはずです。1回しかアクセスされないアイテムをSSDに記録しない方法を実験したところ、SSDのレイテンシがほぼ5%も低下するという心強い結果が得られました。
問題は、このアイデアをどう実際のサービス規模で適用できるかという点でした。1回目のアクセスではキャッシュせず、2回目のアクセスからキャッシュするということは、データのオリジンに対するアクセス量が2倍に増えることを意味します。もちろんそのぶんさまざまなコストが発生し、これでは本末転倒です。そこでCloudflareは、キャッシュ書き込みを2段階に階層化しました。最初はすべてのアイテムを「短期キャッシュ」であるメモリにキャッシュし、その後アクセス回数が複数回のアイテムだけを「昇格」させて、「永続キャッシュ」であるSSDに書き込むのです。そうすればアクセス頻度の低いアイテムは自然にキャッシュから押し出されます。読み取りについては別途気にする必要がありませんでした。SSDからの読み出しは、すでにOSがうまくキャッシュしてくれるからです。
もちろん、この発想を実際のサービスに適用する部分は慎重かつ保守的に進められています。この発想は基本的に多くのメモリを消費しますが、それがOSの既存キャッシュと競合する可能性があり、あるいはサーバープロセスを無停止デプロイ方式で更新している最中に一時的なメモリ不足が起き、結果的にサービス品質が悪化する可能性もあるためです。したがって上記のアイデアは、新たに導入した十分なメモリを持つサーバーでのみ適用する形で、段階的に導入されています。
導入結果は良好です。キャッシュ容量をチューニングしながら適用した結果、SSD書き込みは20%から最大25%まで減少し、これはレイテンシ低下につながりました。今後Cloudflareは、この手法をさらに多くのサーバーへ拡大し、昇格アルゴリズムを改善して「降格」も導入し、SSDだけでなくHDDまで考慮した階層構造を作る予定だとしています。
このアイデアを見て真っ先に思い浮かんだのは、Javaのガベージコレクション手法でした。大多数のガベージコレクション手法の基本前提は、まさに[ほとんどのオブジェクトはごく短時間しか使われない]という、いわゆる「弱い世代仮説」（weak generational hypothesis）だからです。こうした原理が少し形を変えて応用されたものが、上の内容なのではないかと思います。
3件のコメント
良い記事をありがとうございます。
Cloudflareのブログには、さりげなく読んでみる価値のある記事がたくさん上がってくる気がします。
良い企業の技術ブログはどう運営されるのか https://ja.news.hada.io/topic?id=1698
Cloudflare は、ブログ執筆が社内文化として定着しているからだと思います。
とても興味深かったです。ありがとうございます。
わあ……翻訳まで一度にできるなんて（笑）。良い内容の共有ありがとうございます。