Databricksにおける高可用性機能フラグ

信頼性を維持しながらソフトウェアを迅速に提供することは、常に課題となります。Databricksの成長に伴い、数百のサービス、複数のクラウド、数千もの顧客のワークロードにわたって変更を安全に展開する複雑さも増してきました。機能フラグは、コードをデプロイするという決定と、それを有効化するという決定を分離することで、この複雑さを管理するのに役立ちます。この分離により、エンジニアはリリース速度を犠牲にすることなく、障害を特定し、インシデントをより迅速に軽減できます。

Databricks の安定性戦略における重要な要素の 1 つは、「SAFE」と呼ばれる社内の機能フラグおよび実験プラットフォームです。Databricks のエンジニアは、機能のロールアウト、サービスの動作の動的な制御、A/B エクスペリメントによる機能の有効性の測定のために、日常的に SAFE を使用しています。

背景

SAFEは、サービスバイナリのリリースと機能の有効化を完全に分離し、チームがバイナリのデプロイとは独立して機能をロールアウトできるようにするという「北極星」とも言える目標を掲げて開始されました。これにより、機能を徐々により多くのユーザー集団に確実にランプアップしたり、ロールアウトによって引き起こされたインシデントを迅速に軽減したりするなど、多くの副次的なメリットがもたらされます。

急速に拡大する製品の対象領域を持ち、複数のクラウドにまたがって数千社のエンタープライズ顧客にサービスを提供する Databricks の規模では、当社独自の要件を満たすことができる機能フラグシステムが必要でした。

• 安全性と変更管理の高い基準。SAFEの主な価値提案はDatabricksの安定性と運用体制を向上させることであったため、他の要件のほぼすべてはこれに由来しています。
• Azure、AWS、GCP にわたるマルチクラウドでのシームレスなグローバル配信と、高スループットでレイテンシーに敏感な本番サービスをサポートするためのサブミリ秒のフラグ評価レイテンシー。
• コントロールプレーン、Databricks UI、Databricks Runtime Environment、DatabricksのServerlessデータプレーンなど、Databricksのエンジニアがコードを記述するすべての場所に対する透過的なサポート。
• 一般的なフラグリリースを "safe by default" にするほど Databricks のリリースプラクティスに特化した明確な方針を持ちつつ、より専門的な多数のユースケースをサポートする柔軟性も備えたインターフェース。
• フラグ定義がロードされないとサービスを安全に起動できないため、非常に厳格な可用性要件があります。

これらの要件を慎重に検討した結果、最終的に社内でカスタムの機能フラグシステムを構築することを選択しました。当社のアーキテクチャとともに進化でき、何百ものサービスと何千人ものエンジニアにわたってフラグを安全に管理するために必要なガバナンス制御を提供するソリューションが必要でした。スケーリングと安全性の目標を達成するには、インフラストラクチャのデータモデル、サービスフレームワーク、および CI システムとの緊密な統合が必要でした。

2025年後半現在、SAFEには約25,000のアクティブなフラグがあり、週に4,000回のフラグフリップが行われています。ピーク時、SAFEは毎秒3億回以上の評価を実行し、その際、フラグ評価のp95レイテンシを約10μsに維持しています。

この記事では、これらの要件を満たすためにどのように SAFE を構築したか、そしてその過程で得られた学びについて探ります。

機能フラグの活用

まず、SAFE フラグの一般的なユーザージャーニーについて説明します。機能フラグの核となるのは、外部設定で制御される条件に応じて異なる値を取ることができる、サービスの制御フロー内でアクセス可能な変数です。機能フラグの非常に一般的なユースケースの 1 つは、まず少量のトラフィックから始め、徐々にグローバルに有効にしていくという、制御された方法で新しいコードパスを段階的に有効にすることです。

SAFEのユーザーは、まずサービスコード内でフラグを定義し、それを新機能のロジックへの条件付きゲートとして使用します。

その後、ユーザーは社内の SAFE UI に移動し、このフラグを登録して、フラグをロールアウトするためのtemplateを選択します。このテンプレートは、順序付けられたステージのリストで構成される段階的なランプアップ計画を定義します。各ステージはパーセンテージによってゆっくりとランプアップされます。フラグが作成されると、ユーザーには次のような UI が表示されます。

ここから、ユーザーはフラグを一度に1ステージずつ手動でロールアウトするか、スケジュールを設定してフラグフリップを自動的に作成させることができます。内部的に、フラグ設定の信頼できる唯一のソースは、フラグ設定を管理するために軽量ドメイン固有言語(DSL)を使用する、Databricksモノレポにチェックインされたjsonnetファイルです:

ユーザーがUIからフラグを変更すると、その変更の出力はプルリクエストとなり、少なくとも他の1人のエンジニアによるレビューが必要になります。SAFEはまた、安全でない変更や意図しない変更を防ぐために、さまざまなマージ前チェックを実行します。変更がマージされると、PR のマージから 2～5 分以内にユーザーのサービスがその変更を検出し、新しい値の出力を開始します。

ユースケース

機能のロールアウトに関する上記のユースケースに加えて、SAFE は、長期的な動的構成（例: ）など、動的サービス構成の他の側面にも使用されます。タイムアウトやレート制限）、インフラストラクチャ移行のステートマシン制御、または小さな設定 BLOB を配信するために（例:ターゲットを絞ったログ記録ポリシー）。

アーキテクチャ

クライアントライブラリ

SAFEは、内部でサポートされている複数の言語でクライアント「SDK」を提供しており、中でもScala SDKは最も成熟し、広く採用されています。SDKは本質的に、設定読み込みコンポーネントと組み合わせた基準評価ライブラリです。各フラグには、ランタイム時にSDKが返す値を制御する一連の基準があります。SDKは最新の設定セットの読み込みを管理し、ランタイムにその基準を評価した結果を迅速に返す必要があります。

疑似コードでは、基準は内部的に次のようになります。

この基準は、一連のBoolean式ツリーのようなものとしてモデル化できます。迅速な結果を返すために、各条件式を効率的に評価する必要があります。

パフォーマンス要件を満たすために、SAFE SDK の設計にはいくつかのアーキテクチャ原則が具体化されています。(1) 構成の配信と評価の分離、および (2) 静的評価ディメンションとランタイム評価ディメンションの分離です。

1. 配信と評価の分離: SAFE クライアント ライブラリは、配信を常に非同期プロセスとして扱い、設定の配信でフラグ評価の「ホットパス」をブロックすることはありません。クライアントがフラグ設定のスナップショットを取得すると、非同期のバックグラウンド プロセスがそのスナップショットをより新しいスナップショットにアトミックに更新するまで、そのスナップショットに基づいて結果を返し続けます。
2. ディメンションタイプの分離: SAFEでのフラグ評価は、2種類のディメンションで動作します。
   • 静的ディメンションは、実行中のバイナリ自体の特性、例えばクラウドプロバイダー、クラウドリージョン、環境(dev/staging/prod)などを表します。これらの値は、プロセスの実行中は一定のままです。
   • ランタイム ディメンションは、ワークスペース ID、アカウント ID、アプリケーションから提供される値、評価ごとに異なるその他のリクエストごとの属性など、リクエスト固有のコンテキストをキャプチャします。

大規模環境でサブミリ秒の評価レイテンシーを確実に達成するために、SAFE は静的なBoolean式ツリーの一部の事前評価を採用しています。SAFE 設定バンドルがサービスに配信されると、SDK はフラグ設定のメモリ内表現に対してすべての静的ディメンションを即座に評価します。これにより、その特定のサービス インスタンスに関連するロジックのみを含む、簡略化された設定ツリーが生成されます。

リクエスト処理中にフラグ評価が要求された場合、SDK はこのプリコンパイルされた構成に対して、残りのランタイム ディメンションのみを評価する必要があります。これにより、各評価の計算コストが大幅に削減されます。多くのフラグはブール式ツリーで静的ディメンションのみを使用するため、多くのフラグは事実上完全に事前評価できます。

フラグ配信

Databricks のすべてのサービスに設定を確実に配信するために、SAFE は社内の動的設定配信プラットフォームである Zippy と連携して動作します。Zippy アーキテクチャの詳細な説明は別の記事に譲りますが、要するに、Zippy は多層のグローバル/リージョン アーキテクチャとクラウドごとの Blob Storage を使用して、中央ソースから（他のサーフェスに加えて）Databricks コントロールプレーンで実行されているすべての Kubernetes ポッドに任意の構成 BLOB を転送します。

デリバリーされたフラグのライフサイクルは次のとおりです。

1. ユーザーは、いずれかのフラグ設定のjsonnetファイルに対してPRを作成してマージします。そのPRは、その後GithubのDatabricksモノレポにマージされます。
2. 約1分以内に、マージ後のCIジョブが変更されたファイルをピックアップしてSAFEバックエンドに送信し、その後SAFEバックエンドは新しい設定のコピーをデータベースに保存します。
3. 定期的に（約 1 分間隔で）、SAFE バックエンドはすべての SAFE フラグ設定をバンドルし、Zippy グローバル バックエンドに送信します。
4. Zippy Globalはこれらの設定を各Zippy Regionalインスタンスに約30秒以内に配布します。
5. 各サービスポッドで実行されている SAFE SDK は、プッシュベースとプルベースの配信を組み合わせて、新しいバージョンのバンドルを定期的に受信します。
6. 配信されると、SAFE SDK は評価中に新しい設定を使用できます。

エンドツーエンドで、フラグの変更は通常、PR がMergeされてから 3～5 分以内にすべてのサービスに伝播します。

フラグ設定パイプライン

フラグ配信パイプライン内で、フラグ設定は、評価が近づくにつれて、高レベルで人間が読めるセマンティックな設定から、コンパクトで機械が読めるバージョンへと徐々に変換され、複数の形式を取ります。

ユーザー向けのインターフェースでは、フラグは Jsonnet とカスタム DSL を使用して定義され、任意に複雑なフラグ構成を可能にします。この DSL には、事前定義されたテンプレートを使用してロールアウトするようにフラグを構成したり、トラフィックのスライスに特定のオーバーライドを設定したりするなど、一般的なユースケースのためのアフォーダンスがあります。

チェックインされると、このDSLは内部のprotobufの同等物に変換され、設定のセマンティックな意図をキャプチャします。次にSAFEバックエンドは、このセマンティックな設定をさらにBoolean式ツリーに変換します。このBoolean式ツリーのprotobuf記述はSAFE SDKに配信され、SDKはそれをさらに圧縮された設定のインメモリ表現にロードします。

UI

ほとんどのフラグの切り替えは、SAFEフラグを管理するための内部UIから開始されます。このUIを使用すると、ユーザーはワークフローを通じてフラグの作成、変更、廃止を行うことができます。このワークフローは、簡単な変更についてはJsonnetの複雑さの多くを抽象化しつつ、高度なユースケース向けにDSLのほぼすべての機能へのアクセスを提供します。

リッチな UI によって、フラグの切り替えのスケジューリング、merge後のヘルスチェックのサポート、特定のリージョンやサービスに影響を与えた最近のフラグの切り替えを特定するためのデバッグツールなど、QOL (Quality of Life) を向上させる追加機能も提供できるようになりました。

フラグ設定のレビュー

すべての SAFE フラグの変更は、通常の Github PRとして作成され、広範なマージ前バリデーターのセットを使用して検証されます。潜在的に安全でないフラグ変更から保護するための最善の方法について学習を重ねるにつれて、このバリデーターのセットは、数十の個別のチェックを含むまでに成長しました。SAFE の初期導入時には、SAFE フラグの切り替えによって引き起こされた、または軽減されたインシデントの事後レビューが、これらのチェックの多くに情報を提供しました。現在では、たとえば、影響範囲の大きい変更には専門的なレビューを要求したり、フラグを有効にする前に特定のサービス バイナリ バージョンをデプロイする必要があるようにしたり、微妙で一般的な構成ミスのパターンを防いだりするなどのチェックがあります。

チームは、設定の不変条件を適用するために、独自のフラグまたはチーム固有のマージ前チェックを定義することもできます。

障害モードへの対処

サービスの安定性における SAFE の重要な役割を考えると、このシステムは、配信パイプラインの一部に障害が発生した場合でも継続的な運用を保証するために、複数の回復性レイヤーを持つように設計されています。

最も一般的な障害シナリオは、設定配信パスの中断を伴います。デリバリーパスで何らかの理由で設定の更新に失敗した場合でも、サービスはデリバリーパスが復旧するまで、最後に認識された設定で提供を続けます。この「フェイルスタティック」アプローチにより、アップストリームで障害が発生している間でも、既存のサービスの動作の安定性が保証されます。

より深刻なシナリオに備えて、複数のフォールバック メカニズムを維持しています。

1. 帯域外配信: CI または Github プッシュパスのいずれかが利用できない場合、オペレーターは緊急ツールを使用して SAFE バックエンドに構成を直接プッシュできます。
2. リージョナルフェイルオーバー: SAFEバックエンドまたはZippy Globalがダウンした場合、オペレーターは一時的に設定をZippy Regionalインスタンスに直接プッシュできます。サービスは、単一のZippy Regionalの停止による影響を緩和するために、リージョンをまたいでポーリングすることもできます。
3. コールドスタートバンドル: サービス起動中にZippy自体が利用できない場合に対処するため、SAFEはアーティファクトレジストリを介して定期的に設定バンドルをサービスに配布します。これらのバンドルは数時間古い場合もありますが、ライブ配信でブロックされるのではなく、サービスが安全に起動するための十分なバックアップを提供します。

SAFE SDK自体の中では、防御的設計によって、設定エラーの影響範囲が限定されるようになっています。特定のフラグの設定に不備がある場合、影響を受けるのはその単一のフラグのみです。SDKはまた、例外をスローせず、常にコードのdefault値にフォールオープンするという規約を維持するため、アプリケーション開発者はフラグ評価を失敗する可能性があるものとして扱う必要がありません。SDKはまた、設定のパースまたは評価で障害が発生した場合、オンコールのエンジニアに即座にアラートを送信します。SAFEの成熟度と広範なマージ前の検証により、現在、このような障害が本番運用で発生することは極めてまれです。

この回復性に対する階層型アプローチにより、SAFE はグレースフルにデグレードし、単一障害点になるリスクを最小限に抑えます。

学んだ教訓

依存関係の最小化と階層化された冗長なフォールバックにより、運用上の負担が軽減されます。Databricks のほぼすべてのコンピュート サーフェスにデプロイされ、頻繁に使用されているにもかかわらず、SAFE の維持にかかる運用上の負担はかなり管理しやすいものでした。コールドスタートバンドルや SDK の "fail static" 動作などの階層的な冗長性を追加することで、SAFE アーキテクチャの多くが自己修復可能になりました。

開発者エクスペリエンスが最重要です。堅牢なフラグシステムの「人的側面」をスケーリングするには、UXに強く焦点を当てる必要がありました。SAFEはミッションクリティカルなシステムであり、インシデントを軽減するためによく使用されます。そのため、緊急時にフラグを切り替えるためのユーザーフレンドリーなUXを構築することは、非常に効果的でした。製品中心の考え方を採用した結果、細かな問題や混乱が減り、最終的にはインシデントに対する全社的な平均復旧時間 (MTTR) の短縮につながりました。

「ベストプラクティス」を最も簡単な方法にする。最大の学びの 1 つは、ベストプラクティスを文書化するだけでは、エンジニアがそれに従うことを期待できないということでした。エンジニアは、機能をリリースする際に、多くの競合する優先事項を抱えています。SAFEは、安全な方法を簡単な方法にします。リスクの高い有効化パターンに比べ、段階的なロールアウトは手間がかからず、利便性を向上させる機能がより多く利用できます。システムがより安全な行動を奨励する場合、プラットフォームはエンジニアを責任ある変更管理の文化へと導くことができます。

現状と今後の課題

SAFEは現在、Databricks内の成熟した内部プラットフォームとなり、広く使用されています。可用性と開発者エクスペリエンスへの投資は、SAFEフラグの使用を通じて、平均解決時間と本番運用インシデントの影響範囲の両方が継続的に削減されるという形で成果を上げています。

Databricksの製品の対象領域が拡大し続けるにつれて、それらの製品の基盤となるインフラストラクチャプリミティブも、その範囲と複雑さの両方で拡大しています。その結果、Databricksのエンジニアがコードを記述してデプロイするすべての場所をSAFEがサポートできるように、大規模な継続的投資が行われてきました。

このようなミッションクリティカルなインフラストラクチャのスケーリングに興味がある方は、ぜひDatabricksの募集中のポジションをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事