Cloudflare Flagship

 (developers.cloudflare.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Cloudflare Flagship は、コードを再デプロイすることなくアプリケーションの機能公開を制御する、Cloudflare の機能フラグサービス
  • フラグは ターゲティングルール と比率ベースのロールアウトで定義され、Workers のネイティブバインディングから直接評価可能
  • OpenFeature と互換性があり、@cloudflare/flagship SDK を使って Workers、Node.js、ブラウザでフラグを評価できる
  • ターゲティングはユーザー属性、11個の比較演算子、AND/OR のグループ化、順次評価をサポートし、一貫性ハッシュで値を維持する
  • バリアントはブール値、文字列、数値、JSON オブジェクトをサポートし、Cloudflare ダッシュボードでアプリ単位に作成・変更・削除される

主な機能

  • Workers バインディング

    • Binding reference
    • Workers の ネイティブバインディング でフラグを評価する
    • 型安全なメソッドとデフォルト値への自動フォールバックを提供する

  • OpenFeature SDK

    • View SDK docs
    • @cloudflare/flagship OpenFeature provider により、Workers、Node.js、ブラウザでフラグを評価できる
    • 他のフラグプロバイダーから移行する際は、設定を1行変更するだけでよい

  • ターゲティングルール

    • Learn about targeting
    • ユーザー属性に応じて異なるフラグ値を提供する
    • ルールは 11個の比較演算子、論理 AND/OR のグループ化、順次評価をサポートする

  • 比率ベースのロールアウト

    • Learn about rollouts
    • 機能をユーザー比率に合わせて段階的にリリースできる
    • 一貫性ハッシュ により、同じユーザーが常に同じフラグ値を受け取ることを保証する

  • マルチタイプのバリアント

    • Use Multi-type variations
    • フラグのバリアントはブール値、文字列、数値、構造化された JSON オブジェクトにできる
    • オブジェクトバリアントを使うと、設定ブロック全体を1つのフラグとして渡せる

  • フラグ管理

    • Use Flag management
    • Cloudflare ダッシュボードでフラグを作成、更新、削除できる
    • フラグは、プロジェクトやサービスにマッピングされるアプリとして構成される
    • 最初の機能フラグは Get started guide で作成できる

関連する Cloudflare サービス

  • Workers: Cloudflare のグローバルネットワーク上でサーバーレスアプリケーションを構築でき、Flagship はバインディングとして Workers とネイティブ統合される
  • KV: Cloudflare のグローバルネットワーク全体にキー・バリューデータを保存し、Flagship はこのインフラを使ってフラグ設定を配信する

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • ネットワーク往復が0回の抽象化は過小評価すべきではない。f(feature_name, context) の上で、コンテキストは特定の在庫、特定のサプライヤー、特定のB2B顧客の特定ユーザー、特定のビジネスモデルのサブタイプ、特定の時間帯での表示有無に至るまで、非常に細かく合わせられる
    ロジックを直接書いて、定数のように高速な tight loop で実行できるなら、ビジネスの俊敏性は大きく向上する。一部の顧客で文言が変わる可能性があると思うなら、設定可能なコードとして実装すればよく、テストやフラグも自然についてくる
    ただし、このような0-hop構成には洗練された クライアント実行エンジンが必要だが、Cloudflare がここでそれを実装しているようには見えない。メモリ制約のある Workers では理解できるが、従来型インフラではやや納得しにくい
    Statsig のやり方はかなり気に入っている: “Server SDKs hold the entire ruleset of your project in memory...” というアプローチだ
    https://docs.statsig.com/sdks/how-evaluation-works
    自作もできる。数秒ごとにバックグラウンドスレッドでルールセットをいくつかのデータ構造に同期し、参照をアトミックに置き換えればよい。その上で、適用ルール次元に対する CRUD インターフェースさえあればよい
    ただし、誰がどの定数候補を触れるのかという ガバナンスは必須だ。大きな力には大きな責任が伴う

    • これを読むと、機能フラグがアプリケーション設定/カスタマイズとして誤用されるパターンを思い出す。複数の組織ですでに観察したアンチパターンだ
      機能フラグは、トランクベース開発と組み合わせて、QA 環境で機能を有効にし、本番にはまだ出さず、PO/PM によるテストを可能にする用途に近いと思う。トランクベース開発は、複雑なブランチ戦略なしに高速で容易な DevOps を可能にする
      一方で、アプリケーション設定はアプリケーションの一部であり、ビジネス文脈に合わせてアプリをカスタマイズする領域だ。関連するフレームワークやツールがあるのかは知らないが、両者は明確に区別すべきだ
    • 実装自体は難しくない。Mersenne Twister のようなものにモジュロ演算を載せる程度で、最近の仕事では Flipper と、任意の「現在のフラグテーブル状態」エンドポイントだけで十分だった
      そのモジュロ+乱数の組み合わせのせいで、LaunchDarkly のようなツールは複数言語向け SDK を提供しなければならず、私が扱わなければならなかった SDK はどれもその言語にまったく馴染んでいなかった。評価をエッジに押し出したせいで、システム全体が必要以上に複雑になったと思う
      実際には、「この顧客について」の現在のフラグテーブルをたまに再取得する程度で十分で、その方がずっと煩わしくない。Flipper があるおかげで、もうこういうことを自分で扱わなくてよいのはありがたい
    • その0-hop構成は必ずしも高度である必要はなく、Cloudflare が自前で実装する必要もない。OpenFeature に頼れば、クライアントライブラリに簡単なターゲティングルール評価エンジンが統合されている
    • 良い指摘だ。付け加えると、機能フラグ、A/Bテスト、認可はそれぞれ異なる3つの概念だ。この記事のフレーミングは参考になった
      https://www.stigg.io/blog-posts/entitlements-untangled-the-m...
    • 会社で Statsig をうまく使っている。完成度が高く、機能も豊富だ。使われていないフラグを削除候補として見つけてくれるツールがかなり良い
      契約上の席数課金は少し厳しいが、許容範囲ではある

  • 金箔を貼った Boolean-as-a-service のように見える

    • 会社がこうした Boolean-as-a-service をきちんと提供できず、チーム全体が失敗するのを見たことがある。LaunchDarkly のような会社が独立して存在するのには理由がある
      ここまで単純化するなら、世の中のあらゆるサービスは bits-as-a-service に還元できてしまう。実際には、こうしたものには正当なビジネス価値があり、提供プロセスにも複雑さがある
    • 悪くないと思う。データベースで何千もの 機能フラグを追跡したり、管理ダッシュボードを作ったりはしたくない
      どんな SaaS ツールでも “excel-as-a-service” と呼べてしまうし、その程度の効果しかない表現だ
    • その Boolean を 正しい時間に正しい場所へ 安定して届けるのは些細なことではない

  • JS SDK のドキュメントを見ると、こんな警告がある: “クライアント provider はフラグ値を取得するために API トークンを必要とする。このトークンは単一アプリに限定されないため、トークンを持つ誰でもアカウント内のすべてのアプリのフラグを評価できる。公開アプリケーションでは注意して使用すること”
    https://developers.cloudflare.com/flagship/sdk/client-provid...
    ブラウザに配布される前提の クライアント SDK なのに、なぜ注意が必要なのか気になる。どのクライアントでも新しい targetingKey でリクエストを送り、他ユーザーのフラグを観察できるという意味なのだろうか?
    フラグに重要情報を持たせるべきではないにせよ、興味深い設計判断に見える

    • おそらく Cloudflare 内部で使っていたものを、誰かが公開したら面白いと思ったのだろう
      6か月前に Cloudflare が LaunchDarkly の競合を作ろうと真剣に判断していたとは思えない
    • Flagship チームのエンジニアです。アプリスコープトークンは対応中です

  • これは良いのだけれど、皮肉なことに、おそらくFlagshipで提供されるであろうこの機能がまだ出るのを待っているところ
    https://blog.cloudflare.com/enterprise-grade-features-for-al...
    まだエンタープライズ専用機能が下位の有料アカウントに降りてきた例は一つもない気がする
    特に気になっているのはこれ:
    https://developers.cloudflare.com/speed/optimization/content...

    • その通り。Zero Trustのエンタープライズ機能がどうしても必要で、結局エンタープライズ営業担当者と直接話さなければならない状況。時間もかかるし、避けたいストレスも増えそう

  • 最近のCloudflareはうまくやっているが、きめ細かな権限管理が不足している。いまだに本番環境用に完全に別アカウントを作る必要があり、ドメインも1つのアカウントにしか紐付けられないのでSSOがややこしくなる

    • 製品は素晴らしく、長いこと満足して使ってきたが、最近はブログで何度かミスがあった。安定性もしばらく揺らいでいた気がするが、最近は少し良くなったようだ
    • AWSを数年使ったあとCloudflareを試し、ユーザー体験は気に入ったが、同じ懸念から結局戻った。本当にあと一歩なのに惜しい
    • 数年前にすべてのプロジェクトをCloudflareに移し、後悔はしていない。Workers, D1, R2, Queues, Containers, KVを使っている
      メール送信はまだAWSを使っているので、Cloudflare側にもできるようになるといい
    • 私も今日、さらにきめ細かな権限を求めるサポートチケットを開いた
    • これこそが、実務でCloudflareを使えない正確な理由だ。趣味用途の無料ティアは好き

  • OpenFeatureは初めて知ったが、すごく良さそう。実際に統合したことがある人はいる？ https://openfeature.dev

    • OpenFeatureはかなり使ってきたし、いくつかのクライアントライブラリには初期コミットもした。機能フラグの未来そのものだと思うし、エコシステムも急速に成長している
      念のため明かすと、私はFlagsmithのCTO。ここ数年でOpenFeature採用が確実に増加していくカーブを見てきた。以前はこちらから顧客に試してみるよう勧めていたが、今では顧客のほうが要件としてOpenFeatureを持ち込んでくる
      いまやベンダー対応もかなり成熟しており、ほぼすべての言語をカバーしている。新しいサービスに機能フラグを統合する場合でも、自前実装からサードパーティ製ソリューションへ移行する場合でも、OpenFeatureを勧める
    • かなり便利。前職で使っていて、カスタムバックエンドを作りつつ、仕様とSDKはOpenFeatureを使っていた
      完全なカスタムバックエンドを作るのに2週間ほどかかった。複数言語向けのSDKも問題なく動いた。バグを1つ見つけたが、報告したその日のうちに修正された

  • 機能フラグがいまいちよく分からない。データベースのBooleanと本質的に何が違うのか？

    • フラグ自体がBooleanでも文字列でも数値でもその他何でも、それは簡単な部分。難しいのはターゲティングとロールアウトのルール、つまり誰がどのフラグを見るのか、そしてそのルールを非常に高速かつ一貫して評価しなければならないという要件
      自前で作ったチームはたいてい、プロダクト管理、マーケティング、営業がより複雑なルールでターゲティングしたがることで、問題が急速に大きくなるのを経験する
      全体として見れば特別に難しい問題ではないが、規模が大きい。最初は見えない機能がたくさん必要になる
      機能フラグは本質的には権限システムに近い。特定のユーザーだけに特定の機能へのアクセスを与えるものだからで、権限システムを扱ったことがある人なら、グループメンバーシップ、階層グループ、ロール、ACLなどがどれほど複雑になり得るか分かるはず。こうした要素は機能フラグシステムのさまざまなターゲティングルールに似ている
    • パーセンテージロールアウト、RBAC、監査履歴、A/Bテスト、多変量設定まで入ってくると、すぐに複雑になる。そのBoolean1つが、維持・運用しなければならないシステム全体へと変わる
    • 詳しい記事はこちら: https://martinfowler.com/articles/feature-toggles.html
    • 常にBooleanとは限らない。たとえば機能フラグはA/Bロールアウトによく使われる
      Cloudflareも内部では、新機能やビルドをまず無料顧客に配布し、安定化期間のあとでより大きな顧客へ段階的に広げる形で使っている
      機能フラグは一種のファズテストのようにランダムに有効化することもできる。「新しいもの」だけでなく「挙動の変更」にも使えると考えるとよい
      すべてのクライアント上にあるBooleanだと考えることもできるが、一般的にはそのようには実装されない
    • データベースのBooleanで実装することはできるので、それは単なる実装の詳細にすぎない
      機能フラグの主な魅力は、数か月と大量のコミットを要する大きな機能でも、メインブランチ上で作業できるようにしてくれる点にある。私にとっては、より軽量で反復的な開発プロセスを実現してくれる
      別ブランチを維持し、大規模開発中の機能のために別のデプロイ先まで用意するやり方とは対照的だ

  • 機能フラグはしばしば過剰に設計されがち
    設定値、データベースの値、環境変数を見て、動的に一方の経路かもう一方の経路へ進めばよい
    それだけの話。機能を小さく作るか、高いレベルで簡単に切り替えられるようにコードをリファクタリングすべき
    それが簡単にできないなら、マイクロサービス間で機能有効化を調整するために複雑な機能フラグ実装が役立つことはある
    機能が多いならダッシュボードも便利かもしれない
    ただし、そのどちらも機能フラグを避けるべきだという強いシグナルだと思う。機能フラグはローカルで一時的な変更に向いており、そうでない場合は複雑さが蓄積して管理や保守が難しくなる

    • 特定のセグメント、たとえばイタリアの低売上ユーザーに機能を有効化して、ビジネスや性能への影響を見られるという点では妥当性がある
      もちろん、ユーザーが売上基準を超えたり国境を越えたりしたからといって機能を失わせたいわけではないので、何らかの追跡実装が必要になる。分析やエラー追跡も機能フラグサービスと通信しなければならない
      ロケット科学ではないが、環境変数よりは確実に複雑だ
    • 機能フラグの核心は規律だ。目的を持って作り、価値がなくなったらすぐに削除すべき。KISSが当てはまる

  • Cloudflareが、これまで他社サービスを使う必要があったものを提供し始めると、いつも期待してしまう。堅実なものになるという信頼がある
    FunctionではStatsigを使っていた。最初は1つのプロダクトで2人が使い始めただけだったが、12か月以内にプロダクト文言やロールアウトのかなりの部分がStatsigで動くようになった
    Statsigはクライアント側評価があるので、Statsigのサーバーがユーザーデータを処理しなくても、内部の概念に基づいてルールやロールアウトを書ける
    Cloudflareがここで洗練されたプロダクトを作ってくれて、今後は他の製品を使わなくて済むようになるといい

    • 機能フラグをサードパーティーに任せるのは不思議に感じる。何もかも自前で作るべきという立場ではないが、機能フラグは自分たちで作るのに大きな問題はなかった

  • 技術的な詳細はよく分からない普通のユーザーだが、Cloudflareは比較的使いやすいと感じる。これからも頑張ってほしい

    • これまで使ったDNSレジストラの中では最高だ