squid 포워드 프록시 열여덟 대를 넷으로 통합하는 설계를 시작했다. 초기 가정은 ALB 뒤에 두고 무중단으로 교체 배포한다는 흔한 구성이었다.
Table of contents
Open Table of contents
원인 — L7 을 못 쓰는 이유
이 프록시는 CONNECT 터널 방식이라 클라이언트가 연결 요청을 보내면 프록시가 그 주소로 TCP 연결을 열고 바이트를 그대로 중계한다. 안쪽이 암호화돼 있어서 프록시도 내용을 못 본다.
ALB 는 HTTP 요청을 해석해서 라우팅하므로 이 방식이 그 모델에 맞지 않는다. 전송 계층에서 그대로 흘려보내는 NLB 를 써야 했다.
진짜 제약이 있던 자리
NLB 를 internal 로 둘지 internet-facing 으로 둘지를 고민했는데 그것이 핵심이 아니었다. NLB 는 대상까지 내부 라우팅으로 가므로 서브넷이 공개인지 아닌지와 무관하다.
진짜 제약은 대상 서버와 같은 가용영역에 로드밸런서 노드가 있어야 한다는 것이었다. 공개 여부가 아니라 영역 정합이 제약이었고 그것을 모르면 엉뚱한 축으로 배치를 고민하게 된다.
제약 — 고정 IP 와 무중단의 충돌
다음 문제가 컸다. 이 프록시들은 외부에 고정 주소를 노출해야 하고 상대 쪽이 그 주소를 허용 목록에 넣는다.
지금은 인스턴스에 Elastic IP 를 직접 붙이는 방식인데 그 주소는 한 번에 한 인스턴스에만 붙는다. 새 인스턴스를 병렬로 띄워도 주소를 못 붙이고 옮기려면 떼야 하며 떼는 순간 나가는 주소가 바뀌므로 완전 병렬 교체 배포가 성립하지 않는다.
주의 — 축이 다른 보호
여기서 방향을 한 번 잘못 봤다. NLB 의 deregistration_delay 드레이닝이 있으니 괜찮지 않겠느냐고 생각했다.
드레이닝은 인스턴스를 뗄 때 진행 중인 요청을 마저 처리하게 해 주는 인바운드 보호다. 우리가 지켜야 하는 것은 프록시에서 외부로 나가는 주소의 연속성이라 축이 아예 다르고 드레이닝은 그것을 지켜 주지 않는다.
판단 기준 — 교환으로 정리한 선택지
그래서 두 가지 방법을 냈다. 인스턴스의 Elastic IP 를 유지하고 순차 교체하면 비용이 낮은 대신 호스트를 교체할 때 짧은 단절이 있다.
나가는 주소를 NAT Gateway 쪽으로 옮기면 인스턴스와 무관해져 완전 무중단이 되는 대신 추가 비용이 든다. 앞쪽을 골랐다. 이유는 마켓 상대가 허용 목록을 다시 받는 일이 없고 단절이 교체 순간 몇 초라서다. 대신 그 몇 초에 걸린 요청이 실패하는 것을 감수했고 어느 쪽도 틀리지 않는 비용과 무중단의 교환이므로 의뢰한 쪽에 확인받아 결정했다.
나뉘어 있던 이유와 조사 시점
조사하면서 하나 더 나왔다. 열여덟 대가 마켓별로 나뉘어 있어서 설정이 다른가 싶었는데 전부 같은 http_access allow all 설정이었다.
설정 차이가 없고 마켓별 전용 나가는 주소를 주려는 목적뿐이었으므로 squid 공식 문서의 tcp_outgoing_address 로 ACL 별 나가는 주소를 갈라 주면 한 대로 통합이 가능하다는 뜻이었다. 초기 가정 둘이 다 뒤집혔는데 구축 중에 알았으면 설계를 다시 해야 했고 상태를 안 바꾸는 읽기 전용 조사를 착수 전에 한 것이 그것을 막았다.
정리
CONNECT터널 프록시 앞에는 ALB 같은 요청 해석 로드밸런서를 못 쓴다- L4의 배치 제약은 공개 여부가 아니라 대상과 같은 가용영역이다
- 고정 주소를 인스턴스에 붙이면 완전 병렬 배포와 충돌한다
deregistration_delay드레이닝은 인바운드를 보호한다- 나가는 주소의 연속성은 그것이 지켜 주지 않는다
- 비용과 무중단의 교환이면 의뢰한 쪽에 확인받는다
- 왜 나뉘어 있는지를 확인하면 통합 난이도가 정해진다
- 착수 전 읽기 전용 조사가 설계 가정을 뒤집는다