Cloudflareがまた、大規模インフラでは「小さな無駄」がどれほど高くつくかを示す話を出してきた。今回はPingoraを使う社内の負荷分散サービスで、あるアルゴリズムのメモリ使用量を見直し、全世界で100TBを超えるRAMを取り戻したという。派手な新機能の話ではないが、こういう改善こそクラウド事業者の現場では効く。しかも今回は、Rustと少しの数学が主役だ。
元記事が扱っているのは、Cloudflareの内部負荷分散サービス「Pingora Backend Router」、略してPBRだ。PBRは、キャッシュ可能なリクエストをどのサーバーに送るかを決める役割を持っていて、その判断には consistent hashing を使っている。consistent hashing は、サーバーの増減があっても割り当てが大きく崩れにくい方法で、分散システムではよく使われる。Cloudflareではこの仕組みを open-source の pingora-ketama ライブラリで実装していた。
話の発端は、Cloudflare内部のIvanが出したチケットだった。内容は「Pingora Backend Routerで、pingora-ketama に関連する構造体が想定以上のメモリを使っている」というものだ。Cloudflareほどの規模になると、こうした数%の無駄がそのまま巨大なRAM消費につながる。記事では、すでにDNSチームが前月に100TBのメモリを削減していたことにも触れつつ、今回はそれに上乗せするかたちで、さらに100TB超のRAMを回収できたと説明している。
では何が重かったのか。pingora-ketama は consistent hashing を行うためのリングや順序付きの一覧を扱うが、その実装の一部が、必要以上にメモリを食っていた。Cloudflareはまず、なぜその構造がそこまで膨らむのかを分解していく。ここで出てくるのが、少しの数学だ。記事の流れは、単に「データ構造を置き換えました」ではなく、まず分布を理解し、どこに無駄が潜むかを調べ、そのうえで Rust らしいやり方で作り直す、というものになっている。
consistent hashing では、キーをハッシュしてリング状の空間に置き、サーバー側の点に最も近いものへ振り分ける。サーバー数が増えたり減ったりしても、再配置されるリクエストが少なくて済むのが利点だ。Cloudflareの説明では、PBRはこの仕組みでURL単位のルーティングを行っていた。一方で、実装の中には「間隔の管理」や「分布の偏り」を扱う部分があり、そこがメモリ効率の悪さにつながっていた。そこで、アルゴリズムを少し変え、データの持ち方も見直すことで、同じ振る舞いを保ちながら使用量をかなり削減した、というのが記事の核だ。
この改善は、Cloudflareのネットワーク全体で見ると相当に大きい。1台あたりでは小さく見える節約でも、世界中の多数のサーバーに展開されれば合計は一気に膨らむ。記事はそこを強調していて、個々の最適化を「塵も積もれば」ではなく、インフラ経済の話として扱っている。Rustが使われているのも印象的で、メモリ安全性や性能だけでなく、こうした細かい改善を実装しやすい言語特性が背景にあることがうかがえる。
この話でまず面白いのは、節約の単位が「GB」ではなく「100TBを超えるRAM」だという点だ。普通のプロダクト記事なら、ここまでの数字はかなり誇張に見える。でもCloudflareのように、同じ仕組みを世界中の巨大な分散基盤に展開している会社だと、1つの構造体やアルゴリズム変更が、総量ではとんでもない差になる。私はここに、クラウド運用の本質がよく出ていると思う。派手な新技術より、既存機能をより安く、より薄く回すほうが、会社全体ではずっと大きい。
もう1つ引っかかるのは、「数学で削減した」という言い方が決して大げさではないことだ。メモリ最適化というと、キャッシュを減らす、型を小さくする、再利用する、といった実装上の工夫を思い浮かべがちだが、今回は分布そのものを見直している。つまり、どういう入力にどういう偏りが起きるかを理解して、そこに合わせて持ち方を変えた可能性が高い。ここでは、雑な直感よりも、統計や確率に近い見方が効く。大規模システムでは、こうした「分布の理解」がそのままコスト削減になるのだろう。
CloudflareがPingoraまわりの話を頻繁に出すのは、単なる技術広報ではないと思う。Pingoraは新しい配信・ルーティングの土台で、その上にいろいろな社内サービスが乗っている。だから、ここを少し直すだけで効果が何重にも跳ね返る。今回のPBRもその例で、負荷分散の中心にあるロジックを磨いた結果、全社レベルのRAMを回収できた。これは「基盤を自前で持つ会社」の強さでもあり、同時に責任でもある。基盤が重ければ、その重さは全サービスに広がるからだ。
一方で、こうした最適化は外から見ると地味すぎて見落とされやすい。新機能でもなく、見た目の改善でもなく、ユーザーは気づかない。しかしインフラでは、その「気づかれない改善」こそが利益率や余剰容量に直結する。私は、Cloudflareがこの種の記事を出すのは、技術自慢というより、内部での改善文化を外にも見せたいからではないかと思う。しかも Rust を絡めているのがうまい。安全に速く書けるだけでなく、こういう低レベルの調整を現実のコードに落としやすい言語として、Rustの立ち位置がますます強く見える。
最近はAI基盤やGPUの話が目立つが、実際のクラウドコストを左右するのは、もっと古典的なCPU・RAM・ネットワークの積み上げだ。今回のようにRAMを100TB単位で削れるなら、機材の台数、再配置の余裕、障害時のバッファまで変わってくるはずだ。つまり、これは単なる節約ではなく、運用の自由度を買い戻す話でもある。余白が増えれば、障害対応もしやすいし、将来の機能追加にも耐えやすい。
ただし、ここで安易に「みんなも最適化を頑張るべき」と言うのは違うと思う。大規模サービスでしか成立しない改善は確かにある。重要なのは、Cloudflareがその規模に達したからこそ、どの無駄を潰すと効くのかを定量的に見極めている点だ。小手先の省メモリではなく、実運用に効くところへ手を入れている。だからこの記事は、Rustの話でもあり、数学の話でもあり、同時に「大きいシステムを維持するとは何か」の話でもある。
