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