概要
OpenFeatureはフィーチャーフラグマネジメントにおける標準規格として生まれました。
今回はそのOpenFeatureについて紹介します。
なぜ生まれたか？
従来
通常フィーチャーフラグ管理システムはこのようにアプリケーションと密に結合して利用されます。
例えばRelease Togglesでは機能の有効化・無効化など重要な機能として使うため、フィーチャーフラグ管理システムは高い可用性求められますし、Experiment Togglesではユーザ属性に応じた振り分けをするため高い柔軟性が求められます。
しかし前述の様に密結合しているため、フィーチャーフラグ管理システムを変更することは困難でした。
OpenFeature
そこでOpenFeatureは上図のように
- プラガブルなフィーチャーフラグ管理システム（Providers）
- 一貫した統一APIを提供
という形で解決してくれました。
構成要素やデータモデル
構成要素
OpenFeature の構成要素としては以下があります。
- Evaluation API
- フィーチャーフラグを使うためのAPI IF
- Evaluation Context
- フィーチャーフラグのターゲティングなどに使うContextデータの塊（コンテナ）
- Providers
- Evaluation APIとフラグ管理システムとの変換層
- 中身的にはベンダーのSDKをラップしてるだけ
- Hooks
- フラグ評価のライフサイクルにおけるHook。具体的には以下で使う
- ロギング
- トレース
- Evaluation Contextへのデータ変更・追加
- フラグ値のvalidation
- フラグ評価のライフサイクルにおけるHook。具体的には以下で使う
- Events
- Providersなどの状態変化を使ったイベント駆動の処理ができる
- Providersの準備状況の変化
- エラーステータスの変化
- フラグ設定の変化
- Providersなどの状態変化を使ったイベント駆動の処理ができる
処理シーケンス
各要素は次のような処理シーケンスで利用されます。
ref: https://signoz.io/blog/openfeature/
データモデル
OpenFeature のデータモデルは次のようになっています。
ref: https://openfeature.dev/specification/glossary#flagging-specifics
Flag
- フィーチャーフラグ。スイッチ
Flag Key
- フィーチャーフラグを一意に識別するための文字列。評価時にこのキーを使って対象のフラグを取得
Variant
- 各Flagが持つバリアント。Flagが取り得る「状態」や「値」
Targeting
評価コンテキストに基づいて、どのバリアントを返すか決定するルールセット
Rule
各ルールは特定の条件（例: ユーザーの属性やターゲティングキーの値）を定義しており、評価コンテキストが条件に一致すれば、該当するバリアントが選ばれる
Targeting Key
ルール評価に使われる、コンテキスト内の特定属性のキー
Fractional Evaluation
- ユーザを一定の割合でバリアントに割り当てる仕組み。
- A/Bテストや段階リリースに使う。
Default Rule/Default Variant
どのルールにも引っかからなかった場合のルール。またはターゲティングルールがない場合のデフォルト値
クラス図
各データの関係図はこのようになっています。
まとめ
OpenFeature を使う上で必要な構成要素やデータモデルをまとめてみました。
次回は実際にどう実装するかを紹介します。
