포워드 프록시 여러 대 앞에 NLB 를 두는 설계였고 CONNECT 터널 방식이라 ALB 처럼 요청을 해석하는 계층을 쓸 수 없다는 것은 앞서 확인해 둔 상태였다. 그다음 결정들이 줄줄이 이어졌다.
Table of contents
Open Table of contents
배경 — 대상 유형이 가른 것
NLB 에 대상을 붙이는 방식이 instance 유형과 ip 유형 둘이었다. 둘의 실질적인 차이는 클라이언트 주소가 보존되는지였고 AWS 공식 문서대로 preserve_client_ip.enabled 는 ip 유형에 TCP 일 때만 기본 꺼짐이고 나머지는 기본 켜짐이다.
프록시 설정을 보니 src 기반 http_access 를 쓰려 하고 있었으므로 클라이언트 주소를 봐야 했다. 보존이 안 되면 전부 NLB 주소로 보이고 접근 제어가 무의미해지므로 instance 유형으로 정했다.
원인 — 형식이 달라 막힌 헬스체크
다음 문제는 로드밸런서가 대상이 살았는지를 확인하는 방법이었다. 프록시 포트로 GET /health 같은 상대 경로 요청을 보내면 프록시가 400 을 반환한다.
포워드 프록시는 절대 주소나 연결 요청 형식을 기대하므로 상대 경로 요청을 잘못된 요청으로 본다. 그러면 헬스체크가 항상 실패해서 모든 대상이 죽은 것으로 보고된다.
조치 — 두 대안과 그 교환
대안이 둘이었다. 포트가 열려 있는지만 보는 TCP 체크는 간단한 대신 프로세스가 떠 있고 응답만 이상한 경우를 못 잡는다.
프록시와 별도로 :8081 에 작은 서버를 띄우는 전용 헬스체크 포트는 정확한 대신 관리할 구성 요소가 하나 늘어난다. 어느 쪽도 완벽하지 않으므로 둘 다 적고 결정은 넘겼다.
주의 — 배포와 충돌한 고정 주소
가장 큰 제약이 남아 있었는데 이 프록시들이 고정 EIP 를 외부에 노출해야 한다는 것이었다. 상대가 그 주소를 허용 목록에 넣기 때문이다.
그 주소는 한 번에 하나의 인스턴스에만 붙으므로 완전 병렬 배포가 불가능하다. deregistration_delay 는 인바운드를 보호하는 장치라 나가는 주소의 연속성은 지켜 주지 않으므로 방향이 다르다.
검증 — 빈도로 정한 선택
두 안으로 좁혔는데 NAT 게이트웨이로 나가는 주소를 분리하면 인스턴스 수명과 무관해져 완전 무중단이 되지만 비용이 지속적으로 나간다. 인스턴스 주소를 유지하고 순차 교체하면 저비용인 대신 교체 시점에 짧은 단절이 생긴다.
이번에는 뒤쪽을 골랐다. 이유는 교체가 자주 있는 것이 아니고 단절이 짧아서다. 대신 교체 때마다 몇 초의 단절을 감수했다. 완전 무중단이 항상 답이 아니라 얼마나 자주 필요한지를 보고 정하는 것이다. 실측하다가 모든 노드가 http_access allow all 로 설정된 것도 발견했는데 지금은 망 안에 있어 괜찮지만 구성이 바뀌면 위험하므로 범위 밖 항목으로 따로 보고했다.
정리
- 로드밸런서의 대상 유형이 클라이언트 주소 보존을 가른다
- 출발지 기반 접근 제어를 쓰면 보존되는 유형을 골라야 한다
- 포워드 프록시 포트에는 일반 헬스체크를 못 보낸다
- 대안은 전송 계층 체크와 전용 헬스체크 포트다
- 고정 나가는 주소와 완전 병렬 배포는 상호배타적이다
- 드레이닝은 인바운드만 보호한다
- 완전 무중단이 항상 답이 아니라 빈도와 비용을 본다
- 조사 중 발견한 범위 밖 보안 사항은 따로 보고한다