プロンプトとユースケース
再デプロイなしでチームが機能を切り替えられ、環境、ユーザーセグメント、割合（パーセンテージ）によるターゲティングをサポートし、設定サービスが利用できない場合でも安全性を維持できるフィーチャーフラグサービスを設計してください。フォローアップでは、低レイテンシ評価、監査性、承認、ロールバック、マルチリージョンでの可用性を扱う場合があります。
これはプラットフォームエンジニアリング、バックエンド、システムデザインの職種に適しています。公開されている面接ライブラリでは、毎秒数百万規模の評価と超低レイテンシを伴う類似のプロンプトが説明されています。公開されたプラットフォームエンジニアリングの面接レポートでは、コントロールプレーン、データプレーン、安全なロールアウト境界が強調されています。ランダムなコンポーネント名を挙げるのではなく、それらの決定事項に焦点を当ててください。
面接官が評価するポイント
- 書き込みが少なく読み取りが多い設定システムを、コントロールプレーンとデータプレーンに分割しているか。
- パーセンテージロールアウトが安定しており、リクエスト間でユーザーのバージョンが切り替わらないか。
- デフォルト値、有効期限、キルスイッチ、ロールバックによって、不正な設定の影響範囲（ブラスト半径）を制限しているか。
- 一貫性、レイテンシ、監査性、テナント分離のトレードオフを説明できているか。
回答前の明確化事項
評価をSDK、エッジノード、中央サービスのどこで実行するか、ターゲットが毎秒100万回の評価であるか、ターゲティングでユーザー、組織、リージョン、セッションのどれを使用するか、変更が反映されるまでの必要速度、各フラグにどのような安全なデフォルト値があるかを確認します。また、実験、緊急無効化、承認が必要かどうかも明確にしてください。
30秒での回答
フラグ作成、ルール、バージョン、承認、監査ログを担うコントロールプレーンを定義し、SDKまたはエッジキャッシュが公開されたスナップショットを取得してローカルで評価するデータプレーンを定義します。ルールは環境およびターゲットセグメントと一致させ、パーセンテージロールアウトには安定したサブジェクトハッシュを使用します。段階的にリリースし、アラームを監視して、自動的にロールバックします。コントロールプレーンがダウンしている場合は、期限付きの古いスナップショットまたはリスクに応じた安全なデフォルト値を使用します。
ステップバイステップのソリューション
コアデータモデル
フラグには、key、環境、デフォルト値、順序付けられたルール、バージョン、公開時刻、有効期限、監査メタデータが必要です。ルールは、組織、リージョン、ユーザー属性、またはパーセンテージバケットをターゲットにできます。ルールの順序は明示的でなければならず、最初に一致したものが優先されます。公開前に構文、型、セマンティックの競合を検証してください。
コントロールプレーンとデータプレーン
コントロールプレーンは、書き込み、承認、バージョニング、監査、公開を処理します。データプレーンは公開されたスナップショットのみを読み取り、それらを評価します。SDKはインメモリキャッシュを優先し、ポーリング、ストリーム、または通知を介して更新します。したがって、短時間のコントロールプレーンの障害によって、すべてのビジネスリクエストにネットワーク呼び出しが発生することはありません。
安定したロールアウトと安全なリリース
flagKey + stableSubjectId + salt をハッシュ化し、0から9999のバケットにマッピングします。露出が1%から5%、25%、50%、100%へと拡大しても、すでに許可されたユーザーは同じバージョンにとどまります。リリース前にルールと依存関係を検証し、リリース中はエラー、テールレイテンシ、ビジネスメトリクスを監視します。アラームが作動した場合は、最後に検証されたバージョンにロールバックします。
~~~text evaluate(flag, context, snapshot): rules = snapshot[flag].rules[context.environment] for rule in rules: if matches(rule.targeting, context): if rule.percentage is absent: return rule.value bucket = hash(flag.key + context.stableSubject + rule.salt) % 10000 if bucket < rule.percentage * 100: return rule.value return snapshot[flag].safeDefault ~~~
主なトレードオフ
| 選択肢 | メリット | コスト | 使用すべきケース |
|---|---|---|---|
| 中央評価 | 単一のルールソースと高速な更新 | リクエストごとのネットワーク依存 | 低スループットまたは厳格な一貫性 |
| ローカルSDK評価 | 低レイテンシとコントロールプレーンの分離 | より複雑な配信と安全なストレージ | 許容可能な古さ（bounded staleness）を持つ高QPS |
| エッジ評価 | ローカル応答とリージョン復元力 | 配信と無効化の難易度向上 | グローバルトラフィックとリージョン分離 |
AWS AppConfigには、バージョン、環境、デプロイ戦略、バリデーター、段階的ターゲティング、アラームベースのロールバックが文書化されています。これはリリースワークフローをシステムの一部として扱うことを裏付けるものですが、すべてのAWSコンポーネントを別の製品にそのままコピーする必要はありません。
模範回答
サービスをコントロールプレーンとデータプレーンに分割します。コントロールプレーンは、フラグ定義、ルール、バージョン、監査レコードを保存します。検証と承認の後、イミュータブル（不変）な公開スナップショットを生成します。SDKまたはエッジノードはそのスナップショットをキャッシュし、ローカルで評価することで、リクエストごとの中央サービスへの呼び出しを回避します。
パーセンテージロールアウトには安定したサブジェクト識別子を使用するため、露出が1%から25%に増加してもユーザーは1つのバージョンにとどまります。すべてのフラグには安全なデフォルト値と有効期限ポリシーがあります。アプリケーションが更新できない場合、期限切れでない最新のスナップショットを使用するか、フラグのポリシーに従ってリスクのある動作を無効にします。エラー率、P99レイテンシ、ビジネスメトリクスを監視しながら段階的に拡大し、アラーム発生時には自動的にロールバックします。ショートパスのキルスイッチによって緊急無効化を提供できますが、キャッシュの無効化、認可、監査性に関する明確なコストが伴います。
よくある間違い
- すべてのリクエストで中央の設定サービスを呼び出し、レイテンシの単一障害点にしてしまう。
- パーセンテージターゲティングに乱数を使用し、リクエスト間で同一ユーザーのバージョンが切り替わってしまう。
- バージョン、有効期限、監査データを省略し、誰が何をいつ公開したかを説明不能にしてしまう。
- 検証、ロールバック、安全なデフォルト値のないオン/オフAPIのみを設計してしまう。
- 個別のリスクポリシーなしに、結果整合性、キャッシュの古さの許容枠、緊急無効化を混同してしまう。
フォローアップ質問と回答
インスタンス間でユーザー体験の一貫性を保つにはどうすればよいですか？
すべてのインスタンスで同じ安定したサブジェクト識別子、フラグキー、ソルトを使用し、スナップショットバージョンを公開します。ランダムなリクエストIDでバケット分けしてはいけません。匿名トラフィックの場合は永続的なセッション識別子を使用し、その有効期間を定めます。
設定サービスがダウンした場合はどうなりますか？
データプレーンは期限切れでない最新のスナップショットを提供し続けます。TTL（有効期間）後はフラグのリスクポリシーに従い、安全なデフォルト値を返します。古い動作が可視化されるよう、SDKはスナップショットの経過時間、更新失敗、評価ソースを公開する必要があります。
危険な機能を無効化するにはどうすればよいですか？
高リスクのフラグに対して、通常のロールアウトよりも短いパスを持つ権限保護されたキルスイッチを提供します。緊急時であっても、オペレーター、理由、バージョン、影響範囲を記録します。
不正なターゲティングルールを防ぐにはどうすればよいですか？
公開前にスキーマ、型、競合、カバレッジのチェックを実行します。オフラインフィクスチャに対してルールを評価し、各ターゲットが期待されるブランチに到達することを確認します。高リスクの変更は、まずシャドウ環境またはごく小規模な環境でテストします。
複数リージョンをどのように処理しますか？
ローカルデータプレーンの読み取りを維持しながら、公開されたスナップショットをリージョンごとに複製します。すべてのスナップショットにバージョンと公開時刻を含め、リージョン間のバージョン差異を監視し、リージョンが更新できない場合はアラートを発報します。その間は以前の安全なスナップショットを引き続き使用します。
フィーチャーフラグを避けるべきなのはどのような場合ですか？
純粋な静的設定、1回限りの移行、またはトランザクションの一貫性を必要とする認可の決定は、フラグシステムに属さない可能性があります。フラグの数、ルールの複雑さ、有効期限の負債が増加した場合は、ランタイムルールが通常のリリース規律に取って代わらないよう、所有者、有効期限、クリーンアップメトリクスを割り当ててください。