사용한 기술: webflux, loki(그라파나 로그로 v2 확인)
외부 클라이언트 버전을 업그레이드했다.
배경
우리 서비스에서(서비스 A) B 서비스를 호출하고 있다.
서비스 B에서 대규모 변화가 일어났고, 서비스 B는 우리에게 v2를 사용하라고 안내했다.
그래서 우리팀은 서비스 A를 호출하는 경로를 v2로 바꾸는 작업을 시작했다.
작업 방법
버전이 바뀌면서 서비스 B의 요청 포맷 및 응답 포맷이 바뀌었다.
하지만 문제는 우리 서비스(서비스 A)의 응답 포맷은 바뀌면 안 된다는 점이다.
서비스 C -> 서비스 A -> 서비스 B 의 구조다.
여기서 서비스 B의 응답은 v2로 바뀌었지만, 서비스 A에서 서비스 C로 주는 응답은 바뀌면 안 된다.
변환해주는 클래스를 하나 더 만들다.
서비스 C -> 서비스 A -> 서비스 B
이 구조에서, 우리는 서비스 B v2 응답을 기존 구조에 맞춰주기 위해 변환 역할을 하는 클래스를 하나 더 만들었다.
service.request(v2Request)를 호출하면, 실제로 서비스 B가 v2Response를 응답하더라도 v1Response를 응답하도록 했다.
개발이 끝나고 QA도 순조로웠지만.. 복병이 있었다.
운영 QA를 특정 지역에서만 하고 싶다는 요구사항
v2 호출을 특정 지역에서만 하고 싶다는 요구사항이 있었다.
서비스 B를 호출하는 부분은 돈을 차감하는 기능이었기 때문에, 서비스 B를 사용자 전부(100%)에게 영향이 가도록 배포하는 것은 무리가 있었다.
기획자 분은 v2 호출을 특정 지역에서 하고 싶다고 요청했다. 그리고 운영 QA가 된 다음에 전체 배포가 되어야 할 것 같다고 말했다.
그 이후, 특정 지역에서만 v2 호출이 되도록 개발했다.
기존 작업은 (1) v2 호출하는 코드로 수정 (2) v1 호출 코드 삭제 등으로 작업했기 때문에,
우리는 v1 호출 코드를 원복한 후 v1, v2 호출 코드를 동시에 사용해야 했다.
더 잘하려면
사용자 100% 대상으로 한 번에 배포되도 괜찮은 건지 미리 확인한다.
배포 이후를 생각한다면 충분히 '이 기능이 사용자 100%에게 나가도 안전할까?'를 생각해볼만 했다.
하지만 당시에는 생각하지 못했다.
