뜨지 않는 설정은 배포 중에 드러난다

한 줄 요약

Envoy 는 설정 파일 한 장을 읽어 프로세스가 된다. 그 한 장은 관리 포트 · 신원 · 정적 자원 · 동적 자원 네 덩어리이고, 나머지는 전부 그 안의 층이다. 이 구조를 손가락으로 짚을 수 있으면 처음 보는 설정도 길을 잃지 않는다.

왜 이게 필요했나

프록시 설정이 잘못되면 보통 두 가지 중 하나가 일어난다. 하나는 프로세스가 아예 뜨지 않는 것이고, 다른 하나는 뜨긴 뜨는데 요청이 엉뚱한 데로 가는 것이다. 운영에서 무서운 쪽은 첫 번째다. 재시작은 보통 배포 중에 일어나는데, 그때는 이미 옛 프로세스가 내려간 뒤이기 때문이다. @type 한 글자, 들여쓰기 한 칸이 그대로 장애가 된다.

Envoy 는 이 문제를 알고 있어서 설정만 검사하는 모드를 따로 준다.

envoy --mode validate -c boot.yaml

이 명령은 설정을 끝까지 읽고 스키마까지 확인한 다음, 포트는 하나도 잡지 않은 채 종료 코드만 남기고 끝난다. 그래서 이미 Envoy 가 떠 있는 기계에서도 돌릴 수 있고, 컨테이너 이미지를 굽는 CI 단계에도 넣을 수 있다. 설정을 고쳤는데 이 명령을 돌리지 않았다면, 그 설정이 뜰지는 아직 아무도 모르는 것이다.

어떻게 동작하나

부트스트랩의 최상위 열쇠는 네 개만 기억하면 된다.

| 열쇠 | 무엇 | 없으면 |
| --- | --- | --- |
| admin | 관리 포트. 통계·설정 덤프·로그 수준 변경 | 들여다볼 창이 없다 |
| node | 이 프록시의 이름표(id, cluster) | 정적 설정만 쓰면 괜찮다. xDS 를 붙이면 필수 |
| static_resources | 파일에 적어 둔 리스너와 클러스터 | 아무것도 듣지 않는다 |
| dynamic_resources | 밖에서 받아 오는 설정(xDS) | 설정이 고정된다 |

static_resources 안은 다시 다섯 층이다. listener → filter_chain → http_connection_manager → route_config → cluster. 요청이 들어오는 순서와 정확히 같다. 주소와 포트에서 시작해, 어떤 필터 사슬이 받을지 고르고, HTTP 로 해석한 다음, 라우트 표에서 목적지 클러스터 이름을 얻고, 그 이름의 클러스터가 실제 엔드포인트로 보낸다. 설정을 읽을 때 이 순서를 지키면, 어느 층이 비어 있는지가 금방 보인다.

부트스트랩에 적은 것이 실제로 그대로 적용됐는지는 눈으로 확인하지 않는다. 관리 포트의 /config_dump 첫 절이 BootstrapConfigDump 이고, Envoy 가 읽어 낸 값 이 거기 그대로 들어 있다. 파일과 덤프를 나란히 놓고 보는 습관이 "나는 고쳤는데 왜 안 바뀌지" 를 없앤다.

현장에서 만나는 모습

한 기계에 두 번째 Envoy 를 띄우는 순간. 포트를 전부 비켜 놓았는데도 두 번째 프로세스가 unable to bind domain socket with base_id=0 으로 죽는다. Envoy 는 뜨면서 공유 메모리 영역을 하나 잡는데(핫 리스타트 때 통계를 넘겨주려고 쓴다) 그 이름이 base id 로 정해지고 기본값이 0 이기 때문이다. --base-id 로 갈라 주면 둘 다 뜬다. 같은 노드에 프록시를 두 개 두는 구성(하나는 인그레스, 하나는 이그레스)에서 반드시 만난다.

관리 포트를 밖에 열어 둔 사고. admin.address 를 편의상 0.0.0.0 으로 두는 경우가 있다. 그런데 이 포트에는 인증이 없고, /quitquitquit 는 프로세스를 끝내고 /drain_listeners 는 트래픽을 끊는다. 통계를 긁으려고 연 구멍이 곧바로 서비스를 내리는 단추가 된다. 관리 포트는 루프백에 묶고, 필요하면 그 앞에 별도의 프록시를 세워 읽기 경로만 노출한다.

--concurrency 를 모르고 실험하는 경우. 기본값은 코어 수다. 워커 스레드마다 부하 분산 상태가 따로 놀기 때문에, 요청 여덟 번을 보내 엔드포인트 셋에 고르게 갔는지 세면 숫자가 매번 다르게 나온다. 분배를 세는 실험은 --concurrency 1 로 해야 결정적이다.

"고쳤는데 안 바뀝니다." static_resources 에 적은 것은 프로세스가 뜰 때 한 번 읽힌다. 파일을 고쳐도 다시 띄우기 전까지는 아무 일도 일어나지 않는다. 그래서 운영에서는 파일과 /config_dump 를 나란히 놓고 보는 습관이 중요하다 — 덤프에 없으면 아직 반영되지 않은 것이고, 덤프에 있는데 동작이 다르면 그때부터는 설정이 아니라 다른 층을 의심할 차례다. 설정을 밖에서 받아 와 다시 띄우지 않고 바꾸는 방법이 dynamic_resources(xDS)이고, 그것은 이 코스의 마지막 모듈에서 다룬다.

공식 문서: [Bootstrap configuration](https://www.envoyproxy.io/docs/envoy/v1.38.3/configuration/overview/bootstrap) · [Command line options](https://www.envoyproxy.io/docs/envoy/v1.38.3/operations/cli) · [Administration interface](https://www.envoyproxy.io/docs/envoy/v1.38.3/operations/admin)

다음 실습에서 할 것

부트스트랩을 손으로 써서 --mode validate 로 통과시키고, 한 글자를 틀려 거절당하는 것을 본다. 그다음 두 번째 Envoy 를 띄워 --base-id 가 필요한 순간을 실제로 만나고, 마지막에는 관리 포트로 프로세스를 끝냈다가 다시 띄운다.