A/B テストと機能のロールアウトに Varnish を活用するにはどうすればよいでしょうか?

Question

今日、私たちの Web レイヤーが世界に公開されました。私たちは、Web レイヤーの前に Varnish を追加して、サイトを高速化し、バックエンドへの呼び出しを減らしたいと思っています。しかし、いくつか懸念事項があり、ほとんどの人がそれらにどのように対処するのか疑問に思っています。

1. A/B テスト - 各ページの 2 つの「バージョン」をテストして比較するにはどうすればよいでしょうか。つまり、varnish はどのページを表示するかをどのように判断するのでしょうか。各ページに別々のバージョンを保存する場合、またその場合、どのように保存するのでしょうか。

2. 機能のロールアウト - シンプルな機能のロールアウト メカニズムをどのように設定しますか? たとえば、新しい機能/ページをトラフィックの 10% のみに公開し、後でそれを 20% に増やしたいとします。

3. コードのデプロイメントはどのように処理していますか? デプロイメントごとに Varnish キャッシュ全体を消去していますか? (毎日デプロイメントを行っています)。 それとも、(TTL を使用して) ゆっくりと期限切れになるままにしていますか?

これらの問題に関するアイデアや例は大いに感謝！

Answer 1

A/B テスト - 各ページの 2 つの「バージョン」をテストして比較するにはどうすればよいでしょうか。つまり、varnish はどのページを表示するかをどのように判断するのでしょうか。各ページに別々のバージョンを保存する場合、またその場合、どのように保存するのでしょうか。

いくつかの選択肢があります:

• 異なる URL で公開するだけです。

• 特定の URL のキャッシュをバイパスします。passを返すことでこれを行うことができますvcl_recv。次のようになります。

  sub vcl_recv {
      if (req.url ~ "^/path/to/document") {
          return (pass);
      }
  }
  

• 新しいバージョンを公開するときに、キャッシュを明示的に消去します。

機能のロールアウト - シンプルな機能のロールアウト メカニズムをどのように設定しますか? たとえば、新しい機能/ページをトラフィックの 10% のみに公開し、後でそれを 20% に増やしたいとします。

これを行う「簡単な」方法があるかどうかはわかりません。ファイルCに任意のコードを入れることができるので.vcl、ランダムな数字を選択するロジックを追加し、その結果に基づいて適切なバックエンド パスを選択することは可能でしょう。

コードのデプロイメントはどのように処理していますか? デプロイメントごとに Varnish キャッシュ全体を消去していますか? (毎日デプロイメントを行っています)。 それとも、(TTL を使用して) ゆっくりと期限切れになるままにしていますか?

大きな変更の場合はキャッシュを消去し、小さな変更の場合は期限切れにするだけです。