Feature Flagを利用したリリース戦略

の発表資料です。

業務でFeature Flagを簡単に使えるよう整備してリリースに活用したので、そのへんの話を紹介しています。

Transcript

1. Feature Flag を利⽤した リリース戦略 黒曜 @kokuyouwind
2. $ whoami 森 俊介 / 黒曜 @kokuyouwind 株式会社Misoca SRE
3. 本番リリース
4. スモールリリース アジャイルプラクティス ⼩さく、⾼頻度にリリースする 素早く価値を届けられる フィードバックを速く得られる
5. 開発メリット 変更粒度が⼩さくなることで…… コードレビューしやすくなる コードが衝突しづらくなる 問題の原因特定がしやすくなる
6. 😆
7. とはいえ… 現実にはそう簡単にいかないときもある プレスリリース合わせで全部出す ちょっとずつ出すとデータ不整合 ⼀揃いの機能がないとUX が悪い etc...
8. 🤔
9. ビッグバンリリース
10. FeatureFlag 機能を動的にOn/Off できる仕組み ある環境でだけ有効にする あるユーザにだけ有効にする 管理者が全体の有効/ 無効を切り替える etc...
11. FeatureFlag のメリット ⼀般ユーザに⾒せないコードを⼊れられる ⼀般公開と別の単位でリリースできる 公開前の機能を本番で試せる 様々な⽬的に利⽤できる カナリヤリリース A/B テスト etc...
12. というわけで FeatureFlag の話をします
13. アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
14. アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
15. FeatureFlag if feature_enabled? process_with_feature else process_without_feature end 1 2 3 4 5 機能を動的にOn/Off する仕組み 真偽値を返す関数とif ⽂の組み合わせ
16. 基本はこれだけ
17. feature_enabled? システム全体で共通 デプロイ時 ホットリロード リクエストごとに判定 特定ユーザにだけ機能を有効化 特定割合のユーザに機能を有効化 特定属性のユーザに機能を有効化
18. feature_enabled? 設定管理の⽅法は⾊々 環境変数 設定ファイル KVS クラウドサービス etc.
19. FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
20. FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
21. リリーストグル(Release Toggls) リリース前機能を隠すための分岐 不完全なコードのデプロイ デプロイとリリースの分離 短期( リリースしたら消される) 静的( 環境全体の設定)
22. FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
23. 実験トグル(Experiment Toggls) 実ユーザで機能を実験するための分岐 マルチバリエイト分析 A/B テスト 短期〜中期( 実験期間による) 動的( ユーザコホートごとに振り分ける)
24. FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
25. 運⽤トグル(Ops Toggles) 性能をコントロールするための分岐 パフォーマンス影響を⾒て機能デグレさせる 過負荷時の⾼負荷機能オフ 中期〜永続( 上記のいずれの⽬的かによる) 静的( 環境全体の設定)
26. FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
27. 許可トグル(Permission Toggls) 特定のユーザに提供機能を変える分岐 プレミアム機能 α テスト / β テスト ⻑期〜永続 動的( リクエストごとに振り分ける)
28. 同じバケツで管理しない すべてのFeatureFlag を同じ仕組みで管理 するのは危険な道 カテゴリごとに異なる設計を要する 同じ⽅法で管理すると、将来の痛みに つながる Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
29. 個⼈的⾒解 短期的なFeatureFlag での静的/ 動的の別は さほど重要ではない 柔軟に管理できたほうが便利 内部ユーザでの動作確認 カナリヤリリース 短いスパンで消えるコードなので管理 上のつらさも表⾯化しない
30. アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
31. Misoca でのFeatureFlag Feature Toggles (aka Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html 主にこのへん
32. Misoca でのFeatureFlag リリーストグル リリースせず開発期間が⻑期に渡る機能 時間合わせでのリリースが必要な機能 実験トグル・Ops トグル パフォーマンス改善 (A/B テスト、カナリヤテストを兼ねる)
33. 実装 LaunchDarkly を検討したが⾒送り ⾼機能だが費⽤が結構かかる 機能を使いこなせなさそう Redis をバックエンドに⾃作 rollout gem とほぼ同じ仕組みに落ちついた 2 ファイル200 ⾏弱
34. 設定と分岐 # initialize Misoca.feature_flag = Misoca::FeatureFlag.new Misoca.feature_flag.add_target( :new_feature, ' なんかすごい新機能' ) # use if Misoca.feature_flag.enabled?(:new_feature, curren Misoca::UseCase::NewFeature.new.call else Misoca::UseCase::CurrentFeature.new.call end 1 2 3 4 5 6 7 8 9 10 11 12 13
35. ユーザごとの有効化 class Misoca::FeatureFlag::Target def enable_for_user(user) redis.sadd(user_key, user.id) end end Misoca.feature_flag.enable_for_user(user) 1 2 3 4 5 6 7 feature_flag:new_feature:users ( 有効化したユーザid の集合) 42 123456 114514 user id: 123456 redis.sadd 123456
36. ⽐率での有効化 feature_flag:new_feature:segments ( 有効化したユーザid 下2 桁の集合) 00 12 33 redis.sadd 04 87 04 87 例: 有効化率を3% から 5% に 元々含まれない 2 桁の数を2 つ選ぶ (3% から5% なので+2) 04 87
37. ⽐率での有効化 class Misoca::FeatureFlag::Target def enable_percentage(percent) current_segments = redis.smembers(segment_ke unused_segments = ALL_SEGMENTS - current_seg diff_percent = percent - current_segments.co diff_percent.positive? ? redis.sadd(segment_key, unused_segments.sample(diff_percent)) : redis.spop(segment_key, diff_percent.abs end end Misoca.feature_flag.enable_percentage(50) 1 2 3 4 5 6 7 8 9 10 11 12 13 14
38. 有効判定 有効化したユーザid の集合 42 123456 114514 user id: 123456 redis.sismember 123456 有効化したユーザid 下2 桁の集合 00 12 33 redis.sismember 56 04 87
39. 運⽤ 内部ユーザ向けページから有効状況を⾒れる フラグの切り替え 内部ユーザ向けページ( ⾃分のみ) Thor タスク実⾏( ⽐率指定)
40. 実⽤例 軽減税率対応 電卓機能 PDF のS3 キャッシュ
41. 軽減税率対応
42. 軽減税率対応 スモールリリースの難しい機能 影響範囲が広く、作業量が多い プレスリリース合わせでの有効化 リリーストグルを使⽤ コードを適宜master にマージ 内部ユーザはできたところから本番で動作確認 フラグを外して⼀般リリース
43. 電卓機能
44. 電卓機能 ヘルプ更新のため、時間合わせリリース コード量⾃体はそこまで⼤きくない リリーストグルを使⽤ 事前に内部ユーザで動作確認 デプロイせず設定変更のみでリリース デプロイ絡みでのトラブルの⼼配がない
45. PDF のS3 キャッシュ
46. PDF のS3 キャッシュ PDF ⽣成が重いため、S3 に2 次キャッシュ 初回PDF ⽣成時にS3 へ書き込み 1 次キャッシュがない場合、S3 から取得 どの程度改善するか⾒積りづらい S3 へのwrite 処理が増える S3 Read の重さによっては改善しない可能性も
47. PDF のS3 キャッシュ 10% のユーザにリリース→APM で効果測定 PDF Render: 800ms S3 PUT: 94ms S3 GET(miss): 40ms S3 GET(hit): 72ms ⽣成時に+134ms, 読み込み時に728ms 改善 いける！
48. 利⽤者の声 富⼭県 30 代会社員 H.M さん デプロイとリリースが競合しないので 予想外のトラブルを避けられますし、 ロールバックも本当に簡単でした。 分岐処理を後から徐々に外せるのも良いですね。 不満は⼀切ないです。 FeatureFlag 最⾼！ ※ 効果には個⼈差があります
49. 気をつけること 汎⽤のフラグを使わない FeatureFlag を外すときに⼤変 ⼀緒に有効にしたくない機能まで有効になる 新しいフラグを簡単に⾜せると良い リリースしたらきちんとフラグを消す うっかりすると無限にフラグが増える うっかりするとリリース前に巻き戻る
50. 気をつけること2 パフォーマンス影響をチェックする 軽いバックエンドとアルゴリズムにする Redis set はRW ともO(1) 、1~2ms 程度 繰り返し判定しない 1ms でも100 回呼んだら100ms になる 判定結果をキャッシュすると良い
51. アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
52. まとめ ⼤きいリリースはFeatureFlag を使って ⼩分けにデプロイすると便利 ⼩さいものでもFeatureFlag を使うと デプロイせずにリリースできて便利 簡単にフラグを⾜せる/ 消せる仕組みを 整備するのが必要