LaunchDarklyを活用して運用コストを抑えつつfeature flagのプラクティスを浸透させる

チームの課題として、アプリケーションの機能改善やバグ修正を行った際に意図しない領域に影響が出て障害に繋がってしまう、という事象が一定の頻度で発生していました。アーキテクチャの改善によって障害を予防する取り組みと並行して、リリースの範囲を限定して影響範囲を狭めたり、障害発生時の切り戻しを素早く行ったりするための手段としてfeature flagを活用する目論見がありました。
また、新規機能開発時に長寿なfeatureブランチで開発を行うスタイルがとられていたため、コンフリクト解消の手間やビックバンリリースによる潜在的な障害リスクの増加といった課題も存在していました。

そこで、feature flagのプラクティスの浸透により以下を達成することを目指しました。

1. 機能改善やバグ修正時のリリースの安全性および障害発生時のリカバリー速度向上
2. 新規機能開発時のプルリクエストの滞留時間の削減
   

LaunchDarklyの導入以前は、feature flagの活用に関して、ユーザーごとの機能の振る舞いの違いを制御するためのconfigファイルがアプリケーションに静的にインジェクトされるような、いわゆる Permission Toggles 的な形で利用していました。

一方で、開発した機能のデプロイとリリースを分離する、機能のA/Bテストのために一部のユーザーに対してのみ先行してリリースを行う、といった Release Toggles, Experimental Toggles 的なプラクティスは日常的には実践されていませんでした。

• Unleash
• Flagsmith

1. feature flagの設定値を動的に切り替えられるかどうか
   前述したように、障害発生時の切り戻しを素早く行えることが目指す価値の1つだったため、設定値の変更の際にデプロイが必要となるconfigファイルや環境変数による管理ではなく、独立したマイクロサービスによる管理が実現できるかどうかに重きを置きました。
   
2. 導入に必要なSDKやインフラの開発/運用コストを抑えられるかどうか
   一般的に、feature flag管理サービスのSDKの実装ではflagの値をリアルタイムに更新するためのstreaming通信の仕組みなど、比較的複雑な実装が行われることが多いです。そのため、SDKを自前で実装することは可能な限り避けたく、サービスの利用元となる各開発言語に対応する手段が世の中に存在しているかどうかを重視しました。インフラについても同様で、コストと天秤にかける前提でマネージドなサービスに寄せられないかを検討しました。

弊社ではサーバーサイドの開発言語にDartを採用しており、公式でServer Side DartのSDKを提供しているサービスは存在しませんでした。その中でLaunchDarklyは、Relay ProxyというLaunchDarkly側とのstreaming通信を肩代わりしてくれるプロキシーコンポーネントを経由することで開発言語を問わずサービスとの通信を実現できるオプションを、公式がサポートする形で提供していました。Relay Proxyの実装はOSSとして公開されており、デプロイの手段も複数提供されていた (弊社ではHelm chartを使ってKubernetes上にデプロイする方法を採用) ため、開発/運用コストの面でも十分に受け入れ可能だと判断して採用を決めました。

また、サーバーサイドからの利用以外では、モバイルアプリの開発に用いているFlutterや管理画面の開発で採用しているNuxt.jsのSDKは公式のものを採用できるため、基準をクリアしていることを確認しました。

当初の目論見通り、feature flagの活用によりリリースの影響範囲を限定したり切り戻しを即座に行えるようになったことで、リリース直後のユーザーの利用状況を見つつ障害に繋がる一歩手前で修正を切り戻す、といったアクションが取れるようになりました。

長寿featureブランチの課題についても、flagをoffにした状態で小分けにしたプルリクエストをレビュー完了後に即mainブランチにマージしていく開発スタイルに変えていったところ、解消することができました。

目に見える成果として、効果測定のために可視化をはじめたFour Keysを見てみても、各指標が有意に改善していることがわかりました。活用の浸透という点でも、サービス利用開始から半年弱の期間で大小様々数十のflagを作成して運用できています。

また、機能を検討する際にまずは実験的に実装してみて一部のユーザーに提供することで小規模に検証してみよう、といった前向きな議論がチーム内で行われやすくなるなどの副次的な効果も得ることができました。

前述したRelay Proxyの導入にあたって、どのような仕組みで動いているのか、デプロイする際にどのような設定を行うのが適切なのか、といった内容を正しく理解するのに苦労しました。Relay Proxyは公式でサポートしている仕組みではありますが、導入事例はまだ少なくWeb上で検索しても言及した情報にはほとんど辿り着けませんでした。よって公式ドキュメントやOSSとして公開されているレポジトリ内のドキュメントを読み込んで、コンセプトや設定値の意味合いを1つずつ理解する必要があり、一定の時間を要しました。また、サーバーアプリケーションからRelay Proxyにリクエストを行うクライアントの実装は自前で行ったのですが、そこでも一部ハマりどころが存在しました。
この辺りの詳細な話は、弊社のTech Blogでも記事として公開しているので、興味がある方はぜひ併せてご参照ください。

feature flagのプラクティスを実践する際に、まずは環境変数やconfigファイルで値を切り替える、という方法を一歩目に据えるケースは多いかと思います。私自身も過去にそのような意思決定をしたことがあり、確かに手っ取り早く最低限のメリットを享受する手段としては優秀だと考えています。

一方で、flagの設定値を動的に切り替えられるようにする、リリースの対象範囲を限定することで実験を行いやすくする、といった自前で実現するのには少々骨が折れるプラクティスも、LaunchDarklyのようなサービスを活用することで簡単に実現できます。

また、SaaSとしてベストプラクティス的に作り込まれた機能に触れることで、思想面で学びになることも多々あると感じています。こうしたプラクティスを気軽に実践できることは、チームで開発を進める上で強力な武器になってくれることは間違いないので、同様の課題を感じているチームや会社の皆様にはぜひ導入を検討してみることをオススメします。