フィーチャーフラグって難しそう？
フィーチャーフラグ（feature flag）とは、簡単に言うとコードの中で機能のON・OFFを切り替えるためのフラグです。
フィーチャーフラグを使えば好きなタイミングで機能を切り替えられるなんて聞いたことがあるかもしれません。ただ、自分が最初にフィーチャーフラグという概念を知った時、なんだか難しそうな印象を受けました。
どんなツールを使えば良いのかもよくわからないし、そもそもどうやってフィーチャーフラグを実装するのかもよくわからない🤔
フィーチャーフラグという概念はなんとなく知っているけど、実際にどうやって使えるのかわからないという感じでした。
ただ、実際に使ってみると意外と簡単で、しかも色々な場面で使えることがわかったので、今回簡単にまとめてみたいと思います！
フィーチャーフラグ = if else
誤解を恐れずに言うと、
フィーチャーフラグ = if else
です。
もちろん色々な実装方法はあるかと思いますが、本質的にはif-elseによる条件分岐です。
if (featureFlag) {
// ...do something
} else {
// ...do something else
}実際にフィーチャーフラグを導入する時も、まさに上記のコードのようなif文を書いたりします。
featureFlagがtrueの場合は新しい機能を、falseの場合は既存の機能を使うみたいな形です。
例えば、マイクロサービスにおいて、特定のプロパティを今までサービスAから取得していたところを、新しいサービスBから取得したいとなった時、呼び出し先のサービスをフィーチャーフラグによって切り替えることができます。
val property = if (useNewServiceFlag) {
callServiceB()
} else {
callServiceA()
}これがフィーチャーフラグの使い方で、めちゃくちゃシンプルです。
ただ、実際にフィーチャーフラグを使おうとなった時に考えなければならないのが、どのようにフィーチャーフラグを管理するかということです。
フィーチャーフラグの管理
フィーチャーフラグを管理するにはいくつかの方法が考えられます。
- コード内で直接管理
- 設定ファイルで管理
- 外部サービスで管理
コード内で直接管理
コード内に直接フィーチャーフラグをハードコードする方法です。
val featureFlag = true
...
if (featureFlag) {
// ...do something
} else {
// ...do something else
}これはあまり実践的な方法ではないとは思いますが、小規模の開発やPoCなどではありかもしれません。
設定ファイルで管理
変数だけコード内で定義しておいて、実際の値は設定ファイルからセットする方法です。
Springの場合、application.yamlから値を取得する方法があります。
@ConfigurationProperties(prefix = "feature-flags")
data class FeatureFlags(
val featureFlagA: Boolean
)feature-flags:
feature-flag-a: fooさらに、設定ファイルには環境変数などから値を取得できるようにしておくことで簡単にON・OFFの切り替えができるようになります。
外部サービスで管理
外部サービスで管理する方法は、設定ファイルで管理する方法に、ターゲットを絞ったりタイミングを制御できたりする機能が追加されたようなイメージを持っています。
また、ツールにもよるかと思いますが、環境変数を動的に書き換えることでアプリケーションのデプロイが不要になるといったメリットも大きいです。
私自身は使ったことはないですが、LaunchDarklyといったツールがあるようです。
フィーチャーフラグのユースケース
私自身がフィーチャーフラグを使ったことのあるユースケースとしては、
- 一般公開前の機能のデプロイ
- 問題発生時のロールバック手段
- A/Bテスト
が挙げられます。
一般公開前の機能のデプロイ
一般のユーザーにまだ公開していない機能を本番環境にデプロイするときにフィーチャーフラグを使うことができます。
特に、トランクベース開発をしていたりすると、フィーチャーブランチを切らないで直接メインのブランチに変更をマージしたりすることがよくあるため、本番環境でそういった機能が使われないよう制御する必要があります。
フィーチャーフラグを用いることで、一般に公開したいタイミングで簡単に機能をONにすることができ、フィーチャーブランチを長期間保持するよりもコードの管理は比較的楽になる場合があります。
問題発生時のロールバック手段
機能をロールアウトした後に何かしらの問題が発生した場合、フィーチャーフラグをOFFにすることで簡単にロールバックすることができます。
もちろん、デプロイ自体を簡単にロールバックできるような仕組みは他にあったほうが良いですが、例えばデプロイ後一定時間経ってから問題が発覚するということもあり、その場合はもうデプロイをロールバックできなくなっていることもあります。
そういったときにフィーチャーフラグがあると簡単に新機能を隠すことができ、ロールアウト時のリスクを軽減することができます。
もちろん、これは「一般公開前の機能のデプロイ」とも組み合わせることもできます。
A/Bテスト
これは何かしらの外部サービスなどを使ってユーザーをグループ分けしてフィーチャーフラグのON・OFFを切り替えられる必要がありますが、特定のユーザーにだけ新機能を公開することで、旧機能とのA/Bテストを行うこともできます。
A/Bテストのツールは他にもたくさんあると思うので、どのレイヤーでグループ分けをするかといった議論はありますが、フィーチャーフラグを使うことで少なくともコードベースは共通で、フィーチャーフラグのON・OFFだけを切り替えることでA/Bテストを実現できるといったメリットがあります。
フィーチャーフラグの注意点
フィーチャーフラグを使うことは意外と簡単だという話をしてきましたが、実際に運用していく上では少し注意が必要です。
というもの、フィーチャーフラグを至るところで使っていると、今どの環境でどの機能が有効になっているのかといったことがわからなくなったり、デプロイの時に誤ってフィーチャーフラグのON・OFFを切り替えて意図しない挙動をしたりといったリスクが高まります。
マイクロサービスでフィーチャーフラグを使用する場合は、関係するチームやステークホルダーと切り替えるタイミングやフラグ自体を削除する時期などをよくすり合わせておくことが大切かと思います。
まとめ
フィーチャーフラグは意外と簡単に使えるというお話でした。
今回紹介した管理方法やユースケース以外にも色々あると思うので、気になるところがあればコメントいただけると嬉しいです。
コメント