FeatureFlagを使ってサクッとリリースする

Misoca開発チームの黒曜(@kokuyouwind)です。

技術書典7の準備があんまり進んでなくてワタワタしています。

少し前の話になってしまいますが、8月8日に開催されたもくテクpowered by Misoca #2でFeature Flagを使ったリリースの話をしてきました。

以下がそのときの発表スライドです。

今回はこの発表内容をブログでおさらいしたいと思います。

Feature Flagは、機能の有効・無効をコード上で切り替えるテクニックです。(Feature ToggleやFeature Switchなどと呼ばれることもあります。)

ざっくり言うならば、以下のようにフラグに応じて機能を有効にするのがFeature Flagです。

if feature_enabled?
  process_with_feature()
else
  process_without_feature()
end

概念自体は非常に単純ですが、この仕組みを使うことで開発者による事前動作確認やデプロイなしでの機能リリース、A/Bテストなど様々に応用することができます。

応用の分類などは Pete Hodgson氏のFeature Toggles (aka Feature Flags)という記事がわかりやすいので、そちらをご覧ください。*1

FeatureFlagを運用する上では「どの機能について」「誰に対して有効にするか」をうまく管理することが重要です。

Misocaではもともと「開発者のみ有効になるフラグ」を1つ用意して、このフラグを見て分岐処理することで事前確認を行っていました。

しかし、この方法では以下のような問題がありました。

このため、機能ごとにフラグを簡単に追加でき、個別ユーザ単位だけではなく「全ユーザに対して一括で有効にできる」ようなフラグ管理のシステムを導入しました。

ライブラリはいくつかの事情で自作したものを使っていますが、概ねrollout gemと同じインターフェイスになっています。また、バックエンドにはRedisを使っています。

以下のような開発用の管理画面から「現在のユーザについて機能の有効・無効を切り替え」「その機能が一般ユーザに公開されているかの確認」を行うことができるようにしています。

以下の例では「DocumentCacheのS3化」という機能が全ユーザ(100%)に対して公開されている状態です。

f:id:kokuyouwind:20190829165255p:plain

上述の通り機能ごとの有効・無効を簡単に切り替えられるようになったため、新しい機能の動作確認だけではなく、複数の機能の兼ね合いなども確認しやすくなりました。

またデプロイをせずに一般ユーザへ公開できるというのが非常に便利でした。特にリリース時刻が決まっている場合CIトラブル・デプロイトラブルなどが非常に怖いのですが、Feature Flagを使うことでそういった問題を避けて確実にリリースすることができます。

さらに、データベース周りなど「パフォーマンスに影響を与えそうな変更」についても一部ユーザのみに絞ってリリースすることで、効果を検証し問題があっても素早く巻き戻せるようになりました。

MisocaではFeature Flagを使ってサクッとリリースしたいエンジニアを募集しています。