현재 팀의 특성상 기존 코드에 새로운 기능을 덧대는 일보다는 항상 새로운 기능을 만들고 나가는 일이 많았다. 하지만 이번에는 기존 코드가 조금 변경되어 기능이 나갔는데, 기존 기능과의 하위 호환성을 고려하지 않고 배포가 나갈뻔 했다.
배포를 할 때는 서버/프론트의 배포 순서도 생각해야하고, 하나만 먼저 나갔을 때 경우도 생각해야한다.
이번에 내가 만든 기능의 경우 만약 프론트가 먼저 나갔다면 화면에서 undefined 값을 유저가 볼 뻔했고, 서버가 먼저 나갔다면 그 값에 따라 분기가 있었다면 스펙과 다르게 동작을 할 뻔했다. 특히 카나리를 조금씩 올렸을때 고객마다 경험이 크게 차이가 날 수도 있다.
1. 프론트가 먼저 배포가 되어도 괜찮은 경우
-
진입점이 없는 경우
- 물론 엔드포인트를 어떻게 어떻게 찌르면 당연히 api는 호출되겠지만 이건 해킹의 경우이기 때문에 생각하지 않는다. 화면에서 서버 api에 대해 호출이 전혀 할 수 없다면 프론트가 먼저 배포나가도 괜찮다.
-
Api 변경 사항이 없는 경우
- 당연하지만 화면상의 변경이라면 프론트가 먼저 나가도 상관없다.
2. 서버가 먼저 나가도 되는 경우
- 완전 신규 API
- 진입점이 없다는 말과 동일하다
- Api 필드에 변경이 없는 경우
- 필드 추가만 있는 경우
- 필드가 추가되어도 프론트에서는 문제가 생기지 않는다.
3. 협의가 필요한 경우
- Api에 변경이 있는경우
- json에서 key가 바뀐다면 당연히 프론트 개발자에게 말해줘야하고, 어떻게 할지 협의해야 한다.
- value에 따라 분기가 생기는 경우도 마찬가지다.
Graceful 배포
결국 위의 내용들을 종합해서, graceful 한 배포 방법을 정리해보자.
-
Api 버전을 신규로 딴다 (신규 api는 먼저 나가도 되는걸 이용)
- /v2/...
- 버저닝을 하는 것이 restful 하지 않다고는 하지만 그래도 편하다.
- 다만 v2를 나간이후 로그를 추적하여 v1이 안쓰이는지 확인하고 fade out 과정이 필요하다.
-
Api 필드를 신규 필드로 추가한다.
- v1: {"name": "thor", "age": 30}
- v2: {"name": "thor", "age": 30, "newAge": 32}
- v2: {"name": "thor", "age": 30, "v2Name": "thor2", "v2Age": 31}
- 이 방법은 비추다. 나중에 fo를 하기 어렵다
-
Redis Trigger를 이용한다.
- 프론트가 배포되고 나면 레디스를 이용해서 어떤 키를 바라보다가 밸류값을 변경해서 시작할 수 있다.
-
프론트랑 잘 소통한다. 어떤 필드가 추가되었을 때 어떻게 동작할지 미리 잘 확인하는 것이다.
- 장점: 나가면 끝이고 모니터링만 간단하게 하면된다.
- 단점: 커뮤니케이션 비용이 발생하고, 배포에 depenency가 생기고, side-effect를 점검해야 한다.
하지만 간단한 기능 변경이라면 이 방법도 충분히 좋다.
