この記事の途中に、以下の記事の引用を含んでいます。
High-Availability Feature Flagging at Databricks
サービス停止ゼロへの執念──Databricks SAFEが叶える「無停止・無事故」な機能フラグ運用とは？
今やあらゆる先端的なIT企業が、プロダクトのリリーススピードと品質向上を両立させるため、機能フラグ（Feature Flag）という手法を積極的に取り入れています。
しかし、その裏には「本当に止まらない」「事故が起きない」体制が求められます。
この記事では、クラウドデータ分析プロバイダー最大手の一つであるDatabricksが内部向けに開発したハイアベイラビリティな機能フラグプラットフォーム「SAFE」の思想・仕組み・苦労とその教訓を深堀りします。
エッジの効いたアーキテクチャや事例から、「大規模組織の継続的デリバリー運用のリアル」に迫り、みなさまの開発現場にも役立つヒントを考察します。
混沌から秩序へ──DatabricksによるSAFEの野心的な設計思想
まず、DatabricksがこのSAFEを設計した根本的な動機について、記事では次のように述べています。
“SAFE was started with the ‘north star’ goal of fully decoupling service binary releases from feature enablement, allowing teams to roll out features independently from their binary deployment. This allows for many side-benefits, like the ability to reliably ramp-up a feature to progressively larger populations of users, and quickly mitigate incidents caused by a rollout.”
この一文が示すように、SAFE最大の野望は「サービス本体のバイナリデプロイ」と「新機能有効化」の意思決定を完全に切り離し、より細かく・安全に・高速に機能をコントロールできるようにする点にあります。
この『分離』によって、バイナリリリースはあくまで“準備”にとどめ、本当の機能有効化は段階的かつ柔軟なフラグ操作で実施できる——これがSAFE流のリリース哲学です。
加えて、SAFEは単なる“機能切り替え”のための仕組みにとどまらず、次のような様々な用途に拡張されています。
“…SAFE is also used for other aspects of dynamic service configuration, such as: long-lived dynamic configurations (e.g. timeouts or rate limits), state machine control for infrastructure migrations, or to deliver small configuration blobs (e.g. targeted logging policies).”
つまり、タイムアウトやレート上限設定など“サービス構成の動的変更”や、システム移行時の状態管理・限定的な詳細監査ログ出力など、多彩なシナリオに応用されています。
この着眼点は、一般的なSaaS運用の成長過程で痛感されがちな「プロダクト設定管理の一元化・俊敏化」という観点から見ても、非常に示唆的です。
フィーチャーフラッグの次元を超えたスケーラビリティ：SAFEの数字が語るもの
Databricksの規模感を実感できる数字が次の記述です。
“As of late 2025, SAFE has approximately 25k active flags, with 4k weekly flag flips. At peak, SAFE runs over 300M evaluations per second, all while maintaining a p95 latency of ~10μs for flag evaluations.”
日本語で整理すると、2025年時点でアクティブなフラグは約2万5,000件、週あたり4,000件のフリップ（切り替え）がなされ、最大時には毎秒3億回以上の評価処理をしながら、p95（95%パーセンタイル）で10マイクロ秒という超低遅延を誇ります。
Flag数も評価頻度も、国内の多くの企業では想像がつかないスケールです。
しかもこの「膨大な旗振り」の中で、そのほとんどが事故なく回っている事実こそ、SAFE最大の偉業でしょう。
これはエンタープライズSaaSとして「すべての顧客に影響を与えるかもしれない設定変更」という難題を、仕組みでどう乗り越えたのか？を示しています。
アーキテクチャの深層解剖：SAFEが実現した4つの技術的工夫
SAFEがこの目を見張る運用安定性を実現できる理由は、主に以下4つの設計思想の組み合わせにあります。
1. SDKによる「評価」と「配信」の完全分離
SAFEのSDKは、「現在の設定評価＝超高速」「設定更新デリバリ＝非同期・バックグラウンド」という形で徹底的に分離設計されています。
“Separation of delivery from evaluation: The SAFE client libraries always treat delivery as an asynchronous process, and never block the ‘hot path’ of flag evaluation on configuration delivery. … Once delivered, the SAFE SDK can use the new configuration during evaluation.”
この非同期デリバリ設計は、多くの一般的なFeature Flagサービスで発生しがちな“配信失敗による評価遅延”や“ダウンタイム多発”のリスクを根本的に回避しています。
2. 「静的」／「動的」次元の先行評価（Pre-Evaluation）
SAFEは評価処理の低遅延化のために、静的な条件（例：クラウドリージョン、実行環境等）はフラグ受信時点でSDK内で先行計算を済ませ、リクエストごとに変わる動的条件だけ後から評価します。
“To reliably achieve sub-millisecond evaluation latency at scale, SAFE employs preevaluation of parts of the boolean expression tree which are static.”
これにより、多くのフラグでは評価時の処理自体がほぼ「O(1)」で収まるため、評価パスに一切ブロックが生じず、最悪でも古い（キャッシュ済み）設定にフォールバックし続けるという作りになっています。
3. 配信障害でも「サービスは絶対止めない」設計
“If anything in the delivery path results in a failure to update configurations, services simply continue serving their last known configuration until the delivery path is restored. This ‘fail static’ approach ensures that existing service behavior remains stable even during upstream outages.”
いわゆる「fail static」（現状維持による安定担保）アプローチとともに、以下の多重冗長設計も盛り込まれています：
- 緊急アウトオブバンド配信（通常経路外から直接SAFE Backendへ強制反映）
- リージョンレベルの冗長配信
- 「コールドスタート」バンドル配布（サービス起動時用の遅延反映も許容）
これにより、設定配信のどこかが壊れても「サービス本体が不可逆にダウンしない」強靭さを備えています。
4. フラグ変更のガバナンス強化とUX重視
SAFEではすべてのフラグ変更がGitHub PR経由で行われ、専用のプリマージバリデータ（チェック）が多数用意されています。
事故防止策（例：影響範囲が広い変更は追加レビュー必須、バイナリ更新未反映時の有効化禁止等）が徹底されています。
さらに、内部UIも「紧急時に誰でも安全・迅速にフラグ切替できる」「作法を守った方がラク・便利」と感じさせる設計が随所に施されています。
“Developer experience is paramount. Scaling the ‘people aspect’ of a robust flagging system required a strong UX focus. … building a user-friendly UX for flipping flags during emergencies was high leverage.”
「技術」だけでは成功しない──SAFE運用から見える“文化と仕組み”のインタープレイ
SAFEが単なる技術的巧妙さだけでなく“組織文化を推進するエンジン”となっている点にも注目です。
記事中で次のような教訓が語られています。
“Make ‘best practices’ the low-friction route. … SAFE makes the safe path the easy path: gradual rollouts require less effort and have more quality-of-life features available than riskier enablement patterns.”
ここでは「ベストプラクティスの強制は意味がない。本当に安全なやり方のほうが“楽”なら、エンジニアは自然と従うようになる」ことが実体験から強調されています。
日本においても、「紙のルール」「面倒な承認プロセス」「属人的な運用」でガバナンスを保とうとする組織は少なくありません。
SAFEのように、仕組みそのもので「安全・堅牢・ラク」を提供できれば、自然と文化が標準化・改善されていきます。
これはFeature Flag運用に限らず、CI/CDやIaC（Infrastructure as Code）、RBACなど多くの現場改善にも共通する普遍的な教訓です。
私の考察：「組織×技術」の両輪で信頼性を高めるには？
SAFE運用から私が強く感じたのは、「信頼性向上＝技術力 × 組織運用力」の掛け算こそが本質ということです。
とりわけFeature Flagの世界では、「旗を切り替える」こと自体は単なるif文の分岐に見えがちですが、
- その「旗の振り方」から「配布」「監査」「緊急復旧」まで一貫して“想定しうる障害を許容する”
- 「危ないやり方や個別最適なやり方」を自然と回避させる仕組みの洗練度
こそが本物の運用基盤の実力差になります。
実際、日本の大企業でも手作業による設定反映や属人的なフィーチャーフラグ配信が“ブラックボックス”になり、事故時の対応が後手に回ることが少なくありません。
また、「どこかで設定反映が失敗したとき、何が起こるか？」という観点が抜け落ちている例も多いです。
SAFEの事例は、たとえば数万人のクライアントを一斉に巻き込むプロダクト群でも「平常稼働」を貫き、「準備完了後」に自信を持って新機能をロールアウトできるという信頼の本質を示しています。
また、“静的／動的”条件分離や非同期バックグラウンド配信、意図的な“fail static”設計などは、どんな組織でも段階的に取り入れられる普遍的ノウハウです。
明日から活かせるベストプラクティス──SAFE事例から学ぶ「持続的改善」のポイント
SAFEという巨大な舞台裏から日本の技術者が持ち帰るべき教訓をまとめます。
- 仕組みそのもので、安全な行動様式へ「自動的に」誘導するUX設計を目指すこと
- ダウンタイム「ゼロ」を妥協せず、配信失敗時の“現状維持”と複数段の冗長系構築
- 設定反映のレビューからフラグ有効化判断、配信障害時の緊急手当まで“現実的運用”を貫く
- 機能管理だけでなく、パラメータ設定や移行フロー・監査ログ出力など、構成変更全体への応用視点
- 人の作法に頼らず、“安全が一番ラク”になる設計を追求し、文化変革を支援する
あなたの現場でも、小さな機能フラグ管理から始めて、段階的に評価・リファクタリング・運用改善を重ねていくことで、近い将来SAFEのような堅牢な基盤を形作ることが可能です。
現場のリアルな困りごとを「仕組みのレイヤ」で徹底的に抽象化・自動化していくという発想、それが世界標準の一歩です。
categories:[technology]
コメント