HTTP フィルター確認

router 필터를 사슬의 중간에 두면 어떻게 되는가?

• 뒤의 필터들이 건너뛰어지고 경고만 남는다
• 설정을 읽는 시점에 거절되어 Envoy 가 뜨지 않는다
• 요청마다 뒤의 필터가 무작위로 실행된다
• 응답 경로에서만 뒤의 필터가 실행된다

장애 주입으로 서비스의 복원력을 확인할 때 abort 보다 delay 가 더 중요한 이유는?

• abort 는 업스트림에 실제로 요청이 가지 않아 통계가 남지 않는다
• delay 는 비율을 지정할 수 있지만 abort 는 지정할 수 없다
• delay 는 응답 코드를 바꾸지 않아 클라이언트가 재시도하지 않는다
• 느려지는 것은 연결과 스레드를 묶어 장애로 번지므로 타임아웃 설정이 그때 드러난다

지역 속도 제한(local_ratelimit)을 초당 100건으로 걸고 프록시를 열 대 운영한다. 전체 한도는?

• 사실상 초당 1000건 — 프록시마다 자기 토큰을 따로 센다
• 초당 100건 — 프록시들이 토큰을 공유한다
• 초당 10건 — 한도가 프록시 수로 나뉜다
• 예측할 수 없다 — 토큰이 무작위로 배분된다

로그인 경로만 속도 제한을 빡빡하게 걸고 나머지는 느슨하게 하려면?

• 리스너를 두 개 만들어 경로마다 다른 포트로 받게 나눈다
• 같은 필터를 사슬에 두 번 적어 두 벌의 설정을 함께 둔다
• 라우트의 typed_per_filter_config 로 그 라우트만 덮어쓴다
• 가상 호스트를 나누고 각각 다른 클러스터로 보내 분리한다

percentage 를 50%로 둔 abort 로 스무 번 요청했더니 503 이 아홉 번 나왔다. 어떻게 봐야 하는가?

• 비율 설정이 반영되지 않았다. 분모를 HUNDRED 로 명시해야 한다
• 요청마다 독립적으로 뽑는 확률이므로 정상이다. 표본이 작으면 흔들린다
• 워커 스레드가 여럿이라 절반만 필터를 통과했다
• 토큰 버킷이 비어 일부 요청이 필터를 건너뛰었다

속도 제한 통계에서 운영상 가장 의미 있는 값은?

• rate_limited 의 절대값 — 막힌 요청 수가 곧 피해 규모다
• ok 의 절대값 — 통과한 요청 수가 실제 처리량이다
• enabled 의 절대값 — 필터가 도는지 여부를 알려 준다
• rate_limited 와 enabled 의 비율 — 한도가 현실과 맞는지를 보여 준다