$30 off During Our Annual Pro Sale. View Details »

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

RevComm_inc
September 21, 2023

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

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

RevComm_inc

September 21, 2023
Tweet

More Decks by RevComm_inc

Other Decks in Technology

Transcript

  1. Copyright © RevComm Inc.
    Feature Flag について
    本気出して考えて実践してみた
    RevComm Research Dept. Development Group
    Noriki Takahashi

    View Slide

  2. Copyright © RevComm Inc.
    Outline
    1. 自己紹介
    2. Feature Flag とは?
    3. 背景・検討
    4. 実装
    5. 結果
    6. まとめ

    View Slide

  3. Copyright © RevComm Inc.
    1. 自己紹介
    2. Feature Flag とは?
    3. 背景・検討
    4. 実装
    5. 結果
    6. まとめ
    Outline

    View Slide

  4. Copyright © RevComm Inc.
    自己紹介 | 概要
    4
    ● 名前
    ○ 高橋 典生 (たかはし のりき) / nrnrk (のりのりき)
    ● 業務内容
    ○ 機械学習の研究成果を製品に組み込みユーザーに価値を届ける
    ○ 研究開発チームの生産性向上
    ● 好きなもの
    ○ Kubernetes, MLOps, Rust, 型システム, 数学/物理学

    View Slide

  5. Copyright © RevComm Inc.
    自己紹介 | 関わっているプロダクト
    5

    View Slide

  6. Copyright © RevComm Inc.
    自己紹介 | 関わっているプロダクト
    6

    View Slide

  7. Copyright © RevComm Inc.
    自己紹介 | 関わっているプロダクト
    7
    この部分の音声解析のシステムを
    開発・運用しています
    文字起こし
    トピック推定
    感情認識

    View Slide

  8. Copyright © RevComm Inc.
    1. 自己紹介
    2. Feature Flag とは?
    3. 背景・検討
    4. 実装
    5. 結果
    6. まとめ
    Outline

    View Slide

  9. Copyright © RevComm Inc.
    Feature Flag とは?
    9
    発表のテーマは Feature Flag

    View Slide

  10. Copyright © RevComm Inc.
    ところで Feature Flag とは
    何だろう?
    Feature Flag とは?
    10

    View Slide

  11. Copyright © RevComm Inc.
    Feature Flag とは?
    11
    一般的な定義を確認する

    View Slide

  12. Copyright © RevComm Inc.
    ● Feature Flag とは...
    ○ Feature Toggle などとも呼ばれる
    Feature Flag とは?
    12

    View Slide

  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/

    View Slide

  14. Copyright © RevComm Inc.
    ● Feature Flag とは...
    ○ ここでは
    Feature Flag とは?
    14

    View Slide

  15. Copyright © RevComm Inc.
    ● Feature Flag とは...
    ○ ここでは
    ■ 「機能の有効化・無効化をコードの修正なしで実現する概念やその手法」
    ■ という定義として、大らかな意味で捉えて使うことにする
    Feature Flag とは?
    15

    View Slide

  16. Copyright © RevComm Inc.
    ● Feature Flag とは...
    ○ ここでは
    ■ 「機能の有効化・無効化をコードの修正なしで実現する概念やその手法」
    ■ という定義として、大らかな意味で捉えて使うことにする
    ○ よくある実装例
    Feature Flag とは?
    16

    View Slide

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

    View Slide

  18. Copyright © RevComm Inc.
    ● 一般的な Feature Flag のメリットの例
    Feature Flag とは?
    18

    View Slide

  19. Copyright © RevComm Inc.
    ● 一般的な Feature Flag のメリットの例
    ○ 継続的デリバリが容易に
    ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする
    ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和
    Feature Flag とは?
    19

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  23. Copyright © RevComm Inc.
    ● 一般的な Feature Flag のメリットの例
    ○ 継続的デリバリが容易に
    ■ 機能を OFF の状態でリリースして、必要になったタイミングで ON にする
    ● ←「他チームのリリースを待ってリリースする必要がある」問題の緩和
    ○ リスクの低減
    ■ ホットフィックスや完全なロールバックなしに機能の ON / OFF を切り替えられる
    ● ←「ロールバックすると、別の変更も戻ってしまう」問題の緩和
    ○ 段階的リリースが容易に (一部のユーザーだけに公開、など)
    ○ A/B テストが容易に
    Feature Flag とは?
    23
    機能の ON / OFF 制御を簡単にできるようにすることで
    開発効率を向上させつつ、一定の安定性も担保することができる

    View Slide

  24. Copyright © RevComm Inc.
    1. 自己紹介
    2. Feature Flag とは?
    3. 背景・検討
    4. 実装
    5. 結果
    6. まとめ
    Outline

    View Slide

  25. Copyright © RevComm Inc.
    背景・検討 | 課題
    25
    Feature Flag がどういうものかは何
    となくわかった

    View Slide

  26. Copyright © RevComm Inc.
    26
    でも、どうして Feature Flag が必
    要なんだっけ?
    背景・検討 | 課題

    View Slide

  27. Copyright © RevComm Inc.
    ● チームのミッション(の一つ)
    ○ 「機械学習の研究成果を製品に組み込みユーザーに届ける」
    ● 上記を実現するには、より迅速に安全に機能をリリースしていく必要があった
    27
    背景・検討 | 課題

    View Slide

  28. Copyright © RevComm Inc.
    ● チームのミッション(の一つ)
    ○ 「機械学習の研究成果を製品に組み込みユーザーに届ける」
    ● 上記を実現するには、より迅速に安全に機能をリリースしていく必要があった
    ● 2つの課題
    ○ ① 段階的リリースを簡単にできるようにしたい
    ○ ② 連携するシステムになるべく依存せずに開発したい
    28
    背景・検討 | 課題

    View Slide

  29. Copyright © RevComm Inc.
    ● 段階的リリースを簡単にできるようにしたい
    ○ 段階的リリース
    ■ 導入企業の一部にリリース → 全体へのリリース
    29
    背景・検討 | 課題❶ 段階的リリースを簡単にできるようにしたい

    View Slide

  30. Copyright © RevComm Inc.
    ● 段階的リリースを簡単にできるようにしたい
    ○ 段階的リリース
    ■ 導入企業の一部にリリース → 全体へのリリース
    ○ ← 機能的・非機能的な面を踏まえながら段階的にリリースしたい
    ■ 振る舞いの予測が難しい、という機械学習サービスの特性
    ■ → サービスの安定性にも重要
    30
    背景・検討 | 課題❶ 段階的リリースを簡単にできるようにしたい

    View Slide

  31. Copyright © RevComm Inc.
    ● 連携するシステムになるべく依存せずに開発したい
    ○ 音声解析サービスとして、複数のシステム・チームと連携が必要
    ○ 以下のシナリオにも簡単に対応したい
    31
    背景・検討 | 課題❷ 連携するシステムになるべく依存せずに開発したい

    View Slide

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

    View Slide

  33. Copyright © RevComm Inc.
    33
    どのような Feature Flag が
    必要だろうか?
    背景・検討 | Feature Flag の分類

    View Slide

  34. Copyright © RevComm Inc.
    34
    色んな観点が考えられる
    背景・検討 | Feature Flag の分類

    View Slide

  35. Copyright © RevComm Inc.
    35
    flag の生存期間
    変更の粒度
    変更頻度
    誰が制御するか?
    など…
    背景・検討 | Feature Flag の分類

    View Slide

  36. Copyright © RevComm Inc.
    36
    flag の生存期間
    変更の粒度
    変更頻度
    誰が制御するか?
    など…
    背景・検討 | Feature Flag の分類

    View Slide

  37. Copyright © RevComm Inc.
    37
    先人たちの知恵を確認するために
    さらにググってみる...
    背景・検討 | Feature Flag の分類

    View Slide

  38. Copyright © RevComm Inc.
    38
    きちんと整理している人がいた
    背景・検討 | Feature Flag の分類

    View Slide

  39. Copyright © RevComm Inc.
    39
    「白って 200 種類あんねん」
    背景・検討 | Feature Flag の分類

    View Slide

  40. Copyright © RevComm Inc.
    40
    「白って 200 種類あんねん」
    背景・検討 | Feature Flag の分類

    View Slide

  41. Copyright © RevComm Inc.
    41
    「Feature Flag って 4 種類あんねん」
    背景・検討 | Feature Flag の分類

    View Slide

  42. Copyright © RevComm Inc.
    42
    Martin Fowler
    「Feature Flag って 4 種類あんねん」
    (某元パリコレモデル風訳)
    背景・検討 | Feature Flag の分類

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  49. Copyright © RevComm Inc.
    49
    今回導入したいのは
    どの Feature Flag だろうか?
    背景・検討 | 要件の整理

    View Slide

  50. Copyright © RevComm Inc.
    50
    Martin Fowler の分類の2軸を含めて
    改めて整理
    背景・検討 | 要件の整理

    View Slide

  51. Copyright © RevComm Inc.
    ● 生存期間 | 1週間~数ヶ月
    ● 変更頻度 | デプロイなしで反映できれば十分。多くても月に1,2回程度の変更
    51
    背景・検討 | 要件の整理

    View Slide

  52. Copyright © RevComm Inc.
    ● 生存期間 | 1週間~数ヶ月
    ● 変更頻度 | デプロイなしで反映できれば十分。多くても月に1,2回程度の変更
    ○ → Release Toggle (+ Ops Toggle の要素もあり)
    52
    背景・検討 | 要件の整理

    View Slide

  53. Copyright © RevComm Inc.
    ● 生存期間 | 1週間~数ヶ月
    ● 変更頻度 | デプロイなしで反映できれば十分。多くても月に1,2回程度の変更
    ○ → Release Toggle (+ Ops Toggle の要素もあり)
    ● その他の重要な観点
    ○ 制御単位 | 顧客テナントごとに機能の ON/OFF を制御したい
    ○ 対象システム | まずはチームで管理するシステムだけでOK
    ○ 運用 | まずは開発者が簡単に変更できるレベルでOK
    53
    背景・検討 | 要件の整理

    View Slide

  54. Copyright © RevComm Inc.
    1. 自己紹介
    2. Feature Flag とは?
    3. 背景・検討
    4. 実装
    5. 結果
    6. まとめ
    Outline

    View Slide

  55. Copyright © RevComm Inc.
    ● 実装方針案
    実装 | 方針
    55

    View Slide

  56. Copyright © RevComm Inc.
    ● 実装方針案
    1. 環境変数で制御する
    2. アプリケーション設定サービス(AWS AppConfig など)を利用する
    3. Feature Flag 専用サービス(Launch Darkly, Unleash など)を利用する
    実装 | 方針
    56

    View Slide

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

    View Slide

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

    View Slide

  59. Copyright © RevComm Inc.
    2. アプリケーション設定サービス(AWS AppConfig など)を利用する
    ○ 利点: 再起動不要。低コスト。型付きで値を保持できる。
    ○ 欠点: 呼び出し回数を考慮する必要あり。
    ○ 実装: 簡単。Terraform を使って CD を整備すれば、承認付きで更新も反映
    できる
    実装 | 方針 2. アプリケーション設定サービスを利用する
    59

    View Slide

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

    View Slide

  61. Copyright © RevComm Inc.
    3. Feature Flag 専用サービス(Launch Darkly, Unleash など)を利用する
    ○ 利点: フロントエンドとの協調も容易。監視充実。遅れの少ない反映。
    ○ 欠点: 高コスト。サービスを理解する必要あり。
    ○ 実装: SDKがあるので簡単。
    実装 | 方針 3. Feature Flag 専用サービスを利用する
    61

    View Slide

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

    View Slide

  63. Copyright © RevComm Inc.
    ● 1. 環境変数で制御する方式を採用
    63
    実装 | 方針

    View Slide

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

    View Slide

  65. Copyright © RevComm Inc.
    実装
    65

    View Slide

  66. Copyright © RevComm Inc.
    実装
    66

    View Slide

  67. Copyright © RevComm Inc.
    実装
    67

    View Slide

  68. Copyright © RevComm Inc.
    実装
    68

    View Slide

  69. Copyright © RevComm Inc.
    実装
    69

    View Slide

  70. Copyright © RevComm Inc.
    実装
    70
    Feature Flag の設定(ConfigMap)

    View Slide

  71. Copyright © RevComm Inc.
    71
    さあ、これで迅速に安全に
    リリースできるようになった!
    実装

    View Slide

  72. Copyright © RevComm Inc.
    72
    さあ、これで迅速に安全に
    リリースできるようになった!
    実装

    View Slide

  73. Copyright © RevComm Inc.
    73
    しかし
    実装

    View Slide

  74. Copyright © RevComm Inc.
    74
    数ヶ月するとあることに気づいた
    実装

    View Slide

  75. Copyright © RevComm Inc.
    75
    しばらくは問題がないが、運用してしばらく
    すると次のような状態になる
    実装

    View Slide

  76. Copyright © RevComm Inc.
    実装
    76
    Feature Flag の設定(ConfigMap)
    Before

    View Slide

  77. Copyright © RevComm Inc.
    実装
    77
    Feature Flag の設定(ConfigMap)
    After

    View Slide

  78. Copyright © RevComm Inc.
    実装
    78
    完全にリリースが完了したものは、
    ● アプリケーション側の実装
    ● この yaml から削除したい
    を消したい
    Feature Flag の設定(ConfigMap)
    After
    ‘*’ だらけ

    View Slide

  79. Copyright © RevComm Inc.
    実装
    79
    完全にリリースが完了したものは、
    ● アプリケーション側の実装
    ● この yaml から削除したい
    を消したい
    Feature Flag の設定(ConfigMap)
    After
    定期ジョブで通知を飛ばす

    View Slide

  80. Copyright © RevComm Inc.
    実装
    80
    完全にリリースが完了したものは、
    ● アプリケーション側の実装
    ● この yaml から削除したい
    を消したい
    Feature Flag の設定(ConfigMap)
    After
    定期ジョブで通知を飛ばす

    View Slide

  81. Copyright © RevComm Inc.
    実装
    81
    完全にリリースが完了したものは、
    ● アプリケーション側の実装
    ● この yaml から削除したい
    を消したい
    Feature Flag の設定(ConfigMap)
    After
    定期ジョブで通知を飛ばす

    View Slide

  82. Copyright © RevComm Inc.
    実装
    82
    完全にリリースが完了したものは、
    ● アプリケーション側の実装
    ● この yaml から削除したい
    を消したい
    Feature Flag の設定(ConfigMap)
    After
    定期ジョブで通知を飛ばす

    View Slide

  83. Copyright © RevComm Inc.
    実装
    83
    完全にリリースが完了したものは、
    ● アプリケーション側の実装
    ● この yaml から削除したい
    を消したい
    Feature Flag の設定(ConfigMap)
    After
    定期ジョブで通知を飛ばす

    View Slide

  84. Copyright © RevComm Inc.
    ● 段階的リリースが簡単にできるようになった
    ○ ビルド + デプロイ が不要 で公開するテナントの範囲を制御できるように
    ● 連携するシステムの開発を待たずに開発を進められるようになった
    ○ 機能を OFF した状態での先行リリース
    ○ → ConfigMap (設定ファイル) を更新して機能ONに
    ■ 問題起きてもスイッチするのも簡単
    結果
    84

    View Slide

  85. Copyright © RevComm Inc.
    ● 段階的リリースが簡単にできるようになった
    ○ ビルド + デプロイ が不要 で公開するテナントの範囲を制御できるように
    ● 連携するシステムの開発を待たずに開発を進められるようになった
    ○ 機能を OFF した状態での先行リリース
    ○ → ConfigMap (設定ファイル) を更新して機能ONに
    ■ 問題起きてもスイッチするのも簡単
    → 迅速に安全に機能をリリースできるようになった 🎉
    結果
    85

    View Slide

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

    View Slide