【実践ガイド】AppSignalでRuby on Railsのフィーチャーフラグの効果を測定する方法

フィーチャーフラグ(機能フラグ)は、ソフトウェア開発における強力な手法の一つです。新しいコードをデプロイすることなく、アプリケーションの動作を実行時に切り替えられるため、新機能のテスト、A/Bテスト、段階的なリリースなどに幅広く活用できます。

Ruby on Railsにはフィーチャーフラグを管理するためのツールが多数存在しますが、中でも最も人気が高いのがFlipper gemです。本記事では、Solidusストアフロントを題材に、FlipperとAppSignalのカスタムメトリクスを組み合わせて、フィーチャーフラグを実装し、その影響を測定する手順を詳しく解説します。

おさらい:Railsにおけるフィーチャーフラグとは

入門的な内容をお探しの方は、「Add Feature Flags in Ruby on Rails with Flipper」という記事をご覧ください。

簡単にまとめると、フィーチャーフラグとは実行時にアプリケーションの挙動を変える仕組みであり、新しいコードをデプロイする必要はありません。最もシンプルな形は環境変数です。すべてのRuby on Railsアプリケーションは標準で環境変数を利用しており、たとえばENV['WEB_CONCURRENCY']によるアプリケーションサーバーの同時実行数の設定がその一例です。

ただし、環境変数以外にも、ActiveRecordやRedisといった永続化レイヤーを使ってフィーチャーフラグを管理する方法があります。包括的なソリューションを提供しているのがFlipper gemです。

次のコードは、特定のユーザーに対してperformance_improvementというフィーチャーフラグを評価する例です。

それでは、Solidusストアフロントをセットアップして、実際にフィーチャーフラグを試してみましょう。

サンプルアプリ:Solidusストアフロント

やや現実的なシナリオでフィーチャーフラグの影響を測定するため、まずSolidusストアを素早く立ち上げます。

このジェネレーターがセットアップ手順を案内し、いくつか質問をしてきます。

1. フロントエンドの種類を聞かれたら、starterを選択します。
2. 支払い方法の設定はスキップします。
3. Solidusアプリケーションはスタンドアロンアプリとして使うため、/にマウントします。

その後、ターミナルからbin/devを実行すれば準備完了です。https://localhost:3000にアクセスすると、次のような画面が表示されます。

Flipperでフィーチャーフラグを実装する

ここからは、フィーチャーフラグの代表的なユースケースを2つ実装していきます。

• パフォーマンスの改善
• コンバージョン率(CVR)の最適化

まず最初に、flipper gemとActiveRecordストレージアダプタを追加しましょう。

これにより、フィーチャーフラグのチェック時に評価される具体的な条件(Flipperでは「ゲート」と呼ばれます)を参照するためのデータベーステーブルが作成されます。

パフォーマンス改善の検証

このシナリオを検証するために、最適化前のケースとしてストアフロントにsleep 1を追加し、意図的に遅いリクエストを再現します。

次に「パーセンテージ・オブ・タイム」戦略を使って、ランダムなリクエスト群に対して最適化を段階的に展開します。Railsコンソールを開いて以下を入力してください。

負荷テストツールのohaを使えば、実際に半数のリクエストが他より1秒長くかかっていることを確認できます。

コンバージョン率最適化の検証

UIの変更などユーザー向け機能の場合は、「パーセンテージ・オブ・アクター」戦略でフラグを展開するのがおすすめです。この方法なら、各ユーザーは常に同じ体験を受けられるためです。

まず、ECサイト向けに2人のユーザーを作成しましょう。Railsコンソールを起動して以下のコマンドを実行します。

これでサンプルユーザーが2人作成され、うち1人に対してはフィーチャーフラグが一貫して有効になります。

コンバージョン率を押し上げようとする機能をシミュレートするため、チェックアウトボタンを点滅させてみましょう。

両方のユーザーでログインし、ブラウザウィンドウを並べて表示すると、片方のユーザー(左側)だけにエフェクトが有効になっていることが確認できます。

AppSignalカスタムメトリクスでフィーチャーフラグの影響を測定する

どんなに優れたフィーチャーフラグシステムでも、その影響を評価する手段がなければ意味がありません。今回のシナリオで知りたいのは、次の2点です。

• パフォーマンス改善によって、レイテンシは有意に減少したか?
• 点滅するチェックアウトボタンによって、コンバージョン率は有意に向上したか?

これらの最適化の成果を測定するために、AppSignalのカスタムメトリクスを活用します。

まず、AppSignalの組織内で新しいアプリケーションを作成し、指示に従って自分のアプリと接続してください。

計測メトリクスでレイテンシを測定する

先ほどohaによる負荷テストでパフォーマンス改善の効果は確認しましたが、今度はサーバー側のテレメトリとしてレイテンシをAppSignalにレポートしましょう。measurement metric(計測メトリクス)はまさにこの用途にぴったりです。レスポンスタイムをミリ秒単位で送信し、特定のリクエストに対してパフォーマンス最適化が有効だったかどうかを示すメトリックタグを付与します。

ここで少し注意点があります。「Percentage of Time」方式を採用している場合、フラグの状態をインスタンス変数に保持しておく必要があります。そうしないと、実行時とレポート時で異なる値が参照されてしまう可能性があるためです。

それでは、先ほどのローカル負荷テストをもう一度実行してみましょう。

このメトリクスのグラフ化と評価については後ほど解説します。その前に、2つ目のフィーチャーフラグに取り掛かりましょう。

カウンターメトリクスでコンバージョンを集計する

コンバージョンの計測にはカウンターメトリクスを使用します。単にイベントの発生回数を記録したいだけであれば、これが最適な選択肢です。

そのために、CartsControllerを開き、デモンストレーションとしてチェックアウトボタンがクリックされたときにincrement_counterを呼び出すようにします。

それでは、ブラウザウィンドウをそれぞれ開いて、一方で「Checkout」ボタンを3回、もう一方で1回クリックしてテストしてみましょう。これにより、最適化フラグが有効なケースを確認できます。

AppSignalでカスタムダッシュボードを構築する

最後のステップは、データに基づいたビジネス判断を下せるよう、わかりやすいグラフを作成することです。ここではAppSignalのダッシュボードを活用します。手順を順番に見ていきましょう。

1. 左サイドバーの「Add dashboard」をクリックし、「Feature Flag Evaluation」という名前を付けます。

1. 「Add Graph」をクリックしてproducts_response_timeメトリクスを選択します。「mean」を選んで平均値のみを表示し、performance_improvement_enabledタグを適用します。

1. 「Add new Graph」をクリックして、チェックアウト件数用のグラフを追加します。こちらにもoptimization_activeタグを適用します。

これでカスタムダッシュボードの完成です。左の折れ線グラフでパフォーマンス改善が実際に効果を発揮したことを確認でき、右側では最適化が有効なケースでチェックアウト数が多く記録されている様子を観察できます。

以上で完成です!

まとめ

本記事では、Ruby on Railsアプリケーションにおいて、フィーチャーフラグが新機能の管理と展開を柔軟かつ効率的に行うための手段になることを紹介しました。Flipper gemやAppSignalのカスタムメトリクスといったツールを活用すれば、機能のリリースを制御できるだけでなく、パフォーマンスやユーザー行動への影響まで測定できます。

このアプローチにより、新機能を完全に展開する前に十分にテスト・最適化できるようになり、結果としてより安定したユーザーフレンドリーなアプリケーションにつながります。さらに、複数のアプローチの効果を比較検証する際に、データに基づいた意思決定を行うことにも役立ちます。

それでは、Happy coding!

P.S. Ruby Magicの最新記事をいち早く読みたい方は、Ruby Magicニュースレターを購読して、記事を見逃さないようにしましょう!

Julian Rubisch(ジュリアン・ルビッシュ)

ゲスト執筆者のJulianは、ウィーンを拠点とするRuby on Railsフリーランスコンサルタントで、Reactive Railsを専門としています。StimulusReflexコアチームの一員として、2020年以降HTML-over-the-wire技術の最先端開発に携わっています。

Julian Rubischの記事一覧