A/Bテスト。ゲートウェイAPIのクライアントのルーティング

Question

私はマイクロサービスに基づく新しいプロジェクトに取り組んでいます。それは内部のアプリで、わずか約10のマイクロサービスです。私たちは、認証のためのゲートウェイAPIと、場合によってはマイクロサービスの集約を使用します。 （おそらくNetflix zul with Spring Boot）

私はA/Bテストとカナリーテストのルーティングをどうやって行うのかについてはっきりしていません。私は100人のクライアントがいると仮定し、A/Bが新しいバージョンのマイクロサービスをテストしたいと考えます。クライアントアプリケーションは変更を必要とせず、マイクロサービスが提供する機能の内部変更だけです。

私は、（例えば）v2という新しいマイクロサービスを立ち上げると思います。私が困惑しているのは、どのようにしてクライアント1-10を新しいバージョンに向けるのかということです。これを一元的に設定し、クライアント上で何も変更しないようにする必要があります。

MACアドレス（他の識別属性と同様に）を知っており、メッセージを識別する任意の種類のヘッダーを挿入できます。

したがって、これらをA/BテストまたはCanaryデプロイメント用のAPIのv2にどのように誘導できますか？ハイレベル、汎用的なアプローチを記述した場合

Answer 1

は、あなたがこのような何かを行うことができます。

1. あなたのクライアントは、一意に識別することができますいくつかのパラメータを持っている必要があります。あなたはすでにこれを持っているように見えます。
2. 追加のAPIサービスを実装します（実験APIと呼ぶ）。このサービスには、クライアント識別属性を受け取り、クライアントがA/Bテストに関与しているかどうかを示す少なくとも1つのエンドポイントが必要です。
3. 各受信リクエストで、ゲートウェイAPIは、そのExperiment APIエンドポイントを使用して、リダイレクト/コールに使用するマイクロサービスバージョン（v1またはv2）を判断する必要があります。
4. Gateway APIにキャッシングレイヤーを導入するたびに、Experiment APIを呼び出すことを避けるためです。別のオプションとして、カスタムクッキー（「実験」の下にクライアントがあるかどうかを含む）を使用し、そのクッキーが指定されていない場合にのみExperiment APIを呼び出して、そのクッキーをクライアントに返します。

Answer 2

@ Setの答えを少し詳しく説明します。下流のエンドポイントをどのように呼び出すかを決定するために、ゲートウェイAPIに計測コードを導入する必要があります。分散バックエンドのうち、これに関係する唯一のコンポーネントがゲートウェイAPIである場合に限って、上記のソリューションは過剰に設計されています。つまり、ライブラリだけで実現できます。しかし、他のサービスの1つ以上が実験について知っておく必要があることがすぐに分かります。その場合は、スタンドアロンサービスが必要です。

一般的に言えば、堅牢な実験フレームワークを構築することは難しい作業です。あなたはすぐに予期しない問題に遭遇します。ホストアプリケーションを再起動する必要なく、安定性の経験（訪問者を返すために同じ経験を保証する方法）または割り当て割合を変更する方法（または新しいコードを完全にオフにする方法）オープンソースのフレームワークを調べたり、市販のサーバーサイドの計測器を調べたりする必要があります。 （私たちはVariantにある）。

Answer 3

Zuul Gatewayを使用してルーティングを実現する方法を示すGithubのプロトタイプを公開しました。このプロトタイプは、クッキーに基づいてトラフィックを同じアプリケーションの異なるインスタンスにルーティングする方法を示しています。他の基準に基づいてルーティングを行うことができます。 Zuulの代わりにSpring Cloud Gatewayもご覧ください。非常に有望であると思われる。 https://github.com/adiesner/spring-boot-sample-ci-gateway

さらに簡単な設定は、サービスの前にnginxを追加してsplit_clientsメソッドを使用することです。

http { 
    # ... 
    # application version 1a 
    upstream version_1a { 
     server 10.0.0.100:3001; 
     server 10.0.0.101:3001; 
    } 

    # application version 1b 
    upstream version_1b { 
     server 10.0.0.104:6002; 
     server 10.0.0.105:6002; 
    } 

    split_clients "${arg_token}" $appversion { 
     95%  version_1a; 
     *  version_1b; 
    } 

    server { 
     # ... 
     listen 80; 
     location/{ 
      proxy_set_header Host $host; 
      proxy_pass http://$appversion; 
     } 
    } 
} 

https://www.nginx.com/blog/performing-a-b-testing-nginx-plus/