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