Share via


機能フラグ

ヒント

このコンテンツは eBook の「Azure 向けクラウド ネイティブ .NET アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。

Cloud Native .NET apps for Azure eBook cover thumbnail.

第 1 章では、クラウド ネイティブの速度と機敏性の高さについて確認しました。 ユーザーは、迅速な応答性、革新的な機能、ダウンタイム ゼロを期待します。 Feature flags は、クラウドネイティブ アプリケーションの機敏性を高めるための最新のデプロイ手法です。 新しい機能を運用環境にデプロイできますが、その可用性は制限されます。 スイッチを入れるだけで、アプリを再起動したり新しいコードをデプロイしたりせずに、特定のユーザーに対して新しい機能をアクティブ化できます。 これらは、新機能のリリースをコードのデプロイから分離します。

機能フラグは、実行時にユーザーが利用できる機能を制御する条件付きロジックに基づいて構築されます。 最新のクラウドネイティブ システムでは、新しい機能を早い段階で運用環境にデプロイし、限定された対象ユーザーを使用してテストするのが一般的です。 信頼度が高くなったら、機能をより広範な対象ユーザーに段階的にロールアウトできます。

機能フラグには他に次のようなユース ケースがあります。

  • より高いサブスクリプション料金を支払ってもかまわない特定の顧客グループに Premium 機能を限定します。
  • 問題のある機能を迅速に非アクティブ化してシステムを安定化させ、ロールバックや即時修正プログラムのリスクを回避します。
  • ピーク使用期間中にリソース使用率が高いオプション機能を無効にします。
  • 小規模のユーザー セグメントに対して experimental feature releases を実施し、実現可能性と人気を検証します。

機能フラグにより trunk-based 開発も促進されます。 これは、開発者が 1 つのブランチで機能についての共同作業を行うソース管理のブランチ モデルです。 この方法では、多数の実行時間の長い機能ブランチをマージするリスクと複雑さが最小限に抑えられます。 機能は、アクティブ化されるまで使用できません。

機能フラグの実装

特徴フラグの核心部分は、単純な decision object への参照です。 それは on または off のブール値の状態を返します。 通常、このフラグは、機能をカプセル化するコード ブロックをラップします。 フラグの状態によって、そのコード ブロックが特定のユーザーに対して実行されるかどうかが決まります。 図 10-11 に実装を示します。

if (featureFlag) {
    // Run this code block if the featureFlag value is true
} else {
    // Run this code block if the featureFlag value is false
}

図 10-11 - 単純な機能フラグの実装。

このアプローチによって、機能コードから決定ロジックが分離されることに注意してください。

第 1 章では、Twelve-Factor App について説明しました。 ガイダンスで構成設定をアプリケーションの実行可能コードの外部に保持することを推奨しました。 必要に応じて、外部ソースから設定を読み取ることができます。 機能フラグの構成値も、コードベースから独立している必要があります。 フラグの構成を別のリポジトリに外部化することにより、アプリケーションを変更して再デプロイしなくても、フラグの状態を変更できます。

Azure App Configuration では、機能フラグ用の一元的なリポジトリが提供されます。 それを使用すると、さまざまな種類の機能フラグを定義し、その状態をすばやく確実に操作できます。 App Configuration クライアント ライブラリをアプリケーションに追加して、機能フラグの機能を有効にします。 さまざまなプログラミング言語フレームワークがサポートされています。

機能フラグは、ASP.NET Core サービスに簡単に実装できます。 .NET 機能管理ライブラリと App Configuration プロバイダーをインストールすると、宣言によって機能フラグをコードに追加できます。 それによって FeatureGate 属性が有効になると、 コードベース全体に if ステートメントを手動で作成する必要がなくなります。

Startup クラスでの構成が済むと、コントローラー、アクション、またはミドルウェアのレベルで機能フラグの機能を追加できます。 図 10-12 は、コントローラーとアクションの実装を示しています。

[FeatureGate(MyFeatureFlags.FeatureA)]
public class ProductController : Controller
{
    ...
}
[FeatureGate(MyFeatureFlags.FeatureA)]
public IActionResult UpdateProductStatus()
{
    return ObjectResult(ProductDto);
}

図 10-12 - コントローラーとアクションでの機能フラグの実装。

機能フラグが無効になっている場合、ユーザーは応答本文のない 404 (見つかりません) 状態コードを受け取ります。

機能フラグは、C# クラスに直接挿入することもできます。 図 10-13 は、機能フラグの挿入を示しています。

public class ProductController : Controller
{
    private readonly IFeatureManager _featureManager;

    public ProductController(IFeatureManager featureManager)
    {
        _featureManager = featureManager;
    }
}

図 10-13 - クラスへの機能フラグの挿入。

機能管理ライブラリにより、バックグラウンドで機能フラグのライフサイクルが管理されます。 たとえば、構成ストアへの呼び出しの数を最小限に抑えるため、フラグの状態は指定された期間だけライブラリによってキャッシュされます。 それにより、要求の呼び出し中にフラグの状態の不変性を保証できます。 また、Point-in-time snapshot も用意されています。 キーと値の履歴を再構築し、過去 7 日以内の任意の時点での過去値を提供できます。