PFEM Online Feature Flag @ newmo

Transcript

1. Feature Flag 入門と
 newmo の Feature Flag 基盤
 newmo Platform Team
 Shinya Ishitobi
 @iam__tobi
 1
2. 2 Introduction

3. Speaker
 3 • tobi (Shinya Ishitobi / 石飛 真哉) • newmo, Inc. • Platform team • CNCF Kubestronaut https://training.linuxfoundation.org/ja/resources/k ubestronaut-program/
4. Feature Flag 101
 4 Feature Flag とは システムの振る舞いを動的に変更する仕組み Feature Flag を使うことで デプロイとリリースを分離できる Build Test Deploy Release Feature Flag
5. Agenda
 5 • Fundamentals • Case Study @ newmo • Wrap-up
6. 6 Fundamentals

7. What are Feature Flags?
 7 In the most basic case, you can think of a feature flag as an if/else statement that can be controlled at runtime. Feature flags allow application behavior to be altered without the deployment of new code.
 Feature flags are dynamic; they are evaluated at runtime. Many of the use cases just described also require feature flags to be context-aware - a flagging decision must take into account things like which user is making a web request.
 https://openfeature.dev/docs/reference/intro
8. In other words…
 8 • デプロイを伴わず 新機能や実験的機能のオン・オフを制御 • 機能の公開範囲を 動的に制御 (カナリアリリース , A/B テスト) • ユーザー属性などの コンテキスト により値を評価する ON OFF OFF
9. Why Feature Flag?
 9 • 安全なリリース ◦ デプロイ・リリースのタイミングを切り分けることでリリースのリスクを下げる • トランクベース開発 ◦ 頻繁なマージによる素早い価値提供 • 柔軟な検証や実験 ◦ ユーザーセグメントごとにロールアウトすることで新機能の効果を測る
10. Core Components
 10 • Toggle Points • Toggle Router • Toggle Context • Toggle Configuration https://martinfowler.com/articles/feature-toggles.html
11. Core Components: Toggle Point
 11 • フラグを判定するコード上の 分岐点 • フラグの評価結果によって実行パスを 切り替え 機能のオン・オフを評価するエントリポイント
12. Core Components: Toggle Router
 12 • Toggle Point に対して一貫した評価 結果を返す 単一の情報源 • featureflag.IsActive は内部で Toggle Context と Toggle Configuration をフラグの値を評価
13. Core Components: Toggle Context
 13 • Toggle Router がフラグを評価する 際に利用する 文脈情報 (例: 日付) • 他にもエンドユーザーの属性や参照 元 URL など • Evaluation Context (OpenFeature)
14. Core Components: Toggle Configuration
 14 • Toggle Router がフラグ評価する際 に利用する 外部設定 • FFaaS であれば UI で設定したり、 flagd であれば JSON で管理
15. Core Components
 15 • Toggle Points • Toggle Router • Toggle Context • Toggle Configuration https://martinfowler.com/articles/feature-toggles.html
16. Four Flag Categories
 16 • dynamisim ◦ 評価の動的具合 • longevity ◦ 存続期間 https://martinfowler.com/articles/feature-toggles.html
17. Four Flag Categories
 17 https://martinfowler.com/articles/feature-toggles.html • Release Toggle ◦ 静的で短命 ◦ 単純な機能の on / off • Experiment Toggle ◦ 動的 (リクエストごとに変動 ) ◦ カナリアリリース , A/B テスト
18. What is OpenFeature?
 18 https://openfeature.dev/docs/reference/intro • Feature Flag の実装を共通化・標準化するための オープンソースの仕様・ SDK • Feature Flag をベンダーニュートラル に扱うためのインターフェース • CNCF Incubating Project
19. What is flagd?
 19 https://github.com/open-feature/flagd • OpenFeature 準拠の Feature Flag 評価エンジン • セルフホスト・マルチプラットフォーム・多様な Toggle Configuration ストア • シンプルな API・軽量なので容易に導入可能 • 要件に合わせてカスタマイズ • flagd を別プロセスで動かす RPC mode とアプリケーションに組み込む In Process mode • newmo では拡張性やコストなどを考えて flagd を採用
20. Technical Debt
 20 • Zombie Flags ◦ 役目を終えたフラグがコードベースに残り続ける ◦ いつ消して良いかわからない • Flag Proliferation (フラグの増殖) ◦ フラグの増加に伴い分岐も増加 ◦ テストカバレッジの低下や分岐の連鎖によるバグの混入 • フラグ名の不一致 ◦ コードベース・FFaaS 間でのフラグ名不一致によるバグ 開発者は Feature Flag を利用しなくなる ...
21. 21 Case Study @ newmo

22. Background
 22 • newmo では1日に100回程度 main にマージが走り、その度にコードがデプロイ • モビリティ関連のアプリにおけるインシデントは特に重大で、「一部のエンドユーザー」 のみに安全にリリースの対象にする・徐々にロールアウトする必要性 • 多くの開発者が高速に開発を行うために、なるべく認知負荷の低い方法で解決したい Feature Flag 基盤をプロダクト開発に組み込もう！
23. Key Concepts
 23 • 低コスト ◦ 運用管理コスト・クラウド利用料など ... • 認知負荷の軽減 ◦ 宣言的定義・自動生成など ... • 既存 Platform との統合 ◦ すでに存在する認証認可基盤・ Observability 基盤など... Feature Flag 基盤の設計思想
24. Reducing Cognitive Load
 24 利用したい Feature Flag を宣言的に定義し、 利用する時簡単に使いたいし、 利用し終わったら勝手に消えていて欲しい！ • 宣言的定義 ◦ newmo 独自スキーマの Toggle Configuration • 自動生成 ◦ OSS / FFaaS 向けの Toggle Configuration ◦ アプリケーションで利用する Toggle Router
25. Core Components (again)
 25 • Toggle Points • Toggle Router • Toggle Context • Toggle Configuration https://martinfowler.com/articles/feature-toggles.html
26. Declarative Definition & Auto Code Generation 
 26 newmo 独自の Toggle Configuration OpenFeature の Toggle Router flagd の Toggle Configuration
27. Declarative Definition & Auto Code Generation - flagd
 27 newmo 独自の Toggle Configuration flagd の Toggle Configuration
28. Declarative Definition & Auto Code Generation - Go
 28 newmo 独自の Toggle Configuration OpenFeature の Toggle Router
29. Integration with Existing Platform 
 29 https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html 既存の認証認可基盤 (STS Pattern) がユーザー属性を context で伝播している ので、Feature Flag でもそのまま Toggle Context として利用
30. Architecture Overview
 30
31. Auto Cleanup Workflow
 31 • Go の AST を用いて Toggle Point の個数をカウント • 全ての環境のコードベースで 利用されていないフラグは Toggle Configuration から削除 • （本来は）完全にロールアウトしきった意味のないフラグは「分岐ごと削除する」など、よりプロアク ティブなアプローチが必要
32. Observability
 32 OpenFeature SDK は OpenTelemetry と Hook を利用して統合できる https://github.com/open-feature/go-sdk-contrib/tree/main/hooks/open-telemetry • feature_flag.evaluation_requests_total • feature_flag.evaluation_success_total • feature_flag.evaluation_error_total • …
33. 33 Wrap-up

34. Key Takeaways
 34 • Feature Flag はシンプル ◦ Feature Flag とは システムの振る舞いを動的に変更する仕組み ◦ Feature Flag を使うことで デプロイとリリースを分離できる • Platform は一朝一夕では構築できない ◦ すでに他の基盤があったからこそ Feature Flag も構築できた • https://tech.newmo.me/entry/newmo-feature-flag-system
35. 35 Thank you!