翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # マルチバリアント機能フラグの作成 機能フラグバリアントを使用すると、リクエストに対して返す可能性のあるフラグ値のセットを定義できます。マルチバリアントフラグには、異なるステータス (有効または無効) を設定することもできます。バリアントで設定されたフラグをリクエストする場合、アプリケーションは一連のユーザー定義ルールに対して AWS AppConfig を評価するコンテキストを提供します。リクエストで指定されたコンテキストとバリアントに定義されたルールに応じて、 は異なるフラグ値をアプリケーションに AWS AppConfig 返します。 次のスクリーンショットは、3 つのユーザー定義バリアントとデフォルトのバリアントを持つ機能フラグの例を示しています。 ![\[バリアントを含む機能フラグのスクリーンショットの例。\]](http://docs.aws.amazon.com/ja_jp/appconfig/latest/userguide/images/flag-variant-example.png) **Topics** + [マルチバリアント機能フラグの概念と一般的なユースケースを理解する](appconfig-creating-multi-variant-feature-flags-concepts.md) + [マルチバリアント機能フラグルールについて](appconfig-creating-multi-variant-feature-flags-rules.md) + [マルチバリアント機能フラグの作成](appconfig-creating-multi-variant-feature-flags-procedures.md) # マルチバリアント機能フラグの概念と一般的なユースケースを理解する 機能フラグバリアントをよりよく理解するために、このセクションでは、フラグバリアントの概念と一般的なユースケースについて説明します。 **概念** + **機能フラグ**: アプリケーションの機能の動作を制御するために使用される AWS AppConfig 設定タイプ。フラグには、ステータス (有効または無効) と、任意の文字列、数値、ブール値、または配列値を含むオプションの属性セットがあります。 + **機能フラグバリアント**: 機能フラグに属するステータス値と属性値の特定の組み合わせ。機能フラグには複数のバリアントがある場合があります。 + **バリアントルール**: 機能フラグバリアントを選択するために使用されるユーザー定義の式。各バリアントには、 が AWS AppConfig 評価して返すかどうかを決定する独自のルールがあります。 + **デフォルトバリアント**: 他のバリアントが選択されていない場合に返される特別なバリアント。すべてのマルチバリアント機能フラグにはデフォルトのバリアントがあります。 デフォルトのバリアントは、バリアントの順序で最後に設定する必要があり、ルールを関連付けることはできません。最後に定義されていない場合、マルチバリアントフラグを作成しようとする`BadRequestException`と、 は AWS AppConfig を返します。 + **コンテキスト**: 設定の取得時に AWS AppConfig に渡されるユーザー定義のキーと値。コンテキスト値は、ルール評価中に、返す機能フラグバリアントを選択するために使用されます。 **注記** AWS AppConfig エージェントはバリアントルールを評価し、指定されたコンテキストに基づいてリクエストに適用されるルールを決定します。マルチバリアント機能フラグの取得の詳細については、「[基本およびマルチバリアント機能フラグの取得](appconfig-integration-retrieving-feature-flags.md)」を参照してください。 **一般的なユースケース** このセクションでは、機能フラグバリアントの 2 つの一般的なユースケースについて説明します。 *ユーザーセグメンテーション* ユーザーセグメンテーションは、特定の属性に基づいてユーザーを分割するプロセスです。例えば、フラグバリアントを使用して、ユーザー ID、地理的位置、デバイスタイプ、または購入頻度に基づいて、一部のユーザーには機能を公開し、他のユーザーには公開しないようにすることができます。 購入頻度の例を使用して、コマースアプリケーションが顧客ロイヤルティを向上させる機能をサポートしているとします。フラグバリアントを使用すると、ユーザーが最後に何かを購入した日時に基づいて、ユーザーに表示されるさまざまなインセンティブタイプを設定できます。新規ユーザーには顧客になることを促すために小さな割引を提供し、リピーターの顧客には新しいカテゴリから何かを購入するとより大きな割引を提供することができます。 *トラフィック分割* トラフィック分割とは、定義したコンテキスト値に基づいて、ランダムでありながら一貫性のあるフラグバリアントを選択するプロセスです。例えば、少数のユーザー (ユーザー ID で識別) に特定のバリアントを表示する実験を実行することができます。または、ロールアウト全体で一貫したユーザーエクスペリエンスを維持しながら、機能が最初にユーザーの 5%、次に 15%、次に 40%、次に 100% に公開される段階的な機能ロールアウトを実行することもできます。 実験例を使用すると、フラグバリアントを使用して、アプリケーションのホームページで主なアクションの新しいボタンスタイルをテストし、クリック数が増えるかどうかを確認できます。実験では、トラフィック分割ルールを使用してフラグバリアントを作成し、5% のユーザーを選択して新しいスタイルを表示できます。デフォルトのバリアントは、既存のスタイルを表示し続ける必要があるユーザーを示します。実験が成功した場合、パーセンテージ値を増やすことも、そのバリアントをデフォルトにすることもできます。 # マルチバリアント機能フラグルールについて 機能フラグバリアントを作成するときは、そのバリアントのルールを指定します。ルールは、コンテキスト値を入力として受け取り、ブール値を出力として生成する式です。例えば、アカウント ID で識別されるベータユーザーのフラグバリアントを選択するルールを定義して、ユーザーインターフェイスの更新をテストできます。このシナリオでは、次の操作を行います。 1. *UI Refresh* という新しい機能フラグ設定プロファイルを作成します。 1. *ui\$1refresh* という新しい機能フラグを作成します。 1. バリアントを追加するには、作成後に機能フラグを編集します。 1. *BetaUsers* という新しいバリアントを作成して有効にします。 1. リクエストコンテキストのアカウント ID が、新しいベータエクスペリエンスの表示が承認されたアカウント ID のリストにある場合にバリアントを選択する *BetaUsers* のルールを定義します。 1. デフォルトのバリアントのステータスが **[無効]** に設定されていることを確認します。 **注記** バリアントは、コンソールで定義されている順序に基づいて順序付きリストとして評価されます。リストの先頭にあるバリアントが最初に評価されます。指定されたコンテキストに一致するルールがない場合、 はデフォルトのバリアント AWS AppConfig を返します。 が機能フラグリクエスト AWS AppConfig を処理すると、AccountID (この例の場合) を含む指定されたコンテキストが最初に BetaUsers バリアントと比較されます。コンテキストが BetaUsers のルールと一致する場合、 はベータエクスペリエンスの設定データを AWS AppConfig 返します。コンテキストにアカウント ID が含まれていない場合、またはアカウント ID が 123 以外にある場合、 はデフォルトルールの設定データを AWS AppConfig 返します。つまり、ユーザーは本番環境で現在のエクスペリエンスを表示します。 **注記** マルチバリアント機能フラグの取得については、「[基本およびマルチバリアント機能フラグの取得](appconfig-integration-retrieving-feature-flags.md)」を参照してください。 # マルチバリアント機能フラグのルールの定義 バリアントルールは、1 つ以上のオペランドと演算子で構成される式です。オペランドは、ルールの評価中に使用される特定の値です。オペランド値は、リテラル数値や文字列などの静的値、またはコンテキストで見つかった値や別の式の結果などの変数のいずれかにすることができます。「より大きい」などの演算子は、値を生成するオペランドに適用されるテストまたはアクションです。バリアントルール式を有効にするには、「true」または「false」のいずれかを生成する必要があります。 **オペランド** **** | 型 | 説明 | 例 | | --- | --- | --- | | String | UTF-8 文字のシーケンス。二重引用符で囲まれています。 | 
"apple", "Ḽơᶉëᶆ ȋṕšᶙṁ"
| | 整数 | 64 ビットの整数値。 | 
-7, 42
| | 浮動小数点数 | 64 ビットの IEEE-754 浮動小数点値。 | 
3.14, 1.234e-5
| | タイムスタンプ | [日付と時刻の形式に関する W3C ノート](https://www.w3.org/TR/NOTE-datetime)で説明されている特定の時刻。 | 
2012-03-04T05:06:07-08:00, 2024-01
| | ブール値 | true または false 値。 | 
true, false
| | コンテキスト値 | ルール評価中にコンテキストから取得される \$1*key* 形式のパラメータ化された値。 | 
$country, $userId
| **比較演算子** **** | 演算子 | 説明 | 例 | | --- | --- | --- | | eq | コンテキスト値が指定された値と等しいかどうかを判断します。 | 
(eq $state "Virginia")
| | gt | コンテキスト値が指定された値より大きいかどうかを判断します。 | 
(gt $age 65)
| | gte | コンテキスト値が指定された値以上かどうかを判断します。 | 
(gte $age 65)
| | lt | コンテキスト値が指定された値よりも小さいかどうかを判断します。 | 
(lt $age 65)
| | lte | コンテキスト値が指定された値以下かどうかを判断します。 | 
(lte $age 65)
| **論理演算子** **** | 演算子 | 説明 | 例 | | --- | --- | --- | | と | 両方のオペランドが true かどうかを判断します。 | 
(and 
    (eq $state "Virginia") 
    (gt $age 65)
)
| | または | 少なくとも 1 つのオペランドが true かどうかを判断します。 | 
(or
    (eq $state "Virginia") 
    (gt $age 65)
)
| | not | 式の値を反転します。 | 
(not (eq $state "Virginia"))
| **カスタム演算子** **** | 演算子 | 説明 | 例 | | --- | --- | --- | | begins\$1with | コンテキスト値が特定のプレフィックスで始まるかどうかを判断します。 | 
(begins_with $state "A")
| | ends\$1with | コンテキスト値が特定のプレフィックスで終わるかどうかを判断します。 | 
(ends_with $email "amazon.com")
| | contains | コンテキスト値に特定の部分文字列が含まれているかどうかを判断します。 | 
(contains $promoCode "WIN")
| | 情報 | コンテキスト値が定数のリストに含まれるかどうかを判断します。 | 
(in $userId ["123", "456"])
| | matches | コンテキスト値が特定の正規表現パターンと一致するかどうかを判断します。 | 
(matches in::$greeting pattern::"h.*y")
| | exists | コンテキストキーに値が提供されたかどうかを判断します。 | 
(exists key::"country")
| | split | 指定されたコンテキスト値の一貫したハッシュ (複数可) に基づいて、トラフィックの特定の割合について `true` と評価します。`split` の仕組みの詳細については、このトピックの次のセクション「[split 演算子について](appconfig-creating-multi-variant-feature-flags-rules.md#appconfig-creating-multi-variant-feature-flags-rules-operators-split)」を参照してください。 `seed` はオプションのプロパティであることに注意してください。`seed` を指定しない場合、ハッシュは*ローカル*で一貫しており、そのフラグに対してトラフィックは一貫して分割されますが、同じコンテキスト値を受け取る他のフラグはトラフィックを異なる方法で分割する可能性があります。`seed` が指定されている場合、各一意の値によって、機能フラグ、設定プロファイル、および AWS アカウント間でトラフィックが一貫して分割されることが保証されます。 | 
(split pct::10 by::$userId seed::"abc")
| ## split 演算子について 次のセクションでは、さまざまなシナリオで使用した場合の `split` 演算子の動作について説明します。`split` は、指定されたコンテキスト値の一貫したハッシュに基づいて、トラフィックの特定の割合に対して `true` と評価します。これをよりよく理解するには、2 つのバリアントで分割を使用する次のベースラインシナリオを検討してください。 ``` A: (split by::$uniqueId pct::20) C: ``` 予想どおり、ランダムな一連の `uniqueId` 値を指定すると、次のようなディストリビューションが生成されます。 ``` A: 20% C: 80% ``` 3 つ目のバリアントを追加しつつ、次のように同じ分割割合を使用する場合: ``` A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::20) C: ``` 最終的に、次のディストリビューションになります。 ``` A: 20% B: 0% C: 80% ``` この予期しないディストリビューションが発生する可能性があるのは、各バリアントルールが順番に評価され、最初の一致によって返されるバリアントが決定されるためです。ルール A が評価されると、`uniqueId` 値の 20% がそれと一致するため、最初のバリアントが返されます。次に、ルール B が評価されます。ただし、2 番目の分割ステートメントに一致するすべての `uniqueId` 値はバリアントルール A によって既に一致しているため、B に一致する値はありません。代わりにデフォルトのバリアントが返されます。 次に、3 番目の例を考えてみましょう。 ``` A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::25) C: ``` 前の例と同様に、`uniqueId` 値の最初の 20% はルール A と一致します。バリアントルール B の場合、すべての `uniqueId` 値の 25% は一致しますが、その大半は既にルール A と一致しています。これにより、全体の 5% がバリアント B で、残りはバリアント C を受け取ります。ディストリビューションは次のようになります。 ``` A: 20% B: 5% C: 75% ``` **`seed` プロパティの使用** `seed` プロパティを使用すると、split 演算子が使用されている場所に関係なく、特定のコンテキスト値に対してトラフィックが一貫して分割されるようにできます。`seed` を指定しない場合、ハッシュは*ローカル*で一貫しており、そのフラグに対してトラフィックは一貫して分割されますが、同じコンテキスト値を受け取る他のフラグはトラフィックを異なる方法で分割する可能性があります。`seed` が指定されている場合、各一意の値によって、機能フラグ、設定プロファイル、および AWS アカウント間でトラフィックが一貫して分割されることが保証されます。 通常、お客様は、同じコンテキストプロパティでトラフィックを分割する場合、フラグ内のバリアント間で同じ `seed` 値を使用します。ただし、別の seed 値を使用することが適切な場合もあります。ルール A と B に異なる seed を使用する例を次に示します。 ``` A: (split by::$uniqueId pct::20 seed::"seed_one") B: (split by::$uniqueId pct::25 seed::"seed_two") C: ``` 以前と同様に、一致する `uniqueId` 値の 20% がルール A に一致します。つまり、値の 80% がフォールスルーされ、バリアントルール B に対してテストされます。seed が異なるため、A に一致する値と B に一致する値の間に相関はありません。ただし、分割対象となる `uniqueId` 値の数は全体の 80% に限られ、そのうちの 25% がルール B に一致し、75% は一致しません。これは次のディストリビューションに当てはまります。 ``` A: 20% B: 20% (25% of what falls through from A, or 25% of 80%) C: 60% ``` # マルチバリアント機能フラグの作成 このセクションの手順を使用して、機能フラグのバリアントを作成します。 **[開始する前に]** 次の重要な情報に注意してください。 + 既存の機能フラグを編集してバリアントを作成できます。*新しい設定プロファイルを作成するときに*、新しい機能フラグのバリアントを作成することはできません。まず、新しい設定プロファイルを作成するワークフローを完了する必要があります。設定プロファイルを作成したら、設定プロファイル内の任意のフラグにバリアントを追加できます。新しい設定プロファイルを作成する方法については、「[で機能フラグ設定プロファイルを作成する AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md)」を参照してください。 + Amazon EC2、Amazon ECS、Amazon EKS コンピューティングプラットフォームの機能フラグバリアントデータを取得するには、 AWS AppConfig エージェントバージョン 2.0.4416 以降を使用する必要があります。 + パフォーマンス上の理由から、 AWS CLI SDK は を呼び出してバリアントデータを取得 AWS AppConfig しません。 AWS AppConfig エージェントの詳細については、「」を参照してください[AWS AppConfig エージェントを使用して設定データを取得する方法](appconfig-agent-how-to-use.md)。 + 機能フラグバリアントを作成するときは、そのバリアントのルールを指定します。ルールは、リクエストコンテキストを入力として受け取り、ブール結果を出力として生成する式です。バリアントを作成する前に、フラグバリアントルールでサポートされているオペランドと演算子を確認してください。バリアントを作成する前にルールを作成できます。詳細については、「[マルチバリアント機能フラグルールについて](appconfig-creating-multi-variant-feature-flags-rules.md)」を参照してください。 **Topics** + [マルチバリアント機能フラグの作成 (コンソール)](#appconfig-creating-multi-variant-feature-flags-procedures-console) + [マルチバリアント機能フラグの作成 (コマンドライン)](#appconfig-creating-multi-variant-feature-flags-procedures-commandline) ## マルチバリアント機能フラグの作成 (コンソール) 次の手順では、 AWS AppConfig コンソールを使用して既存の設定プロファイルのマルチバリアント機能フラグを作成する方法について説明します。既存の機能フラグを編集してバリアントを作成することもできます。 **マルチバリアント機能フラグを作成するには** 1. [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/) で AWS Systems Manager コンソールを開きます。 1. ナビゲーションペインで、**[アプリケーション]** を選択し、アプリケーションを選択します。 1. **[設定プロファイルと機能フラグ]** タブで、既存の機能フラグ設定プロファイルを選択します。 1. **[フラグ]** セクションで、**[新しいフラグの追加]** を選択します。 1. **[機能フラグ定義]** セクションの **[フラグ名]** に名前を入力します。 1. **[フラグキー]** には、フラグ識別子を入力して、同じ設定プロファイル内のフラグを区別します。同じ設定プロファイル内のフラグに同じキーを設定することはできません。フラグを作成した後、フラグ名は編集できますが、フラグキーは編集できません。 1. (オプション) **[説明]** フィールドに、このフラグに関する情報を入力します。 1. **[バリアント]** セクションで、**[マルチバリアントフラグ]** を選択します。 1. (オプション) **[機能フラグ属性]** セクションで、**[属性を定義]** を選択します。属性を使用すると、フラグ内に追加の値を指定できます。属性と制約の詳細については、「[機能フラグ属性について](appconfig-creating-configuration-and-profile-feature-flags.md#appconfig-creating-configuration-profile-feature-flag-attributes)」を参照してください。 1. **[キー]** には、フラグキーを指定し、**[タイプ]** リストからそのタイプを選択します。**[値]** および **[制約]** フィールドでサポートされているオプションについては、属性に関する前述のセクションを参照してください。 1. **必須の値** を選択して、属性値が必須かどうかを指定します。 1. 属性を追加するには、**[属性を定義]** を選択します。 1. 属性の変更を保存するには、**[適用]** を選択します。 1. **[機能フラグバリアント]** セクションで、**[バリアントを作成]** を選択します。 1. **[バリアント名]** に名前を入力します。 1. **[有効化された値]** トグルを使用してバリアントを有効にします。 1. **[ルール]** テキストボックスにルールを入力します。 1. **[バリアントを作成]** > **[上にバリアントを作成]** または **[下にバリアントを作成]** オプションを使用して、このフラグに追加のバリアントを作成します。 1. **[デフォルトバリアント]** セクションで、**[有効化された値]** トグルを使用してデフォルトバリアントを有効にします。必要に応じて、ステップ 10 で定義された属性の値を指定します。 1. **[Apply]** (適用) を選択します。 1. フラグとそのバリアントの詳細を確認し、**[フラグを作成]** を選択します。 新規の機能フラグとバリアントをデプロイする方法の詳細については、「[に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md)」を参照してください。 ## マルチバリアント機能フラグの作成 (コマンドライン) 次の手順では、 AWS Command Line Interface (Linux または Windows) または Tools for Windows PowerShell を使用して、既存の設定プロファイルのマルチバリアント機能フラグを作成する方法について説明します。既存の機能フラグを編集してバリアントを作成することもできます。 **[開始する前に]** AWS CLIを使用して多変量機能フラグを作成する前に、以下のタスクを完了してください。 + 機能フラグ設定プロファイルを作成します。詳細については、「[で機能フラグ設定プロファイルを作成する AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md)」を参照してください。 + AWS CLIを最新バージョンに更新します。詳細については、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLIの最新バージョンをインストールまたは更新する](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 **マルチバリアント機能フラグを作成するには** 1. 作成するマルチバリアントフラグの詳細を指定する設定ファイルをローカルマシンに作成します。ファイル拡張子 (`.json`) を付けてこのファイルを保存します。ファイルは [https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html) JSON スキーマに準拠している必要があります。設定ファイルのスキーマの内容は、次のようになります。 ``` { "flags": { "FLAG_NAME": { "attributes": { "ATTRIBUTE_NAME": { "constraints": { "type": "CONSTRAINT_TYPE" } } }, "description": "FLAG_DESCRIPTION", "name": "VARIANT_NAME" } }, "values": { "VARIANT_VALUE_NAME": { "_variants": [ { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" }, { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" }, { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" }, { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" } ] } }, "version": "VERSION_NUMBER" } ``` 以下は、3 つのバリアントとデフォルトのバリアントの例です。 ``` { "flags": { "ui_refresh": { "attributes": { "dark_mode_support": { "constraints": { "type": "boolean" } } }, "description": "A release flag used to release a new UI", "name": "UI Refresh" } }, "values": { "ui_refresh": { "_variants": [ { "attributeValues": { "dark_mode_support": true }, "enabled": true, "name": "QA", "rule": "(ends_with $email \"qa-testers.mycompany.com\")" }, { "attributeValues": { "dark_mode_support": true }, "enabled": true, "name": "Beta Testers", "rule": "(exists key::\"opted_in_to_beta\")" }, { "attributeValues": { "dark_mode_support": false }, "enabled": true, "name": "Sample Population", "rule": "(split pct::10 by::$email)" }, { "attributeValues": { "dark_mode_support": false }, "enabled": false, "name": "Default Variant" } ] } }, "version": "1" } ``` 1. `CreateHostedConfigurationVersion` API を使用して、機能フラグの設定データを AWS AppConfigに保存します。 ------ #### [ Linux ] ``` aws appconfig create-hosted-configuration-version \ --application-id APPLICATION_ID \ --configuration-profile-id CONFIGURATION_PROFILE_ID \ --content-type "application/json" \ --content file://path/to/feature_flag_configuration_data.json \ --cli-binary-format raw-in-base64-out \ outfile ``` ------ #### [ Windows ] ``` aws appconfig create-hosted-configuration-version ^ --application-id APPLICATION_ID ^ --configuration-profile-id CONFIGURATION_PROFILE_ID ^ --content-type "application/json" ^ --content file://path/to/feature_flag_configuration_data.json ^ --cli-binary-format raw-in-base64-out ^ outfile ``` ------ #### [ PowerShell ] ``` New-APPCHostedConfigurationVersion ` -ApplicationId APPLICATION_ID ` -ConfigurationProfileId CONFIGURATION_PROFILE_ID ` -ContentType "application/json" ` -Content file://path/to/feature_flag_configuration_data.json ` -Raw ``` ------ `service_returned_content_file` には、 AWS AppConfig 生成されたメタデータを含む設定データが含まれています。 **注記** ホストされた設定バージョンを作成すると、 AWS AppConfig はデータが [https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html) JSON スキーマに準拠していることを確認します。 AWS AppConfig さらに、 は、データ内の各機能フラグ属性が、それらの属性に定義した制約を満たしていることを確認します。