코로케이션 전환으로 은행 API 로 나가는 경로를 새 squid 프록시로 바꾸고 실제로 도달하는지 확인해야 했다. 처음에는 은행 API 엔드포인트를 직접 불러 보면 되겠다고 생각했다.
Table of contents
Open Table of contents
증상 — 호출 한 번의 비용
그 엔드포인트를 부르려면 JWT 토큰이 필요하고 토큰을 얻으려면 이체 권한을 가진 서비스 계정으로 로그인해야 했다. 그 계정 식별자를 정해진 방식으로 인코딩하고 운영 비밀키로 HS256 서명하는 단계까지 밟아야 한다.
비밀키는 별도 저장소에 있고 운영 키를 꺼내는 것 자체가 조심스럽다. 검증 한 번의 비용이 검증하려는 대상보다 커진 상태였다.
판단 기준 — 이미 흐르는 트래픽
두 가지 방법이 있었다. 운영 키를 꺼내 검증용 호출을 한 번 보내는 것과, 이 경로로 이미 흐르고 있는 운영 트래픽의 로그를 보는 것이다. 뒤쪽을 골랐다. 이유는 내가 새로 부를 이유가 없어서다. 대신 트래픽이 뜸한 새벽에는 판정할 로그가 없어 기다려야 하는 것을 감수했다.
wallet-svc 로그에 upstream_response_time 과 upstream_status 가 함께 찍히고 있었다. 응답 시간이 0보다 크고 응답 코드가 2xx 면 은행에 실제로 도달했다는 뜻이 된다.
원인 — 도달 후 거부와 도달 실패
로그를 훑다가 401 이 여럿 보여서 경로가 막힌 것으로 볼 뻔했다. 내용을 열어 보니 upstream_response_time 이 이백 밀리초대로 찍혀 있었고 본문은 자격증명이 잘못됐다는 메시지였다.
은행에 도달은 했고 은행이 인증을 거부한 것이므로 우리 경로 문제가 아니었다. 응답 코드만 보면 두 경우가 같아 보이고 응답 시간을 함께 봐야 갈린다.
조치 — 검증 수단을 고르는 순서
이후로 검증 수단을 비용순으로 보게 됐다. 이미 있는 로그와 Micrometer 지표로 되는지를 먼저 보고 안 되면 부작용 없는 호출을 보고 그다음이 인증이 필요한 호출이다.
상태를 바꾸는 시도는 마지막이고 되돌릴 준비가 있어야 한다. 위에서부터 내려가면 대개 앞의 둘에서 끝나는데 이번 건도 첫째로 끝났고 처음에 셋째부터 떠올린 것이 문제였다.
연결성만 볼 때는 같은 망 안의 다른 서버에서 curl -x squid:3128 로 인증이 필요 없는 은행 상태 확인 경로를 부르면 됐다. ssh 접속 권한부터 알아보고 있었는데 그럴 필요가 없는 자리였다.
기준을 먼저 적고 데이터를 본다
로그로 판정하기로 하고 나서 무엇이 보이면 통과인지를 먼저 적었다. upstream_response_time 이 있고 5xx 가 아니면 통과이고 연결 오류나 시간 초과나 응답 시간 부재면 실패로 정했다.
401 인증 거부는 별개 사안이므로 판정에서 제외한다고 미리 적었다. 기준을 안 적고 로그를 먼저 보면 본 것에 맞춰 해석을 만들게 되어 답이 흔들린다.
정리
- 검증용 호출이 비싸면 이미 흐르는 트래픽의 로그를 쓴다
- 판정 근거는 필드 하나가 아니라
upstream_status와upstream_response_time조합으로 정한다 - 도달 후 거부와 도달 실패는 응답 코드만으로 안 갈린다
- 응답 시간이 그 둘을 가른다
- 검증 수단은 기존 데이터와 무해한 호출과 인증 호출 순으로 고른다
- 상태를 바꾸는 시도는 마지막이고 되돌릴 준비가 필요하다
- 위에서부터 내려가면 대개 앞에서 끝난다
- 판정 기준을 먼저 적고 데이터를 본다