Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

の発表資料です。

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

kokuyouwind

August 08, 2019
Tweet

More Decks by kokuyouwind

Other Decks in Programming

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 を使うと デプロイせずにリリースできて便利 簡単にフラグを⾜せる/ 消せる仕組みを 整備するのが必要