ハクソク

世界を動かす技術を、日本語で。

Cloudflare フラッグシップ

10時間前原文(developers.cloudflare.com)

概要

  • CloudflareのFlagship は、アプリケーションの機能公開を安全に管理する フィーチャーフラグサービス
  • 再デプロイ不要 で機能の可視性を制御し、柔軟な ターゲティングや段階的リリース が可能
  • OpenFeature標準 に完全対応し、SDKで様々なランタイムに対応
  • Workersとのネイティブ連携 やダッシュボードによる管理機能を提供
  • コミュニティサポート や開発者向けリソースも充実

Flagshipによるフィーチャーフラグ管理

  • Flagship はCloudflareが提供する フィーチャーフラグ管理サービス
  • 機能の公開・非公開を コードの再デプロイなし で制御
  • ターゲティングルール や パーセンテージロールアウト による段階的リリースをサポート
  • Workersネイティブバインディング で直接フラグ評価が可能
  • 型安全なメソッドと 自動デフォルトフォールバック 機能

OpenFeature互換性とSDK

  • OpenFeature はCNCFの オープン標準 フィーチャーフラグ管理仕様
  • Flagshipは OpenFeature完全互換 で、@cloudflare/flagship SDKを利用可能
  • Workers、Node.js、ブラウザ など複数のJavaScriptランタイムに対応
  • フラグプロバイダの切り替えは 設定1行の変更 で完了
  • SDKドキュメントや 導入ガイド も提供

ターゲティングルールとロールアウト

  • ユーザー属性 に基づく柔軟なフラグバリュー配信
  • 11種の 比較演算子、AND/ORグルーピング、シーケンシャル評価に対応
  • パーセンテージロールアウト で段階的な機能リリースが可能
  • 一貫したハッシュ処理で 同一ユーザーは常に同じフラグ値 を取得

多様なフラグバリエーション

  • フラグバリエーションは boolean、string、number、JSONオブジェクト に対応
  • オブジェクトバリエーションで 設定ブロック全体 を1つのフラグで配信可能

フラグ管理とインフラ

  • Cloudflareダッシュボードで フラグの作成・更新・削除 が可能
  • プロジェクトやサービス単位で アプリごとにフラグを整理
  • Workers とのネイティブ統合
  • KV Store を活用したグローバルなキー・バリューストレージインフラ

開発者向けサポート

  • Discordコミュニティ で質問や情報共有が可能
  • @CloudflareDev のTwitterアカウントで最新情報やアナウンスを配信

Hackerたちの意見

最近Cloudflareが調子いいね。ただ、細かい権限設定がまだ足りないかな。プロダクション用に別のアカウントを作らないといけないから、SSOがめちゃくちゃになるし、一つのドメインには一つのアカウントしか紐づけられないのが面倒。

└

そうそう！今日、もっと細かい権限設定を求めるサポートケースを開いたばかりだよ。

└

AWSを何年も使った後にCloudflareを試してみたけど、UXはすごく良かった。でも、同じ理由で結局戻っちゃった。もう少しで完璧なのにね。

└

みんなにプロダクションにアクセスさせちゃえばいいんじゃない？

└

彼らの製品はクールで、これまでずっと満足してるけど、最近ブログでちょっとしたミスがあったね。それに、信頼性に問題があったみたいだけど、最近は良くなってきた感じ。

└

これが本当に、実際の仕事で使うのをためらわせる理由なんだよね。趣味のための無料プランは大好きなんだけど。

└

前払いまたは支出制限オプションなしでは絶対に使わない。バグ、攻撃、ミスクリックで6〜7桁の請求書が来るなんて狂ってる。

└

うん、数年前に全部のプロジェクトで切り替えたけど、もう戻れないね。Workers、D1、R2、キュー、コンテナ、KV。メール送信はまだAWS使ってるから、それが来たら嬉しいな。

OpenFeatureは初めて知った、面白いね！これを統合した経験のある人いる？ https://openfeature.dev

└

かなり便利だよ。前の会社で使ってた。カスタムバックエンドを作ったけど、仕様書とSDKを使ったんだ。フルカスタムバックエンドを作るのに2週間くらいかかったかな。言語間のSDKも問題なく動いたよ（まあ、バグを一つ見つけて報告したら、その日のうちに修正されたけど）。

これはいいけど、まだこれが届くのを待ってるんだよね（皮肉なことに、これもFlagshipを使ってるかも）： https://blog.cloudflare.com/enterprise-grade-features-for-al... — まだエンタープライズ専用の機能が下位の（有料）アカウントに来たことはないと思う。特に興味があるのはこれだね： https://developers.cloudflare.com/speed/optimization/content...

└

そうそう、これ！ゼロトラストのエンタープライズ機能が必要で、実際に営業の人と話さなきゃいけなくなりそうなんだけど、それが時間を取られるし、避けたいストレスになるんだよね。

彼らのJS SDKのドキュメントを見てたら、こんな警告があったよ：> クライアントプロバイダーはフラグの値を取得するためにAPIトークンが必要です。このトークンは特定のアプリにスコープされていないため、トークンを持っている人はアカウント内のすべてのアプリでフラグを評価できます。公開アプリケーションでクライアントプロバイダーを使用する際は注意してください。 https://developers.cloudflare.com/flagship/sdk/client-provid... 誰かこれを明確にしてくれない？ブラウザにデプロイするために設計されたクライアントSDKが、なぜ注意が必要なの？これって、どんなクライアントでも新しいtargetingKeyでリクエストを送って、他のユーザーのフラグを観察できるってこと？フラグは重要な情報であるべきではないけど、これは興味深い設計選択に思える。

└

考えてみよう。これはおそらくCloudFlare内部で使われているもので、誰かが公開するのが面白いと思ったんじゃないかな。6ヶ月前にCloudFlareの誰かが、LaunchDarklyに対抗する製品を作るのが良いアイデアだと思ったとは考えにくい。

└

ジェーン・ウォンがこれを読んでよだれ垂らしてる。

└

こんにちは！Flagshipチームのエンジニアの一人だよ。アプリスコープのトークンは現在進行中だよ。

f(feature_name, context)のゼロネットワークホップの抽象化の力を過小評価しないで。コンテキストはあなたのニッチに極めて特化できるからね。特定のサプライヤーからの特定のユーザーのための特定の在庫、特定のビジネスモデルのサブタイプの特定のB2Bクライアント向けに、特定の時に特定の機能を見せるべきかどうか。自分のロジックを書けて、それを定数のように簡単かつ高性能でループ内で実行できるなら、ビジネスは信じられないほどアジャイルになるよ。顧客によってテキストが変わるかも？じゃあ、設定可能にするコードを書けばいいし、テストとフラグも無料で手に入る。残念ながら、そのゼロホップのセットアップには洗練されたクライアント実行エンジンが必要だけど、Cloudflareはここでは実装してないみたい。メモリ制約のあるワーカーには理にかなってるけど、従来のインフラにはあまり合わない。Statsigには私が好きなアプローチがあるよ：> これを実現するために、サーバーSDKはプロジェクトの全ルールセットをメモリに保持します - 各ゲートや実験のJSON表現です。クライアントSDKでは、initializeを呼び出すときにすべてのゲート/実験を評価します - 私たちのサーバー上で。 https://docs.statsig.com/sdks/how-evaluation-works 自分で作ることもできるよ - バックグラウンドスレッドで数秒ごとにルールセットをいくつかのデータ構造に同期させて、参照を原子的に入れ替えればいい。あとは適用ルールセットの次元に対するCRUDインターフェースが必要なだけ。誰がどの定数をいじれるかのガバナンスには気をつけてね。大きな力には大きな責任が伴うから。

└

いいアドバイスだね。機能フラグ、ABテスト、権利付与はそれぞれ別の概念ってことを覚えておくといいよ。このブログ記事（関係ないけど）は参考になると思ったよね： https://www.stigg.io/blog-posts/entitlements-untangled-the-m...

└

残念ながら、そのゼロホップのセットアップには高度なクライアント実行エンジンが必要だけど、Cloudflareではここに実装されていないみたい。メモリ制約のあるWorkersには理にかなってるけど、従来のインフラにはあまり意味がないね。え、何それ？ CF Workersではできないような論理が必要なの？

└

もうちょっと具体的に教えてくれる？

└

残念ながら、そのゼロホップ設定には高度なクライアント実行エンジンが必要だけど、Cloudflareはここではそれを実装してないみたい。高度である必要はないし、彼らが自分たちで実装する必要もないよ。クライアントライブラリにはシンプルなターゲティングルール評価エンジンが統合されてるOpenFeatureを利用してる。

└

Statsigは、うちの仕事でめっちゃうまくいってる。すごく洗練されていて、機能も豊富。使われていないフラグを削除候補として特定するためのツールもいい感じ。契約にある席ごとの課金はちょっと厳しいけど、なんとかやっていけるよ。

Cloudflareが他のプロバイダーを使わなきゃいけなかった機能を提供し始めると、いつもワクワクする。FunctionでStatsigを使ってたんだ。最初は2人で1つの製品に使ってたけど、12ヶ月以内に私たちの製品コピーやロールアウトの大部分がそれに基づいてた。Statsigはクライアントサイドの評価を持ってるから、Statsigのサーバーがユーザーデータを処理しなくても、内部の概念に基づいてルールやロールアウトを書ける。Cloudflareがここで洗練された製品を作ってくれることを願ってるよ、そうすれば将来的に他の製品を使わずに済むから！

└

サードパーティの機能フラグ使ってるの？全部自分で作るわけじゃないけど、機能フラグは自分で作るのに問題ないよ。

機能フラグって、しばしば過剰に設計されてることが多いよね。設定をチェックして、BDDの値や環境変数で動的にどちらかのパスに行く。それだけ。小さな機能があるか、コードをリファクタリングして高レベルで簡単に切り替えられるようにする必要があるよ。もし簡単にできないなら、複雑な機能フラグの実装が役立つかもしれないけど、マイクロサービス間で機能の有効化を調整するためにね。多くの機能があるなら、ダッシュボードも役立つかも。でも、どちらも機能フラグを避けるべきだっていう強いサインだと思う。ローカルで一時的な変更には向いてるけど、そうじゃないと複雑さが増して管理やメンテナンスが難しくなるよ。

└

特定のセグメント（例えば、イタリアの低収益ユーザー）に対して機能をオンにできるっていうのは、ビジネスやパフォーマンスへの影響を見られるから、確かに言えることだよね。もちろん、収益の閾値を超えたり国境を越えたらユーザーがその機能を失うのは避けたいから、何らかのトラッキングを実装する必要があるよ。アナリティクスやエラートラッキングも機能フラグサービスと連携する必要があるし。決してロケットサイエンスではないけど、環境変数よりは複雑だね。

└

フィーチャーフラグの大事なところは、ルールを守ることだね。目的を持って作って、価値がなくなったらすぐに取り除く。KISSの原則が当てはまるよ。

フィーチャーフラグって、いまいち理解できないんだよね。データベースのブール値と何が根本的に違うの？

└

それが全てだよ。これは、もっとCloudflareに縛り付けるために存在してるだけ。

└

いつもブール値ってわけじゃないよ。例えば、A/Bロールアウトにフィーチャーフラグが使われることが多い。Cloudflare自身も、まずは無料の顧客に新機能やビルドを提供して、その後に徐々に大きな顧客に展開してる。フィーチャーフラグは、ランダムにオンにすることもできて、いわゆるファズテストみたいなこともできる。単に「新しいもの」と考えないで、「変わった動作」として捉えることもできるよ。クライアントごとのブール値と考えることもできるけど、一般的にはそう実装されてないかな。

└

パーセンテージロールアウト、RBAC、監査履歴、A/Bテスト、多変量テスト…すぐに複雑になるよ。そのブール値は、維持管理しなきゃいけない全体のシステムに変わるんだ。

└

これは、もう少し文脈があるブール値だね。特定の地域にしか適用されないこともあるし、依存関係もあるかも：フラグXをオフにしたら、自動的にフラグYもオフになるみたいな。

└

これはただの実装の詳細で、フィーチャーフラグはデータベースのブール値で十分実装できるよ。私にとってフィーチャーフラグの主な魅力は、大きな機能に取り組むことができる点だね。これにはしばしば数ヶ月かかるし、多くのコミットが必要になるから。少なくとも私にとっては、より軽量で反復的な開発プロセスにつながるんだ。これは、大きな開発中の機能のために別のブランチや別のデプロイ先を維持するのとは対照的だね。

└

フラグ（ブーリアン、文字列、数字、その他何でも）は、実はそんなに難しい部分じゃないんだよね。問題は、ターゲティングやロールアウトのルール（つまり、誰がどのフラグを見るか）で、これが意外と複雑になりがち。自分で作った人は、プロダクトマネジメントやマーケティング、営業がもっと複雑なルールを使いたがることに気づくことが多いから、問題が大きくなっちゃうんだよね。全体的に見ればその問題は特に難しくはないと思うけど、実際には結構大きな問題で、一見すると分からないような多くの機能が必要になるんだ。追記: 複雑さを説明するのに別の例えを思いついた。機能フラグの本質は、実は権限管理システムなんだよね。特定のユーザーだけが特定の機能にアクセスできる。権限システムに関わったことがある人なら、その複雑さが分かると思う。グループメンバーシップ、階層的なグループ、役割、ACLなど、そういうものは機能フラグシステムで使われるさまざまなターゲティングルールに本当に似ている（というか、実際にはその一部だね）。

└

それに関するツールが問題なんだよね。どうやってブーリアンを設定して、フリートの5%のクエリに対してだけ真を返すようにするの？ どの5%のフリートなの？ それから、あらかじめ決めたペースで増やしていくの？ それとも、機能のプレビューグループにいる顧客にだけ真を返すようにする？ もしその5%のフリートで真が返されている部分がクラッシュしたり例外を投げたりしたら、データベースは自動的に偽を返すの？ それはあなたの可観測性スタックに接続されてるの？ 基本的には、データベースにブーリアンとして実装することはできるけど、他のスタックと連携しているツールがあるからこそ「機能フラグ」という名前に値するんだよね。

ゴールドプレートのブーリアン・アズ・ア・サービス

└

MVP

古い機能フラグをコードから安全に削除するサービスには喜んでお金を払うよ。