現在、独自の Varnish サーバーを管理するか、Fastly のようなホスティング サービスを使用するかを決定しています。ここで最も重要な決定要因の 1 つは、効率的なタグベースのキャッシュの無効化です。これは、Varnish を API の前に配置する予定であり、多くの関連ページを無効にするパージ リクエストを頻繁に発行する必要があるためです。
Fastly はSurrogate Keysを提供しており、Varnishは Hashtwo、Hashninja、XKey など、さまざまな名前で呼ばれる個別のモジュールを提供しているようです。これらの機能は同じように見えます。それらは実際には同じですか、それとも 2 つの機能についてのブログ投稿からは明らかではない重要な技術的または効率的な違いがありますか?
サロゲート キーは、この機能の Fastly による実装です。私は現在の実装を作成しましたが、HashTwo/Hashninja/xkey を使用していないため、実装間の違いについての権威ではありません。Xkey は、 https: //github.com/varnish/libvmod-xkey で vmod として公開されています。
サロゲート キーは Fastly のサービスの標準的な部分ですが、CDN としてホストされているプラットフォームの一部として提供しています。ほとんど正当な理由がないため、オープンソースではありません。それを行うことについていくつかの議論がありましたが、それは大きな優先事項ではありません (部分的には、Varnish が 2.1.4 からのフォークであるため)。
個々のキーが 1kb を超えることは許可されておらず (理由は?)、キー リスト全体が 16kb を超えることは許可されていません。約 1 年ほど前にお客様からのリクエストにより、これらの値の制限を引き上げました (以前は合計 1kb でした)。そのスペース内に収まる限り、キーの数に制限はありません (ただし、これによりキースペースが効果的に制限されることはわかっています)。長さを制限する理由は、キー パージによって一定数の線形時間操作が発生するためです。現在の制限に実際的な問題があったとしたら、私は驚かれることでしょう。
xkey は、キーもヘッダーを介して指定されるという意味で長さとキーの数が制限されていることに注意してください。ヘッダーの長さは、接続を処理するスレッドで使用可能なワークスペースによって効果的に制限されます。独自の Varnish を実行する場合、この長さは調整可能であり、これは実際的な制限ではないかもしれませんが、存在します。
コードをスキャンして気付いたもう 1 つの小さな違いは、xkey vmod が複数の xkey ヘッダーをサポートしているのに対し、Fastly サロゲート キーは最初に一致したヘッダーから取得されることです。機能を実現するために使用されるデータ構造に関してはいくつかの違いがあります (部分的にはマルチテナント Varnish を実行するという事実による) が、それ以外の機能は類似しているように見えます。
最後に、(この時点で) 世界中に数百の Varnish インストールのクラスターがあります。私たちのインフラストラクチャの一部は、パージをネットワークを通じて確実に配布し、それらがグローバルに適用されるようにすることに関係しています。Varnish ノードのクラスターを実行する場合、複数のノードにまたがるキャッシュを無効にするために追加の作業を行う必要がある場合があります (ただし、これは小さなクラスターでは重大な問題になる可能性は低いです)。
xkey と hashtwo (一部のマーケティング資料では hashninja) は同じです。
Fastly との主な違いは、xkey がオブジェクト/URL ごとのキーの長さや数に制限を追加しないことだと思います。私の知る限り、どちらもかなりうまく機能します。(完全な開示: 私は Varnish Software で働いています)