이동 전 흐름 그리기
브라우저 수집 후 서버와 목적지로 보내는 과정이 남을 수 있습니다. Consent Mode는 상태를 전달하고 일부 동작을 조정하지만 선택 배너나 법률 검증을 단독 제공하지 않습니다.
| 단계 | 통제 | 필요 증거 |
|---|---|---|
| 브라우저 또는 앱 | 수집 필드와 선택. | 실제 보낸 요청. |
| 수집 서버 | 검증, 필터와 접근. | 허용 또는 거부 이벤트. |
| 목적지 | 실제 전달 데이터. | 페이로드와 동의 규칙. |
| 운영 | 보관, 권한과 복구. | 삭제, 장애와 접근 테스트. |
실제 전송 내용 테스트하기
- 목적별 허용 필드와 수신자를 정합니다. 전송 전에 URL, 매개변수, 식별자와 로그를 검사하고 기본 필터링을 가정하지 않습니다.
- 동의, 거부와 선택 변경을 처음부터 끝까지 테스트합니다. 브라우저, 서버 컨테이너와 각 목적지를 확인합니다.
- 수신, 허용, 전달 이벤트를 대조합니다. 중복, 누락, 장애와 복구를 테스트하고 서버 비용과 부하도 측정합니다.
이익과 의무를 따로 평가하기
비슷한 경로에서 성능을 확인합니다. 초기 브라우저 수집이 계속 필요할 수 있습니다. 자사 도메인이 면제를 뜻하지 않습니다. 프랑스의 일부 방문자 측정 면제는 조건부이며 광고 태깅에 자동 적용되지 않습니다.
1차 자료
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
서버 측 태깅에 대한 흐름 테스트가 여전히 필요합니다.
태그를 서버로 이동한다고 해서 측정 기준이 자동으로 준수되거나 최소화되는 것은 아닙니다. 실제 배포 환경에서 전송된 요청, 수신자, 식별자 및 거부 후 동작을 검사하십시오.
- 브라우저, 수집 서버, 공급업체 및 전송된 필드를 매핑하십시오.
- 선택 전, 거부 후, 동의 철회 후 테스트를 수행하십시오.
- 설정을 명시된 목적 및 관련 CNIL 조건과 비교하십시오.
1차 자료: CNIL — Outils de mesure d’audience et traceurs. 관련 방법: 실무 가이드 읽기.
API 할당량과 속도 제한
제한은 용량, 재시도와 고객 간 배분에 영향을 줍니다.
- 할당량이 계정, 키 또는 자원 중 어디에 적용되는지와 클라이언트의 동시 작업 수를 기록합니다. 평균 빈도가 낮아도 무제한 대기열은 서비스를 과부하시킬 수 있습니다.
- 429에 Retry-After가 있으면 해석하고 다음 요청까지 기다립니다. 증가하는 대기 시간과 클라이언트별 시간 분산을 최대 시도 수와 전체 기한에 결합합니다.
- 쓰기 응답이 사라졌다면 재시도 전에 상태를 확인합니다. 모의 시험에서 할당량, 늦은 응답과 취소를 조합하여 중복 효과 없이 대기열이 끝나는지 확인합니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}예상 판단
30초 대기를 준수하고 20개 워커의 재시도를 분산하며 횟수를 제한합니다.
클라이언트 20개의 재시도 분산과 횟수 계산
가상 예시: 워커 20개가 +0 s에 각각 429와 Retry-After: 30을 받습니다. 시간표는 가능한 분산 예시이며 서버 용량을 보장하지 않습니다. 각 워커는 최초 요청 외에 3회 재시도할 수 있습니다.
| 정책 | 계산 또는 일정 | 효과와 한계 |
|---|---|---|
| 동시 재시도 | 20 × 1 = 20 @ +30 s | 30초를 기다리면 대기 지시는 지키지만 20개 요청이 동시에 돌아오므로 부하가 다시 집중될 수 있습니다. |
| 분산 재시도 | 4 × 5 = 20 @ +30…+34 s | 초당 4개씩 5초 동안 보내면 재시도 20개가 분산되지만 총수는 줄지 않습니다. 이 예시 일정은 무작위 지연을 더하는 백오프 정책을 대신하지 않습니다. |
| 25초 후 마감 | 25 s < 30 s → 0 | 남은 시간이 요구된 30초보다 짧으면 계약에 따라 중단하거나 연기합니다. 마감에 맞추려고 대기를 줄이지 않습니다. |
| 최대 예산 | 20 × (1 + 3) = 80 | 모든 시도를 사용하면 최초 요청 20개와 재시도 60개로 총 80개입니다. 상한이 있어도 성공이나 안전한 반복은 보장되지 않습니다. |
검증 절차
- 할당 범위 및 재시도 예산을 기록합니다.
- 허가된 시험에서만 할당량을 소진합니다.
- 429, Retry-After 및 제한된 시간선을 보존합니다. 기술적 제한과 업무 결과를 구분하세요. 할당량 소진을 재고 0이라는 응답으로 바꾸면 안 됩니다.
- 외부 부하 없는 모의 환경에서 네 계층 각 세 총호출을 셉니다.
- 가상 큐 작업을 만료시켜 새 작업이 시작되지 않는지 확인합니다.
- 모의 실패 뒤 허가한 작업을 점진 복구하고 호출, 기한과 고유 결과를 보존합니다.
429가 이전 쓰기 미실행을 증명하나요?
아닙니다. 응답이 사라진 작업은 별도로 대조해야 하며 다른 시도의 응답으로 그 상태를 판단하면 안 됩니다.
1차 자료: IETF — RFC 6585, HTTP 429. 관련 방법: 실무 가이드 읽기.
탄소 측정 경계
비교에는 공통 범위와 기능 단위가 필요합니다.
- 구성 요소, 지역, 기간과 기능 단위를 정합니다. 예를 들면 완료한 작업 한 건입니다. 같은 서비스를 제공하는 조건을 비교합니다.
- 에너지, 배출 계수와 하드웨어 할당분을 기록합니다. 측정과 추정을 구분하고 제외 항목을 배출량 0으로 간주하지 않습니다.
- 가상 예: (12 + 3) gCO2e / 작업 5건 = 건당 3 gCO2e. 불확실한 가정을 바꾸고 총배출량도 비교합니다.
재현 가능한 수락 사례
가상 예시입니다. 고객이나 실제 관측 결과를 나타내지 않습니다.
사례 입력 보기
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}예상 판단
(2 × 100 + 50)/100 = 작업당 2.5 gCO2e이며 선언한 범위에만 해당합니다.
검증 절차
- 경계, 기능 단위 및 계수를 정합니다.
- 에너지, 내재 배출 및 결과를 분리합니다.
- 출처와 암묵적 상쇄 없는 계산을 보존합니다.
1차 자료: Green Software Foundation — Software Carbon Intensity. 관련 방법: 실무 가이드 읽기.
API: 계층 간 재시도 증폭 방지
앱, SDK, 프록시와 서비스가 같은 호출을 재시도할 수 있습니다. 가상 네 계층에서 각 세 번의 총시도를 하면 실패한 의존성에 최대81번 호출합니다. 기존 할당 관리에 공유 예산과 유효 기한을 추가합니다.
- 앱, SDK, 프록시와 의존성의 자동 시도를 정리합니다. 책임 계층을 고르고 계약에 따라 추가 시도를 끄거나 조정합니다. 첫 시도도 총예산에 포함합니다. 작업 ID를 보존하고 비멱등 작업 재시도 전 불확실한 효과를 확인합니다.
- 클라이언트 실제 한도를 고려해 대기, 연결과 처리를 포함한 전체 기한을 정합니다. 큐 수용 전 만료 작업을 거부합니다. 로컬 취소가 서버 중단을 입증하지 않으므로 상태를 대조합니다. 모든 큐를 동시에 재시작하지 말고 점진 복구를 시험합니다.
각 계층 세 번이면 전체 세 번인가요?
아닙니다. 가상 네 계층에서 세 번씩이면 마지막 의존성에 최대3⁴ = 81번 호출합니다.
만료가 원격 효과를 취소하나요?
꼭 그렇지 않습니다. 새 무용한 작업을 막고 시작된 원격 작업은 상태 확인과 가능한 보상이 필요합니다.
1차 자료: AWS — Timeouts, retries, and backoff with jitter. 관련 방법: 실무 가이드 읽기.