그림자 교통 및 비교
1) 그림자 트래픽이란 무엇이며 필요한 이유
섀도우 트래픽 (일명 트래픽 미러링/다크 런칭) 은 사용자에게 영향을 미치지 않으면 서 프로덕션 버전과 병행하여 새 버전의 서비스에 대한 실제 요청/이벤트의 안전한 "실행" 입니다. 새 버전의 결과는 클라이언트로 반환되지 않으며 외부 부작용을 생성하지 않지만 비교 시스템에서 수집됩니다.
주요 목표:- 호환성 확인: 체계, 계약, 비즈니스 로직.
- 성능 평가: 대기 시간, 실제 부하 중 저항.
- 드리프트 감지: 응답, 분포, 오류율의 차이.
- 카나리아 릴리스 준비: 실제로 트래픽을 전환하기 전에 위험을 줄입니다.
- 커널/알고리즘을 다시 작성하고 데이터베이스/캐시를 마이그레이션하며 다른 런타임/SDK로 전환하여 외부 API 제공자를 변경합니다.
2) 그림자 트래픽의 건축 패턴
2. 1 L7 프록시/게이트웨이 (HTT/gRPC)
프록시는 요청 → 는 이전 버전의 전투 응답을 제공합니다. → 요청의 사본을 "그림자" 로 비동기식으로 미러링합니다.
동기식 API에 적합합니다.
공유/미러링 필터 제어: 도중에 헤더, 사용자, 테넌트.
yaml route:
route:
cluster: prod-v1 request_mirror_policies:
- cluster: shadow-v2 runtime_fraction:
default_value:
numerator: 10 # 10% denominator: HUNDRED trace_sampled: truenginx location /api/ {
proxy_pass http://prod_v1;
mirror/shadow; # request copy
}
location = /shadow {
internal;
proxy_pass http://shadow_v2; # answer ignored
}2. 이벤트 버스 2 개 (카프카/스레드)
주제 수준에서 티가 수행됩니다
생산자는 평소와 같이 읽습니다. → 소비자는 읽습니다.
동시에 섀도우 파이프 라인은 동일한 스트림을 별도의 샌드 박스로 읽습니다.
옵션: MirrorMaker/Replicator, 이중 쓰기 (주의), 소스 → prod + shadow bridge.
2. 3 리플레이어 (레코드/재생)
실제 요청/트레일 (PCAP/NGINX 액세스, gRPC 탭) 의 스냅 샷 → 제어 된 속도로 "그림자" 로 재생
2. 4 "합성 그림자"
생산 로그 + 충전 엣지 케이스 단계에서로드 프로파일을 생성하는 것은 기밀 유지 제한에 유용합니다.
3) 상태 및 부작용 격리
황금 규칙: 그림자는 외부 세계를 변화시키지 않습니다.
데이터베이스/캐시 또는 별도의 샌드 박스 (스냅 샷/복제) 에 대한 리드 온 액세스.
나가는 부작용 금지: 지불, 편지, 보풀, 웹 후크 → 스터브/블랙홀/레코드 전용.
명령/POST demempotence: 그림자를 원본의 반복으로 등록해서는 안됩니다.
PII/비밀 마스킹, 테스트 제공 업체 토큰.
예: 거울에 마스킹
yaml shadowFilter:
headers:
redact:
- Authorization
- X-Api-Key body:
jsonPaths:
- replace "$ .email" # with token
- "$.card. number"4) 샘플링 전략 및 안전로드
트래픽 점유율: 처음에 1-10%; v2가 예산 내에 있으면 증가합니다.
선택 기준: 경로, 사용자, 요청 크기, 작업 유형 (GET가 더 안전 함).
Perf 예산: 미러링으로 p95/p99 전투 서비스가 증가해서는 안됩니다. 그림자는 항상 비동기입니다.
역압: 섀도우 체인이 과열되면 전투 요청이 아닌 섀도우를 떨어 뜨립니다.
시간: 최소 24-72 시간 동안 diem 및 피크 패턴을 커버합니다.
5) 결과 비교: 방법 및 수준
5. 1 비교 수준
1. 바이트 디프: 일대일 응답/이벤트의 본문. 간단하지만 깨지기 쉬운 (타임 스탬프, 키 순서).
2. 시맨틱 디프: 필드를 정규화하고 정렬하고 에페 메리 드 (traceID, 타임 스탬프, 카운터) 를 무시하십시오.
3. 비즈니스 불변량: 동일한 금액, 상태, 수량, 경계 여부.
4. 통계 분석: 메트릭 분포가 일치합니까? (p50/p95, KS 테스트, 카테고리 ² ²).
5. 2 비교 정책
마스크/무시 필드 목록 (예: '업데이트', 'etag').
정확도: 숫자에 대한 절대/상대 오류 (예: λ1e-6).
관용 밴드: "가격 차이 λ0. 01 "", + 0 오류를 넘지 않습니다. prod에 비해 1% ".
비교기 의사 코드
pseudo compare(prod, shadow, policy):
a = normalize(prod, policy)
b = normalize(shadow, policy)
diffs = deepDiff(a, b, ignore=policy. ignore, floatTol=policy. floatTol)
invariants_ok = checkInvariants(a, b, policy. invariants)
return Result(diffs, invariants_ok)5. 3 자 프로스 오트 벳의 비교
상관 ID가 필요합니다.
링크 스팬: 섀도우 트랙이 전투에 연결됩니다.
6) 관찰 가능성 및 비교 아티팩트
메트릭:- 'shadow _ insters _ total {route,...}'
- 'shadow _ disclipancies _ total {style = byte' semantic 'invariant}'
- 'shadow _ orr _ ratio'... shadow _ slo _ break _ total '
- Perf: 'shadow _ latencies _ ms {p50, p95, p99}'
- 어려운 로그: 키별로 컴팩트 한 JSON 델타.
- 보고: 상위 N 불일치가있는 일일 보고서, 경로/세입자 별 열지도.
- UI "diff 탐색기": 유형, 경로, 현장, CSV로 내보내기 필터.
7) 특별한 경우와 미묘함
7. 1 일관성과 일관성
그림자 요청은 나중에/더 일찍 올 수 있습니다. 버전/시간 (Lamport/vector) 또는 창 공차로 정규화합니다.
쓰기 후 읽기: 동기식 복제가없는 읽기 복제본이있는 그림자는 지연 창을 통해 비교하여 다른 답변을 제공합니다.
7. 캐시/권장 사항 2 개
prod와 shadow caches를 혼합하지 마십시오.
ML/추천자의 경우 온라인 메트릭과 오프라인 메트릭을 별도로 비교하십시오. 드리프트 입력 기능을 관찰하십시
7. 3 외부 제공 업체
기록 전용/스터브 모드로 클라이언트를 감싸십시오.
결제 서비스 (세금, 요율) 의 경우-양 당사자의 디렉토리 스냅 샷을 수정하십시오.
8) 카나리아 병치/청록색
그림자: 사용자에게는 위험이 없지만 실제 부작용은 없습니다. 논리와 perf에 좋습니다.
카나리아: 새 버전의 실제 답변 중 적은 비율; 기성품 롤백 전략과 SLA가 필요합니다.
청록색: 검증 후 즉시 전환; 그림자는 종종 그 앞에서 사용됩니다.
9) 구현 계획 (GitOps 스타일)
1. 목표 및 지표: 불변량과 공차는 불일치에 대해 어떤 SLO를 확인합니다.
2. 추적: 상관 ID, 분산 추적 링크.
3. 프록시 구성: 미러 정책, 샘플링, 수정.
4. 격리: 데이터베이스 샌드 박스/캐시, 사이드 스터브, 테스트 키.
5. 비교기: 정규화, 무시 맵, 불변, 보고서.
6. 로드 계획: 녹색 메트릭으로 1-5% 에서 시작하여 최대 20-50% 까지 성장합니다.
7. 관찰 가능성: "불일치/perf/볼륨" 대시 보드.
8. 종료 기준: "0 중요한 불일치 48 h", "prod보다 나쁘지 않은 오류", "105% 내의 perf".
9. 카나리아로 이동: 안전한 공유 및 자동 가다 규칙에 실제 답변을 포함하십시오.
10) 설정 예
10. 1 Istio (트래픽 미러 링)
yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["svc. example"]
http:
- route: [{ destination: { host: svc, subset: v1 } }]
mirror:
host: svc subset: v2 mirrorPercentage:
value: 0. 1 # 10%10. 2 카프카 티 (스케치)
text source-topic -> prod-consumer-group
-> shadow-consumer-group (isolated sink/db)10. 3 비교 규칙 (yaml 정책)
yaml ignoreFields:
- $.traceId
- $.meta. generatedAt floatTolerance:
default: 1e-6 fields:
$.price: 0. 01 invariants:
- name: "nonNegativeTotal"
expr: "$.total >= 0"
- name: "statusMapping"
expr: "map($.status in ['ok','fail'], true)"11) 반 패턴
섀도우 기록: 그림자에서 실제 지불/알림.
공유 캐시/공유 대기열: 교차 충격 및 오염.
정규화 부족: 클럭/키 순서로 인해 바이트 확산이 "빨간색" 입니다.
이동 중 너무 높은 비율: 펜 prod의 분해.
긴 "영원한 그림자": 두 번째 시스템은 별도로 생활하며 현실과 다릅니다.
12) 그림자 모드 발사 체크리스트
- 프록시는 공유 및 편집이있는 미러로 구성됩니다.
- 그림자 격리: DB/캐시/외부 통합-재택 전용/스터브 만.
- 상관 ID는 모든 곳에서 던져집니다. 흔적이 연결되어 있습니
- 비교기는 불변량을 무시/정규화하고 확인할 수 있습니다.
- 불일치 및로드에 대한 대시 보드 및 경고.
- 노선/임차인에 의한 샘플링; 한계와 역압.
- 녹색 조명 공차와 기준이 정의됩니다.
- 카나리아/청록색으로의 전환 및 롤백 계획.
13) FAQ
Q: 그림자는 A/B와 어떻게 다릅니 까?
A: A/B에서 두 버전 모두 사용자에게 답변을 반환하고 (분할 실험) Shadow에서 새 버전은 사용자에게 영향을 미치지 않습니다. 답변 만 분석됩니다.
Q: POST/PUT를 그림자로 만들 수 있습니까?
A: 예, 부작용 격리 (스터브) 및 demmpotence가 보장되는 경우. 종종 GET부터 시작하여 확장하십시오.
Q: 항목 순서가 수정되지 않은 경우 응답을 어떻게 비교합니까?
A: 세트/키로 비교하거나 비교하기 전에 안정적인 키로 정렬하십시오.
Q: 데이터베이스 복제 지연으로 어떻게해야합니까?
A: "비교 창" 을 입력하고 참고 도서 스냅 샷; 벽 시간이 아닌 버전별로 결과를 집계하십시오.
14) 총계
그림자 트래픽은 "고통없는 생산 리허설" 입니다: 실제 부하, 사용자의 위험 없음, 불일치에 대한 자세한 분석. 성공은 격리, 올바른 샘플링, 품질 비교기 및 관찰 가능성에 의해 결정됩니다. 제안 된 계획에 따라 카나리아/청록색 릴리스로가는 길을 자신있게 연결하고 건축의 진화를 가속화하는 재현 가능한 관행을 얻게됩니다.