Feature Flagについて本気出して考えて実践してみた
by
RevComm_inc
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
Copyright © RevComm Inc. Feature Flag について 本気出して考えて実践してみた RevComm Research Dept. Development Group Noriki Takahashi
Slide 2
Slide 2 text
Copyright © RevComm Inc. Outline 1. 自己紹介 2. Feature Flag とは? 3. 背景・検討 4. 実装 5. 結果 6. まとめ
Slide 3
Slide 3 text
Copyright © RevComm Inc. 1. 自己紹介 2. Feature Flag とは? 3. 背景・検討 4. 実装 5. 結果 6. まとめ Outline
Slide 4
Slide 4 text
Copyright © RevComm Inc. 自己紹介 | 概要 4 ● 名前 ○ 高橋 典生 (たかはし のりき) / nrnrk (のりのりき) ● 業務内容 ○ 機械学習の研究成果を製品に組み込みユーザーに価値を届ける ○ 研究開発チームの生産性向上 ● 好きなもの ○ Kubernetes, MLOps, Rust, 型システム, 数学/物理学
Slide 5
Slide 5 text
Copyright © RevComm Inc. 自己紹介 | 関わっているプロダクト 5
Slide 6
Slide 6 text
Copyright © RevComm Inc. 自己紹介 | 関わっているプロダクト 6
Slide 7
Slide 7 text
Copyright © RevComm Inc. 自己紹介 | 関わっているプロダクト 7 この部分の音声解析のシステムを 開発・運用しています 文字起こし トピック推定 感情認識
Slide 8
Slide 8 text
Copyright © RevComm Inc. 1. 自己紹介 2. Feature Flag とは? 3. 背景・検討 4. 実装 5. 結果 6. まとめ Outline
Slide 9
Slide 9 text
Copyright © RevComm Inc. Feature Flag とは? 9 発表のテーマは Feature Flag
Slide 10
Slide 10 text
Copyright © RevComm Inc. ところで Feature Flag とは 何だろう? Feature Flag とは? 10
Slide 11
Slide 11 text
Copyright © RevComm Inc. Feature Flag とは? 11 一般的な定義を確認する
Slide 12
Slide 12 text
Copyright © RevComm Inc. ● Feature Flag とは... ○ Feature Toggle などとも呼ばれる Feature Flag とは? 12
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 flag とは、機能の有効化・無効化をソースコードの修正や再デプロ イ不要でできるようにするためのソフトウェア開発のコンセプトである。 ■ https://launchdarkly.com/blog/what-are-feature-flags/
Slide 14
Slide 14 text
Copyright © RevComm Inc. ● Feature Flag とは... ○ ここでは Feature Flag とは? 14
Slide 15
Slide 15 text
Copyright © RevComm Inc. ● Feature Flag とは... ○ ここでは ■ 「機能の有効化・無効化をコードの修正なしで実現する概念やその手法」 ■ という定義として、大らかな意味で捉えて使うことにする Feature Flag とは? 15
Slide 16
Slide 16 text
Copyright © RevComm Inc. ● Feature Flag とは... ○ ここでは ■ 「機能の有効化・無効化をコードの修正なしで実現する概念やその手法」 ■ という定義として、大らかな意味で捉えて使うことにする ○ よくある実装例 Feature Flag とは? 16
Slide 17
Slide 17 text
Copyright © RevComm Inc. ● Feature Flag とは... ○ ここでは ■ 「機能の有効化・無効化をコードの修正なしで実現する概念やその手法」 ■ という定義として、大らかな意味で捉えて使うことにする ○ よくある実装例 Feature Flag とは? 17 関数の中では実行時に true / false が決まるようになっている (例: 環境変数、サービスへの問い合わせ、など)
Slide 18
Slide 18 text
Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 Feature Flag とは? 18
Slide 19
Slide 19 text
Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 ○ 継続的デリバリが容易に ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和 Feature Flag とは? 19
Slide 20
Slide 20 text
Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 ○ 継続的デリバリが容易に ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和 ○ リスクの低減 ■ ホットフィックスや完全なロールバックなしに機能の ON / OFF を切り替えられる ● ←「ロールバックすると、別の変更も戻ってしまう」問題の緩和 Feature Flag とは? 20
Slide 21
Slide 21 text
Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 ○ 継続的デリバリが容易に ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和 ○ リスクの低減 ■ ホットフィックスや完全なロールバックなしに機能の ON / OFF を切り替えられる ● ←「ロールバックすると、別の変更も戻ってしまう」問題の緩和 ○ 段階的リリースが容易に (一部のユーザーだけに公開、など) Feature Flag とは? 21
Slide 22
Slide 22 text
Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 ○ 継続的デリバリが容易に ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和 ○ リスクの低減 ■ ホットフィックスや完全なロールバックなしに機能の ON / OFF を切り替えられる ● ←「ロールバックすると、別の変更も戻ってしまう」問題の緩和 ○ 段階的リリースが容易に (一部のユーザーだけに公開、など) ○ A/B テストを容易に Feature Flag とは? 22
Slide 23
Slide 23 text
Copyright © RevComm Inc. ● 一般的な Feature Flag のメリットの例 ○ 継続的デリバリが容易に ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和 ○ リスクの低減 ■ ホットフィックスや完全なロールバックなしに機能の ON / OFF を切り替えられる ● ←「ロールバックすると、別の変更も戻ってしまう」問題の緩和 ○ 段階的リリースが容易に (一部のユーザーだけに公開、など) ○ A/B テストが容易に Feature Flag とは? 23 機能の ON / OFF 制御を簡単にできるようにすることで 開発効率を向上させつつ、一定の安定性も担保することができる
Slide 24
Slide 24 text
Copyright © RevComm Inc. 1. 自己紹介 2. Feature Flag とは? 3. 背景・検討 4. 実装 5. 結果 6. まとめ Outline
Slide 25
Slide 25 text
Copyright © RevComm Inc. 背景・検討 | 課題 25 Feature Flag がどういうものかは何 となくわかった
Slide 26
Slide 26 text
Copyright © RevComm Inc. 26 でも、どうして Feature Flag が必 要なんだっけ? 背景・検討 | 課題
Slide 27
Slide 27 text
Copyright © RevComm Inc. ● チームのミッション(の一つ) ○ 「機械学習の研究成果を製品に組み込みユーザーに届ける」 ● 上記を実現するには、より迅速に安全に機能をリリースしていく必要があった 27 背景・検討 | 課題
Slide 28
Slide 28 text
Copyright © RevComm Inc. ● チームのミッション(の一つ) ○ 「機械学習の研究成果を製品に組み込みユーザーに届ける」 ● 上記を実現するには、より迅速に安全に機能をリリースしていく必要があった ● 2つの課題 ○ ① 段階的リリースを簡単にできるようにしたい ○ ② 連携するシステムになるべく依存せずに開発したい 28 背景・検討 | 課題
Slide 29
Slide 29 text
Copyright © RevComm Inc. ● 段階的リリースを簡単にできるようにしたい ○ 段階的リリース ■ 導入企業の一部にリリース → 全体へのリリース 29 背景・検討 | 課題❶ 段階的リリースを簡単にできるようにしたい
Slide 30
Slide 30 text
Copyright © RevComm Inc. ● 段階的リリースを簡単にできるようにしたい ○ 段階的リリース ■ 導入企業の一部にリリース → 全体へのリリース ○ ← 機能的・非機能的な面を踏まえながら段階的にリリースしたい ■ 振る舞いの予測が難しい、という機械学習サービスの特性 ■ → サービスの安定性にも重要 30 背景・検討 | 課題❶ 段階的リリースを簡単にできるようにしたい
Slide 31
Slide 31 text
Copyright © RevComm Inc. ● 連携するシステムになるべく依存せずに開発したい ○ 音声解析サービスとして、複数のシステム・チームと連携が必要 ○ 以下のシナリオにも簡単に対応したい 31 背景・検討 | 課題❷ 連携するシステムになるべく依存せずに開発したい
Slide 32
Slide 32 text
Copyright © RevComm Inc. ● 連携するシステムになるべく依存せずに開発したい ○ 音声解析サービスとして、複数のシステム・チームと連携が必要 ○ 以下のシナリオにも簡単に対応したい ■ 1. 電話で最初に使う機能Aをリリース ■ 2. Web Meeting で最初に使う機能B をリリース ■ 3. 機能Aだけ戻す ● (再掲: 機械学習サービスはリリース後の 挙動が予想しにくい) 32 背景・検討 | 課題❷ 連携するシステムになるべく依存せずに開発したい
Slide 33
Slide 33 text
Copyright © RevComm Inc. 33 どのような Feature Flag が 必要だろうか? 背景・検討 | Feature Flag の分類
Slide 34
Slide 34 text
Copyright © RevComm Inc. 34 色んな観点が考えられる 背景・検討 | Feature Flag の分類
Slide 35
Slide 35 text
Copyright © RevComm Inc. 35 flag の生存期間 変更の粒度 変更頻度 誰が制御するか? など… 背景・検討 | Feature Flag の分類
Slide 36
Slide 36 text
Copyright © RevComm Inc. 36 flag の生存期間 変更の粒度 変更頻度 誰が制御するか? など… 背景・検討 | Feature Flag の分類
Slide 37
Slide 37 text
Copyright © RevComm Inc. 37 先人たちの知恵を確認するために さらにググってみる... 背景・検討 | Feature Flag の分類
Slide 38
Slide 38 text
Copyright © RevComm Inc. 38 きちんと整理している人がいた 背景・検討 | Feature Flag の分類
Slide 39
Slide 39 text
Copyright © RevComm Inc. 39 「白って 200 種類あんねん」 背景・検討 | Feature Flag の分類
Slide 40
Slide 40 text
Copyright © RevComm Inc. 40 「白って 200 種類あんねん」 背景・検討 | Feature Flag の分類
Slide 41
Slide 41 text
Copyright © RevComm Inc. 41 「Feature Flag って 4 種類あんねん」 背景・検討 | Feature Flag の分類
Slide 42
Slide 42 text
Copyright © RevComm Inc. 42 Martin Fowler 「Feature Flag って 4 種類あんねん」 (某元パリコレモデル風訳) 背景・検討 | Feature Flag の分類
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つ ● 生存期間 ○ いつまで flag を使うか? ● 変更頻度 ○ どのタイミングでの変更が 必要? ** 一部大幅な意訳あり (“変更頻度” の原文: 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
Copyright © RevComm Inc. 49 今回導入したいのは どの Feature Flag だろうか? 背景・検討 | 要件の整理
Slide 50
Slide 50 text
Copyright © RevComm Inc. 50 Martin Fowler の分類の2軸を含めて 改めて整理 背景・検討 | 要件の整理
Slide 51
Slide 51 text
Copyright © RevComm Inc. ● 生存期間 | 1週間~数ヶ月 ● 変更頻度 | デプロイなしで反映できれば十分。多くても月に1,2回程度の変更 51 背景・検討 | 要件の整理
Slide 52
Slide 52 text
Copyright © RevComm Inc. ● 生存期間 | 1週間~数ヶ月 ● 変更頻度 | デプロイなしで反映できれば十分。多くても月に1,2回程度の変更 ○ → Release Toggle (+ Ops Toggle の要素もあり) 52 背景・検討 | 要件の整理
Slide 53
Slide 53 text
Copyright © RevComm Inc. ● 生存期間 | 1週間~数ヶ月 ● 変更頻度 | デプロイなしで反映できれば十分。多くても月に1,2回程度の変更 ○ → Release Toggle (+ Ops Toggle の要素もあり) ● その他の重要な観点 ○ 制御単位 | 顧客テナントごとに機能の ON/OFF を制御したい ○ 対象システム | まずはチームで管理するシステムだけでOK ○ 運用 | まずは開発者が簡単に変更できるレベルでOK 53 背景・検討 | 要件の整理
Slide 54
Slide 54 text
Copyright © RevComm Inc. 1. 自己紹介 2. Feature Flag とは? 3. 背景・検討 4. 実装 5. 結果 6. まとめ Outline
Slide 55
Slide 55 text
Copyright © RevComm Inc. ● 実装方針案 実装 | 方針 55
Slide 56
Slide 56 text
Copyright © RevComm Inc. ● 実装方針案 1. 環境変数で制御する 2. アプリケーション設定サービス(AWS AppConfig など)を利用する 3. Feature Flag 専用サービス(Launch Darkly, Unleash など)を利用する 実装 | 方針 56
Slide 57
Slide 57 text
Copyright © RevComm Inc. 1. 環境変数で制御する ○ 利点: 通信が発生しない。追加コストなし。 ○ 欠点: リアルタイムな変更が難しい (再起動が必要)。フロントエンドなどと協 調困難。 ○ 実装: とても簡単。EKS x ArgoCD の GitOps なので、ConfigMap (設定用の yamlファイル)を修正してマージするだけでOK 実装 | 方針 1. 環境変数で制御する 57
Slide 58
Slide 58 text
Copyright © RevComm Inc. 1. 環境変数で制御する ○ 利点: 通信が発生しない。追加コストなし。 ○ 欠点: リアルタイムな変更が難しい (再起動が必要)。フロントエンドなどと協 調困難。 ○ 実装: とても簡単。EKS x ArgoCD の GitOps なので、ConfigMap (設定用の yamlファイル)を修正してマージするだけでOK ○ ← 最終的に今回はこの方式を選択(理由は後述) 実装 | 方針 1. 環境変数で制御する 58
Slide 59
Slide 59 text
Copyright © RevComm Inc. 2. アプリケーション設定サービス(AWS AppConfig など)を利用する ○ 利点: 再起動不要。低コスト。型付きで値を保持できる。 ○ 欠点: 呼び出し回数を考慮する必要あり。 ○ 実装: 簡単。Terraform を使って CD を整備すれば、承認付きで更新も反映 できる 実装 | 方針 2. アプリケーション設定サービスを利用する 59
Slide 60
Slide 60 text
Copyright © RevComm Inc. 2. アプリケーション設定サービス(AWS AppConfig など)を利用する ○ 利点: 再起動不要。低コスト。型付きで値を保持できる。 ○ 欠点: 呼び出し回数を考慮する必要あり。 ○ 実装: 簡単。Terraform を使って CD を整備すれば、承認付きで更新も反映 できる ○ ← 再起動のハードルが高かったり、設定を共有する範囲が比較的広い場合 (例: ECS でも Lambda でも参照する、など)に有効。 実装 | 方針 2. アプリケーション設定サービスを利用する 60
Slide 61
Slide 61 text
Copyright © RevComm Inc. 3. Feature Flag 専用サービス(Launch Darkly, Unleash など)を利用する ○ 利点: フロントエンドとの協調も容易。監視充実。遅れの少ない反映。 ○ 欠点: 高コスト。サービスを理解する必要あり。 ○ 実装: SDKがあるので簡単。 実装 | 方針 3. Feature Flag 専用サービスを利用する 61
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
Copyright © RevComm Inc. ● 1. 環境変数で制御する方式を採用 63 実装 | 方針
Slide 64
Slide 64 text
Copyright © RevComm Inc. ● 1. 環境変数で制御する方式を採用 ○ 再起動することが許容できる ■ 切り替えのタイミングをそこまで厳密に制御する必要がない ○ 導入企業ごとに機能のON/OFFができれば十分 ○ ConfigMap を変更するだけでよく楽だった ○ 既存の実装は変数へのハードコードだったので、移行も楽だった ● 全社的な導入が必要だったり、リクエスト単位での挙動の変更が必要な A/B Testing が必要になった際に、Feature Flag 専用サービスを利用 or 作成す れば良さそう 64 実装 | 方針
Slide 65
Slide 65 text
Copyright © RevComm Inc. 実装 65
Slide 66
Slide 66 text
Copyright © RevComm Inc. 実装 66
Slide 67
Slide 67 text
Copyright © RevComm Inc. 実装 67
Slide 68
Slide 68 text
Copyright © RevComm Inc. 実装 68
Slide 69
Slide 69 text
Copyright © RevComm Inc. 実装 69
Slide 70
Slide 70 text
Copyright © RevComm Inc. 実装 70 Feature Flag の設定(ConfigMap)
Slide 71
Slide 71 text
Copyright © RevComm Inc. 71 さあ、これで迅速に安全に リリースできるようになった! 実装
Slide 72
Slide 72 text
Copyright © RevComm Inc. 72 さあ、これで迅速に安全に リリースできるようになった! 実装
Slide 73
Slide 73 text
Copyright © RevComm Inc. 73 しかし 実装
Slide 74
Slide 74 text
Copyright © RevComm Inc. 74 数ヶ月するとあることに気づいた 実装
Slide 75
Slide 75 text
Copyright © RevComm Inc. 75 しばらくは問題がないが、運用してしばらく すると次のような状態になる 実装
Slide 76
Slide 76 text
Copyright © RevComm Inc. 実装 76 Feature Flag の設定(ConfigMap) Before
Slide 77
Slide 77 text
Copyright © RevComm Inc. 実装 77 Feature Flag の設定(ConfigMap) After
Slide 78
Slide 78 text
Copyright © RevComm Inc. 実装 78 完全にリリースが完了したものは、 ● アプリケーション側の実装 ● この yaml から削除したい を消したい Feature Flag の設定(ConfigMap) After ‘*’ だらけ
Slide 79
Slide 79 text
Copyright © RevComm Inc. 実装 79 完全にリリースが完了したものは、 ● アプリケーション側の実装 ● この yaml から削除したい を消したい Feature Flag の設定(ConfigMap) After 定期ジョブで通知を飛ばす
Slide 80
Slide 80 text
Copyright © RevComm Inc. 実装 80 完全にリリースが完了したものは、 ● アプリケーション側の実装 ● この yaml から削除したい を消したい Feature Flag の設定(ConfigMap) After 定期ジョブで通知を飛ばす
Slide 81
Slide 81 text
Copyright © RevComm Inc. 実装 81 完全にリリースが完了したものは、 ● アプリケーション側の実装 ● この yaml から削除したい を消したい Feature Flag の設定(ConfigMap) After 定期ジョブで通知を飛ばす
Slide 82
Slide 82 text
Copyright © RevComm Inc. 実装 82 完全にリリースが完了したものは、 ● アプリケーション側の実装 ● この yaml から削除したい を消したい Feature Flag の設定(ConfigMap) After 定期ジョブで通知を飛ばす
Slide 83
Slide 83 text
Copyright © RevComm Inc. 実装 83 完全にリリースが完了したものは、 ● アプリケーション側の実装 ● この yaml から削除したい を消したい Feature Flag の設定(ConfigMap) After 定期ジョブで通知を飛ばす
Slide 84
Slide 84 text
Copyright © RevComm Inc. ● 段階的リリースが簡単にできるようになった ○ ビルド + デプロイ が不要 で公開するテナントの範囲を制御できるように ● 連携するシステムの開発を待たずに開発を進められるようになった ○ 機能を OFF した状態での先行リリース ○ → ConfigMap (設定ファイル) を更新して機能ONに ■ 問題起きてもスイッチするのも簡単 結果 84
Slide 85
Slide 85 text
Copyright © RevComm Inc. ● 段階的リリースが簡単にできるようになった ○ ビルド + デプロイ が不要 で公開するテナントの範囲を制御できるように ● 連携するシステムの開発を待たずに開発を進められるようになった ○ 機能を OFF した状態での先行リリース ○ → ConfigMap (設定ファイル) を更新して機能ONに ■ 問題起きてもスイッチするのも簡単 → 迅速に安全に機能をリリースできるようになった 🎉 結果 85
Slide 86
Slide 86 text
Copyright © RevComm Inc. ● 「Feature Flag って 4種類あんねん」 ○ 生存期間と変更頻度を中心に整理 → 実装方針が明確になりやすい ● Kubernetes 内で完結する場合は、ConfigMap での運用は簡単でおすすめ ○ ただし、Release Toggle で再起動を許容できる場合に限る ○ 広範囲に導入 or リクエスト単位での制御が必要なら専用サービスが良さそう ● Feature Flag は不要になった後の対応まで考慮する必要がある ○ 定期ジョブなどを利用して不要な分岐を削除できるようにする まとめ 86