기능 플래그 및 기능 릴리스
FF (Feature Flag) 는 코드를 해제하지 않고 시스템 동작을 가능/비활성화하는 관리 조건입니다 플래그를 사용하면 기능을 안전하게 출시하고 사용자/시장/테넌트 그룹을 대상으로하며 문제가있는 구성 요소를 신속하게 비활성화하고 실험을 수행하며 런타임에 매개 변수를 구성 할 수 있습니다.
주요 목표:- 방출에 대한 폭발 반경을 줄입니다.
- 별도의 배포 및 활성화.
- 감사, SLO 및 원 클릭 롤백으로 투명한 변경 관리를 허용합니다.
1) 깃발의 종류와 적용 시점
릴리스 플래그 - 새로운 기능의 단계적 포함 (어두운 → 카나리아 → 램프 업 → 100%).
Ops/kill-switch-종속성의 즉각적인 단절 (공급자, 서브 시스템, 대량 계산).
실험 (A/B, 다변형) - 트래픽을 변형 (무게, 끈적 끈적한 버킷) 으로 나눕니다.
권한/권한-역할/계획/관할권별로 기능에 액세스 할 수 있습니다.
원격 설정 - 플래그/설정의 동작 파라미터 (임계 값, 타임 아웃, 공식).
마이그레이션 플래그 - 체계/데이터 경로 전환 (새 인덱스/DB/엔드 포인트로 이동).
패턴 방지: "모든 것에 대해" 동일한 플래그-기능, comp 스위치 및 매개 변수로 나뉩니다.
2) 플래그 데이터 모델 (최소)
yaml flag:
key: "catalog. new_ranker"
type: "release" # release ops kill experiment permission config migration description: "New Directory Ranking"
owner: "search-team@company"
created_at: "2025-10-01T10:00:00Z"
ttl: "2026-01-31" # delete deadline after 100% enable rules:
- when:
tenant_id: ["brand_eu","brand_latam"]
region: ["EE","BR"]
user_pct: 10 # progressive percentage then: "on"
- when:
kyc_tier: ["unverified"]
then: "off"
variants: # for experiments
- name: "control"; weight: 50
- name: "v1"; weight: 30
- name: "v2"; weight: 20 payload:
v1:
boost_freshness: 0. 3 boost_jackpot: 0. 2 v2:
boost_freshness: 0. 2 boost_jackpot: 0. 4 prerequisites: # dependent flags/schema versions
- key: "catalog. index_v2_ready"
must_be: "on"
audit:
require_ticket: true change_window: "09:00-19:00 Europe/Kyiv"
safeguards:
max_rollout_pct: 50 # stop threshold auto_rollback_on:
p95_ms: ">200"
error_rate: ">2%"3) 평가 및 타겟팅
차이나, 지역/라이센스, 통화, 채널, 로케일, 역할, 계획, 장치, 사용자 _ id, 코호트, kyc _ tier, 실험 _ bucket.
평가 순서: 전제 조건 → 규칙 거부 → 규칙 → 규칙 → 기본값을 허용합니다.
끈적 끈적한 버켓: 실험의 경우 사용자가 항상 하나의 옵션을 얻을 수 있도록 안정적인 식별자 (예: 'hash (user _ id, flag _ key)') 를 해시하십시오.
ts result = evaluate(flag, context) // pure function if (!prereqs_ok(result)) return OFF if (deny_match(result, ctx)) return OFF if (allow_match(result, ctx)) return resolve_variant_or_on(result, ctx)
return flag. default4) FF 분포 및 아키텍처
옵션:- 서버 측 SDK (권장): 백엔드의 진실 및 캐시 소스; 논리의 통일.
- 가장자리/CDNA 평가: 주변에서 빠른 타겟팅 (PII/비밀이없는 경우).
- 클라이언트 측 SDK: UI 개인화가 필요한 경우 최소한의 컨텍스트와 민감한 규칙이 없습니다.
- 코드로 설정: CD를 통한 저장소, CI 검증, 롤아웃에 플래그를 저장합니다.
- 스타트 업 부트 스트랩 + 스트리밍 업데이트 (SSE/gRPC) + 마지막 스냅 샷에 대체.
- SLA "신선도" 플래그: p95 소 5 초
5) 릴리스 전략
5. 1 어두운 발사
이 기능은 활성화되었지만 사용자에게는 보이지 않습니다 메트릭 및 오류를 수집합니다.
5. 2 카나리아
우리는 하나의 관할권/임차인에 1-5% 의 트래픽을 포함합니다. 모니터 p95/p99, 오류, 변환.
정지 조건-메트릭에 의한 오토 카토프 임계 값 트리거.
5. 3 프로그레시브 롤 아웃
수동/자동 검증으로 예약 된 10% → 25% → 50% → 100%.
5. 4 그림자/미러 링
명백한 효과없이 새로운 경로에 대한 요청을 복제하고 결과/대기 시간을 비교합니다.
5. 5 파란색/녹색 + FF
우리는 두 가지 버전을 배포합니다. 플래그는 트래픽을 조종하고 세그먼트별로 종속성을 전환합니다.
6) 의존성 및 교차 서비스 일관성
준비 상태의 전제 조건과 "건강 플래그" 를 사용하십시오. 색인이 작성되고 마이그레이션이 완료됩니다.
이벤트를 통한 조정: 'FlagChanged (flag _ key, scope, New _ state)'.
중요한 시나리오의 경우 2 단계 전환을 사용하십시오
1. 읽기 경로 → 2) 확인 메트릭 → 3) 작성/부작용을 가능하게합니다.
서비스 계약: 기본값은 안전하지 않은 OFF 여야합니다.
7) 관찰 및 SLO
플래그/변형/세그먼트 당 메트릭:- 'flag _ eval _ p95 _ ms', 'ormes _ rate', 'sign _ freshness _ ms'.
- 비즈니스 지표: 'ctr', '변환', 'ARPU', '유지', 가드 레일 (예: RG 사건).
- 오토 카토파의 자동 SLO 임계 값.
로그/추적: 'flag _ key', 'variant', 'decision _ source' (서버/에지/클라이언트), 'contact _ hash' 를 추가하십시오.
대시 보드: 임계 값이있는 롤아웃 "래더", 세그먼트 별 히트 맵 오류.
8) 안전 및 준수
맥락에서 PII 최소화.
RLS/ACL: 도메인/시장별로 플래그를 변경할 수있는 사람.
민감한 플래그에 대한 시간 변경 창 (창 변경) 및 "이중 확인".
불변의 감사: 누가/언제/무엇/왜 (티켓/사건 링크).
관할권: 깃발은 규제 금지를 우회해서는 안됩니다 (예: 금지 된 국가에서의 경기 포함).
9) "장수" 플래그 관리
각 플래그에는 TTL/삭제 날짜가 있습니다.
100% 포함 된 후-코드 브랜치를 삭제하는 작업을 만듭니다. 그렇지 않으면 "플래그 부채" 가 증가합니다.
깃발을 '마이그레이션 '/' 일회성' 으로 표시하고 상수 '허가/설정' 과 분리하십시오.
10) 샘플 계약 API/SDK
평가 API (서버 측)
http
POST /v1/flags/evaluate
Headers: X-Tenant: brand_eu
Body: { "keys":["catalog. new_ranker","rgs. killswitch"], "context": { "user_id":"u42", "region":"EE" } }
→ 200
{
"catalog. new_ranker": { "on": true, "variant":"v1", "as_of":"2025-10-31T12:10:02Z" },
"rgs. killswitch": { "on": false, "variant":null, "as_of":"2025-10-31T12:10:02Z" }
}클라이언트 SDK (또는 대체, 대체)
ts const ff = await sdk. getSnapshot() // bootstrap const on = ff. isOn("catalog. new_ranker", ctx)
const payload = ff. payload("catalog. new_ranker", "v1")11) 다른 회로와의 상호 작용
요율 제한/할당량: 플래그는 사고 기간 동안 RPS/활성화 스로틀링을 낮출 수 있습니다.
회로 차단기/분해: 킬 스위치는 무거운 경로를 비활성화하고 분해를 가능하게합니다.
디렉토리/개인화: 깃발은 가중치/순위 규칙을 변경합니다 (원격 설정을 통해).
데이터베이스 마이그레이션: 플래그는 점차 읽기/쓰기를 새로운 체계로 번역합니다 (읽기-복제본 → 이중 쓰기 → 쓰기 기본).
12) 플레이 북 (런북)
1. 25% 포함 후 사건
Autocatoff는 모든/세그먼트, 통화 티켓, 통계 수집, RCA에 대해 → OFF 플래그를 트리거했습니다.
마이그레이션 플래그를 통해 일시적으로 저하/오래된 분기를 활성
2. p95 카탈로그 성장
임계 값 'p95 _ ms> 200' - 오토 카토프; 'flag _ key = catalog로 로그 스냅 샷을 수정하십시오. 새로운 _ ranker '.
페이로드 설정을 사용합니다.
3. 관할권 부족
허가 플래그는 실수로 'NL' -OFF + 사후 감사에서 게임을 시작하여 가드 규칙 "지역 거부" 를 추가했습니다.
4. A/B의 차이
실험을 중지하고 CUPED/층화 된 분석을 수행하고 업데이트 된 스케일로 다시 롤링하십시오.
13) 테스트
단위: 규칙/우선 순위/전제 조건의 결정 론적 평가.
계약: 플래그 체계 (JSON/YAML), 유효성 검사기, 병합 전 CI 확인.
부동산 기반: "거부> 허용", "가장 구체적인 승리", 안정적인 버켓 팅.
새로운 구성에서 실제 컨텍스트를 재생합니다.
E2E: 카나리아 스크립트 (스텝 업/스텝 다운), 오토 캐토프 점검 및 감사 이벤트.
혼돈: 스트리밍 절벽, 레거시 스냅 샷, 대규모 플래그 업데이트.
14) 전형적인 오류
클라이언트 플래그의 비밀 논리 (누출/스푸핑).
TTL → 코드에 플래그의 "묘지" 가 없습니다.
→ 세분화가없는 "범용" 플래그는 문제를 국소화 할 수 없습니다.
가드 레일/오토 카토 폰 없음-수동 사고.
플래그 → 동기화되지 않은 플래그 간의 호환되지 않는 종속성.
캐시 → 대기 시간 스파이크없이 각 요청에서 플래그의 평가.
감사/변경 창 없음-규정 준수 위험.
15) 사전 판매 점검표
- 유형, 소유자, 설명, TTL 및 티켓 요구 사항으로 생성 된 플래그.
- 정의 된 표적 규칙; 원치 않는 지역/역할에 대한 '거부'.
- 끈적 끈적한 버킷은 결정 론적입니다. ID가 안정적입니다.
- 사전 요구 사항 및 건강 플래그 준비; 기본 안전.
- p95/p99의 대시 보드 및 경고, 오류 _ rate, 비즈니스 가드 레일.
- Autocatoff 구성; 롤아웃 정지 임계 값 및 롤백 조건.
- 카나리아 계획-백분율/이정표/창/소유자 변경
- 구성은 CI에서 검증됩니다. 클러스터/지역에 분산 된 스냅 샷.
- 지원/제품 문서; 사건 플레이 북.
- 100% 후에 코드 분기와 플래그 자체를 제거 할 계획입니다.
16) "마이그레이션" 플래그의 예 (DB/인덱스)
yaml flag:
key: "search. use_index_v2"
type: "migration"
description: "Switching reads to index v2"
prerequisites:
- key: "search. index_v2_built"
must_be: "on"
rules:
- when: { tenant_id: ["brand_eu"], user_pct: 5 } then: "on"
- when: { tenant_id: ["brand_eu"], user_pct: 25 } then: "on"
safeguards:
auto_rollback_on:
search_p95_ms: ">180"
error_rate: ">1%"
ttl: "2026-02-01"결론
Feature Flags는 "온/오프" 일뿐만 아니라 변경 위험 관리의 규율입니다. 클리어 플래그 유형, 결정 론적 타겟팅, 가드 레일이있는 프로그레시브 디스플레이, 자동 도용, 감사 및 삭제 계획은 릴리스를 예측할 수 있고 사고가 간결하고 통제됩니다. 일류 시민으로서 건축에 깃발을 만들면 더 자주, 더 안전하고 의미있는 가치를 제공 할 수 있습니다.