인수한 서비스에서 외부로 나가는 우회 서버가 nginx 의 stream 블록에 listen 8081 과 8082 와 8083 으로 열려 있었다. 각 포트의 설정을 비교하니 완전히 같았다.
Table of contents
Open Table of contents
배경 — 설정이 같은 세 포트
설정이 같은데 포트를 셋으로 나눈 것은 이유가 있을 수밖에 없다. 설정 파일만 보면 그 이유가 안 보인다.
같은 것이 셋 있는 구성은 대개 설정이 아니라 그 앞이나 뒤가 다르다. 그래서 포트 뒤에 무엇이 붙어 있는지를 봤다.
해 본 것 — 뒤에 붙은 노드 조합이 달랐다
포트별 proxy_pass 가 가리키는 upstream 을 보니 server 목록의 조합이 각각 달랐다. 하나는 두 노드만 붙어 있고 다른 하나는 셋이고 나머지는 넷이었다.
각 노드는 고정 공인 IP 를 하나씩 가지므로 나가는 요청이 그 주소로 보인다. 설정은 같고 나가는 주소의 집합만 다른 구성이었다.
원인 — 상대의 허용 목록 크기
이유는 상대 쪽에 있었다. 거래처는 허용 IP 목록을 등록받는데 등록 개수에 제한이 있는 곳이 있었다.
넷을 다 등록할 수 있는 곳에는 out_wide 를 쓰고 둘까지만 되는 곳에는 out_narrow 를 쓴다. 외부의 제약이 우리 쪽 구성을 정한 셈이다.
조치 — 라우팅 대신 앞단 구성
거래처마다 다른 노드 집합을 쓰게 하는 방법은 요청마다 라우팅하는 것과 포트로 나누는 것 둘이었다. 전임자는 뒤쪽을 택했고 나도 그대로 두는 쪽을 골랐다. 이유는 우회 서버가 아무것도 몰라도 되고 어느 포트로 보내느냐가 곧 어느 노드로 나가느냐가 돼서다.
대신 호출하는 쪽이 거래처와 포트의 대응을 알아야 하고 그 대응표를 application.yml 에서 관리해야 하는 것을 감수했다. 새 연동을 붙일 때는 등록 가능 개수 확인이 가장 먼저인데 그것을 안 하고 넓은 포트를 쓰면 등록 안 된 노드로 나갈 때만 403 으로 거부된다.
막힌 지점 — 슬롯 여유와 무중단 전환
그 거부는 어느 노드로 나가느냐가 매번 달라서 간헐적으로 나타난다. 간헐적인 인증 실패는 이 구성을 의심할 신호가 된다.
주소를 바꿀 때도 제약이 있는데 무중단으로 하려면 새 주소와 옛 주소를 둘 다 등록해 두고 전환한 뒤에 옛 것을 빼야 한다. 등록 슬롯이 꽉 찬 거래처는 그것이 불가능하므로 여유가 있는 곳과 없는 곳을 미리 갈라야 전환 계획이 선다.
정리
- 설정이 같은데 여러 포트가 있으면 뒤에 붙은 노드 조합을 본다
- 같은 것이 여럿이면 설정이 아니라 앞뒤가 다르다
- 외부의 허용 목록 크기가 우리 구성을 정하는 경우가 있다
- 라우팅 로직 대신 앞단 구성으로 나누면 서버가 단순해진다
- 대신 호출하는 쪽이 대응표를 알아야 한다
- 새 연동은 등록 가능 개수 확인이 먼저다
- 간헐적 인증 실패는 이 구성을 의심할 신호다
- 슬롯이 꽉 찬 곳은 무중단 전환이 안 되므로 미리 갈라 둔다