Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Feature Flagを利用したリリース戦略
Search
kokuyouwind
August 08, 2019
Programming
0
100
Feature Flagを利用したリリース戦略
の発表資料です。
業務でFeature Flagを簡単に使えるよう整備してリリースに活用したので、そのへんの話を紹介しています。
kokuyouwind
August 08, 2019
Tweet
Share
More Decks by kokuyouwind
See All by kokuyouwind
Let's use LLMs from Ruby 〜 Refine RBS types using LLM 〜
kokuyouwind
0
5k
APMをちゃんと使おうとしたら、いつのまにか独自gemを作っていた話
kokuyouwind
0
530
RBS meets LLMs - Type inference using LLM
kokuyouwind
0
670
オンラインボードゲームを作りたい人生だった
kokuyouwind
0
300
1年間本番運用してわかった、スタートアップこそAWS Copilot CLIを使うべきNつの理由
kokuyouwind
2
10k
なるべく楽したいAWSセキュリティ
kokuyouwind
1
32
Railsパフォーマンス・チューニング入門
kokuyouwind
0
200
Rubyパターンマッチに闇の力が備わり最強に見える
kokuyouwind
0
54
Slackワークフロー活用術
kokuyouwind
0
60
Other Decks in Programming
See All in Programming
継続的な活動で築く地方エンジニアの道
myamashii
2
350
Clean Architecture by TypeScript & NestJS
ryounasso
0
150
Javaの現状2024夏 / Java current status 2024 summer
kishida
4
1.4k
Architectures with Lightweight Stores: New Rules and Options
manfredsteyer
PRO
0
100
ぼっちを避けて楽しむためのアノテコノテ / Various Tips and Tricks to Avoid Loneliness and Have Fun
nrslib
3
1.7k
HMSコンペ 11th Solution (team : kansai-kaggler)
t88
1
680
Terraformテスト入門
msato
0
520
Android開発者のための Kotlin Multiplatform入門
ntaro
0
190
【Go言語】ジェネリクス
tomo1227
0
170
企業向け生成AIアプリの 開発から得られた知見
takaakikakei
0
310
なぜ宣言的 UI は壊れにくいのか / Why declarative UI is less fragile
uenitty
29
13k
しくじり先生 Image Matching Challenge 2024 編
goosehaaan
0
810
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
33
6.9k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
189
16k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
129
32k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
We Have a Design System, Now What?
morganepeng
46
7k
Building Adaptive Systems
keathley
34
2k
Fireside Chat
paigeccino
25
2.8k
The Pragmatic Product Professional
lauravandoore
29
6.1k
Adopting Sorbet at Scale
ufuk
71
8.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
Git: the NoSQL Database
bkeepers
PRO
423
64k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.8k
Transcript
Feature Flag を利⽤した リリース戦略 黒曜 @kokuyouwind
$ whoami 森 俊介 / 黒曜 @kokuyouwind 株式会社Misoca SRE
本番リリース
スモールリリース アジャイルプラクティス ⼩さく、⾼頻度にリリースする 素早く価値を届けられる フィードバックを速く得られる
開発メリット 変更粒度が⼩さくなることで…… コードレビューしやすくなる コードが衝突しづらくなる 問題の原因特定がしやすくなる
😆
とはいえ… 現実にはそう簡単にいかないときもある プレスリリース合わせで全部出す ちょっとずつ出すとデータ不整合 ⼀揃いの機能がないとUX が悪い etc...
🤔
ビッグバンリリース
FeatureFlag 機能を動的にOn/Off できる仕組み ある環境でだけ有効にする あるユーザにだけ有効にする 管理者が全体の有効/ 無効を切り替える etc...
FeatureFlag のメリット ⼀般ユーザに⾒せないコードを⼊れられる ⼀般公開と別の単位でリリースできる 公開前の機能を本番で試せる 様々な⽬的に利⽤できる カナリヤリリース A/B テスト etc...
というわけで FeatureFlag の話をします
アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
FeatureFlag if feature_enabled? process_with_feature else process_without_feature end 1 2 3
4 5 機能を動的にOn/Off する仕組み 真偽値を返す関数とif ⽂の組み合わせ
基本はこれだけ
feature_enabled? システム全体で共通 デプロイ時 ホットリロード リクエストごとに判定 特定ユーザにだけ機能を有効化 特定割合のユーザに機能を有効化 特定属性のユーザに機能を有効化
feature_enabled? 設定管理の⽅法は⾊々 環境変数 設定ファイル KVS クラウドサービス etc.
FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson
https://martinfowler.com/articles/feature-toggles.html
FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson
https://martinfowler.com/articles/feature-toggles.html
リリーストグル(Release Toggls) リリース前機能を隠すための分岐 不完全なコードのデプロイ デプロイとリリースの分離 短期( リリースしたら消される) 静的( 環境全体の設定)
FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson
https://martinfowler.com/articles/feature-toggles.html
実験トグル(Experiment Toggls) 実ユーザで機能を実験するための分岐 マルチバリエイト分析 A/B テスト 短期〜中期( 実験期間による) 動的( ユーザコホートごとに振り分ける)
FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson
https://martinfowler.com/articles/feature-toggles.html
運⽤トグル(Ops Toggles) 性能をコントロールするための分岐 パフォーマンス影響を⾒て機能デグレさせる 過負荷時の⾼負荷機能オフ 中期〜永続( 上記のいずれの⽬的かによる) 静的( 環境全体の設定)
FeatureFlag の分類 Feature Toggles (aka Feature Flags) / Pete Hodgson
https://martinfowler.com/articles/feature-toggles.html
許可トグル(Permission Toggls) 特定のユーザに提供機能を変える分岐 プレミアム機能 α テスト / β テスト ⻑期〜永続
動的( リクエストごとに振り分ける)
同じバケツで管理しない すべてのFeatureFlag を同じ仕組みで管理 するのは危険な道 カテゴリごとに異なる設計を要する 同じ⽅法で管理すると、将来の痛みに つながる Feature Toggles (aka
Feature Flags) / Pete Hodgson https://martinfowler.com/articles/feature-toggles.html
個⼈的⾒解 短期的なFeatureFlag での静的/ 動的の別は さほど重要ではない 柔軟に管理できたほうが便利 内部ユーザでの動作確認 カナリヤリリース 短いスパンで消えるコードなので管理 上のつらさも表⾯化しない
アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
Misoca でのFeatureFlag Feature Toggles (aka Feature Flags) / Pete Hodgson
https://martinfowler.com/articles/feature-toggles.html 主にこのへん
Misoca でのFeatureFlag リリーストグル リリースせず開発期間が⻑期に渡る機能 時間合わせでのリリースが必要な機能 実験トグル・Ops トグル パフォーマンス改善 (A/B テスト、カナリヤテストを兼ねる)
実装 LaunchDarkly を検討したが⾒送り ⾼機能だが費⽤が結構かかる 機能を使いこなせなさそう Redis をバックエンドに⾃作 rollout gem とほぼ同じ仕組みに落ちついた
2 ファイル200 ⾏弱
設定と分岐 # 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
ユーザごとの有効化 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
⽐率での有効化 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
⽐率での有効化 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
有効判定 有効化したユーザid の集合 42 123456 114514 user id: 123456 redis.sismember
123456 有効化したユーザid 下2 桁の集合 00 12 33 redis.sismember 56 04 87
運⽤ 内部ユーザ向けページから有効状況を⾒れる フラグの切り替え 内部ユーザ向けページ( ⾃分のみ) Thor タスク実⾏( ⽐率指定)
実⽤例 軽減税率対応 電卓機能 PDF のS3 キャッシュ
軽減税率対応
軽減税率対応 スモールリリースの難しい機能 影響範囲が広く、作業量が多い プレスリリース合わせでの有効化 リリーストグルを使⽤ コードを適宜master にマージ 内部ユーザはできたところから本番で動作確認 フラグを外して⼀般リリース
電卓機能
電卓機能 ヘルプ更新のため、時間合わせリリース コード量⾃体はそこまで⼤きくない リリーストグルを使⽤ 事前に内部ユーザで動作確認 デプロイせず設定変更のみでリリース デプロイ絡みでのトラブルの⼼配がない
PDF のS3 キャッシュ
PDF のS3 キャッシュ PDF ⽣成が重いため、S3 に2 次キャッシュ 初回PDF ⽣成時にS3 へ書き込み
1 次キャッシュがない場合、S3 から取得 どの程度改善するか⾒積りづらい S3 へのwrite 処理が増える S3 Read の重さによっては改善しない可能性も
PDF のS3 キャッシュ 10% のユーザにリリース→APM で効果測定 PDF Render: 800ms S3
PUT: 94ms S3 GET(miss): 40ms S3 GET(hit): 72ms ⽣成時に+134ms, 読み込み時に728ms 改善 いける!
利⽤者の声 富⼭県 30 代会社員 H.M さん デプロイとリリースが競合しないので 予想外のトラブルを避けられますし、 ロールバックも本当に簡単でした。 分岐処理を後から徐々に外せるのも良いですね。
不満は⼀切ないです。 FeatureFlag 最⾼! ※ 効果には個⼈差があります
気をつけること 汎⽤のフラグを使わない FeatureFlag を外すときに⼤変 ⼀緒に有効にしたくない機能まで有効になる 新しいフラグを簡単に⾜せると良い リリースしたらきちんとフラグを消す うっかりすると無限にフラグが増える うっかりするとリリース前に巻き戻る
気をつけること2 パフォーマンス影響をチェックする 軽いバックエンドとアルゴリズムにする Redis set はRW ともO(1) 、1~2ms 程度 繰り返し判定しない
1ms でも100 回呼んだら100ms になる 判定結果をキャッシュすると良い
アジェンダ FeatureFlag の基本と分類 Misoca でのFeatureFlag の使い⽅ まとめ
まとめ ⼤きいリリースはFeatureFlag を使って ⼩分けにデプロイすると便利 ⼩さいものでもFeatureFlag を使うと デプロイせずにリリースできて便利 簡単にフラグを⾜せる/ 消せる仕組みを 整備するのが必要