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

「【日経×コドモン×RevComm】サービスの安定性、信頼性を高めるDevOps/SREの取り組み」での発表資料です。
https://nikkei.connpass.com/event/292415/

Transcript

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