Response Time Analysis
Response Time Analysis 관련 장애 문제 5개를 모았습니다. 검수된 문제부터 풀어 보세요.
먼저 읽을 가이드
DNS는 바뀌었는데 일부 client가 이전 backend로 갈 때DNS record는 갱신됐지만 resolver cache, HTTP/2 keepalive, client pool이 이전 target을 붙잡는 상황Network2분 읽기firewalld에서 열려 보이는데 접속은 계속 막힐 때port rule은 있어 보이지만 zone, runtime/permanent drift, source binding, 상위 방화벽 때문에 연결이 실패하는 상황Network3분 읽기timeout과 connection refused를 네트워크 경로로 분리하는 법DNS, route, firewall, proxy, listener 상태가 같은 연결 실패처럼 보이는 상황Network2분 읽기
추천 문제
검수된 문제를 먼저, 그다음 시나리오가 자세한 문제를 보여 줍니다.
모든 문제 5개
NETWORK-1205프록시 health 페이지는 초록인데 사용자 트래픽이 계속 실패프록시 health 엔드포인트는 괜찮아 보이는데 실제 사용자 트래픽이 계속 실패합니다 — TLS hostname 경로가 단순 health check와 다른 upstream 인증서나 route를 고릅니다.Network중급19분ProNETWORK-1200리버스 프록시 타임아웃 튜닝이, upstream 경로 하나가 요청을 예상 밖으로 직렬화한다는 사실을 가림타임아웃 값을 올리면 증상이 잠시 나아지는데, 진짜 문제는 병렬이어야 할 백엔드 경로가 직렬화돼 적당한 부하에서도 멈춘다는 것입니다.Network고급23분ProNETWORK-1203host DNS는 되는데 프록시 프로세스가 reload 전까지 옛 resolver 뷰를 유지host 수준에서는 이름 해석이 고쳐졌는데 장수 프로세스 하나가 계속 더 오래된 resolver 상태를 써서 엉뚱한 백엔드로 트래픽을 보냅니다.Network중급17분ProNETWORK-1195리버스 프록시가 499와 upstream 타임아웃을 함께 반환팀이 공개 NGINX 진단 글을 읽고 499 상태 코드에 집중합니다. 진짜 문제는 클라이언트가 먼저 끊을 만큼 느린 백엔드 경로입니다.Network중급19분ProNETWORK-1197프록시 계층 하나의 DNS TTL 전제가 더 길어 로드밸런서가 옛 백엔드 경로를 계속 재사용failover나 백엔드 전환이 맞아 보이는데 트래픽이 계속 옛 타깃을 때립니다 — 프록시나 edge 캐시 하나가 운영자 예상보다 긴 DNS 수명을 따릅니다.Network중급20분Pro