#DevOps

Istio 3-4편: 507 status code와 istiod disconnected 탐지

Summary

Envoy가 던진 의문의 507 에러와 소리 없는 xDS 연결 끊김 현상 해결하기

채널코퍼레이션 DevOps 팀이 공유하는 실전 Istio/Envoy 트러블슈팅과 커스텀 프로브 구성 전략

프로덕션 환경에서 Istio 및 Envoy를 운영하며 직면하기 쉬운 까다로운 장애 사례 두 가지를 다룹니다. 대용량 요청 시 발생하는 507 에러의 숨겨진 원인인 재시도 버퍼 제한 메커니즘을 파헤치고, 컨트롤 플레인(istiod)과의 연결 단절을 실시간으로 감지하기 위한 메트릭 활용법과 안정적인 커스텀 readinessProbe 설계안을 제시합니다.

01507 Insufficient Storage 에러가 사실은 Envoy의 재시도 버퍼 용량(기본 1MB) 초과로 인한 로컬 응답임을 규명
02대용량 페이로드 스트리밍 중 재시도가 발생할 때만 에러가 발현되는 특이 조건을 분석하여 무분별한 버퍼 확대 대신 클라이언트 재시도 전략 권장
03기본 readinessProbe가 최초 설정 수신 이후의 xDS 연결 단절을 감지하지 못하는 한계점 지적
04Envoy 내부 메트릭인 control_plane.connected_state를 안전하게 노출시키기 위한 proxyStatsMatcher 정규식 설정 팁 공유
05재연결 루프 시 발생하는 플래핑을 방지하기 위해 successThreshold와 failureThreshold를 활용한 이중 완충 프로브 설계

RECOMMENDATION

서비스 메쉬 환경에서 대용량 API를 처리하거나 컨트롤 플레인의 일관된 상태 유지가 중요하다면, Envoy의 버퍼 설정 및 xDS 연결 상태 모니터링을 즉시 점검하고 복원력 있는 커스텀 프로브 도입을 검토하세요.

The Problem

채널코퍼레이션에서 Istio Ambient 모드 운영 중 대용량 페이로드 요청에서 낯선 507(Insufficient Storage) 에러가 발생하고, 일부 게이트웨이/웨이포인트 프록시가 istiod와의 xDS 연결이 끊겼음에도 기존 readinessProbe가 이를 감지하지 못해 오래된 설정으로 트래픽을 처리하는 문제가 발생했습니다.

The Solution

507 에러는 Envoy가 재시도를 위해 보관하는 페이로드 버퍼 제한을 초과해 발생한 것으로 파악하여 대용량 요청은 클라이언트 단에서 재시도하도록 권장하고, xDS 연결 끊김 문제는 Envoy의 control_plane.connected_state 메트릭과 successThreshold/failureThreshold 조율을 적용한 커스텀 readinessProbe를 통해 해결하고자 했습니다.

The Result

507 에러의 발생 메커니즘(재시도 버퍼 제한)을 명확히 규명하여 대규모 장애 전파를 방지하는 대안을 세웠으며, xDS 연결 단절 시 게이트웨이가 불완전한 상태로 트래픽을 계속 수신하여 플래핑(flapping)되는 현상을 커스텀 프로브 설정을 통해 완화할 수 있게 되었습니다.

Trade-off

커스텀 readinessProbe에서 stats 경로를 매번 파싱하는 방식은 다소 정교하지 못하며, 프로브 설정을 잘못 기입할 경우 스타트업 지연이나 원치 않는 플래핑을 유발할 수 있는 잠재적 위험이 존재합니다. 또한 대용량 페이로드 재시도를 애플리케이션으로 이관하면서 클라이언트의 구현 복잡도가 소폭 증가했습니다.

Key Concepts

Concept · 01

Envoy Retry Buffer

Envoy 프록시가 업스트림 요청 실패 시 재시도(Retry)를 수행하기 위해 요청 바디(Request Body) 페이로드를 일시적으로 보관하는 메모리 영역입니다. 스트리밍 자체는 크기 제한이 없으나, 재시도가 필요한 시점에는 이 버퍼의 제한(기본 1MB)을 초과할 경우 재시도가 불가능해집니다.

본문에서는 페이로드가 큰 POST 요청 중 업스트림 실패가 겹쳤을 때, 버퍼 크기 초과로 인해 507 에러가 발생하는 원인으로 작용했습니다.

Concept · 02

control_plane.connected_state

Envoy 프록시가 컨트롤 플레인(istiod)과의 xDS 설정 동기화용 gRPC 스트림이 연결되어 있는지를 나타내는 Envoy 내부 상태 메트릭입니다. 연결이 활성화되어 있으면 1, 끊어지면 0 값을 가집니다.

pilot-agent가 istiod 연결에 실패하여 Envoy 스트림이 닫히는 현상을 탐지하기 위한 핵심 지표로 활용되었습니다.
Prometheus로 수집하기 위해 proxyStatsMatcher 정규식에 정확한 메트릭 이름을 매칭시키는 설정이 필요함을 강조했습니다.

Concept · 03

readinessProbe Flapping

쿠버네티스에서 Pod의 준비 상태를 검사할 때, 특정 일시적 결함이나 빠른 재시도 루프로 인해 Ready와 NotReady 상태가 빠르게 반복해서 전환되는 현상입니다. 이로 인해 트래픽이 불완전하게 유입 및 차단되어 서비스 안정성을 해치게 됩니다.

xDS 재연결 시 일시적으로 connected_state가 1로 튀는 현상 때문에 단일 성공 시 바로 Ready로 복구되는 플래핑을 완화하고자 successThreshold와 failureThreshold를 둘 다 3으로 설정했습니다.

Continue reading · same source

More from 채널 톡

View all posts from 채널 톡

Istio 3-4편: 507 status code와 istiod disconnected 탐지

Summary