概要

OpenFeatureはフィーチャーフラグマネジメントにおける標準規格として生まれました。

openfeature.dev

今回はその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
• Events
  • 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 を使う上で必要な構成要素やデータモデルをまとめてみました。

次回は実際にどう実装するかを紹介します。

参考

• https://openfeature.dev/