ActiveMQ 와 API 서버를 NCloud 의 새 VPC 로 옮기면서, 나가는 공인 IP 가 은행 원화 입출금 API 쪽에 허용 목록으로 등록돼 있어 그것을 유지해야 했다. notify-svc 하나가 걸렸는데 그것도 주소를 보존해야 하는 대상인지 확인이 필요했다.
Table of contents
Open Table of contents
배경 — 공인 주소가 없던 서비스
서버 프로비저닝 스크립트를 보니 그 서비스는 사설 서브넷에 있고 공인 IP 를 안 받고 있었다. 그러면 밖으로 나갈 때 NAT Gateway 를 거친다.
여기까지는 스크립트만 봐도 알 수 있는 내용이었다. 다만 그 서비스가 프록시를 거치는지 아닌지는 스크립트 어디에도 안 적혀 있었다.
원인 — 소스가 없는 사각지대
이 서비스의 코드가 우리 워크스페이스에 없었고 외주가 만든 것이라 서버 정의만 있었다. 코드가 없으면 어디로 어떻게 호출하는지를 확인할 방법이 아예 없다.
두 가지 방법이 있었다. 서버에서 tcpdump 로 실제 나가는 패킷을 잡아 보는 것과, 외주사 git 원격에서 해당 파일을 받아 읽는 것이다. 뒤쪽을 골랐다. 이유는 패킷은 지금 이 순간의 경로만 보여 주고 조건 분기로 다른 경로를 타는 경우를 못 잡아서다. 대신 저장소 접근 권한을 받느라 하루가 더 드는 것을 감수했다. 소스가 없는 서비스는 모르겠다는 채로 넘어가기 쉬워서 그대로 두면 이관에서 그것만 빠진다.
프록시를 안 쓰던 경로
코드를 보니 RestTemplate 의 SimpleClientHttpRequestFactory 에 setProxy() 가 없고 은행 API 주소를 직접 부르고 있었다. 같은 은행 API 를 부르는 wallet-svc 는 setProxy() 로 공인 IP 를 가진 squid 프록시를 경유하고 있었다.
그러면 두 서비스의 나가는 주소가 서로 다르고 은행에 등록된 주소도 둘이 된다. 실제로 squid 의 공인 IP 와 NAT Gateway 의 공인 IP 가 각각 따로 등록돼 있었다.
주의 — 놓치면 한쪽만 조용히 끊긴다
프록시만 챙겨서 옮기면 NAT Gateway 주소가 바뀌면서 notify-svc 하나만 막히게 된다. 나머지 서비스는 그대로 잘 도니까 이관이 성공한 것으로 보인다.
막힌 쪽은 한참 지난 뒤에 입금 알림이 안 온다는 문의로 드러나게 된다. 그래서 같은 상대를 부른다고 묶지 않고 서비스별로 주소 보존 여부를 각각 판단했다.
정의와 소스와 망 설정
그래서 조사 순서를 서버 정의와 소스와 ACG·라우팅 설정 셋으로 잡았다. 정의만 보면 사설이라는 것까지이고 소스를 봐야 프록시를 안 쓴다는 것을 알며 망 설정까지 봐야 실제로 어디로 나가는지가 나온다.
어느 단계에서든 중간에 멈추면 그다음은 확인이 아니라 추측이 된다. 사설이니까 프록시를 쓰겠지라는 문장이 그 추측의 전형이었다.
정리
- 같은 상대라도 서비스마다 나가는 경로가 다를 수 있다
- 한쪽은
squid프록시를 경유하고 다른 쪽은NAT Gateway로 직접 나갈 수 있다 - 그러면 저쪽에 등록된 주소도 둘이 된다
- 놓치면 한쪽만 조용히 끊기고 이관은 성공으로 보인다
- 같은 상대라고 묶지 말고 서비스별로 판단한다
- 서버 정의와 소스와 망 설정을 순서대로 본다
- 중간에 멈추면 그다음은 추측이 된다
- 소스가 없는 서비스가 사각지대이므로 원격에서라도 읽는다