フィーチャー トグルを使用してテストと A/B テストを構成する

App Lifecycle Manager のフィーチャー トグルの割り当てを使用すると、トラフィックの割合を分割してアプリケーションをテストできます。これにより、一部のユーザーにはアプリケーションの 1 つのパターンが表示され、他のユーザーには別のパターンが表示されるため、どのパターンまたは機能がより成功しているかを判断できます(このプロセスは A/B テストと呼ばれることがよくあります)。 フィーチャー トグルの割り当てを使用すると、トラフィックの分割方法を定義し、割り当てられたパターンをアプリケーションに統合できます。

このガイドでは、パターンを定義し、トラフィック分割を構成して、パターンをアプリケーションに統合する方法について説明します。

トラッキングと分析を簡素化するには、パターンに説明的な文字列 ID(「experimental」や「baseline」など)を割り当て、これらの名前をコードと分析パイプラインで直接使用する必要があります。

前提条件

始める前に、次のものを用意してください。

  1. フィーチャー トグルのデプロイ クイックスタートまたはフィーチャー トグルの使用(スタンドアロン クイックスタート)を完了している。
  2. App Lifecycle Manager リソースを管理するように構成された Google Cloud CLI 環境がある。

フィーチャー トグルの割り当てを構成する

試験運用版のフィーチャー トグルを構成する手順は次のとおりです。

  1. 各ユーザーに一貫したエクスペリエンスを提供するために、スティッキー バケットに使用されるランダム化された属性(userIDなど)を定義します。

      gcloud beta app-lifecycle-manager flags attributes create "user-id-attr" \
          --key="userID" \
          --attribute-value-type="STRING" \
          --location=global
    
  2. 割り当てを使用して、分割(50/50 など)を定義し、 説明的なパターン ID を参照します。

    # Create a flag with explicitly named variants for the experiment and a 50/50 allocation referencing the custom IDs
    gcloud beta app-lifecycle-manager flags create "search-algo-test" \
      --key="search-algo-test" \
      --flag-value-type=BOOL \
      --location="global" \
      --unit-kind="demo-test-unitkind" \
      --variants='[
          {
          "id": "experimental",
          "booleanValue": true
          },
          {
          "id": "baseline",
          "booleanValue": false
          }
      ]'\
      --evaluation-spec='{
          "allocations": [{
              "id": "search-split-50-50",
              "randomizedOn": "userID",
              "slots": [
              {"variant": "baseline", "weight": 50},
              {"variant": "experimental", "weight": 50}
              ]
          }],
          "defaultTarget": "search-split-50-50",
          "attributes": ["projects/PROJECT_ID/locations/global/flagAttributes/user-id-attr"]
      }'
    
  3. バックエンド サービスで OpenFeature SDK を初期化し、評価コンテキストに userID を挿入します。BooleanValueDetails(または言語に応じた同等のもの)メソッドを使用して、アプリケーションで variantID(文字列)を取得します。これにより、ブール値だけでなく、説明的な名前に基づいてバックエンド ロジックを切り替えることができます。

    // 1. Prepare evaluation context
    evalCtx := map[string]any{"userID": currentUser.ID}
    
    // 2. Fetch evaluation details to get the variant name
    details, err := client.BooleanValueDetails(ctx, "search-algo-test", false, evalCtx)
    
    // 3. Execute logic based on the Variant ID (string name)
    if details.Variant == "experimental" {
        results = search.ExperimentalV2(query)
    } else {
        results = search.BaselineV1(query)
    }
    
  4. 説明的なパターン名を使用すると、監査と分析で ドキュメントが自動的に生成されます。評価を監査するには、パフォーマンス指標とともに details.Variant 文字列を記録します。

     startTime := time.Now()
     // ... perform search ...
     duration := time.Since(startTime)
    
     // Audit: Log the descriptive variant name ("experimental" or "baseline")
     logger.Info("Search performed",
        "variant", details.Variant,
        "latency_ms", duration.Milliseconds(),
     )
    

    「試験運用版」グループと「ベースライン」グループの指標を比較することで、新しいアルゴリズムによってバックエンドの効率や検索の関連性が向上するかどうかを手動で分析してから、完全に展開に進むことができます。

次のステップ