プロフィール
Ruby PR

Ruby on RailsでFeature FlagsをAWSと連携して活用する方法

 
記事内に商品プロモーションを含む場合があります

アプリケーション開発を進める中で、
新しい機能を一部のユーザーにのみ提供したり、
リリース後の機能を簡単に無効にする必要がある場合があります。

そんなときに役立つのが
Feature Flags（機能フラグ）です。

本記事では、
Ruby on RailsでFeature Flagsを導入し、
AWSと連携して効率的に管理する方法を解説します。

Contents
  1. Feature Flagsとは？特定の機能を動的に有効/無効にできる仕組み
  2. Ruby on RailsでのFeature Flagsの実装方法
  3. AWSでのFeature Flagsの管理
  4. Feature Flagsの運用におけるベストプラクティス
  5. まとめ

Feature Flagsとは？特定の機能を動的に有効/無効にできる仕組み

Feature Flags（機能フラグ）とは、
アプリケーション内の特定の機能を
動的に有効/無効にできる仕組みのことです。

たとえば、新機能を一部のユーザーにのみ公開したり、
必要に応じて即座に機能を無効化することが可能です。

アプリケーションの特定の機能を、
コードを変更することなくオン・オフすることができるため、
開発や運用の柔軟性が高まります。

利用シーン:

  • A/Bテスト
    特定のユーザーだけに新しい機能を試してもらい、
    フィードバックを得る。
  • 段階的リリース
    新機能を全ユーザーに公開する前に、
    一部のユーザーだけに公開して問題がないか確認する。
  • ロールバック
    もし新機能に不具合が見つかった場合、
    Feature Flagsで素早く無効にすることが可能。

Ruby on RailsでのFeature Flagsの実装方法

Ruby on Railsでは、
Feature Flagsを簡単に導入できる
ライブラリがいくつか存在します。

中でも代表的なのがFlipperやRolloutです。

ここでは、Flipperを使った基本的な
Feature Flagsの実装方法を紹介します。

Flipperのインストール

Flipperは、
Railsアプリケーションに簡単に導入できる
Feature Flags管理ライブラリです。

以下の手順でインストールします。

gem install flipper


また、Gemfileに以下を
追加してインストールします。

gem 'flipper'
gem 'flipper-active_record' # データベースにフラグを保存する場合

基本的な使い方

Flipperを使うと、簡単にフラグを管理できます。
以下の例では、新しいダッシュボード機能を
一部のユーザーにのみ提供する場合のコードを示しています。

# フラグの作成
flipper = Flipper[:new_dashboard]

# フラグを有効にする
flipper.enable

# フラグをチェックして機能を切り替え
if flipper.enabled?(current_user)
  render 'new_dashboard'
else
  render 'old_dashboard'
end


このコードでは、
new_dashboardというフラグを作成し、
そのフラグが有効になっているかどうかをチェックしています。

AWSでのFeature Flagsの管理

Feature Flagsは、
アプリケーション内部で管理することも可能ですが、
クラウドサービスを使うことでより柔軟でスケーラブルな運用が可能になります。

ここでは、AWS AppConfigを使って
Feature Flagsを管理する方法を紹介します。

AWS AppConfigの特徴

AWS AppConfigは、
AWSが提供する設定管理サービスです。

これを利用することで、
Feature Flagsをリアルタイムで
切り替えることができます。

たとえば、
リリース後に急な不具合が発生した場合でも、
すぐに機能を無効化できるため、
ダウンタイムを最小限に抑えることができます。

AWS AppConfigは、
アプリケーションの設定や構成を
管理するために設計されています。

設定情報はJSONやYAML形式で保存され、
リアルタイムで更新可能です。

Railsアプリと組み合わせることで、
コードを変更せずに、新機能の有効化や無効化、
その他の設定をリアルタイムで制御できます。

主な特徴

  • リアルタイム更新
    設定やFeature Flagsを即座に変更でき、
    ユーザーに影響を与えずにアプリケーションの動作を調整可能。
  • 高度な設定管理
    環境ごと（開発、ステージング、本番など）に
    設定を分けて管理できる。
  • 安全なデプロイ
    段階的なリリースやエラーチェックを行い、
    問題が発生した場合は迅速にロールバックできる。

AWS SDK for Rubyのインストール

まず、
AWS SDK for Rubyをインストールします。

Aws::AppConfigDataを使用するためには、
SDKが最新版であることを確認します。

gem install aws-sdk-appconfigdata


または、Gemfileに以下を追加します。

gem 'aws-sdk-appconfigdata'

AWS AppConfigとRailsの統合

AWS AppConfigは、
AWSのサービスの一部として、
動的にアプリケーション設定や
構成情報を管理できるツールです。

特にFeature Flagsの管理に便利で、
リアルタイムにフラグの状態を更新できるため、
サービスのダウンタイムを最小限に抑えることができます。

これをRailsアプリケーションと統合することで、
スムーズかつスケーラブルなFeature Flagsの管理を実現できます。

ここでは、
AWS AppConfigとRuby on Railsをどのように統合して、
動的にFeature Flagsを操作するのかを詳しく解説します。

ステップ1: AWS AppConfigの設定

次に、AWS AppConfig側の設定を行います。

  1. AWS Management Consoleに
    ログインし、AppConfigを開きます。
  2. アプリケーションを作成します。
    これは、Railsアプリに対して管理する
    設定を定義するための枠組みです。
  3. 環境（Environment）を設定します。
    通常は「開発」「ステージング」「本番」など、
    アプリケーションの各環境に合わせて設定を分けます。
  4. 構成プロファイル（Configuration Profile）を作成します。
    これには、管理するFeature Flagsの内容をJSON形式で定義します。

例として、以下のようなJSON形式の設定ファイルが考えられます。

{
  "new_dashboard_enabled": true,
  "max_items_per_page": 50
}

ステップ2: AWS AppConfigDataを使った設定を取得

以下のコードでは、
Aws::AppConfigDataを使って
AWS AppConfigからFeature Flagsのデータを取得し、
それに基づいて処理を分岐します。

require 'aws-sdk-appconfigdata'

class FeatureFlags
  def initialize
    @client = Aws::AppConfigData::Client.new(region: 'us-east-1')
    @token = nil
  end

  def fetch_flags
    # 初回リクエストでコンフィグを取得するためのトークンを取得
    if @token.nil?
      start_configuration_session
    end

    response = @client.get_configuration(
      configuration_token: @token
    )

    # トークンを更新して再利用可能に
    @token = response.next_poll_configuration_token

    # フラグ情報をJSONとしてパースして返す
    JSON.parse(response.content)
  end

  private

  def start_configuration_session
    session_response = @client.start_configuration_session({
      application_identifier: 'MyRailsApp',
      environment_identifier: 'env-xxxxxx',  # 環境ID
      configuration_profile_identifier: 'FeatureFlagsConfig'
    })

    @token = session_response.initial_configuration_token
  end
end

  • start_configuration_session
    AppConfigから設定情報を
    取得するためにまずセッションを開始します。
    このセッションのtokenを使用してデータを取得します。
  • get_configuration
    取得したトークンを使って設定データを取得します。
    レスポンスに含まれるJSON形式の設定データを
    パースして、Feature Flagsとして利用します。
  • next_poll_configuration_token
    新しい設定の取得に使用するために、
    次回のポーリング用のトークンを取得します。

ステップ3: Feature Flagsに基づく処理の分岐

次に、
取得したFeature Flagsに
基づいて処理を分岐します。

以下は、new_dashboardというフラグに基づいて、
新しいダッシュボード機能を有効にするかどうかを判断する例です。

feature_flags = FeatureFlags.new.fetch_flags

if feature_flags["new_dashboard_enabled"]
  render 'new_dashboard'
else
  render 'old_dashboard'
end

このように、new_dashboard_enabledフラグが
trueの場合は新しいダッシュボードを表示し、
falseの場合は従来のダッシュボードを表示します。

このフラグはAppConfigでリアルタイムに変更できるため、
コードの変更なく機能のオン・オフを切り替えることが可能です。

ステップ4: 設定のキャッシュと更新頻度の調整

AWS AppConfigの設定は、
各リクエストで頻繁に取得すると
パフォーマンスに影響を与える可能性があります。

そのため、キャッシュを実装し、
定期的に設定を更新するのが一般的です。

以下のコードは、
キャッシュを使って設定を1時間ごとに更新する例です。

class FeatureFlags
  CACHE_EXPIRATION = 1.hour

  def fetch_flags
    Rails.cache.fetch('feature_flags', expires_in: CACHE_EXPIRATION) do
      response = @client.get_configuration(
        configuration_token: @token
      )
      JSON.parse(response.content)
    end
  end
end

この実装では、
Rails.cacheを利用して1時間ごとにフラグを更新し、
無駄なAPIリクエストを抑制します。

Feature Flagsの運用におけるベストプラクティス

Feature Flagsの運用にあたっては、
いくつかのベストプラクティスを意識することが重要です。

フラグの有効期限を設定する

Feature Flagsは
一時的なものとして使用するのが理想的です。

長期間残しておくと、コードが複雑化し、
管理が難しくなるため、
不要になったフラグは定期的に削除することが推奨されます。

フラグの影響範囲を最小限にする

Feature Flagsは、
できるだけ小さな機能に対して設定することで、
意図しないバグや不具合を避けることができます。

例えば、フロントエンドだけでなく、
バックエンドにも影響するような大規模な機能に
フラグを適用する場合は慎重に運用する必要があります。

まとめ

Feature Flagsを利用することで、
アプリケーションの機能を柔軟に管理し、
リスクの少ないリリースが可能になります。

特にAWS AppConfigと連携させることで、
スケーラビリティやセキュリティを確保しながら、
リアルタイムに機能をコントロールすることができます。

まずは簡単なフラグから導入し、
徐々に本格的な運用へと進めていくことで、
開発スピードと安全性の両方を向上させることができるでしょう。

RELATED POST