フィーチャーフラグを抽象化するOpenFeatureとは？

CNCFのWebinarから、サンドボックスプロジェクトとして採用されたOpenFeatureのイントロダクションを紹介する。OpenFeatureはフィーチャーフラグの抽象化のためのオープンなスタンダードとして開発が進んでおり、ベンダーニュートラルなAPIを提供するプロジェクトだ。DynatraceとLaunchDarklyなどがオープンソースコミュニティの主要なメンバーだが、CNCFへのサンドボックスプロジェクトとしての採用は2022年6月17日なので、サンドボックスとして活動は現時点で1年と少しになる。この動画自体は2023年6月29日に公開されたものだ。セッションを担当しているのはDynatraceのエンジニアでCNCFとCD FoundationのアンバサダーでもあるAdam Gardner氏だ。

プライベートではダイビングが好きだと言うGardner氏

このセッションではフィーチャーフラグの必要性を解説する背景としてソフトウェアデリバリーの問題点について解説した後に、カナリアデプロイメントなどのテクニックを紹介し、フィーチャーフラグの優位性を示したうえでデモとしてKillercodaというWebブラウザ上でさまざまなソフトウェアを学習するためのサイトを使って、フィーチャーフラグの機能を実際に動かして紹介している。

ソフトウェアデリバリーの解説からフィーチャーフラグの解説、そしてデモ

ここではソフトウェアが開発され本番環境にデリバリーされるまでをDay 1、それ以降のバージョンアップなどでソフトウェアが更新される段階以降をDay 2として解説している。多くのデベロッパーにとってはDay 1は1日であるのに対して、Day 2は何度も繰り返し行われる内容であり、いかにソフトウェアを更新し続けるか、そして更新のプロセスが悪いユーザーエクスペリエンス与えないかが要点であることには間違いない。

Gardner氏は特に本番環境においてバージョンを更新するための方法として、V1を完全に停止してからV2に入れ替える方法はビジネスのニーズには合っていないと説明。その上でカナリアデプロイメントによって複数のバージョンを同時に実行した上で、その割合を変えて徐々に新バージョンに置き換える方法を紹介した。

カナリアデプロイメントでバージョンを徐々に入れ替える方法

ここではロードバランサーによってトラフィックが徐々にV1からV2に移行していくようすを解説している。しかしカナリアデプロイメントでは複数のバージョンが実行されるため、多くのリソースが必要になることなどを挙げて必ずしも最適な方法論ではないと説明した。ここでは説明されていないが、ブルーグリーン・デプロイメントも同様に複数のインスタンスを必要とすることから最適ではないという見解だろう。

そして前述の評価を踏まえた上でフィーチャーフラグを紹介した。フィーチャーフラグはソフトウェア開発のテクニックで、よりきめ細かく機能のオンオフが可能になると説明。カナリアデプロイメントやブルーグリーン・デプロイメントがどちらかと言えば運用サイドのテクニックとしてスムーズな更新を目指していたのに比べると、フィーチャーフラグは完全にデベロッパーが管理する発想だ。

フィーチャーフラグの紹介

次のスライドでは実際にコードの例を見せて説明。ここでは通常は新機能を利用することはできないが、テスターであればその新機能が実行されるようにするという内容となっている。

フィーチャーフラグのコードの概念を紹介

ただしフィーチャーフラグにおいても単一の開発グループだけが存在し、同じツールを使うのであれば問題はないが、仮に複数の開発グループが存在し、それぞれのビジネスドメインに合ったツールを選択するようになれば、問題が顕在化すると説明。フィーチャーフラグ自体は素晴らしい機能だが、それを実際に大きな組織で活用しようとすれば、必ずこの問題に遭遇するというのが背景にあるようだ。

複数の開発チームがそれぞれのフィーチャーフラグを使う

この問題を解決するためには、フィーチャーフラグのツールとそれを組み込んだアプリケーションの間にそれを抽象化するレイヤーが必要だと説明。

フィーチャーフラグとアプリケーションの間に別の「魔法」のレイヤーが必要

そしてそれを実現するのがOpenFeatureであるというのが、このセッションの大きなポイントだ。

OpenFeatureとは？

オープンでベンダーにニュートラルなAPIを提供するのがOpenFeatureと説明。すでに市場に存在するフィーチャーフラグツールのベンダーとも連携することを強調している。

LaunchDarkly、CloudBees、Flagsmithなどのロゴが紹介されている

この部分を理解するには、OpenFeatureのブログにある図が役に立つだろう。

最初の図ではさまざまなフィーチャーフラグのツールが開発のためのフレームワークやプラットフォームごとにSDKを提供し、それを使ってフィーチャーフラグを実装しているようすが描かれている。しかし、複数のツールが利用されることでメッシュのような組み合わせが発生し、管理を行う側の労力が発生することをしめしている。

どのフィーチャーフラグツールもSDKを提供し、組み合わせ爆発が発生する

しかし中間に抽象化するレイヤー、この場合はOpenFeatureが存在すれば開発側は好きなフィーチャーフラグツールとフレームワークを使いながら、シンプルなAPIでフィーチャーフラグを使うことができると説明している。この2枚の図は、下記のOpenFeatureを紹介するブログからの引用だ。ぜひ、記事のほうも参照して欲しい。

OpenFeatureを中間に入れることで抽象化が可能

●参考：ブログ：OpenFeature - a standard for feature flagging

ここからセッション自体は後半となり、Killercodaを使って実際にフィーチャーフラグのデモを行っている。ここでKubernetesではない環境とKubernetes環境に分けて説明しているのはKubernetesを使っていないエンジニアに向けたメッセージだろう。つまり、仮想マシンなどのレガシーなスタイルでの開発であっても、フィーチャーフラグの応用範囲に含まれるという意味だ。

OpenFeature Operatorを使ってKubernetes環境でのデモを実施

デモの内容は以下のGitHubリポジトリから参照して欲しい。

●参考：OpenFeatureのデモ：https://github.com/open-feature/playground

またKillercoda上でのデモも公開されており、実際に操作して理解を進めることも可能だ。

●参考：Killercoda上のOpenFeatureデモ

セッションの中では特にKillercodaの解説はなかったが、セットアップに時間がかかるさまざまなソフトウェアを学ぶためのプラットフォームとしては非常に優れているので、これを機会にエンジニアは体験することをお勧めする。CNCFが行っているKubernetesの認定試験、CKA、CKAD、CKSのコンテンツも用意されているので、クラウドネイティブなシステムを体験するためだけではなく試験対策にもなるだろう。

●参考：Killercoda

最後にOpenFeatureに関するさまざまなリソースを紹介してセッションを終えた。Kubernetesのエコシステムが拡大したのはKubernetesそのものの優位性だけではなく、CSI（Container Storage Interface）やCNI（Container Network Interface）のようにインターフェースが抽象化されたことが大きいだろう。フィーチャーフラグもそのAPIが抽象化され、プラグインのような形でアプリケーションデベロッパーに拡がるかどうかは、コミュニティの努力と協力するベンダーの数に影響されるように思われる。

似たような試みであるサービスメッシュの抽象化を目指したSMI（Service Mesh Interface）が思ったような成果を出せていない状況だが、OpenFeatureの今後に期待したい。

「すべてのユーザーのためにフィーチャーフラグを標準化」がタグライン