はじめに
本記事は any Advent Calendar #2 「マルチテナントSaaSにおけるエンジニアリング大全」 Day12 の記事です。 弊社anyのアドベントカレンダーをひとつ丸ごと占有して、ひとりアドベントカレンダーとして、筆者の「マルチテナントSaaSのエンジニアリング」への経験をすべてアウトプットしていくカレンダーです。
今日はマルチテナントSaaSにおけるカスタマイズのキモであるフラグ管理について紹介をしていきます🏄♂️
フィーチャーフラグ（Feature Flag）について
まずフィーチャーフラグの概要について紹介しましょう。フィーチャーフラグ（フィーチャートグルとも言います）とは、 コードを変更することなくシステムの振る舞いを変更できる仕組み です。トランクベース開発を実現し、未完成の機能を安全に本番環境へ統合することを可能にします。
フィーチャーフラグには、主に4つの種類があることが下記の記事においても紹介されています。
https://martinfowler.com/articles/feature-toggles.html
| 種類 | 目的 | 期間 | 動的/静的 |
|---|---|---|---|
| Release Toggle | トランクベース開発によるCDを実現。開発中の機能をmasterに統合しながら、いつでも本番リリースできる状態を保つ | 短期（1〜2週間） | 静的 |
| Experiment Toggle | A/Bテストやカナリアリリースを実装。一部のユーザーに新機能を適用し、その効果を比較検証する | 中期（数時間〜数週間） | 動的 |
| Ops Toggle | システムの運用面を制御。パフォーマンスへの影響が不確実な場合に、Opsチームが迅速に機能を無効化・縮退できる。MTTR改善に寄与。高負荷時に非重要な処理を抑えるキルスイッチ的な使い方も | 短期（例外的に長期も） | 動的 |
| Permissioning Toggle | 特定ユーザーの機能やUXを変更。Experiment Toggleとの違いは、「実験中」ではなく「実証済みの機能を特定ユーザーに提供する」点 | 長期 | 動的 |
マルチテナントにおけるカスタマイズ性
マルチテナントSaaSの文脈においては、テナントごとに有効/無効にしたい場合があります。上記の説明によれば、Ops ToggleやPermission Toggleに該当します。
もちろん開発者内部の用途ではRelease ToggleやExperiment Toggleも実装することはあるでしょう。
例えば
- 特定のプラン以上でないと解放されない機能がある
- 実験的な機能（ベータ版）を特定テナントに公開する
- パフォーマンス懸念があるテナントに対して一時的に無効化する
といった用途として用いることができます。
これらをユーザ自身が設定画面から変更できる場合もあれば、CSなどが機能を開放する場合などもあるでしょう。いずれにしても、ユーザ単位の設定に加えて、「テナント単位での設定をフラグ管理したい」ニーズとしてフィーチャーフラグを活用する場合があります。
OpenFeatureと未来
さて開発者目線ではフィーチャーフラグを管理する仕組みが必要になりますが、各社がそれぞれ独自の実装を持っており、統一した標準がこれまで存在しませんでした。Feature Flag as a Serviceとして提供するSaaSも非常に多いのですが、現時点では群雄割拠な印象が強くベンダーロックインが懸念されます。
そこで登場したのがOpenFeatureです。OpenFeatureは「ベンダーに依存しない、コミュニティ主導のフィーチャーフラグAPI仕様」を提供するオープンソースプロジェクトで、CNCFのインキュベーティングプロジェクトとして採用されています。
OpenFeatureは、各種サービスからFeature Flagを抽象化する層を用意しており、ベンダーロックインを防ぐことを提唱しています。ちなみに弊社プロダクトのQastにおいては現時点では完全な自前実装となっており、OpenFeatureをはじめとしたフィーチャーフラグ管理を整理したい段階です。
さいごに
マルチテナントSaaSにおけるカスタマイズ性を支えるフィーチャーフラグについて紹介しました。OpenFeatureといった標準化の未来も見えてきたなかで、どのように技術を選定するかについてヒントになれば幸いです。