준비 검사와 이상치 감지는 다른 것을 본다
한 줄 요약
쿠버네티스는 파드가 스스로 말하는 상태(준비 검사)로 트래픽을 뺀다. 메시의 이상치 감지는 사이드카가 실제로 받은 응답으로 뺀다. 준비 검사는 통과하는데 요청마다 500 을 내는 파드는 앞의 눈에는 멀쩡하고 뒤의 눈에만 고장이다.
왜 이게 필요했나
준비 검사는 보통 /healthz 같은 가벼운 경로를 본다. 그런데 장애는 흔히 그 경로 밖에서 난다 — 데이터베이스 연결 풀이 말랐거나, 설정 하나가 틀어진 파드 한 대만 특정 요청에 500 을 낸다. 준비 검사는 여전히 200 이니 쿠버네티스는 그 파드를 엔드포인트에 계속 둔다. 파드가 셋이면 요청의 3분의 1 이 실패하고, 누가 로그를 보기 전까지 그대로다.
클라이언트 쪽 프록시는 응답을 직접 받으므로 이것을 안다. 같은 업스트림이 연달아 실패하면 그 업스트림만 잠시 빼면 된다 — Envoy 의 이상치 감지(outlier detection)가 그 일이고, Istio 는 DestinationRule 의 outlierDetection 으로 켠다.
어떻게 동작하나
이상치 감지 — 업스트림 호스트 하나하나를 따로 본다.
| DestinationRule | Envoy 클러스터 | 뜻 |
|---|---|---|
consecutive5xxErrors: 2 |
consecutive5xx: 2 |
연속 5xx 가 이만큼이면 방출 |
interval: 2s |
interval: "2s" |
방출 여부를 판정하는 주기 |
baseEjectionTime: 60s |
baseEjectionTime: "60s" |
한 번 방출될 때의 기본 시간 |
maxEjectionPercent: 50 |
maxEjectionPercent: 50 |
한 번에 뺄 수 있는 호스트의 최대 비율 |
방출은 그 사이드카의 부하 분산표에서만 일어난다. 쿠버네티스 엔드포인트는 그대로이고, 다른 클라이언트의 사이드카는 자기가 받은 응답으로 따로 판단한다. 방출된 호스트는 기본 방출 시간이 지나면 돌아오고, 또 실패하면 방출 횟수에 비례해 더 길게 빠진다. maxEjectionPercent 는 장애가 모든 호스트로 번졌을 때 전부 빼 버려 아무 데도 못 가는 일을 막는 안전장치다.
보이게 하기. Istio 는 사이드카가 내는 Envoy 통계를 기본으로 거른다. 방출 횟수(outlier_detection.ejections_enforced_total)를 보려면 파드 애너테이션 proxy.istio.io/config 의 proxyStatsMatcher 로 그 통계를 살려야 하고, 프록시가 뜰 때 읽으므로 파드를 다시 만들어야 한다. 방출된 호스트는 istioctl proxy-config endpoints 에서 OUTLIER CHECK 가 FAILED 로 보인다.
미러링 — VirtualService 의 mirror 는 요청을 복제해 다른 서비스로 보내고 그 응답을 버린다. 복제본은 원래 요청과 같은 x-request-id 를 달고 가므로 받는 쪽 로그에서 짝을 찾을 수 있다. 새 버전을 운영 트래픽으로 시험하되 사용자에게는 원래 버전의 응답만 돌려준다.
장애 주입 — VirtualService 의 fault 는 클라이언트 쪽 사이드카가 요청을 보내기 전에 지연(delay)이나 중단(abort)을 넣는다. 중단된 요청은 업스트림에 닿지 않고 접근 로그의 응답 플래그가 FI 로 찍힌다. 헤더 조건을 붙이면 시험하는 요청만 망가뜨릴 수 있다.
현장에서 만나는 모습
"파드 셋 중 하나가 계속 500 인데 아무도 몰랐습니다." 준비 검사가 통과하는 고장이다. 이상치 감지를 걸어 두면 사용자가 보는 오류가 몇 번에서 멈춘다. 대신 고장 자체가 가려지므로 방출 통계에 알림을 걸어야 한다.
"이상치 감지를 켰더니 호스트가 전부 빠졌습니다." 업스트림 전체가 느려졌을 때 maxEjectionPercent 를 100 으로 두면 생긴다. 모두 빼면 갈 곳이 없어 오히려 장애가 커진다.
"미러링을 켰더니 새 버전 쪽 데이터베이스에 주문이 두 번 들어갔습니다." 미러는 응답만 버릴 뿐 요청은 진짜로 처리된다. 부작용이 있는 요청(쓰기)은 미러 대상에서 따로 막아야 한다.
공식 문서: DestinationRule — OutlierDetection · Mirroring · Fault Injection · Envoy outlier detection · ProxyConfig proxyStatsMatcher
다음 실습에서 할 것
늘 500 을 내는 파드 하나를 멀쩡한 파드 둘과 같은 서비스 뒤에 두고 실패율을 먼저 잰다. 통계를 살린 뒤 이상치 감지를 걸어 오류가 멈추는 것과 Envoy 가 그 파드를 방출해 둔 모습을 확인하고, 미러링과 헤더 조건의 장애 주입을 더한다. 마지막으로 이 설정들이 Envoy 설정의 어느 칸이 되었는지 꺼내 본다.