フィーチャーフラグ管理の課題と宣言的集約管理、エコシステムの構築へ

トランクベース開発やABテスト、カナリアリリースなどで、システムの柔軟性を高めるフィーチャーフラグの重要性が高まっている。株式会社サイバーエージェントの岩見 彰太氏は、CloudNative Days Summer 2024にて、「OpenFeatureと自動生成を活用したフィーチャーフラグの宣言的集約管理」と題し、フィーチャーフラグの基本から、OpenFeatureによる標準化、さらに自動生成を活用したシステム運用の効率化について紹介した。

フィーチャーフラグとトランクベース開発の関係

岩見氏はまず、トランクベース開発とフィーチャーフラグの役割について解説した。トランクベース開発は、メインブランチに頻繁にコードをマージし、常にプロダクション環境にデプロイ可能な状態を維持する開発手法である。この手法は、デプロイのスピードを速める一方で、リスク管理のためにフィーチャーフラグが活用される。

「トランクベース開発では、メインブランチが常にリリース可能な状態であることが求められます。しかしすべての変更を即座に反映させるのはリスクを伴うため、フィーチャーフラグを使って、機能のオン・オフを簡単に制御できるようにします」と岩見氏は語った。

feature flagとは

フィーチャーフラグの基本的な機能は、コードを変更することなくシステムの挙動を切り替えることであり、これは「if」文によって簡単に実装される。しかし岩見氏は、この「if」文が管理されないまま残ると、システムが複雑化しやすいという課題にも触れた。

「フィーチャーフラグを使って機能を制御することは便利ですが、その役割が終わったらすぐに削除しないと、不要なコードが増えてしまい、最終的にはシステム全体の複雑さを招くことになります。これがゾンビフラグと呼ばれる現象です」と語った。

フィーチャーフラグの種類とその用途

フィーチャーフラグは目的に応じて4つの種類に分類される。「Release Toggles」「Experiment Toggles」「Ops Toggles」「Permission Toggles」の4つで、それぞれの特徴を理解し、適切に使い分けることが効率的な運用につながる。

Release Togglesは、トランクベース開発において、進行中の機能を安全にメインブランチへとマージするために使われる。通常1～2週間以上は残さず、最終的には削除されるべきである。すべてのユーザーに対して同時にリリースする機能に対して使用される。

Experiment Togglesは、ABテストやカナリアリリースに使用されるフラグであり、一部のユーザーに対して限定的に機能を有効化するために使用される。仮説検証のために一定期間有効にしておく必要があるが、結果が出た後は速やかに不要なコードを削除するべきである。

Ops Togglesは、システムの運用やパフォーマンス調整のために使用され、新しい機能がパフォーマンスにどのような影響を与えるか不明な場合に導入される。また、システムに負荷がかかった際に、一部の機能を停止させるためにも使用される。

Permission Togglesは、特定のユーザーに対して特別な機能を公開するために使用される。これは既存の機能を特定の条件下で限定的に提供するためのフラグであり、一般的には、検証が終わった後に正式にリリースされる機能を特定ユーザーにのみ公開する際に活用される。

フィーチャーフラグ管理の課題とOpenFeatureの登場とその利点

フィーチャーフラグの効果的な運用には、管理システムの導入が欠かせない。フィーチャーフラグを単にコード内に実装するだけでは、リアルタイムでの更新や複数のフラグの状態を管理することが難しい。岩見氏は、これを解決するためのソリューションとして「FFSaaS」（Feature Flag SaaS）を紹介した。

フラグ管理システム

「FFSaaSを使用することで、フィーチャーフラグの状態をリモートで管理し、リアルタイムでフラグを変更することができます。さらに、ユーザーのコンテキスト情報に基づいてフラグを評価し、その結果をシステムに反映させることも可能です」と岩見氏は説明した。

しかしFFSaaSの導入にも課題がある。各サービスが提供するSDKの仕様は異なり、異なるサービス間でフラグを共有するのは困難である。またベンダーロックインの問題も無視できない。「FFSaaSのSDKを使うと、ベンダーロックインが発生することがあります。サービスを乗り換えたい場合、使用している実装をすべて修正する必要があるため、これは大きな課題です」と岩見氏は語った。

次に岩見氏は、フィーチャーフラグの管理を標準化するためのOSS「OpenFeature」を紹介した。OpenFeatureはCNCFのIncubating Projectとしても採択されている。OpenFeatureを使用することで、ベンダーロックインの問題を回避し、異なるFFSaaS間で自由にフラグを切り替えることができる。「OpenFeatureを使うことで、ベンダーロックインを避けることができ、開発者はプロバイダを変更するだけで異なるフィーチャーフラグサービスに移行できます。環境やニーズに応じて、複数のサービスを使い分けることも可能です」と岩見氏は語った。

OpenFeatureのなにが嬉しいか

OpenFeatureは、フラグの評価APIやプロバイダ、フラグ評価時のコンテキスト管理など、さまざまな機能を提供する。また、テレメトリーやエラーハンドリングにも対応しており、フラグの評価過程でフックを挿入することができる。「OpenTelemetryのように、フラグ評価の過程で必要な情報をフックによって追加したり、エラー処理を行ったりできます。これにより、システムの可観測性を高めることが可能です」と岩見氏は語った。

自動生成を活用したフィーチャーフラグの宣言的集約管理

岩見氏は、OpenFeatureの導入に加え、フィーチャーフラグの管理をより効率的にするために、自動生成を活用した方法についても詳述した。この手法では、フィーチャーフラグの情報を1つのプロファイルに集約し、そこからアプリケーションコードやインフラコード（Terraform）、テストコード、さらにはPRラベルまでを自動生成できる。このプロセスによってミスが減り、システム全体の整合性を高めることができる。

とくに自動生成にはprotoc pluginが重要な役割を果たしている。岩見氏は「protoc pluginを活用することで、大量のコードを効率的に自動生成できるようになり、プロジェクト全体では34万行以上のコードが自動生成されています」と語り、protoc-gen-starというライブラリを活用して、コード生成を簡略化していることを強調した。

「この仕組みを使うことで、手動でコードを記述するよりも、一貫性の高いコードが生成され、管理ミスを大幅に減らすことができます」と岩見氏は語った。例えば、フィーチャーフラグの情報をプロトファイルに記述するだけで、その情報から必要なコードがすべて自動生成される。この一元化されたプロファイルを使うことで、アプリケーションとインフラのコードが整合性を持つだけでなく、フィーチャーフラグが適切に使用されているかのチェックも簡単に行える。

具体的には、フィーチャーフラグの型や期限（expiry days）をプロファイルに記述し、これをもとにリマインダーテストやPRラベルなども自動生成する仕組みを導入している。とくにGoのコード生成においては、バックエンドとフロントエンドの両方で共通のフィーチャーフラグを使用する場面でも、一貫性を保つことができる。

削除ライフサイクルの課題と今後の展望

フィーチャーフラグの運用において、削除のタイミングは極めて重要な課題である。削除されるべきフィーチャーフラグがシステム内に残っているとコードが複雑化し、システム全体のメンテナンス性が低下する。岩見氏は、フィーチャーフラグの削除に関するライフサイクルの問題についても言及した。

「削除ライフサイクルは、フィーチャーフラグの運用における大きな課題です。アプリケーションコードからフィーチャーフラグを取り除いた後でなければ、FFSaaS上から削除することはできません。このタイミングを間違えると、システムに予期せぬ影響が出る可能性があります」と岩見氏は語った。

ライフサイクルの違い

この課題を解決するために、岩見氏はprotoc pluginを活用し、フィーチャーフラグの削除ライフサイクルを管理する仕組みを導入している。具体的には、フィーチャーフラグの削除が適切なタイミングで行われるよう、リマインダーテストを自動生成することで、削除のし忘れを防ぐ仕組みが実装されている。さらにPRラベルの自動生成もprotoc pluginを通じて行われており、フィーチャーフラグが作成・削除される際には、適切なラベルが自動的にPRに付与される仕組みも導入されている。これによりフィーチャーフラグに関連する変更が容易に追跡できるようになっている。

また今後の展望として、フィーチャーフラグの追加・削除を完全に自動化するシステムの構築を視野に入れている。GitOpsを活用し、フラグの追加や削除がトリガーとなり、アプリケーションコードやTerraformが自動的に更新される仕組みを目指している。「フィーチャーフラグの追加と削除を完全に自動化し、システム全体が一貫してフラグを管理できるエコシステムを構築したいと考えています」と語り、岩見氏はセッションを締めくくった。