要約

  • PHK として広く知られる Kamp は、Verdens Gang が本番用の Web アクセラレータを発注した後、アプリケーション層のキャッシュマネージャを別途用意する代わりにオペレーティングシステムの仮想メモリを利用して、Varnish Cache の原型を設計・実装した。
  • FreeBSD の各リリース、jails、GEOM、timecounter、基本システムのプリミティブにわたる彼の仕事は、状態を「所有権と障害境界が明確な再利用可能なレイヤー」に置くという一貫した規律を反映している。
  • VCL、プロセス分離、共有メモリログによって Varnish のリクエスト経路は狭く保たれ、その一方で HTTP ポリシー、カーネルの挙動、拡張機能、周辺の配信システムに大きな責任が移される。
  • Beer-Ware や Moral License、スポンサーシップの実験は、技術的ミニマリズムの経済的な裏面を浮き彫りにする。機械の仕事は減らせても、セキュリティ、リリース、専門的な人手による保守には依然として資金が必要だからだ。

Verdens Gang は「引き算による性能」を本番環境で試した

Varnish Cache は 2005 年ごろ、ノルウェーの新聞社 Verdens Gang（以下 VG）が抱える本番環境の問題から始まった。同社は、トラフィックの急増を吸収しバックエンドの仕事を減らせる Web アクセラレータを必要としていたが、既存のキャッシュソフトウェアが抱える複雑さやボトルネックを再現するものは望んでいなかった。Poul-Henning Kamp は VG の支援を受けて初期システムを設計・実装し、プロジェクトは 2006 年に公開された。

決定的な選択は、アプリケーションレベルのキャッシュマネージャを廃することだった。Varnish はキャッシュしたオブジェクトをアドレス空間にマッピングし、どのページをメモリに残すかをオペレーティングシステムの仮想メモリ機構に任せた。アプリケーション側は HTTP ポリシー、リクエスト処理、オブジェクトのメタデータに専念した。VCL がキャッシュの判断を表現し、管理プロセスが設定とワーカーのライフサイクルを制御し、共有メモリログが大量の監視データを同期式のリクエスト書き込みから切り離した。

これらの選択は高速さという評判を生んだが、より深い効果は責任の移転だった。カーネルのメモリ挙動の重要性が増し、コンパイルされたポリシーは強力であると同時に危険なものになった。役割を絞ったプロキシは、その範囲外の機能について隣接するシステムを必要とした。「引き算による性能向上」は全体を単純にしたのではなく、状態の所有者をより明確にしたのである。

Kamp はこの勘所を、FreeBSD のリリースエンジニアリング、jails、GEOM、timecounter、その他のカーネル・基本システムのプリミティブを通じて培ってきた。その後の精密な時刻計測、オープンソースの資金調達、プロジェクト運営に関する仕事は、同じ問いをコードと組織に当てはめている。すなわち、その仕事をすでに所有しているレイヤーはどこか、別のレイヤーを取り除いたときに生まれる依存関係は何か、という問いである。

核となる問いは、「減らすこと」が、運用しやすく引き継ぎやすいシステムを生むのか、それとも単に複雑さを、運用者がもはや見通せない場所へ移すだけなのか、ということだ。Kamp の実績が最も説得力を持つのは、削った後に明確なインターフェース、観測可能な障害経路、そして残った責務を担う用意のあるメンテナーが残る場合である。

リリースエンジニアリングはインターフェースの約束を見える化した

Kamp が 386BSD と FreeBSD のコード系統と関わるようになったのは、プロジェクトの運営とアーキテクチャがまだ完全に定まらない時期だった。本人による回顧録では、1994 年初頭から約 6 年間 FreeBSD コアチームに在籍し、FreeBSD 2.x のリリースエンジニアリングと、カーネルおよび基本システムにまたがる仕事を担当したとされている。

リリースエンジニアリングが重要な出発点なのは、開発者にオペレーティングシステムを「パッチの集合」ではなく「納品物」として見ることを強いるからだ。コードは一体としてビルドでき、アップグレードが可能で、開発の議論についていなかった利用者にも障害が理解できるものでなければならない。リリースエンジニアは、技術的な野心と、人々が実際にインストールできるシステムとの境界で仕事をする。

Kamp の貢献リストには、VFS ネームキャッシュ、sysctl、メモリ割り当て、デバイスシステム、安全な文字列バッファ、jails、GEOM、ディスク暗号化、timecounter が含まれる。このリストは一部、本人による一次記録に基づいており、コミット単位の帰属に取って代わるものではない。これらの多くは他の人々と共同で開発され、彼の当初の仕事の後に大規模な保守が続けられた。それでも、その広がりは、Varnish が生まれた設計環境を描写するものとしては十分に裏付けられている。

オペレーティングシステムのプロジェクトは、無関係なアプリケーションが再利用できる仕組みに報いる。ネームキャッシュはシステム全体のパス解決を改善する。timecounter はハードウェアクロックの共通抽象化を作る。GEOM はストレージ変換を合成可能にする。jails はホスト型サービスを包み込むのではなく、隔離のモデルを提供する。この方向性は、Kamp が後に Varnish で問うた疑問を促す。アプリケーションは、カーネルの一般的な仕組みを再実装する代わりに、それに頼ることはできないだろうか、と。

FreeBSD はまた、運営の経験ももたらした。Kamp は初期のコアチームに籍を置き、2000 年ごろにプロジェクトが選挙制へ移行するのに合わせてその正式な役割を離れた。技術的な関与は続いたが、現在の FreeBSD の権限は現役のコミッターと現在の Core Team に属している。歴史上のリーダーシップは、永続する肩書きではない。

この区別が重要なのは、オープンソースにおける影響力は、正式な役職が終わった後も続きうるからだ。サブシステムは、一人の設計者の選択を数十年にわたって内包できるが、その後を継ぐメンテナーが実装とポリシーを変えていく。永続する貢献とは、他人が所有できる実用的な抽象化であって、無期限の支配権ではない。

Kamp の FreeBSD での実績は、リリースエンジニアリングを中心に置かないと、無関係なカーネル仕事の目録のように見えるかもしれない。リリースとは、個々の変更が一つのオペレーティングシステムになる場である。すべてのサブシステムが同じインターフェースに対してビルドでき、インストールメディアが利用者に届き、デフォルト設定が弁護可能で、変更が以前の状態からのアップグレードに耐えなければならない。

Kamp が FreeBSD 2.x のリリースに歴史的責任を負っていたことは、バージョン番号を超えて意味を持つ。リリースの仕事は、自分のコードだけを見ている開発者が無視できる依存関係を明らかにする。デバイスの変更はインストーラを壊しうる。ライブラリのインターフェースはサードパーティ製ソフトウェアを立ち行かなくさせうる。新しいカーネルの仕組みは、ドキュメント、ツール、ロールバックが欠けていれば、技術的には妥当でも運用上は使えないものになりうる。

この背景は、後の Varnish の形を説明するのに役立つ。このキャッシュは、実装チームを待つ論文上のアルゴリズムとして設計されたわけではない。出版社が稼働させ、観測し、変更する必要があるソフトウェアとして生まれた。管理プロセス、VCL の読み込み、共有ログ、実行時パラメータは、高速なループに運用経路がなければ Verdens Gang の問題を解決できなかったため、システムの一部になったのである。

リリースエンジニアリングはまた、永続的な互換性の負債への抵抗も促す。いったんインターフェースが公開され、利用者がそれを中心に構築すれば、取り除くコストは高くなる。弱い抽象化を拒否する最も安全な場は、それがリリースの一部になる前だ。Kamp の著作は狭い契約と明確な所有権を好むことが多い。なぜなら、追加されたすべての面は、やがて誰かの保守の義務になるからだ。

証拠は、FreeBSD 2.x のすべてのリリース決定を一人に帰属させることを支持しない。それは、Kamp が統合の境界で仕事をした時期があったことを支持する。その役割は実践的な教訓をもたらした。アーキテクチャとは、利用者が次のリリースで守られることを期待する約束の蓄積でもある、ということだ。

インフラストラクチャの購入者にとって、これはプロトタイプと保守されたシステムの有用な区別である。プロトタイプは仕組みを実証する。リリースプロセスは、メンテナーがその仕組みをパッケージ化し、限界を伝え、退行を修復し、利用者を前進させられることを実証する。Varnish の長寿命は、当初のストレージ設計と同じくらい、この第二の規律に依存している。

小さなプリミティブは、長く価値を保ちつつ時代の前提も帯びた

Kamp の FreeBSD への貢献のいくつかは、運用者が購入したり気づいたりするような製品ではなかった。それらは基本システムのプリミティブだった。ネームキャッシュ、メモリ割り当て、sysctl、動的文字列構築、デバイス基盤である。その価値は、他のコードが行う仕事のコストや安全性を変えることにあった。

VFS ネームキャッシュは、同じファイルシステム名が再び使われるときに、高コストなパス解決を繰り返すことを避ける。正確な実装は進化しており、功績は共同のものだが、設計上の問題は永続する。ファイルパスは、ストレージオブジェクトの上に置かれた人間可読な名前空間である。その関係をキャッシュすることはシステム全体の性能を改善できる一方、古くなった、あるいは誤って無効化されたエントリはファイルシステムの見え方を壊す。これは、後に HTTP キャッシュで見られるのと同じ取引のコンパクトな例である。再利用には、無効化のルールが正しい場合にのみ価値がある、という取引だ。

Kamp の歴史的なアロケータ仕事であるphkmallocは、もう一つの一般的なコストに対処した。汎用の割り当てはほとんどすべてのサービスの下にあり、アロケータの挙動は断片化、ロック、局所性に影響する。歴史的な実装を、現在のすべてのシステムに対する答えとして提示すべきではない。その関連性は、性能の仕事が、測定されている機能よりも下の層から始まることが多いという点にある。Web キャッシュは、HTTP ロジックが効率的でも、割り当てとオブジェクトの寿命によって制限されうる。

sbufの仕事は、カーネルと基本システムのコードにおける、より安全な動的文字列構築を提供した。部分的なデータから構築される文字列は、切り詰めやメモリエラーの日常的な発生源である。共有プリミティブはすべての呼び出し元を正しくはしないが、各サブシステムがバッファ管理を場当たり的に実装する必要性を減らす。これはシステムズエンジニアリングの静かな形態である。多くの将来の呼び出し箇所から、繰り返されるエラーの発生源を一つ取り除くのである。

デバイスと DEVFS の仕事は、ハードウェアがソフトウェアにどう見えるかを扱った。デバイスは、ライフサイクル、命名、権限という問題を伴う物理的または仮想的なリソースである。一貫した名前空間と接続モデルがあれば、後のドライバや管理ツールは、それぞれが独自の規約を発明することなく、それらを扱える。

これらの貢献を、Kamp が FreeBSD の近代的な基本システムを一人で設計したという主張にまで拡張すべきではない。彼自身の記録は一次的な証拠であり、後の開発者たちが大規模な仕事を行った。擁護できる結論は手法についてである。彼は繰り返し、上の呼び出し元の数に応じて利益が増幅されるインターフェースに取り組んだ。

この増幅は、従来のプロフィールでは見落とされがちだ。安全な文字列プリミティブや、より予測しやすいクロック抽象化から誰が利益を得たかを示す顧客ロゴは存在しないからである。インフラストラクチャの価値は、重複したコード、回避可能なクラッシュ、繰り返される I/O が「ない」こととして現れることが多い。その仕事が目に見えるのは、プリミティブが失敗するか、置き換えなければならなくなったときだけだ。

Kamp の実績には、GBDE ディスク暗号化と、一般に MD5crypt と呼ばれるパスワードハッシュ形式も含まれる。両方とも彼のシステム仕事の完全な記録に属し、両方ともしっかりとした歴史的境界を必要とする。

GBDE は FreeBSD のストレージ内で暗号変換を適用した。これは、ブロックデバイスの周りで機能を合成するという GEOM 時代の関心に合致する。ただし、現在の FreeBSD 利用者には他の選択肢があり、現在のセキュリティ推奨は脅威モデル、実装、サポートに依存する。初期の暗号化設計は、機密性と鍵依存型ストレージへの取り組みの証拠であって、歴史的な仕組みを新規導入に選ぶべきだという証拠ではない。

MD5crypt は、単純な高速 MD5 ハッシュを、ソルトと繰り返し作業を伴う形式で強化する必要があった時代に、パスワード保存用に設計された。この形式は Unix 系システムとネットワーク機器に広まった。現代のパスワードセキュリティは、意図的に高コストでメモリを意識したパスワードハッシュへと移行している。安価な汎用ハッシュは大規模な推測攻撃に弱いからだ。正しい編集上の扱いは「期限付きの影響力」である。ある設計がある時代の実務を改善し、後に不適切になりうる、という扱いだ。

この「時代付け」の規律は、インフラストラクチャジャーナリズムにおいて特に重要である。古いソフトウェアは、指針が変わった後も、アプライアンスや組み込み製品の中に残り続ける。「広く展開されている」という呼び方は、技術的負債を説明しているのに、まるで推奨のように聞こえることがある。著者を称賛しても、それを使い続ける後のベンダー判断のすべてに責任が移るわけではない。

この原則は、Varnish の設定、FreeBSD のサブシステム、時刻プロトコルにも当てはまる。機能名は安定していても、実装や脅威の前提は変わることがある。プロフィールは、当初の問題、歴史的貢献、現在の保守、そして現在の導入助言を分離すべきである。

Kamp がエッセイやコンピュータ史の仕事で古いシステムを再訪する姿勢は、その分離を編集上の厄介ごとではなく主題そのものにしている。システムエンジニアは、自分たち自身の過去の決定を引き継ぐ。成熟した実践は、なぜその選択が妥当だったか、何が変わったか、初期の仕事が無意味だったかのように装わずに利用者がどう移行できるかを記録する。

jails は隔離を、アプリケーションの慣習ではなくカーネルのプリミティブにした

FreeBSD の jails は、ファイルシステム、プロセス、ネットワーク、管理上の制限を組み合わせることで、プロセス隔離を伝統的なchrootモデルを超えて拡張した。この発想は、複数のサービス環境が一つのカーネルを共有しながら、システムの制約されたビューを見ることを可能にした。

Kamp の初期の貢献は文書化された歴史の一部であり、その後の jail 開発ははるかに広い FreeBSD コミュニティに属する。この区別は、jails が大規模な運用機能群へ進化したために特に重要である。創設者はモデルを確立できても、その後のすべてのセキュリティ境界、管理ツール、展開に責任を負うわけではない。

アーキテクチャ上の関連性は明確だ。隔離は、各アプリケーションが同意して振る舞うよりも、カーネルが強制する方が信頼できる。jail に入れられたプロセスは、設定と共有カーネルの脅威モデルに従って、他のプロセスグループやネットワークリソースを見ることを制限されうる。運用者は、別々の物理マシンより低いオーバーヘッドで、影響範囲を縮小してサービスを実行できる。

jail は、あらゆる脱出やカーネル脆弱性に対する保証ではない。環境は一つのカーネルを共有する。特権設定とデバイス露出は重要だ。ネットワーク設計は隔離を弱体化させうる。この仕組みは権限を減らし、より明確な境界を作るが、セキュリティエンジニアリングの必要性をなくすわけではない。

この考え方は、Varnish の管理プロセスとワーカーの分離にも再び現れる。トラフィックを処理する子プロセスは、すべての管理特権を必要としない。親は子を再起動し、設定を制御できる。プロセス境界は、一つの巨大なプロセスが正しく動き続けると想定する代わりに、障害の帰結を割り当てる。

jails はまた、プリミティブの経済的価値を示す。ホスティングプロバイダやシステム管理者は、それぞれが独自の仕組みを発明することなく、隔離を中心にサービスを構築できる。カーネルプロジェクトが境界の保守コストを吸収し、利用者はその利益とバグの両方を引き継ぐ。この移転は、所有権と更新経路が明確であれば許容できる。

GEOM はストレージを合成可能な変換のグラフとして扱った

ストレージシステムはしばしば機能を階層化する。ディスクは、パーティション分割され、ミラーリングされ、暗号化され、ラベル付けされ、さらに別の抽象化を通じて公開されることがある。一貫したフレームワークがなければ、各機能が独自のデバイス検出と I/O 配管を持つことになり、重複と厄介な相互作用が生まれる。

GEOM は FreeBSD に、ストレージ変換を合成するためのモジュール式フレームワークを提供した。プロバイダとコンシューマがグラフで接続され、クラスがパーティション分割、ミラーリング、暗号化などの操作を実装できる。このフレームワークは、ストレージレイヤーがどう接続し、どう I/O を渡すかについて、カーネルに共通言語を与える。

Kamp は主要な設計者・貢献者として文書化されている。後の GEOM クラスと保守はプロジェクトに属する。その意義は、やはり完全な製品ではなく仕組みにある。複数の機能が、それぞれが私的なスタックになることなく共存できるように契約を定義することだ。

合成にはコストがある。各レイヤーは、メタデータ、障害挙動、回復要件を追加しうる。暗号化レイヤーは鍵を必要とし、ミラーは状態の整合を必要とし、パーティションレイヤーは独自のジオメトリを持つ。コードではエレガントなグラフも、基盤のデバイスが故障し、運用者が変換の順序を理解していないときには、修復が難しくなりうる。

したがって GEOM は、Kamp のシステム哲学の両面を反映している。明確なインターフェースは、重複した実装を減らす。しかし、それらのインターフェースから組み立てられたシステムを理解する義務から運用者を解放するものではない。汎用プリミティブは、どのチームもテストできないほどの多くの組み合わせを可能にする。

Varnish との比較は、Web キャッシングとブロック I/O が同じだということではない。両方のシステムが、どのレイヤーが状態を所有すべきか、変換を必要以上にコピーしたり隠したりせずにどう合成するかを問うているのだ。カーネルにまたがる Kamp の仕事は、アプリケーション開発者がしばしば避けるオペレーティングシステムの抽象化に対する実践的な信頼を彼に与えた。

timecounter は時計をシステムの責任にした

オペレーティングシステム内の信頼できる時刻は、ハードウェアクロックが食い違い、ドリフトし、停止し、あるいは異なる解像度と安定性を提供するまでは、単純に聞こえる。アプリケーションは単調で正確な時間軸を望む。カーネルは、すべてのサブシステムに発振器の挙動を理解させることなく、ハードウェアソースと補正機構を組み合わせなければならない。

FreeBSD の timecounter の仕事は、ハードウェア時刻ソースの上に抽象化を作った。Kamp の貢献は、カーネルの時刻管理とその後の保守というより広い歴史に属する。このモデルは、システムが品質に応じてカウンタを選択・利用し、共通インターフェースを通じて時刻をオペレーティングシステムの他の部分に公開することを可能にした。

この仕事は、Kamp が長年関心を続ける NTP、PTP、ハードウェア参照、そしてレガシーな時刻プロトコルの弱点へとつながった。時刻インフラは、発振器、ネットワーク遅延、カーネルの規律、運用監視を組み合わせる。プロトコルメッセージが正しくても、ローカルクロックが不安定なことがある。高解像度のカウンタが精密であっても不正確なことがある。ネットワーク経路は、単純な往復時間の推定では除去できない非対称な遅延をもたらすことがある。

時刻管理は HTTP キャッシングとはかけ離れて見えるが、アーキテクチャ上の問いは似ている。補正を所有すべきレイヤーはどこか。どの状態が権威を持つのか。システムは、誤解を招く一つの数値ではなく、不確実性をどう公開するのか。時刻ロジックをすべてのアプリケーションで重複させることは、強力なカーネルとプロトコルの境界を維持するより悪い選択だろう。

運用上の重要性は高い。ログ、分散トランザクション、証明書、測定は時刻に依存する。エラーはイベントを順不同に見せたり、セキュリティ判断を無効にしたりしうる。インフラは、一台のサーバへの盲目的な信頼ではなく、独立した監視とフォールバックに値する。

Kamp の最近の著作と実験的な仕事は、時刻を引き続きシステム問題として扱っている。公開記録が示すのは持続的な関心であって、一つの実装が NTP や PTP を置き換えたという主張ではない。その価値は、時刻を「持ち主のないユーティリティ」として受け入れるのではなく、ハードウェアからプロトコル、カーネルを通ってエンジニアリングするよう主張することにある。

timecounter、NTP、PTP の実験、時刻ハードウェアに関する Kamp の仕事は、Varnish の隣に第二の技術的な柱を形成する。時刻は、オペレーティングシステムが一度取得して配布すればよいサービスのように見えるかもしれない。実際には、マシンは不完全な発振器、ハードウェアカウンタ、割り込みとスケジューリングの遅延、カーネルの変換、同期プロトコル、そしてエラー許容度の異なるアプリケーションを組み合わせている。

FreeBSD の timecounter 抽象化は、カーネルが利用可能なハードウェアソースから共通インターフェースを通じて時刻を得ることを可能にする。カウンタは、高周波数、限られた幅、ドリフト、ロールオーバー挙動、プラットフォーム固有のアクセスコストを持ちうる。カーネルはそれらのティックを有用なタイムベースに変換し、デバイスの癖がすべてのアプリケーションに漏れないようにしながらソースを選択しなければならない。

これは、状態を正しいレイヤーに置くもう一つの例である。アプリケーションがそれぞれハードウェアカウンタを読み、補正を発明すべきではない。カーネルは、一貫したシステムクロックを維持し、共通インターフェースを通じて公開する立場にある。ネットワークプロトコルは、外部参照に対するオフセットと周波数を推定できる。監視は、ローカルクロックまたは参照経路が信頼できなくなったときにそれを検出できる。

NTP と PTP は、関連するが異なる運用上の問題を解決する。NTP は一般ネットワーク全体に時刻を配布し、変動する遅延と不完全なサーバに耐えなければならない。PTP は、ハードウェアタイムスタンプとネットワークサポートを備えた管理された環境で、はるかに厳密な同期を提供できる。どちらのプロトコルも、発振器の物理、経路の非対称性、または悪い運用設計を取り消すことはできない。

Kamp によるレガシープロトコルと実装選択への批判は、技術的主張として扱うべきであり、自動的にコンセンサスと見なすべきではない。その重要性は、隠れた連鎖を明示的にすることにある。ログやパケットキャプチャのタイムスタンプは、ハードウェア、カーネル、プロトコルの決定の出力である。それらのレイヤーが食い違うとき、分散システムはイベントの順序を誤り、証明書を無効にし、測定を壊し、インシデントの再構築を信頼できないものにする。

Varnish との関連は、Web キャッシュに実験室級の時計が必要だということではない。それは、「一つのレイヤーが測定を所有し、システムの他の部分が信頼できる十分な証拠を公開しなければならない」という繰り返しの主張である。キャッシュの寿命、ログのタイムスタンプ、タイムアウトは、すべて時刻に関する決定である。クロックが不安定であるか、その不確実性が隠されているなら、より上位の正しさを証明するのは難しくなる。

精密時刻の仕事はまた、独立したエンジニアリングの限界を示す。参照実装や実験的なデーモンを構築すればプロトコルの問題は明らかになりうるが、本番の時刻サービスは、ハードウェア供給、ネットワークトポロジ、カーネル統合、長期間の観測、そしてドリフトに対応する運用者に依存する。単一の実装がその連鎖を制御することはない。

顧客が出資したプロジェクトがアーキテクチャをオープン製品に変えた

発注関係が中心にある。Varnish は人為的な競争に勝つために発明されたのではない。そこには顧客、ワークロード、運用からのフィードバックがあった。ニュース出版社にはトラフィックの急増、頻繁に変わるコンテンツ、需要下でレイテンシが問題になるバックエンドシステムがある。キャッシュはオブジェクトを素早く提供し、間違ったオブジェクトを提供しないようにしなければならない。

初期資金はまた、オープンインフラがどう始まりうるかを示す。顧客が具体的な問題の解決に支払い、できたコードが広く使えるように公開される。コミュニティは他のワークロードをテストし、システムを改善できる。スポンサーは、クローズドな製品を所有することなく解決策を得る。

公開されている証拠は、契約の全額や条件を明らかにしない。それは、起源と本番環境での関係を裏付けるのであって、金額の見積もりではない。VG の役割を Varnish の現在の所有権に転換すべきではない。Kamp の作者としての立場を、すべての展開の所有権に転換すべきでないのと同じだ。

既存のキャッシュを拡張するのではなく新しいキャッシュを始めるという決定は、アーキテクチャ上の判断を反映していた。Kamp は、従来のアプローチが古いオペレーティングシステムの前提を引きずり、カーネルのキャッシュを重複させていると信じていた。クリーンな設計は、現代の仮想メモリと狭い HTTP アクセラレーションの範囲を活用できた。

ゼロから始めることにはリスクもある。成熟したプロジェクトには、何年分ものプロトコルのエッジケースが含まれる。新しい実装は、テストとインシデントを通じてそれらを学ばなければならない。本番のスポンサーは、それらの前提を早期に突きつけられる環境を提供した。

仮想メモリがキャッシュマネージャになった

Varnish を特徴づけるストレージの選択は、メモリマッピングを使い、ページの常駐をオペレーティングシステムに管理させることだった。キャッシュされたオブジェクトはアドレス空間で表現でき、どのページを RAM に残し、どのページを回収するか、あるいはストレージに裏打ちするかはカーネルが決めた。

この設計は、アプリケーション内に二つ目のキャッシュ置換システムを持つことを避けた。従来のキャッシュは、オブジェクトをメモリで追跡し、ファイルに書き出し、後でカーネルのページキャッシュを通じて読み直すかもしれない。そこではコピーと重複した状態が生まれる。Varnish はマッピングされたデータを参照し、ページフォールトや追い出しにオペレーティングシステム全体のメモリ判断を反映させることができた。

これは時折、Varnish はインメモリキャッシュだと要約される。その言葉は不十分だ。このアーキテクチャはファイルまたはメモリに裏打ちされたストレージを使え、オペレーティングシステムは圧力に応じてページを移動させうる。ディスクが存在しないわけではない。それは、従来の形のユーザースペースによるオブジェクト I/O エンジンではなく、仮想メモリの挙動を通じて管理される。

この手法はカーネルに依存する。ページ置換、ライトバック、ファイルシステムの挙動、アドレス空間の制限は性能に影響する。無関係なプロセスからのメモリ圧力は常駐を変えうる。コンテナや仮想マシンはホストと相互作用する制限を持つことがある。運用者には、キャッシュヒット率だけでなく、システムレベルの可観測性が必要だ。

利得はリクエスト経路の仕事の削減である。オブジェクトは、再利用のたびに複数のバッファを通じてコピーされたり、アプリケーションロジックが同期式に読み出したりする必要がない。CPU は、HTTP の判断とネットワーク I/O により多くの時間を使える。

この設計はまた、信頼に関する表明でもある。Kamp は、アプリケーション開発者がしばしば再実装する仕事を、成熟した仮想メモリシステムに任せることを信頼した。その信頼はカーネルの経験に裏打ちされていた。すべてのアプリケーションがストレージを委譲すべきだという普遍的な法則ではない。耐久性、アクセス、制御の要件が異なるワークロードは別の設計を必要とするかもしれない。

したがって、Varnish の性能の評判はワークロードの範囲内で述べられるべきだ。キャッシュ可能性、オブジェクトサイズ、バックエンドレイテンシ、リクエスト構成、メモリ、カーネル、設定はすべて重要である。ベンチマークは、そのテスト範囲内での挙動を証明するのであって、あらゆるプロキシや CDN に対する永続的な優位性を証明するものではない。

Varnish のメモリマッピング設計は、仮想アドレス空間が物理 RAM についての表明だと扱われると、最も誤解されやすい。オブジェクトをマッピングすると、カーネルがページを提供できるアドレスがプロセスに与えられる。マッピングされたすべてのページが同時に常駐する必要があるわけではない。

この区別は大きなアドレス空間を有用にした。アプリケーションは、すぐに常駐するメモリより大きいキャッシュを参照でき、どのページがアクティブかはオペレーティングシステムが決めた。アドレス空間が制約されたシステムでは、物理ストレージが尽きる前でも、マッピングの数とサイズが限界になりえた。

したがって、レジデントセットサイズは容量分析の一部にすぎない。運用者は、マッピングされたストレージ、ページフォールト、回収、ファイルシステムの裏打ち、他のプロセスからの圧力を理解する必要がある。コンテナの制限は、ホストに空きメモリがあっても実効挙動を変えうる。スワップや高頻度のフォールトは、正しさを保ちながらレイテンシを壊すことがある。

このアーキテクチャはアプリケーションレベルの追い出しエンジンを避けるが、追い出しをなくすわけではない。その決定をカーネルポリシーへ移す。そこで Varnish は直接の制御を減らし、システム全体の知識から利益を得る。この取引は、オペレーティングシステムが信頼され、ホストが「隠れた相互作用を持つ隔離されたアプリケーションクォータ」ではなく一つのシステムとしてプロビジョニングされるときに最もよく機能する。

これは Kamp の手法の正確な例である。重複したキャッシュマネージャが取り除かれ、残ったレイヤーがより重要になり、正しい指標で観測されなければならなくなった。「Varnish はメモリを使う」は不十分な運用上の記述であり、有用な問いは、圧力下で仮想メモリがどうワーキングセットを供給するかである。

VCL はキャッシュポリシーを実行可能に——そしてレビュー可能にした

キャッシュはステータスコードだけから正しさを判断できない。クッキー、認証、リクエストメソッド、ヘッダ、バックエンド選択、鮮度、無効化、例外のためのルールが必要だ。Varnish 設定言語（VCL）は、それらの判断を運用者に公開する。

VCL は C に変換され、ロード可能なオブジェクトにコンパイルされる。稼働中のシステムは、管理制御の下で設定をロードし、切り替えられる。コンパイルされたポリシーは、リクエストごとに高水準言語を解釈することを避け、デーモンのソースを変更せずに挙動を変える構造化された方法を運用者に与える。

その力は大きい。VCL プログラムはバックエンドを選択し、ヘッダを変更し、リクエストをキャッシュしてよいかを判断し、TTL 値を設定し、パージを実装し、条件に応じてトラフィックを誘導できる。インフラチームが保守する場合でも、それはアプリケーションアーキテクチャの一部になる。

その力はリスクも生む。構文的に有効なポリシーが、個人向けコンテンツをキャッシュしたり、認証を無視したり、トラフィックを間違ったバックエンドへ送ったりしうる。ルールはヒット率を上げて正しさを損ないうる。変更には、バージョン管理、テスト、段階的ロールアウト、そして HTTP とアプリケーションの両方を理解する人々によるレビューが必要だ。

コンパイルは信頼境界を追加する。コンパイラを呼び出すプロセス、モジュールパス、インラインまたは拡張コードは制御されなければならない。VMOD は能力と攻撃面を追加できる。高速なポリシー言語が自動的に安全な言語であるとは限らない。

VCL はまた、組織の責任を変える。アプリケーションチームはキャッシュヘッダを制御し、プラットフォームチームは VCL を制御し、セキュリティチームはクッキーと認証に関心を持つ。それらのチーム間の前提からインシデントが生じうる。言語はポリシーをレビュー可能なほど明示的にするが、それ自体で所有権を調整はできない。

これは Kamp の最も影響力のある設計選択の一つである。性能は一つの製品設定にハードコードされていない。運用者はリクエスト経路の近くでポリシーを表現できる。仕組みと現場の判断が分離されているため、システムは異なるアプリケーションにわたって有用であり続ける。

リバースプロキシキャッシュは、正しい表現を正しい要求者に提供するときにだけ、バックエンドの負荷とレイテンシを減らせる。HTTP にはこの判断を支援するメタデータが含まれているが、実際のアプリケーションは曖昧または一貫性のないシグナルを出すことが多い。

鮮度はキャッシュディレクティブと有効期限で制御できる。Varyは、異なるリクエストヘッダが異なる表現を生むことを示す。クッキーと認証はしばしば個人化を意味する。バックエンド障害の間、古いコンテンツの提供が安全なこともあれば、ユーザー変更後の再利用が安全でないこともある。

Varnish は「すべての成功レスポンスがキャッシュ可能」と主張するのではなく、これらの判断を公開する。運用者はポリシーを調整でき、その結果に対する責任を負う。Varyや認証を無視して達成した高いヒット率は、性能上の成功ではなくデータ整合性の失敗である。

無効化も難しい境界である。URL によるオブジェクトのパージは、すべてのバリアントを除去しないかもしれない。バンルールはグループに一致し、リソースを消費しうる。アプリケーションのイベントは遅延または喪失しうる。短い鮮度期間は、古いコンテンツのリスクとバックエンドの節約を減らす。万能の無効化戦略は存在しない。

バックエンドの挙動もキャッシュを形作る。遅い、または故障したオリジンはキューと再試行を生む。古いコンテンツの提供は、ポリシー次第でサービスを維持できる。ヘルスチェックはバックエンドを外すことができ、設定が悪ければ障害を増幅しうる。Varnish は配信システムの一つのレイヤーであり、その正しさはアプリケーションとオリジンのインフラに依存する。

アーキテクチャ上の規律は、これらのトレードオフをポリシーと可観測性において明示的にすることだ。Varnish は仕事を避けることで高速になれるが、再利用が妥当かを判断するために必要な仕事を避けてはならない。

高速経路は、制御・観測・容量の限界から分離されたままだった

Varnish は管理プロセスと、ワーカーすなわちキャッシュプロセスを使う。管理側は設定、パラメータ、子のライフサイクルを制御する。ワーカーはトラフィックを処理する。子が失敗すれば、親は情報を集めて再起動できる。

この分離は、トラフィックを処理するプロセスの権限と永続性を減らす。クラッシュしても管理レイヤーが消える必要はない。新しい VCL は管理された条件下でコンパイル・ロードできる。特権は、プラットフォームと設定に応じて起動後に減らすことができる。

再起動があらゆる障害からの回復であるわけではない。メモリ内の状態は失われうる。クライアントはエラーを見るかもしれない。クラッシュの繰り返しはループを生みうる。実際の原因はバックエンドやオペレーティングシステムかもしれない。運用者には、自動再起動を回復力の証明と見なすのではなく、クラッシュ診断と制限が必要だ。

分離はアップグレードと設定移行も支援するが、高可用性はより大きなアーキテクチャに属する。一つの Varnish プロセスが単一障害点になれないなら、通常は複数インスタンス、ロードバランサー、ヘルスチェック、容量が必要だ。

このパターンは Kamp のカーネル仕事に似ている。一つのコンポーネントがすべてのシステム特権を持たずに失敗できるように境界を定義する。その価値は、完全な隔離ではなく実践的な封じ込めにある。

Varnish の共有ログ（Shared Log）は、構造化されたイベントレコードを共有メモリに書き込む。ツールは、ワーカーにすべてのイベントを従来のファイルへ同期式に追記させることなく、リクエスト、バックエンド、キャッシュのトランザクションを読める。

この設計はブロッキングを減らし、異なるコンシューマが同じストリームを検査できるようにする。運用者はリクエストを追跡し、メトリクスを集計し、ログを別のシステムへエクスポートできる。高容量の記録はプロセスの近くに保たれ、長期保存は委譲される。

共有メモリは有限である。遅れるコンシューマは、リングが進むとレコードを取り逃すことがある。インシデント調査に使うツールは、ライブログがアーカイブだと想定するのではなく、必要なデータをエクスポートまたは保持すべきだ。

イベントモデルは専門的である。トランザクションには、クライアントとバックエンドのリクエスト、再試行、キャッシュ判断が含まれうる。レコードを理解するには、Varnish の識別子とライフサイクルに精通している必要がある。構造化ログは機械処理を改善するが、スキーマの必要性をなくすわけではない。

プライバシーとセキュリティも適用される。ヘッダ、URL、バックエンド情報には機微なデータが含まれうる。エクスポータはフィールドを最小化し、アクセスを制御すべきだ。高速ログは、キャッシュ自身のリソース使用を超える保存コストのボリュームを生みうる。

このアーキテクチャもまた、クリティカルパスから仕事を取り除き、責任を別の場所へ移す。Varnish は詳細な証拠を効率的に公開する。保持、検索、アクセスポリシーを所有するのは運用者である。

Varnish のワーカーモデルは、スレッドとプールを使って多くの同時接続を処理する。スレッドは一部の操作でブロックしても全トラフィックを止めず、システムは生成とリソース制限を制御する。

スレッドはスタックとスケジューラの関心を消費する。少なすぎるとクライアントを待たせ、多すぎるとメモリを消耗し競合を増やす。遅いクライアントと遅いバックエンドはリソースの保持の仕方が異なる。接続挙動、キープアライブ、タイムアウト、オペレーティングシステムの制限はすべて安全な範囲に影響する。

実装は進化しており、正確なチューニングは導入されているバージョンに属する。一般的な点は、キャッシュが高速だからといって並行処理が無料になるわけではないということだ。運用者はスレッドキュー、ドロップ、バックエンドレイテンシ、メモリ圧力を監視する必要がある。

メモリ内のキャッシュヒットがあるワークロードは、繰り返しミスしてオリジンを待つものとは異なる。ヒット中心のベンチマークは、バックエンドが遅くなったときの障害挙動についてはほとんど語らない。容量計画には、ミスストーム、パージ、再起動のシナリオを含めるべきだ。

Varnish の狭いデータ経路は、運用者に明確なカウンタと制御を与える。それはまた、性能がシステムの性質であるという現実を露呈する。カーネルのネットワーク処理、スケジューラ、メモリ、ストレージ、バックエンド、アプリケーションポリシーがすべて関与するのだ。

オープンなコード、商用サポート、任意の資金提供は別々のレイヤーに留まる

Varnish Cache はオープンソースプロジェクトであり、現行のメンテナー、リリース、パッケージ、モジュールがある。Varnish Software は、この技術を中心とした製品とサービスを提供する別の商業会社である。Kamp は最初の設計者であり、プロジェクトとの関わりを保っているが、現在のすべての決定や商用提供を所有・管理しているわけではない。

この区別は、採用が広がるにつれてより重要になった。企業はサポート、パッケージ化された機能、説明責任を求めた。会社はそれらのサービスを提供し、独自または別個に管理されるコンポーネントを開発できる。上流プロジェクトは公開コードベースとコミュニティプロセスを維持する。

商業活動はオープンな開発を支えると同時に、分岐したインセンティブを生みうる。顧客がコアに不適切な機能を求めることがある。会社は、無所属のメンテナーより多くのエンジニアリング能力を持つかもしれない。商標や製品名が、利用者がどのレイヤーを買っているかの混乱を生むことがある。

擁護可能なプロフィールは、アーキテクチャと初期実装を Kamp に帰し、継続中のリリースを現行メンテナーに帰し、Varnish Software の事業をそれ自身の機関としての記録として扱う。あるレイヤーからの展開の主張を、別のレイヤーに割り当てるべきではない。

この原則は FreeBSD にも当てはまる。Kamp の歴史的なコアチームとサブシステムの仕事は重要だが、現在のプロジェクトは現在の体制によって運営されている。オープンインフラは、作者の功績が永続的な所有権にならずに称えられるときに、耐久性を持つ。

Kamp は Beer-Ware ライセンスと関連づけられる。これは非公式の寛容型ライセンス文で、利用を許し、双方が会った場合は作者にビールを一杯おごることを提案する。このライセンスは、意図的に平易な言葉で社会的な互恵を表現する。法的な適合性は文脈に依存し、正式なコンプライアンス要件のある組織は従来型のライセンスを好むかもしれない。

Varnish Moral License は別の問題に対処する。これは、Varnish から利益を得る組織が Kamp の仕事を支援できる任意の仕組みである。ソフトウェアライセンスではなく、コードの利用に必須でもない。「モラル（道徳的）」という枠組みは、寛容な法的ライセンスが強制できない保守労働を利用者に認識するよう求める。

Kamp は 2004 年、FreeBSD の仕事に対するコミュニティからの直接スポンサーシップを実験していた。このパターンは、インフラ保守の経済への持続的な関心を示す。広く使われるコードは大きな価値を生みうる一方、困難で魅力のない仕事を担う人々の支援は不安定になりうる。

公開されている証拠は、完全な年間収入、参加者数、プロジェクト予算を提供しない。資金調達の仕組みは、実証された普遍的なモデルではなく実験として記述されるべきだ。任意の貢献は独立した仕事を支えられるが、予測できないこともある。

より広い教訓は、コードの効率性は労働をなくさないということだ。当初の性能問題が解決された後も、プロトコル変更、セキュリティレビュー、ドキュメント、リリースは続く。機械の仕事を取り除くプロジェクトは、資金が見えない人的労働に依然として依存しうる。

Kamp の経歴は単純な雇用タイトルの並びに当てはまらない。彼の現在の公的な身分は、独立して自営するシステムプログラマー兼執筆者である。その独立は、コーポレートロードマップの外の仕事を追求する能力を守りうる。同時に、受益者が分散しているインフラを維持することの経済的脆弱性も露呈する。

2004 年の FreeBSD スポンサーシップ実験、Beer-Ware 文書、Varnish Moral License は、この問題の異なる部分に対処する。直接スポンサーシップはコミュニティに開発時間の資金提供を求めた。Beer-Ware は支払い義務ではなく寛容な社会的要請を用いた。Moral License は、Varnish から大きな価値を受け取る組織に、コードを利用する法的権利を変えずに任意で貢献するよう求める。

これらの仕組みのどれも、公開記録において完全なプロジェクト予算を供給しない。その重要性は、不快な依存関係を見えるようにすることにある。寛容なライセンスは法的摩擦を取り除き、採用を容易にできる。しかし、セキュリティトリアージ、プロトコル作業、ドキュメント、リリースエンジニアリングが資金を得られることを保証しない。

企業はしばしば、メンテナーを雇用し、サポートを購入し、財団に資金を出すことで、間接的にこの問題を解決する。独立した貢献者は、コンサルティング、スポンサーシップ、任意の支払いに頼るかもしれない。各モデルは優先順位を形作る。顧客資金は緊急の展開に注意を向けさせる。会員資金は大規模な参加者を優遇しうる。任意の支援は広範で信頼性に欠けることがある。

Kamp のモデルは、受益者に価値を受け取った後にそれを認識するよう求める。このアプローチは自由を保ち、上流をサブスクリプション製品にすることを避ける。それはまた、調達システムが設計上は行わない倫理的な応答に依存する。企業はライセンスに完全に適合しながら、何も貢献しないことができる。

Varnish や他のオープンインフラを使うリーダーにとって、これは慈善的な周辺問題ではない。メンテナーの能力は、脆弱性対応、ツールチェーン互換性、プロトコルの最新性に影響する。オープンソースで節約したコストは、困難な仕事を担う報酬を誰も払わないとき、継続性リスクとして再び現れうる。

「bikeshedding（自転車置き場の議論）」は、決定権が不明確なときの運営コストになる

Kamp の技術エッセイは、しばしばコードからプロジェクト運営へと移る。bikeshedding という言葉は、グループが簡単で目に見える細部に不釣り合いな注意を払い、より難しい決定の議論が少なくなる傾向を指す。彼の 2026 年 7 月の ACM Queue 誌の記事は、この制度についての考察を続けた。

この現象は、うんざりする会議の振る舞い以上のものである。インフラプロジェクトのレビュー担当者の注意力は限られている。命名についての長い議論は、セキュリティやアーキテクチャの決定を遅らせうる。貢献者は自信のある場所に参加するため、些細な問題が専門的な問題よりも多くの声を集めることがある。

明確な範囲と決定権はコストを減らせる。メンテナーは、どの反論が重要か、いつ合意で十分か、いつ決定を下さなければならないかを説明すべきだ。過度な中央権限は有用なレビューを沈黙させうる。未定義のプロセスは、すべての変更を際限のない議論の人質にする。

Varnish が意図的に範囲を絞っているのは、部分的には運営ツールである。一般的な Web サーバになることを拒否することで、プロジェクトが調停しなければならない機能の数を減らす。FreeBSD のサブシステムインターフェースも同様に決定を局所化する。範囲はアーキテクチャだけの問題ではない。一つのリポジトリの中で、いくつのコミュニティとインセンティブが衝突するかを決めるのだ。

Kamp の議論好きなスタイルは、彼の見解に関する一次的な証拠であって、すべてのプロジェクトが同じ失敗をするとの外部からの証明ではない。その著作が有用なのは、技術的複雑さを、それを受け入れ資金を出す社会システムに結びつけるからだ。

狭いコアはリスクをその拡張境界へ移す

範囲の狭いキャッシュは完全なアプリケーションサーバになることを避け、その範囲外の機能には TLS 終端、ロードバランサー、または別のプロキシを必要とするかもしれない。カーネルの仮想メモリに依存することはオブジェクトストレージを単純化し、カーネルのチューニングを重要にする。コンパイルされた VCL はリクエストのオーバーヘッドを減らし、安全なビルド経路を必要とする。すべての「引き算」には、隣接する所有者がいる。

これは矛盾ではない。それはアーキテクチャの帰結である。システムは、仕事の総量を消し去るのではなく、責任を明確に割り当てることで単純になれる。運用者は、選んだ境界がチームの専門性とサポート体制に一致するかを判断しなければならない。

現代の HTTP は圧力を加える。HTTP/2、HTTP/3、TLS、エッジコンピューティング、複雑なルーティングは、バージョンとアーキテクチャに応じて、Varnish、隣接プロジェクト、または商用製品が扱うかもしれない。当初の設計を、その後のすべての機能が創業時の範囲の一部だったかのように判断すべきではない。

セキュリティと正しさもミニマリズムに抵抗しうる。キャッシュポリシーは、個人向けデータを守るのに十分な情報を必要とする。可観測性システムは、障害を診断するのに十分な詳細を必要とする。必要な制御を所有する機能を取り除くことは、依存関係を隠すだけだ。

Kamp の最も強い教訓は、すべてのプログラムを最小化することではない。重複した仕事を取り除き、残った所有者を明示的にすることだ。隣接するシステムが機能を所有するとき、インターフェースと障害経路は理解されるべきである。

範囲を絞ったキャッシュは、あらゆる認証方式、ヘッダ変換、ルーティング判断、アプリケーション固有の機能を予期できない。Varnish モジュール（一般に VMOD と呼ばれる）は、運用者と開発者に、すべての機能をコアデーモンに置かずに VCL を追加関数で拡張する方法を与える。

このモデルは、Kamp が狭いインフラを好むことを支持する。コアは安定したリクエストエンジンを保ち、拡張インターフェースを公開できる。専門的なコードは、それを必要とする組織やベンダーとともに進化できる。モジュールは、普遍的なデフォルトとして不適切なデータ、暗号、ポリシーを統合できる。

拡張性はソフトウェアのサプライチェーンを生む。VMOD は機微なプロセスコンテキスト内で実行され、リクエストデータを扱い、キャッシュやバックエンドの判断に影響しうる。そのソース、ビルドシステム、リリース頻度、導入されている Varnish バージョンとの互換性は、セキュリティ境界の一部になる。

バイナリまたは API の互換性は、アップグレード時に重要である。Varnish のリリースは、モジュールの再ビルドや更新を必要とするインターフェースを変えうる。商用ディストリビューションは、上流で保守されていないモジュールをサポートすることがある。一つの拡張機能に依存する組織は、それを独立して再ビルドし、置き換え、監査できるかを知る必要がある。

モジュールはまた、インシデントの帰属にも影響する。クラッシュや誤った応答は、コアコード、VCL、VMOD、またはキャッシュの背後にあるアプリケーションに起因しうる。共有メモリログとクラッシュ証拠は、それらのレイヤーを分離できる十分な文脈を保つべきだ。すべての失敗を「Varnish」と呼ぶことは、それを修復できる所有者を隠す。

運営上のトレードオフは FreeBSD のサブシステムモデルに似ている。共通インターフェースは、すべての決定を中央集権化せずに専門コンポーネントの存在を可能にする。インターフェースには依然として、安全でない前提を拒否し、ライフサイクル変更を伝えるメンテナーが必要だ。

リーダーにとって、拡張機能の棚卸しは Varnish のバージョンと同じくらい重要である。最小のコアでも、多くのモジュール、私的な VCL ライブラリ、管理ラッパーが周囲に蓄積されると、複雑な展開を生みうる。Kamp の手法は、コアから移された責任がどこかで名前を与えられ、支援されている場合にのみ有効であり続ける。

Varnish は、配信スタックがその周囲で何を所有するかによって定義される

Varnish はしばしば、クライアントまたはエッジプロキシとアプリケーションオリジンの間に展開される。その位置は、オブジェクトが再利用可能なときに、オリジンを繰り返しの仕事から守り、応答レイテンシを減らし、トラフィックの急増を吸収できる。また、キャッシュを、DNS、TLS 終端、ロードバランシング、Web アプリケーションファイアウォール、コンテンツ管理システム、管理型配信ネットワークを含みうるチェーンの中に置く。

したがって、製品の境界は除外によって理解しやすい。Varnish は完全なコンテンツ配信ネットワークではない。CDN がキャッシュを使うからといって、世界中の拠点、顧客ルーティング、証明書運用、管理されたコントロールプレーンを所有するわけではない。アプリケーションサーバでもない。ページのビジネス上の意味を決めるのでもない。現代のアーキテクチャにおいて自動的に最善の TLS エンドポイントであるとか、唯一のプロキシであるということもない。

それらの除外は性能戦略の一部だった。追加される責任はすべて、コード経路、設定、状態、セキュリティレビューを増やす。範囲を絞った HTTP アクセラレータは、オブジェクトのライフサイクルとリクエスト経路を最適化できる。統合型エッジプラットフォームは、チェーンのより多くを所有することで調達と運用を単純化できる。選択は、組織がコンポーネントの制御と、統合されたサービス境界のどちらを重視するかに依存する。

NGINX、Apache Traffic Server、Squid、HAProxy は、この空間の異なる部分で重なる。NGINX は Web サーバ、プロキシ、キャッシュを組み合わせる。Traffic Server は独自のアーキテクチャを持つ本格的なキャッシュプロキシである。Squid はフォワードプロキシとリバースプロキシの両方で長い歴史を持つ。HAProxy は同じキャッシュモデルを提示するのではなく、ロードバランシングとプロキシ機能に集中する。管理型 CDN は、グローバルインフラと商用運用を追加する。

有用な比較は、どの名前が普遍的に最速かを問うものではない。どのコンポーネントがキャッシュセマンティクス、TLS、ルーティング、ヘルス、設定、可観測性、サポートを所有するかを問うのだ。Varnish の設計は、運用者が明示的な HTTP ポリシーを望み、隣接システムを統合できるときに魅力的になりうる。組織がその統合を所有したくない場合、管理型エッジサービスがより適切かもしれない。

この競争的文脈は、ロックインの意味も変える。オープンソースのキャッシュは一つのホスト型バックエンドへの依存を減らすが、展開はカスタム VCL、VMOD、独自の管理レイヤー、文書化されていないアプリケーション挙動に結びつきうる。移植性はソースとアーキテクチャに存在する。それでも、規律ある設定とテストを必要とする。

Varnish の範囲の狭さは、統合型エッジプラットフォームを置き換えるよりも、アーキテクチャの置き換えを容易にできる。ソース、VCL、HTTP の境界は見える。その利点は、組織が文書化されていないデフォルト、私的モジュール、本番にしか存在しないアプリケーションの前提に依存するとき、消える。

移行には挙動テストが必要だ。どのレスポンスがキャッシュ可能か、バリアントがどう分離されるか、いつ古いコンテンツが許容されるか、無効化がどう機能するか、オリジンが失敗したら何が起きるか。二つのプロキシは似た設定を受け入れても、HTTP のエッジケースで異なることがある。

これは状態所有権のもう一つの形態である。実行可能な設定はポリシーの一部を記録し、テストは意図した結果を記録する。その両方がなければ、オープンなコンポーネントは、ライセンスが置き換えを妨げないにもかかわらず、運用上ロックインされうる。

Kamp のミニマリスト的なアーキテクチャは、移行すべき責任の数を減らす。残る責任を保存する必要性をなくすわけではない。

障害テストはキャッシュヒットのベンチマーク以上のものを明らかにする

Varnish は性能の主張で知られるようになったが、最も示唆に富む本番テストは、キャッシュ可能性を減らすか、隣接レイヤーを損なうものであることが多い。サイトは、オブジェクトがホットでオリジンが健全な間は効率的に見えても、パージ、ミスの急増、遅いバックエンドの間に急激に失敗しうる。

キャッシュミスの集中（ミスストーム）はボトルネックを変える。以前はワーカーで終わっていたリクエストが、今度はオリジンの容量を待つ。多くのクライアントが同じ未キャッシュのオブジェクトを求めるなら、バージョンと設定次第で、リクエストの統合（コアレス）または関連ポリシーがバックエンドを守れる。アプリケーションが多くのバリアントを生成するなら、キャッシュは有用な再利用なしにメモリを消費しうる。

メモリ圧力も、仮想メモリの取引のもう一つのテストである。カーネルはページを回収し、フォールトを生み、他のプロセスと競合しうる。キャッシュは論理的には正しくても、レイテンシが不安定になることがある。運用者には、Varnish のカウンタに加えてホストレベルのメモリとページングの証拠が必要だ。

設定の再読み込みと再起動のテストは、運用上の所有権を明らかにする。チームは、どのオブジェクトが生き残るか、クライアントがどうドレインされるか、失敗した VCL がどう拒否されるか、ワーカーのクラッシュが監視にどう現れるかを知るべきだ。自動再起動は、対応者が一時的なプロセス障害と、繰り返される欠陥や枯渇したリソースを区別できるときだけ有用である。

バックエンドのヘルスポリシーも、障害の注入（フェイルインジェクション）を必要とする。容量を過度に積極的に外すチェックは、部分的な問題を全面停止に変えうる。古いコンテンツの提供は可用性を保てるが、即時の鮮度の要件に違反しうる。正しいポリシーはキャッシュだけではなく、アプリケーションに依存する。

これらのテストは、Kamp のより広いシステム的主張を支持する。性能はピークリクエスト率ではない。状態が変わり、リソースが乏しくなり、コンポーネントが失敗する間に届けられる有用な仕事である。重複した仕組みを取り除くことは、残った境界が想定ではなくテストされれば、その挙動を改善できる。

永続する手法は、状態を「所有できる場所」に置くことだ

FreeBSD、Varnish、時刻管理を通じて、Kamp は繰り返し、状態はどこに属するのかと問うた。jails は隔離をカーネルに置く。GEOM はストレージ合成を共有フレームワークに置く。timecounter はハードウェアクロックを抽象化する。Varnish は常駐を仮想メモリに委譲し、HTTP ポリシーを VCL を通じて公開する。共有ログはイベントの生成と保持を分離する。

設計は異なるが、一つの規律を共有する。二つのレイヤーが同じ真実の競合バージョンを維持することを避ける、という規律だ。重複した状態は、同期の仕事と不明確な障害所有権を生む。共通のプリミティブは、その上のワークロードに十分強いなら、両方を減らせる。

この手法は、Kamp が資金調達と運営に関心を持つ理由も説明する。誰も保守を所有しなければ、コードの所有権は十分ではない。すべての機能の議論が無期限に範囲を広げられるなら、プロジェクトの範囲は明確ではない。技術的な「引き算」には、当初の作者が去った後も決定を守る制度的な境界が必要だ。

Varnish の現在のコミュニティと FreeBSD の継続的な進化は、この仕事が一人のエンジニアを超えて動いていることを示す。その移行自体が成果の一部である。Kamp の影響は、他の人が保守できるシステムと、彼のアーキテクチャが運用者に答えさせ続ける問いによって最もよく測られる。

性能は一つの成果である。より深い成果は明瞭さだ。重複する仕組みが減り、制御面が明確になり、システムが失敗したときにどのレイヤーを直すべきかを特定できる可能性が高まる。