Feature Flagについて本気出して考えて実践してみた

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © RevComm Inc. Feature Flag とは？ 13 ● Feature Flag とは... ○ Feature Toggle などとも呼ばれる ○ Feature Toggle (or Feature Flags) とは、チームがコードの変更なしでシステムの挙動を修正できるようにする強力な技術である。 ■ https://martinfowler.com/articles/feature-toggles.html ○ Feature ﬂag とは、機能の有効化・無効化をソースコードの修正や再デプロイ不要でできるようにするためのソフトウェア開発のコンセプトである。 ■ https://launchdarkly.com/blog/what-are-feature-ﬂags/

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © RevComm Inc. ● Feature Flag とは... ○ ここでは ■ 「機能の有効化・無効化をコードの修正なしで実現する概念やその手法」 ■ という定義として、大らかな意味で捉えて使うことにする ○ よくある実装例 Feature Flag とは？ 17 関数の中では実行時に true / false が決まるようになっている (例: 環境変数、サービスへの問い合わせ、など)

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 ○ 継続的デリバリが容易に ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和 ○ リスクの低減 ■ ホットフィックスや完全なロールバックなしに機能の ON / OFF を切り替えられる ● ←「ロールバックすると、別の変更も戻ってしまう」問題の緩和 ○ 段階的リリースが容易に (一部のユーザーだけに公開、など) Feature Flag とは？ 21

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Copyright © RevComm Inc. ● 連携するシステムになるべく依存せずに開発したい ○ 音声解析サービスとして、複数のシステム・チームと連携が必要 ○ 以下のシナリオにも簡単に対応したい ■ 1. 電話で最初に使う機能Aをリリース ■ 2. Web Meeting で最初に使う機能B をリリース ■ 3. 機能Aだけ戻す ● (再掲: 機械学習サービスはリリース後の挙動が予想しにくい) 32 背景・検討 | 課題❷ 連携するシステムになるべく依存せずに開発したい

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Copyright © RevComm Inc. 43 * https://martinfowler.com/articles/feature-toggles.html に翻訳を加えたもの背景・検討 | Feature Flag の分類生存期間変更頻度デプロイごとに変更実行中の再設定で変更リクエストごとに変更数年数ヶ月数週間数日 ** 一部大幅な意訳あり (“変更頻度” の原文: Dynamism)

Slide 44

Slide 44 text

Copyright © RevComm Inc. 44 * https://martinfowler.com/articles/feature-toggles.html に翻訳を加えたもの背景・検討 | Feature Flag の分類生存期間変更頻度デプロイごとに変更実行中の再設定で変更リクエストごとに変更数年数ヶ月数週間数日主要な軸は2つ ● 生存期間 ○ いつまで ﬂag を使うか？ ● 変更頻度 ○ どのタイミングでの変更が必要？ ** 一部大幅な意訳あり (“変更頻度” の原文: Dynamism)

Slide 45

Slide 45 text

Copyright © RevComm Inc. 45 * https://martinfowler.com/articles/feature-toggles.html に翻訳を加えたもの背景・検討 | Feature Flag の分類生存期間変更頻度デプロイごとに変更実行中の再設定で変更リクエストごとに変更数年数ヶ月数週間数日 Release Toggles ● 未完成のコードもリリースできるようにする (トランクベース開発など) ● リリースの制御のために利用される ** 一部大幅な意訳あり (“変更頻度” の原文: Dynamism)

Slide 46

Slide 46 text

Copyright © RevComm Inc. 46 * https://martinfowler.com/articles/feature-toggles.html に翻訳を加えたもの背景・検討 | Feature Flag の分類生存期間変更頻度デプロイごとに変更実行中の再設定で変更リクエストごとに変更数年数ヶ月数週間数日 Experiment Toggles ● A/Bテストを実施する ● リクエストごとにランタイムで特定のコードを実行する ** 一部大幅な意訳あり (“変更頻度” の原文: Dynamism)

Slide 47

Slide 47 text

Copyright © RevComm Inc. 47 * https://martinfowler.com/articles/feature-toggles.html に翻訳を加えたもの背景・検討 | Feature Flag の分類生存期間変更頻度デプロイごとに変更実行中の再設定で変更リクエストごとに変更数年数ヶ月数週間数日 Ops Toggles ● システムの運用面の振る舞いを制御する ● 機能のパフォーマンスが不明確な場合や、必要に応じてその機能を迅速に無効にする ** 一部大幅な意訳あり (“変更頻度” の原文: Dynamism)

Slide 48

Slide 48 text

Copyright © RevComm Inc. 48 * https://martinfowler.com/articles/feature-toggles.html に翻訳を加えたもの背景・検討 | Feature Flag の分類生存期間変更頻度デプロイごとに変更実行中の再設定で変更リクエストごとに変更数年数ヶ月数週間数日 Permission Toggles ● 特定のユーザーにのみ恒久的に製品体験を変更する ● 例: プレミアムユーザーのみに特定の機能をオンにする場合など ** 一部大幅な意訳あり (“変更頻度” の原文: Dynamism)

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Copyright © RevComm Inc. 1. 環境変数で制御する ○ 利点: 通信が発生しない。追加コストなし。 ○ 欠点: リアルタイムな変更が難しい (再起動が必要)。フロントエンドなどと協調困難。 ○ 実装: とても簡単。EKS x ArgoCD の GitOps なので、ConﬁgMap (設定用の yamlファイル)を修正してマージするだけでOK 実装 | 方針 1. 環境変数で制御する 57

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Copyright © RevComm Inc. 2. アプリケーション設定サービス(AWS AppConﬁg など)を利用する ○ 利点: 再起動不要。低コスト。型付きで値を保持できる。 ○ 欠点: 呼び出し回数を考慮する必要あり。 ○ 実装: 簡単。Terraform を使って CD を整備すれば、承認付きで更新も反映できる ○ ← 再起動のハードルが高かったり、設定を共有する範囲が比較的広い場合 (例: ECS でも Lambda でも参照する、など)に有効。実装 | 方針 2. アプリケーション設定サービスを利用する 60

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Copyright © RevComm Inc. 3. Feature Flag 専用サービス(Launch Darkly, Unleash など)を利用する ○ 利点: フロントエンドとの協調も容易。監視充実。遅れの少ない反映。 ○ 欠点: 高コスト。サービスを理解する必要あり。 ○ 実装: SDKがあるので簡単。 ○ ← A/B Testing などでリクエスト単位の制御が必要だったり、設定のリアルタイム性が重要な場合などに有効実装 | 方針 3. Feature Flag 専用サービスを利用する 62

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Copyright © RevComm Inc. ● 1. 環境変数で制御する方式を採用 ○ 再起動することが許容できる ■ 切り替えのタイミングをそこまで厳密に制御する必要がない ○ 導入企業ごとに機能のON/OFFができれば十分 ○ ConﬁgMap を変更するだけでよく楽だった ○ 既存の実装は変数へのハードコードだったので、移行も楽だった ● 全社的な導入が必要だったり、リクエスト単位での挙動の変更が必要な A/B Testing が必要になった際に、Feature Flag 専用サービスを利用 or 作成すれば良さそう 64 実装 | 方針

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

Slide 85

Slide 85 text

Slide 86

Slide 86 text

Copyright © RevComm Inc. ● 「Feature Flag って 4種類あんねん」 ○ 生存期間と変更頻度を中心に整理 → 実装方針が明確になりやすい ● Kubernetes 内で完結する場合は、ConﬁgMap での運用は簡単でおすすめ ○ ただし、Release Toggle で再起動を許容できる場合に限る ○ 広範囲に導入 or リクエスト単位での制御が必要なら専用サービスが良さそう ● Feature Flag は不要になった後の対応まで考慮する必要がある ○ 定期ジョブなどを利用して不要な分岐を削除できるようにするまとめ 86