Bucketeer Lite: 軽量環境（Fly.ioまたはAWS）でのフィーチャーフラグ管理システムの実行

こんにちは、CyberAgent Hanoi Dev Center の Bucketeer チームのバックエンドエンジニアです。Bucketeer は、AbemaTV を含む CyberAgent のサービスで長年使用されているオープンソースのフィーチャーフラグおよび A/B テストプラットフォームです。この記事では、2 つの異なるプラットフォームで実行する方法を紹介します: Fly.io – 軽量 VM のグローバルネットワーク上でコンテナ化アプリケーションを実行する PaaS。 AWS Elastic Container Service Fargate – サーバーレスコンテナプラットフォーム。 **Bucketeer の機能** フィーチャーフラグを使用すると、アプリケーションを再デプロイすることなく、どのユーザーがどのバージョンの機能を利用するかを制御できます。最も単純な形では、「ユーザーの 10% に機能 X を表示する」といった条件分岐です。実際には、以下のような有用なパターンを実現します: * **段階的ロールアウト** – ユーザーの 1% にリリースし、エラーを監視してから徐々に 100% に拡大 * **A/B テスト** – 2 つのバリアント間でトラフィックを分割し、ベイズ推論を使用してどちらがより良いパフォーマンスを示すかを測定 * **キルスイッチ** – デプロイをロールバックせずに機能を即座に無効化 * **ターゲットリリース** – 内部ユーザー、ベータテスター、または特定のセグメントに最初にリリース * **自動運用** – カスタムメトリクスに基づいてロールアウトを自動的にロールバックまたは進行 Bucketeer は単一のプラットフォームでこれらすべてをサポートします。様々な言語やフレームワーク (iOS、Android、React を使用した Web フロントエンド、Golang、NodeJS を使用したサーバーなど) 向けの SDK が利用可能です。アプリケーションは SDK を呼び出してフラグを評価し、プラットフォームがターゲティング、スケジューリング、実験追跡を処理します。 **標準デプロイメントとそのコスト** 標準的な Bucketeer デプロイメントは Google Cloud 上で実行されます: オーケストレーションに GKE、サービス間のイベントストリーミングパイプラインに Cloud Pub/Sub、実験データウェアハウスに BigQuery を使用します。これは堅牢な本番環境設定ですが、約 300 米ドル/月の基本コストがかかります。Pub/Sub と BigQuery はどちらも使用量に応じて課金されるため、イベント量に応じてコストは増加します。 Bucketeer を評価しているチームや、小規模なアプリケーションを実行しているチームにとって、この参入障壁は高くなります。また、そもそも Google Cloud を利用している必要があります。 **Lite バージョン** 私たちは Bucketeer を Google Cloud 以外でも利用可能にしたいと考え、標準的なコンテナプラットフォーム上で実行するように設計された Lite バージョンを構築しました。標準デプロイメントとの主な違いは次のとおりです: * イベントパイプラインは Cloud Pub/Sub の代わりに Redis Streams を使用 * データウェアハウスは、実験分析用に BigQuery の代替として MySQL または PostgreSQL をサポート これらの変更により、Bucketeer は Google Cloud アカウントを必要とせず、コンテナをホストできる任意のプラットフォーム上で実行できます。 私たちは 2 つのオプションのデプロイメントスクリプトを用意しました。すべての価格は米ドル/月で、24/7 稼働を想定しています。 両方のデプロイメントは同じサービスを実行します。Nginx はブラウザトラフィックを Web (コンソールと管理 API) に、SDK 呼び出しを API (フラグ評価) にルーティングします。Subscriber は Redis Streams からイベントを消費し、結果を MySQL に書き込みます。Batch はスケジュールされたジョブ (ロールアウト進行、実験評価、自動運用) を実行し、ベイズ的有意性計算のために HTTPStan を呼び出します。Batch-Cron はスケジュールに従って Batch をトリガーします。Migrations は Atlas を使用したワンショットタスクとして実行されます。 主な違いはインフラストラクチャです。 * **Fly.io の場合**、各サービスは Fly Machine として実行されます。これはミリ秒で起動し、実行中のみ課金される軽量 VM です。同じ組織内のマシンはプライベート WireGuard ネットワークを共有し、`*.internal` DNS を介して到達可能なため、サービスは公開されることなく相互に通信します。API は独自のエニーキャスト IP を取得します: 複数のリージョンにマシンをデプロイすると、Fly.io は各 SDK クライアントを最も近いマシンに自動的にルーティングします。Redis は Upstash によって管理され、各サービス上のローカル socat プロキシがパスワード認証を処理します。MySQL は永続ボリュームを持つ Fly Machine 上で実行されます。 * **AWS の場合**、Application Load Balancer が単一のエントリーポイントであり、Nginx に転送します。アプリケーションサービスはパブリックサブネット内の ECS Fargate タスクとして実行されます – NAT Gateway は不要です。サービスは AWS Cloud Map (`*.bucketeer.local`) を介して相互を発見します。MySQL と Redis はプライベートサブネット内の RDS と ElastiCache 上で実行されます。シークレットはコンテナ起動時に SSM Parameter Store から注入されます。 **Fly.io アーキテクチャ** ![](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/04/flyio_deployment.png) **Fly.io ~34 米ドル/月** **推定コスト (米ドル)** * shared-1x, 1024 MB * shared-1x, 512 MB * shared-1x, 256 MB * shared-1x, 256 MB * shared-1x, 256 MB * shared-1x, 256 MB * shared-1x, 256 MB * shared-1x, 256 MB * 2x IPv4 (nginx + api) **AWS アーキテクチャ** ![](https://developers.cyberagent.co.jp/blog/wp-content/uploads/2026/04/aws_lite_bucketeer.jpg) **AWS ECS Fargate ~88 米ドル/月 (us-east-1)** **推定コスト (米ドル)** * ECS Fargate (Nginx) – 0.25 vCPU, 512 MB * ECS Fargate (API) – 0.25 vCPU, 512 MB * ECS Fargate (Web) – 0.25 vCPU, 512 MB * ECS Fargate (Batch) – 0.25 vCPU, 512 MB * ECS Fargate (Subscriber) – 0.25 vCPU, 512 MB * db.t3.micro, 20 GB * ElastiCache Redis * 無効 – ECS タスクは `assign_public_ip=true` でパブリックサブネットを使用 AWS Free Tier (最初の 12 ヶ月): RDS と ElastiCache は無料です (特定の条件に基づきます。詳細は AWS の料金プランウェブサイトをご確認ください)。これによりコストは約 61 米ドル/月になります。 **Bucketeer でのフィーチャーフラグの使用** デプロイ前にプラットフォームの感触を得たい場合、Bucketeer デモサイトでは、フィーチャーフラグ、段階的ロールアウトなどをサンドボックス環境で試すことができます – インフラ設定は不要で、Google アカウントでサインインするだけです。 デプロイ後は、Web コンソールと SDK を介して Bucketeer と対話します。 フラグの作成は簡単です – 名前を付け、タイプ (ブール値、文字列、数値、または JSON) を選択し、デフォルト値を設定します。そこからターゲティングルールの設定、ロールアウトのスケジュール設定、または実験への関連付けができます。 ロールアウトでは、フラグバリエーションを受け取るユーザーの割合を徐々に増やすことができます。初期割合とスケジュールを設定すると、Bucketeer が自動的に進行させます。 実験では、2 つ以上のフラグバリエーション間でトラフィックを分割し、目標イベント (クリック、コンバージョン、カスタムメトリクス) を追跡します。プラットフォームはベイズモデルを使用して統計的有意性を決定するため、事前に固定サンプルサイズを設定する必要はありません。 自動運用は特に興味深い部分です。「治療群のユーザーのエラー率が 1% を超えた場合、フラグを自動的にロールバックする」などのルールを定義します。これにより、フィーチャーフラグは安全層 – 自動サーキットブレーカーを備えた段階的デリバリー – に変わります。 これらは各デプロイオプションのコンピュート仕様に基づいた大まかな推定値です。API サービス (SDK フラグ評価) は主要なスループットの懸念点です – フラグを評価するアプリケーション内のすべてのリクエストで呼び出されます。 * Fly.io (shared-cpu-1x) * AWS (0.25 vCPU Fargate) * フラグ評価 – キャッシュヒット * フラグ評価 – キャッシュミス (DB 読み取り) * イベント取り込み (Redis Streams 書き込み) * 管理 API (Web コンソール) ほとんどのチームにとってこれは十分です。SDK は評価結果をローカルにキャッシュするため、API はすべてのページロードで呼び出されるわけではありません – SDK の初期化時と定期的な更新時のみです。数十万の日次アクティブユーザーを持つアプリケーションは、通常、フラグ評価の RPS (1 秒あたりのリクエスト数) が 100 を大幅に下回ります。 注意すべきボトルネック: * **MySQL コネクションプール** – 両方のデプロイメントは 50 のオープン接続を設定します。デフォルトインスタンスサイズ (AWS の db.t3.micro、Fly.io の shared-1x) では、MySQL は約 500–800 の単純なクエリ/秒で飽和します。 * **Upstash Redis レイテンシ** – Upstash はリモート管理サービスです (往復約 1–3 ミリ秒、ローカル ElastiCache は約 0.1 ミリ秒)。これは AWS デプロイメントと比較して、キャッシュを多用するパスのスループットを制限します。 * **Fly.io 共有 CPU** – shared-cpu-1x はバースト可能であり、保証された割り当てではありません。持続的な高トラフィックはスロットリングされる可能性があります。 より多くの容量が必要な場合、水平スケーリングは簡単です。API サービスはステートレスです – Fly.io では `fly scale count 2 -a bucketeer-api`、AWS では ECS の desired count を調整します。追加インスタンスごとにほぼ同じスループットが追加されます。 Lite デプロイメントが快適に処理できる範囲を超えるトラフィックがある場合、内部 SaaS オプション (CyberAgent チーム向け) または本番規模向けに設計された Google Cloud 上の標準 Bucketeer デプロイメントのいずれかを推奨します。 **Lite バージョンに含まれないもの** * **イベントパイプライン** – 標準バージョンは Cloud Pub/Sub を使用します。これは完全管理型で、高スループット、グローバル分散イベントストリーミング向けに設計されています。Lite バージョンはこれを Redis Streams に置き換えます。これは中規模ではうまく機能しますが、Pub/Sub の耐久性保証や、バックプレッシャーなしでより高いイベント量を処理する能力には及びません。例えば、1 秒あたり 10000 または数百万ものイベントが予想される場合、またはイベント損失なしの保証配信が必要な場合、Cloud Pub/Sub がより適しています。 * **データウェアハウス** – すべてのフラグ評価はイベントを生成し、使用統計としてコンソールに保存・表示されます。標準バージョンはこれに BigQuery を使用します。Lite バージョンは MySQL または PostgreSQL を使用します – ほとんどのチームに適していますが、イベントテーブルが数億行に達すると、コンソール統計を支える集計クエリの速度が顕著に低下します。BigQuery はこの種の読み取りのために構築されており、数十億行を数秒で処理します。Lite デプロイメントを離れずにより多くの余裕が必要な場合、TimescaleDB も Lite バージョンに実装されています – これは時系列データ向けに特別に構築された PostgreSQL 拡張機能であり、自動パーティショニングと圧縮を介して、プレーンな PostgreSQL や MySQL よりも大幅に大規模な集計を処理します。 高可用性と可観測性もデフォルトでは設定されていません – Lite デプロイメントは各サービスの単一インスタンスを実行し、stdout にログを出力します。ただし、各サービスは使用要件に基づいてスケールアップできます。 **始め方** デプロイメントスクリプトは `github.com/bucketeer-io/bucketeeraform` で利用可能です。リポジトリには、Fly.io と AWS の両方のセットアップ手順を含む README.md が含まれています。全体のプロセスは、クローンから実行中の Web コンソールまで約 10–15 分かかります。 Bucketeer を評価中、または Google Cloud 外で実行したい場合、これは妥当な出発点となります。コントリビューションとフィードバックを歓迎します。 **CyberAgent 内での Bucketeer の利用** CyberAgent のチームで、自社のインフラストラクチャを管理したくない場合は、Bucketeer を内部 SaaS としても提供しています。Bucketeer チームが CyberAgent 内でプラットフォームをホスト・運用するため、セットアップなしですぐにフィーチャーフラグの使用を開始できます。直接お問い合わせください。

Bucketeer Lite: 軽量環境（Fly.ioまたはAWS）でのフィーチャーフラグ管理システムの実行

背景や根拠まで確認しますか？

調べる

選ぶ

サイト