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