Cloudflare、数学とRustで100TBのRAMを節約

私の理解は正しいだろうか。つまり彼らは、サーバーごとにかなり大きなN個のハッシュ値をメモリに保存し、リクエストのハッシュが、全サーバーハッシュのうち最も近い上位の値を使ってどのサーバーに送るかを決定する、ということをしたのだろうか？

それは結局、重みとサーバー総数の関数である確率PでサーバーSを一貫して選択することに帰着するのではないだろうか？

ハッシュの巨大なルックアップテーブルを保存せずに、与えられた確率でサーバーを選択するもっと良い方法がきっとあるはずだ。何らかのRendezvousハッシングとか。

Cloudflareは本当に素晴らしい。私のメインのサイドプロジェクト（http://sourcelibrary.org）にとって、とても多くのことを可能にしてくれて、その価格と性能にはとても自分の手柄とは言えない。彼らの文章がAIで書かれていようと気にしない。ただ、自分のAIにもハッシングについてこんなに上手に歌わせられたらいいのにと思うだけだ…でも待てよ…今日、Claudeがタイムスタンプで十分な場面でハッシングを使おうとしているのに気づいて、今は本当に自分を疑い始めている、うーん…

私は一貫性ハッシングとketamaを捨てて、さらに600TiBを節約できるより良いシステムにしたい。

キーハッシュの最初のNビットを使ってサーバーパーティションを選ぶ。そうすれば妥当な数になる（例：パーティションあたり128サーバー）。次に、サーバー名の高品質な事前計算済みハッシュ（sha256の最初の64ビット）を、H(K + N)のNとして使う。Hとしてwyhashのwymumを使えば、o(n)の整数乗算を行いつつ、統計的には依然として良いハッシュである結果を保てる。

これでトーナメントハッシュを使うことになり、小さなNのおかげでO(N)とO(N log N)の違いは問題にならない。また、このO(N)は現在のようにキーごとに160個のハッシュを計算するよりもはるかに少ないCPUで済むので、リクエストごとに追加されるレイテンシもずっと少なくなる。

こういうのを見ると、ソフトウェア開発がほとんどの仕事の失われる場所になる時代に突入しようとしているのだと思う。これはワンショットのバイブコーディングでどうにかなるものではない。しかし、きちんとしたソフトウェアエンジニアリングにおいては、個人が提供する問題はどんどん大きくなるばかりで、ますます多くの問題が数学を創造的に使って実際に解決される必要が出てくるので、そうした仕事は安全だ。人々はただ、低くぶら下がっている果実を失ったことを嘆いているだけだ。

これらの最適化は印象的だが、考えさせられる。企業はどの時点で、何も期待通りに動かない、不可解なサイロの集まりになってしまうのだろうか？AIのおかげでコードベースの探索もずっと速くなったので、今はこれはあまり問題ではないのかもしれない。

素晴らしい記事だ！日常のプログラミング業務であまり（ほとんど）微積分をやる機会がない者として、Kevinがその導出（補足記事にリンクされている）に踏み込んでいるのを読むのはとても楽しかった。ここで否定的なことを言っている人たちはレーズンを飲み込めばいい。

Rustのセクションは、ハッシュを格納する構造体に関するストレージ改善の部分だけだが、2バイトが大きな違いを生むほど本当にそんなに多くのハッシュが必要なのだろうか？記事では詳しく説明されていないが、おそらく全てのコンピュータ上の全てのタスクに対するハッシュなのだろうから、まあそうなのかもしれない。