사용한 기술: spring webflux, elasticsearch
장애가 났다.
다음과 같은 일이 있었다.
신규 api 배포 건에서는 새로운 데이터 유형과, 새로운 로직이 추가되었다.
새로운 데이터 유형은 (새로운 주문금액 필드 + 기존 노출그룹) 조합을 가지고 있었다.
신규 api는 새로운 데이터 유형을 처리할 수 있었다.
(신규 api + 새로운 데이터 유형)에 대한 qa 테스트를 거쳤고, qa는 아무 이상없음을 보증했다.
하지만, 새로운 데이터 유형이 운영에 적용되는 당일 밤 에러가 급속도로 올라가기 시작했고, 장애가 일어났다.
그 이유는 배포 이전 api가 새로운 유형의 데이터를 처리할 수 없었기 때문이다.
상위호환이 되지 않는다는 것
새로운 데이터 유형은 이전 주문금액 필드가 null이었다.
배포 이전 api는 기존 노출그룹의 데이터는 모두 주문금액 필드가 not null이라고 가정했기에, 배포 이전 api는 새로운 데이터 유형을 읽을 수 없었다.
즉, 배포 이전 api는 새로운 데이터 유형에 대해 상위호환 가능하지 않았다.
어떤 코드가 상위호환이 될 수 없다는 건, 옛 코드가 새로운 데이터를 읽을 수 없음을 의미한다.
위에서 배포 이전 코드는 새로운 유형의 데이터를 읽을 수 없었기 때문에 에러가 났다.
따라서 위 경우에서 배포 이전 코드는 새로운 유형의 데이터에 대해 상위호환이 되지 않았다.
qa는 보통 새로운 api에 대해서만 진행되기 때문에, 위에서는 qa가 진행됐음에도 불구하고 장애가 일어났다.
상위호환이 되지 않을 때 어떻게 해야 하나?
여러 가지 방법이 있을 수 있다.
1. 먼저 새로운 유형의 데이터의 영향범위가 어느 정도인지 분석한다.
2. 만약 새로운 유형의 데이터의 영향범위가 제한적이라면, 즉 상위호환이 되지 않는 경우에도 유저 영향이 거의 없다면(에러가 매우 특수한 경우에만 일어나는 경우), 영향도에 대해서만 인지하고, 배포를 진행한다.
3. 만약 새로운 유형의 데이터의 영향범위가 매우 크다면, 하위호환 가능한 api를 먼저 배포한 후 새로운 유형의 데이터를 추가해야 한다.
** 하위호환성: 새로운 코드가 옛 유형의 데이터를 읽을 수 있다는 것을 의미한다.
결론
배포 이전 코드의 새로운 데이터 유형을 읽을 수 있는지 항상 확인하자.
그리고 확인한 상위호환성 여부에 따라 배포 전략을 수정하자!
