要点: Feature Flagは一時的Controlであり、OwnerとExpiryがなければ第二のCodebaseになります。
課題
Flag組合せ、SDK Version差、未訓練Kill Switchが不整合を作ります。
単純な対策だけでは不十分な理由
DeployとReleaseを分離しCanaryと即時停止を可能にします。
Entitlement Flagには強いAuditが必要です。
処理フロー
Control Plane
Version Policy→SDK Snapshot
Local Evaluation→Application
Flag Decision→Telemetry
Exposure・Outcome
Version Policy→SDK Snapshot
Local Evaluation→Application
Flag Decision→Telemetry
Exposure・Outcome
アーキテクチャ上の判断
Purpose別Type
Release、Experiment、Kill Switch、Entitlementを分けます。
Local Evaluation
Signed Snapshotで中央依存を避けます。
Exposure記録
実到達時のVariantを記録します。
さらに深く考える
両Variant互換
Code、Schema、Eventで互換を維持します。
組合せ制限
Dependencyと排他を定義します。
実装手順
- FlagをPurpose別に分類します。
- Owner、Expiry、Safe Defaultを必須化します。
- 安定CohortでSLOとOutcomeを比較します。
技術例: Typed Flag Declaration
flag checkout_v2 {
type: RELEASE
owner: commerce-team
expires: 2026-08-31
default: CONTROL
targeting: stableHash(tenantId)
}ValidatorでOwner、Default、Expiryを強制します。
想定すべき障害パターン
- Service間Versionが違います。
- 破壊MigrationはFlagで戻りません。
- 未Exposure UserをExperimentに数えます。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| Version別Exposure | 実Code Pathを示します。 |
| Variant別SLO | Rollout判断です。 |
| Flag Age | Debtを測ります。 |
設計の検証方法
- SDK間Variantを比較します。
- Control Plane停止を試験します。
- Kill SwitchをLoad下で訓練します。
安全なRollout計画
Typed Registry、Exposure、CI Expiryの順で導入し、Riskの高いKill Switchから移行します。
本番前チェックリスト
- 同Subjectは同Variantです。
- Failure Defaultを定義します。
- Expired FlagをCIで止めます。
まとめ
FlagはDecisionを観測しLifecycleを終える時だけReleaseを安全にします。