Feature Flagを用いたサーバーサイドリリースの実装と柔軟な運用について/implementation_and_operation_of_server_side_release_with_feature_flag

担当しているプロダクトでのフィーチャーフラグの事例とサーバーサイドの実装、運用について共有します。
以下イベントでの登壇資料です。
https://findy.connpass.com/event/299657/

Transcript

1. Feature Flagを⽤いたサーバーサイド リリースの実装と柔軟な運⽤について Kazushi Hirai
2. ⾃⼰紹介 l 所属︓ l LINEヤフーコミュニケーションズ株式会社 (旧LINE Fukuoka株式会社) l 開発1部 開発Kチーム リーダー l サーバサイドエンジニア l 興味︓ l 家族（娘、息⼦）, 体を動かすこと, マラソン l X(旧Twitter): @hkazushi0627 ฏҪ Ұ࢙ ,";64)*
   )*3"*
3. LINE STORE 背景 l LINE STOREのサーバサイド開発を担当 l LINEの各デジタルアイテムを販売する 公式オンラインストア l https://store.line.me l Webアプリケーション l Java/Kotlin、Spring Boot l オープンソースソフトウェアを活⽤ l ミドルウェア、ストレージなど、⾃前で構築 l トランクベース開発 l 週1回のプロダクションリリース
4. LINE STORE フィーチャーフラグのユースケース l リリースフラグ︓ l 新機能をフラグを使って、リリース（機能ON）する l 開発中やテストが完了していないコードをプロダクション環境にデプロイできる l デプロイなしで、指定⽇時に機能をリリースできる l 例︓サイト上の会社名を10/1 10AMに変更したい l ⼀定期間だけ有効な機能（キャンペーン）のON、OFFを制御する
5. LINE STORE フィーチャーフラグのユースケース l 機能制限フラグ︓ l 特定の属性を持つユーザのみに機能を提供する l 例︓サブスクリプション機能は⽇本と台湾のユーザに提供 l コードではフラグのチェックだけを⾏い、国などの条件をハードコードしない l デプロイなしで、段階的に機能をリリースができる 設定ファイル︓ プログラムコード︓ ユーザ国 フラグ ⽇本 ON 台湾 ON それ以外 OFF ⽇本・台湾 それ以外 機能ON 機能OFF
6. LINE STORE フィーチャーフラグの実装 l フラグ管理サーバ︓ l 設定ファイルを⼀元管理する l 開発者は設定を変更できる l 変更後、アプリケーションサーバに変更を配布する l 設定ファイル︓ l フィーチャーフラグを定義する l アプリケーションは、フィーチャーフラグの設定値に よって、環境やユーザの属性に応じて 機能のON/OFFを切り替える l プログラムコード︓ l フィーチャーフラグを⽤いて、処理を分岐する
7. LINE STORE 実装︓フラグ管理サーバ https://line.github.io/centraldogma/ l Central Dogma︓ l Git、Zookeeperベースのサービス設定リポジトリ l LINEのオープンソースソフトウェア l 設定ファイルをサーバ上で可⽤性⾼く、バージョン管理できる l クライアントライブラリ l ほぼリアルタイムで、アプリケーションに変更を反映できる
8. LINE STORE 実装︓フラグ管理サーバ l GitHub連携︓ l 設定ファイルをGitHub上で管理できる l プルリクエストを作成して、レビューした上で変更をマージする l プルリクエスト作成時︓CI上でビルドチェックの実⾏ l プルリクエストマージ後︓アクションの実⾏、Slack通知など
9. LINE STORE 実装︓設定ファイル l DSL(Domain Specific Language)として、PlanOutを使⽤ l PlanOut︓ l Meta(旧Facebook)が開発したA/Bテスト、フィーチャーフラグ⽤のフレームワーク l Javaの実装であるPlanOut4jをライブラリとして使⽤ 設定ファイル(YAML)︓ PlanOut4j userId=xxxx isRelease=true country=JP パラメータ user-new-string=true フラグ値を算出 フィーチャーフラグ︓ アプリケーションで 環境やユーザの属性値を パラメータとして設定 If, elseの条件分岐の記述 環境やユーザ属性で分岐して フラグのON/OFFを設定 アプリケーション︓
10. LINE STORE 実装︓プログラムコード l 初回導⼊のみ l アプリケーションに、Central DogmaクライアントやPlanOut4jの組み込みが必要 l 導⼊以降 l 開発者はフラグによる分岐を⾏うだけなので、容易にフラグの導⼊が可能 l ユーザのコンテキストクラスやシステムクラスに フィーチャーフラグが判定するメソッドがあれば、どこでも使⽤できる
11. LINE STORE 運⽤における課題と対策 l リグレッションテストで、フィーチャーフラグON、OFF両⽅の検証が必要 l フラグの組み合わせが、Beta、Staging: ON、Production: OFF の状態で フラグOFF の検証が漏れた場合、 Productionデプロイで、初めてOFFの動作検証が⾏われる 実際、検証漏れによる不具合や障害が発⽣ 対策 導⼊されているフィーチャーフラグの⼀覧や各環境の状態を 開発者以外のプロジェクトメンバー（特にテストメンバー）に共有する 課題 プロダクションデプロイまでのプロセスが複雑になる
12. LINE STORE 運⽤における課題と対策 対策 テスト⽤にフラグを上書きする機能をアプリケーションを追加 ⾮開発者でもON/OFFの切り替えを可能にして、検証実施の障壁を下げる （ただし、プロダクション環境は⾮表⽰） 設定ファイル︓ フラグを変更するUI︓ Cookie︓ フラグ︓ON フラグ︓OFF 設定 Cookieの値を優先 機能ON 課題 ⾮開発者にとって、フラグの変更にはサーバの設定変更が必要 ON/OFFの検証実施の障壁が⾼い（コミュニケーションコスト、いつでも変更できない） 上書きした値はCookieで管理することで、他のユーザのテストやアプリケーションの動作には影響を与えない
13. 発表の流れ l コードのデプロイと機能リリースを分離するためにフィーチャーフラグを使⽤ l ユーザ属性を使⽤した機能制限でもフィーチャーフラグを活⽤ l フラグ管理サーバには、Central Dogma を使⽤ l リアルタイムでの変更反映とGitHubと連携した安全なオペレーションを実現 l 設定ファイルのDSLに、PlanOut を使⽤ l 環境やユーザ属性によるフラグの分岐を実装 l フィーチャーフラグ導⼊による運⽤の課題を解決するために l プロジェクトメンバー内で、フィーチャーフラグ状態を共有を実施 l フラグを上書きする機能を実装して、容易にON/OFFの検証実施を可能にする まとめ
14. THANK YOU!