ルーティング確認

*.example.com 가상 호스트를 파일 맨 위에, www.example.com 가상 호스트를 맨 아래에 뒀다. www.example.com 으로 요청이 오면 어느 쪽이 받는가?

• 위에 쓴 *.example.com — 가상 호스트도 라우트처럼 위에서부터 첫 매치를 쓴다
• 아래에 쓴 www.example.com — 가상 호스트는 순서가 아니라 구체성으로 고른다
• 둘 다 맞으므로 Envoy 가 설정을 거절해 리스너가 뜨지 않는다
• 요청마다 번갈아 — 같은 순위의 가상 호스트는 라운드 로빈으로 나뉜다

domains: ["*"] 인 가상 호스트를 한 라우트 표에 두 개 뒀다. 무슨 일이 일어나는가?

• 먼저 쓴 쪽만 쓰이고 뒤쪽은 조용히 무시된다
• 요청마다 둘 중 하나가 무작위로 골라진다
• 설정을 읽는 시점에 거절되어 Envoy 가 뜨지 않는다
• 두 가상 호스트의 라우트가 하나로 합쳐져 순서대로 평가된다

safe_regex 로 ^/id/[0-9]+$ 를 적은 라우트가 있고 그 아래에 prefix: "/" 라우트가 있다. /id/abc 요청은 어떻게 되는가?

• 정규식이 맞지 않으므로 아래의 prefix 라우트가 받는다
• 정규식 라우트가 400 을 돌려준다
• 가상 호스트 선택으로 돌아가 다른 가상 호스트를 다시 고른다
• 정규식이 맞지 않으므로 404 가 나간다

weighted_clusters 로 75 대 25 를 걸고 요청 마흔 번을 보냈는데 비율이 매번 다르다. 실험을 결정적으로 만들려면?

• connect_timeout 을 늘려 연결 실패로 흘러가는 요청을 없앤다
• 클러스터의 lb_policy 를 RING_HASH 로 바꿔 요청을 고정한다
• --concurrency 1 로 띄워 워커 스레드를 하나로 만든다
• 가중치 합을 100 이 아니라 total_weight 로 명시한다

헬스 체크 경로를 애플리케이션이 아니라 프록시에서 끝내고 싶다. 무엇을 쓰는가?

• redirect 로 내부 상태 페이지로 옮겨 준다
• route.cluster 를 비워 두면 Envoy 가 기본 200 을 돌려준다
• headers 조건으로 헬스 체커의 User-Agent 만 걸러 낸다
• direct_response 로 상태 코드와 본문을 직접 지정한다

라우트·가상 호스트·라우트 표 세 곳에 같은 이름의 응답 헤더를 더하면?

• 세 값이 모두 응답에 남는다. 덮어쓰기가 아니라 각각 더해지기 때문이다
• 가장 안쪽인 라우트의 값만 남고 나머지는 버려진다
• 가장 바깥인 라우트 표의 값만 남는다
• 같은 이름이 겹치므로 설정 로딩이 거절된다