회로 제어 시간 초과

1) 왜 필요한가

시스템은 하나의 "치명적인" 실패가 아니라 지연과 "파동" 의 축적에서 비롯됩니다. 타임 아웃은 대기 시간과 자원 확보를 제한하며 회로 제어 (차단기 + 흘림 + 적응 경쟁) 는 종속성 체인을 따라 열화가 확산되는 것을 방지합니다. 목표는 p95/p99를 목표 경계 내에 유지하고 부분 오류에 대한 가용성을 유지하는 것입니다.

2) 기본 정의

2. 타임 아웃 1 가지 유형 (L7/L4)

시간 초과를 연결합니다.
TLS/핸드 셰이크 타임 아웃-악수 TLS/HTTP2 서문.
타임 아웃 쓰기-요청 (본문 포함) 을 보냅니다.
타임 아웃을 읽으십시오-응답 및/또는 전신의 첫 바이트를 기다리십시오.
유휴/유지 생존 시간 초과-비활성 연결.
전체 마감일- 전체 요청에 대한 "하드" 마감일 (엔드 투 엔드).

2. 마감일 예산 2 개

대상 '마감일 _ 전체' 를 선택하고 단계별로 나눕니다

'ingress (gateway) + autZ + app + DB/cash + 아웃 바운드 PSP'.

• 게이트웨이: 30ms,
• 신청: 120ms,
• DB: 120ms,
• PSP: 100ms,
• 마진: 30ms.

2. 3 전파 및 취소

'마감일 '/' 타임 아웃' 은 체인 (컨텍스트, 헤더, gRPC 마감일) 으로 전달되어야합니다. 만료시-배경 작업 취소 (중단/ctx 취소), 명확한 잠금/세마포어.

3) 시간 초과 설정 전략

1. 하향식: SLO 및 p95를 기반으로-엔드 투 엔드 마감일을 설정 한 다음 하위 타임 아웃으로 나뉩니다.
2. "고가의" 경로 (파일 다운로드, 보고서, 외부 PSP) 를 식별하십시오.

• dempotent (GET/상태 반복) -더 짧고 공격적입니다.
• 쓰기/금전-약간 더 길지만 단일 반복과 demopotency가 있습니다.

4. 계획/임차인에 의한 졸업 (기업은 더 긴 타임 아웃을 가질 수 있지만 병렬 처리는 줄어 듭니다).

4) 회로 차단기: 모델 및 매개 변수

4. 1 트리거링 정책

느린 통화 속도-임계 값 T.보다 긴 통화 비율

실패율-쿼리/시간 N 창에서 오류율이 10% 이상입니다.
결과 실패: M 연속 실패.
오류 클래스: 타임 아웃/5xx/연결 재설정 → "치명적", 4xx-고려하지 마십시오.

4. 2 가지 조건

폐쇄-모든 것을 건너 뛰고 통계를 축적합니다.
개방-즉각적인 실패 (리소스를 절약하고 의존성을 분쇄하지 않음).
"물 테스트" 에 대한 반 개방 - 작은 "샘플" (N 요청).

4. 3 유용한 추가

벌크 헤드: 의존성 당 스레드/연결 풀로 모든 것을 "빨리" 하지 않습니다.
적응 형 동시성: 관찰 된 대기 시간에 의한 자동 동시성 제한 (AIMD/Vegas 유사 알고리즘).
로드 시딩: 로컬 리소스가 부족한 경우 조기 장애/저하 (대기열, CPU, GC 일시 중지).

5) 상호 작용: 타임 아웃, 휴식, 한계

첫 번째 마감일 다음 다시 트레이: 각 반복은 공통 마감일에 맞아야합니다.
리플레이를위한 백오프 + 지터; '재시도 후' 및 재 시도 예산을 존중하십시오.
속도 제한: 폭풍을 강화하지 않도록 차단기가 열린 상태-낮은 한계.
이데올로기: 필수 작업 ("멍청한" 타임 아웃을 피하기 위해).
철회 장소: 바람직하게는 내부가 아닌 가장자리 (클라이언트/게이트웨이) 에서.

6) 실제 대상 값 (벤치 마크)

공개 읽기 API: 엔드 투 엔드 '200-500 ms', 타임 아웃 '100-300 ms'.
중요한 글쓰기 (지불): '300-800 ms' e2e; 외부 PSP 소 '250-400 ms'.
연결/TLS: '50-150ms' (더-네트워크/솔더링 문제).
유휴: '30-90 s' (모바일 클라이언트-배터리 절약을 위해 더 짧음).
p95/p99 및 영역의 값을 조정하십시오.

7) 구성 및 예

7. 1 특사 (클러스터 + 경로, 의사)

yaml clusters:
- name: payments_psp connect_timeout: 100ms type: STRICT_DNS lb_policy: ROUND_ROBIN circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 2000 max_requests: 2000 max_retries: 50 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

routes:
- match: { prefix: "/api/v1/payments" }
route:
cluster: payments_psp timeout: 350ms        # per-request deadline idle_timeout: 30s retry_policy:
retry_on: "reset,connect-failure,refused-stream,5xx,gateways"
num_retries: 1 per_try_timeout: 200ms

7. 2 NGINX (둘레)

nginx proxy_connect_timeout 100ms;
proxy_send_timeout  200ms;  # write proxy_read_timeout  300ms;  # read (первый байт/все тело)
keepalive_timeout   30s;
send_timeout     15s;

Быстрый отказ при перегрузке limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 50;

7. 3 gRPC (클라이언트, Go-pseudo)

go ctx, cancel:= context.WithTimeout(context.Background(), 350time.Millisecond)
defer cancel()
resp, err:= client.Pay(ctx, req) // Deadline передается вниз

7. (PHP 3 = 3.0.6, PHP 4)

go client:= &http.Client{
Timeout: 350 time.Millisecond, // общий дедлайн на запрос
Transport: &http.Transport{
TLSHandshakeTimeout: 100 time.Millisecond,
ResponseHeaderTimeout: 250 time.Millisecond,
IdleConnTimeout: 30 time.Second,
MaxIdleConnsPerHost: 100,
},
}

7. 5 Resilience4j (자바, 의사)

yaml resilience4j.circuitbreaker.instances.psp:
slidingWindowType: TIME_BASED slidingWindowSize: 60 failureRateThreshold: 50 slowCallDurationThreshold: 200ms slowCallRateThreshold: 30 permittedNumberOfCallsInHalfOpenState: 5 waitDurationInOpenState: 30s

resilience4j.timelimiter.instances.psp:
timeoutDuration: 350ms

8) 관찰 및 경고

8. 1 메트릭

'http _ client _ inters {endpoint, 상태}', 'client _ latency _ bucket'

8. 2 트레일

스팬: 수신 → 핸들러 → DB/Redis → 외부.
속성: '타임 아웃 _ ms _ 대상', '회로 _ state', '큐 _ time _ ms'.
외계인: 타이 p99는 특정 미량 ID에 이릅니다.

8. 3 경고

'p99 _ latency {critical}'> 는 X 분을 연속으로 목표로합니다.
'타임 아웃 _ rate {종속성}' 이> Y% 증가했습니다.
'개방 '/' 플랩 핑' 차단기로의 빈번한 전환.
높은 CPU/GC로 'shed _ quirls _ total' 의 성장.

9) 적응 동시성 및로드 Shedding

9. 1 아이디어

대기 시간이 길어짐에 따라 자동화는 병렬 처리를 줄입니다

AIMD: 천천히 증가하고 급격히 감소하십시오.

라스베가스와 같은: 대기열 시간을 유지하십시

토큰 기반: 각 요청은 토큰을 "연소" 합니다. 토큰은 측정 속도에 따라 발행됩니다.

9. 2 구현

경로당 국소 세마포어; 목표는 '큐 _ time' 을 임계 값 이하로 유지하는 것입니다.
게이트웨이의 글로벌 "퓨즈" (한계 RPS/경쟁).
CPU/연결이 부족한 경우 논리 실행 이전의 조기 장애 ('Redue-After' 가있는 429/503).

10) 테스트 및 혼돈 시나리오

대기 시간 주입: 의존성 당 인위적으로 50-300ms를 추가합니다.
패킷 손실/dup/drop (tc/tbf, Toxiproxy).
손잡이 회전: 연결 풀을 줄이고 채도를 높입니다.
Kill/Degrade One zone/shard (부분 사용 불가).
점검: 리트레이 폭풍을 "실패" 하지 않습니다. 차단기가 예측 가능하게 열립니다. 대기열이 커지고 있는지 여부.

11) 안티 패턴

클라이언트 타임 아웃 후 실행 취소/중단 → 배경 작업이 계속되지 않습니

세부 사항이없는 하나의 글로벌 "읽기 시간 초과" 는 무대 당 연결됩니다.
공통 마감일 → 배상이 없다는 것은 SLO를 넘어선 것입니다.
지터가없고 재 시도 예산이없는 Retrai.
유휴 타임 아웃이없는 "영원한" 연결 → 누출 설명자.
브레이커는 4xx를 치명적인 실수로 간주합니다.
시간 초과는 모바일/불안정한 네트워크에 비해 너무 깁니다.

12) iGaming/Finance의 세부 사항

중요한 글쓰기 (예금/출력): Idempotency-Key를 사용한 짧은 반복, 무한한 기대 대신 '202 수락' + 폴링.
PSP/뱅킹: 공급자/지역별 별도의 정책 (일부 느림).
책임있는 지불 및 한도: 잠금/리뷰-빠른 '423/409' 는 "매달린" 거래를 늘리지 마십시오.
보고/집계-비동기식으로 실행됩니다 (배치 + 상태 리소스).

13) Prod 준비 점검표

• 엔드 투 엔드 중요 경로 마감일 (GET/POST) 이 정의되었습니다.
• 단계별로 예산 책정; 마감일 전파가 활성화되었습니다.
• 게이트웨이 및 클라이언트에서 연결/TLS/읽기/쓰기/유휴 구성 요소.
• 고장률과 느린 호출 임계 값을 가진 회로 차단기; 올바른 반 개방 논리.
• 의존성에 대한 벌크 헤드; 경로 당 동시성 한계.
• 과부하 중에 비즈니스 로직이 실행되기 전에로드 흘림.
• 후퇴와의 통합: 백오프 + 지터, 재 시도 예산, '재시도 후' 존중.
• 이데올로기 기록, 'Idempotency-Key' 및 이벤트 아웃 박스.
• 지표: 타임 아웃/슬로우 콜/브레이커/큐 시간/경쟁.
• 혼돈 테스트: 지연/손실/고장 주입, 영역 저하.
• 고객 문서: 샘플 타이밍, 응답 코드, 재생 팁.

14) TL; DR

각 요청에 마감일을 정하고 단계적으로 정렬하여 체인 아래로 펼치십시오. 회로 차단기 + 벌크 헤드 + 적응 형 동시성 + 로드 쉐딩을 통해 결함을 관리합니다. 재생-마감일 내에 만 지터와 예산으로; 쓰기-dempotent 만. 측정 시간 초과/느린 통화, 차단기 상태 및 '큐 _ time' 은 정기적으로 혼돈 테스트를 실시합니다.