APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

【KubeCon 2025 London】Feature Flagで高頻度のリリースを実現する

はじめに

皆さんこんにちは。ACS事業部 亀崎です。 2025年4月1日〜4日に行われたKubeCon + CloudNativeCon Europe 2025 Londonでは、Feature Flag / OpenFeatureに関するセッションがいくつもありました。

今回は私自身が参加したセッションからその内容を簡単にご紹介したいと思います。

Feature Flag / OpenFeature とは

ご存知の方も多いかと思いますが、フィーチャーフラグとは特定の機能(フィーチャー)を動的に有効化したり無効化したりすることができる仕組みです。フィーチャーフラグを使わない場合、新しい機能を実装した場合、その機能を含んだコードをビルドし、プロダクション環境にデプロイすることで公開していると思います。新しい機能を公開する際に少しずつ利用できるユーザーを広げながら公開を拡大したいという場合には、カナリアデプロイのように新旧のバージョンを並列に動かすことで実現します。 フィーチャーフラグを使うと、1つのバイナリで機能の公開・非公開を切り替えられるようになるのが便利なところです。

フィーチャーフラグの機能は、独自でそうした仕組みを実現するかまたはベンダーが公開するフィーチャーフラグサービスを利用してました。ベンダー公開のものを利用するのは便利なのですが、ベンダーロックインが発生してしまうという課題があります。 そこでフィーチャーフラグの実装インターフェース部分を共通化しようというのがOpenFeatureです。

openfeature.dev

実際の活用例

今回KubeCon Londonで私自身が参加した2つのセッションでフィーチャーフラグを紹介していました。

How we deliver changes to Kubernetes

まず1つ目がOctopus Deployにおけるものです。

kccnceu2025.sched.com

Octopus DeployではSaaS版のサービスも提供しています。様々な地域にユーザーがいるため、サービスのメンテナンスウィンドウというのもバラバラです。そうした中でカナリアデプロイでリリースを行っていました。このやり方では1つのバージョンのリリースがすべてのユーザーにいきわたるまでに2週間が必要です。そうした中で問題が発生して公開が途中で中断となるともっと大変です。

機能を提供する開発者としてはもっと短い期間で公開をしていきたい。可能であれば週に数回は行いたい。 しかし先程のように1つのリリース作業が完了するまでに2週間かかってしまっている状態です。

そこでフィーチャーフラグを利用し、Trunk Baseの開発・リリースを採用しました。これにより公開するバイナリは原則1つで、その中でフィーチャーフラグで公開するユーザーを徐々に広げていくといった方針を取りました。 これにより、全ユーザーに公開されるまでに3日程度で完了することができるようになりました。一部ユーザーだけに発生する問題があれば、そのユーザーのみ機能をオフにし、その他のユーザーは機能を公開したまま、問題箇所を修正するといったことも可能になったとのことです。

Type-safe Feature flagging in OpenFeature

2つ目はGoogleでの事例です。

Googleにおいてもフィーチャーフラグを活用しています。

kccnceu2025.sched.com

Googleでは多数のフィーチャーフラグを設定しています。これらの個々のフラグは

Create -> Manage -> Deprecate -> Delete

というライフサイクルをたどります。リリース後切り替えが不要となったフラグは削除していきます。

しかし、そうなると課題が生じます。その1つがフラグ名のハードコーディングです。

以下の例のように、String Text(この例では with-cows という名称)でフラグを設定しています。

こうしたテキストベースでのフラグがコードのあちこちに出てきてしまうと、さきほどのライフサイクルの後半、とくに削除の際には「削除漏れ」等が発生する可能性が増加します。

そこでOpenFeature CLIの機能を活用しています。 OpenFeatureではフラグをjsonで指定し、それを利用するコードを生成することができます。

JSONでの指定

生成したコードの利用

featureFlagw.withCows() の部分がさきほどのString Textでの指定と違います。このようなコードにすることで、削除漏れがあったとしてもビルド時に検知することができ、より安全にフラグの削除が可能になります。

こうした機能があることで安心してフィーチャーフラグを活用して、高頻度のリリースを安心して実現しています。

まとめ

他にもFeature Flag / OpenFeature に関するセッションはいくつもあったようです。今回OpenFeatureはさまざまなところで言及されるもので、今ホットなOSSになっているように感じました。

ぜひ今回のようなセッションの内容をご参考にしていただき、より頻度の高いリリースを実現していきましょう。