고정된 주소와 지켜볼 수 있는 것

연동하는 쪽에서 나가는 주소를 고정해 달라고 했다. 그쪽 방화벽에 등록하기 위해서였다.

Open Table of contents

상황 — 요구가 둘이었다

만족시켜야 할 요구가 둘이었다.

상대 요구   우리가 부를 때 나가는 주소가 고정이어야 한다
우리 요구   그 호출이 잘 되고 있는지 봐야 한다

지금은 web01 과 web02 두 대라 나가는 주소가 둘이고 서버를 늘리면 또 늘어난다.

주소를 고정하는 것만 보면 한 곳으로 모으면 되지만 그러면 우리 쪽에서 어느 서버가 불렀는지가 안 보이게 된다.

web01 과 web02 를 구분하던 것이 나가는 주소였기 때문이다. 두 요구가 서로 당기는 구조라 한쪽만 보고 정하면 다른 쪽이 무너진다.

web01 과 web02 가 밖으로 나갈 때 한 곳을 거치게 했다.

서버 A ─┐
        ├─→ 나가는 게이트웨이 (고정 주소) → 상대
서버 B ─┘

게이트웨이 주소만 등록하면 되고 서버를 늘려도 상대에게 다시 알릴 필요가 없다.

등록하는 데 며칠이 걸리는 일이라 이 차이가 컸다. 서버를 늘릴 때마다 상대 쪽 절차를 밟아야 한다면 늘리는 것 자체가 부담이 된다.

게이트웨이 를 거치는 한 단계가 늘어난 것은 그 값으로 받아들였다. 그 한 단계가 늘어난 지연보다 등록 절차에 묶이는 쪽이 컸다.

모으니 게이트웨이 가 죽으면 전부 못 나간다.

게이트웨이 1   x.x.x.10
게이트웨이 2   x.x.x.11

x.x.x.10 과 x.x.x.11 두 대로 두고 둘 다 등록해 달라고 했다.

늘리는 것을 미리 감안해 대역으로 등록해 달라고 요청했지만 그쪽 정책상 개별 주소만 된다고 했다.

그래서 앞으로 쓸 주소를 미리 몇 개 확보해 한 번에 등록했다. 나중에 하나씩 요청하면 매번 며칠씩 걸리고 그때마다 그쪽 일정에 끌려간다.

호출이 잘 되는지 보려면 우리 쪽 기록이 필요했다.

호출한 시각
어느 서버가 불렀는지
어느 게이트웨이로 나갔는지
응답 코드와 걸린 시간

넷을 남겼는데 어느 서버가 불렀는지가 이번 구성 때문에 새로 필요해진 것이다.

게이트웨이를 거치면 상대 쪽 로그에는 x.x.x.10 만 남는다. 주소로 구분하던 것이 없어졌으니 우리 쪽에서 따로 남겨야 한다.

X-Origin-Node: web01
X-Request-Id: a8f2c1...

X-Origin-Node 와 X-Request-Id 를 실어 보냈고 상대가 그것을 로그에 남겨 주면 맞춰 볼 수 있다.

주소를 고정하면서 잃은 정보를 다른 자리에서 되찾는 작업이 함께 필요했다.

ip route 설정만 보고 믿지 않았다.

$ curl -s https://api.ipify.org
x.x.x.10

api.ipify.org 를 각 서버에서 불러 밖에서 보이는 주소를 확인했다.

한 대에서 x.x.x.10 이 아닌 주소가 나온 적이 있었다.

$ ip route show
default via 10.0.0.1 dev eth0

ip route 의 기본 경로가 게이트웨이가 아니라 원래 라우터로 되어 있었다.

설정을 그렇게 해 뒀다는 것과 실제로 그 주소로 나간다는 것은 다른 사실이다. 예외 경로가 하나 남아 있으면 일부 요청만 다른 주소로 나간다.

그 한 대만 상대 방화벽에서 막혀 간헐적 실패로 보였을 것이다. 전체가 안 되면 금방 알지만 일부만 안 되는 것은 원인을 찾는 데 오래 걸린다.

우리 쪽 curl 결과가 맞아도 상대 등록이 안 됐으면 안 된다.

$ curl -sv https://partner.example.com/api/ping 2>&1 | grep -E "HTTP|Connection"

partner.example.com 에 실제로 붙여 보니 하나는 되고 하나는 안 됐다.

x.x.x.11 이 상대 등록에서 빠져 있었고 우리 쪽만 보면 반쪽이라 양쪽에서 확인해야 완료였다.

연결이 끊겼을 때 알게 하는 것도 넣었다.

$fails = $this->countRecentFails($partnerId, 300);
if ($fails > 10) {
    notify("협력사 연동 실패 {$fails}건 (최근 5분)");
}

countRecentFails 가 센 값이 열을 넘으면 알림이 간다.

업무 호출이 없는 시간에도 cron 으로 살아 있는지 보는 것을 따로 뒀다.

*/30 * * * * /usr/local/bin/check-partner-api.sh

상대가 방화벽 설정을 바꿔 막힌 일이 있었는데 check-partner-api.sh 로 몇 시간 만에 알았다. 업무가 없는 시간의 상태를 알아야 장애 시각을 좁힐 수 있다.