서비스가 둘이면 나가는 길도 둘이다

미들웨어를 다른 망으로 옮기면서 나가는 주소가 저쪽에 등록돼 있어 그것을 유지해야 했다. 서비스 하나가 걸렸는데 그것도 주소를 보존해야 하는 대상인지 확인이 필요했다.

Open Table of contents

공인 주소가 없던 서비스

컨테이너 정의를 보니 그 서비스는 사설 서브넷에 있고 공인 주소를 안 받고 있었다. 그러면 밖으로 나갈 때 게이트웨이를 거친다.

여기까지는 컨테이너 정의만 봐도 알 수 있는 내용이었다. 다만 그 서비스가 프록시를 거치는지 아닌지는 정의 어디에도 안 적혀 있었다.

이 서비스의 코드가 우리 워크스페이스에 없었고 컨테이너 정의만 있었다. 코드가 없으면 어디로 어떻게 호출하는지를 확인할 방법이 아예 없다.

원격 저장소에서 해당 파일을 직접 받아 읽었다. 소스가 없는 서비스는 모르겠다는 채로 넘어가기 쉬워서 그대로 두면 이관에서 그것만 빠진다.

코드를 보니 호출 클라이언트에 프록시 설정이 없고 상대 주소를 직접 부르고 있었다. 같은 상대를 부르는 다른 서비스는 프록시를 경유하고 있었다.

그러면 두 서비스의 나가는 주소가 서로 다르고 저쪽에 등록된 주소도 둘이 된다. 실제로 프록시의 주소와 사설 서브넷 게이트웨이의 주소가 각각 따로 등록돼 있었다.

프록시만 챙겨서 옮기면 게이트웨이 주소가 바뀌면서 그 서비스 하나만 막히게 된다. 나머지 서비스는 그대로 잘 도니까 이관이 성공한 것으로 보인다.

막힌 쪽은 한참 지난 뒤에 사용자 문의로 드러나게 된다. 그래서 같은 상대를 부른다고 묶지 않고 서비스별로 주소 보존 여부를 각각 판단했다.

그래서 조사 순서를 컨테이너 정의와 소스와 망 설정 셋으로 잡았다. 정의만 보면 사설이라는 것까지이고 소스를 봐야 프록시를 안 쓴다는 것을 알며 망 설정까지 봐야 실제로 어디로 나가는지가 나온다.

어느 단계에서든 중간에 멈추면 그다음은 확인이 아니라 추측이 된다. 사설이니까 프록시를 쓰겠지라는 문장이 그 추측의 전형이었다.