마저 가보자! 테스트 전략 수립
이어지는 내용입니다. 전 포스트를 확인해주세요. Spring 5 업그레이드 고군분투 (2)
한번 테스트를 위한 스펙만 나열해보자!
- MySQL, Redis를 사용
- 25%의 낮은 유닛 테스트 커버리지(더이상 쓰지 않는 코드의 테스트 커버리지가 더 높았음)
- 400+ 여개의 API
- 500 ms 내의 응답
크게 이정도가 될 것 같다. 이로 인하여 파생되는 문제들은 다음과 같다.
- 쓰기, 읽기가 다를 수 있는 문제
- 성능이 안좋아져 SLA를 지킬 수 없는 문제
- 커버리지가 너무 낮아 안전하게 배포할 수 없는 문제.
그래서 다음과 같은 테스트를 진행할 수 있다.
- MySQL(모든 테이블 대상), Redis(모든 캐쉬 대상) 쓰고 읽기
- 부하테스트
- API 케이스 별로 다 테스트 하기
이 테스트들을 어떻게 접근하고 진행했는지 공유하고자한다.
Read/Write 테스트
웹서버는 Stateless하지만 Redis와 DB는 State, 영속성이 있다. 즉 해당부분이 오염될 시, 돌이킬 수 없는 강을 건너고 만다.
그렇기에 모든 테이블 및 캐쉬 키를 테스트 해야했다.
대략 40여개가 되는 테이블에 각각 로우를 저장해보고 삭제하였다. 테이블에 대해서는 워낙 역할이 잘 분배되었기에 별탈 없이 테스트 하였다. 하지만 문제는 캐쉬 키였다. 캐쉬가 생기게 되는 조건과 삭제되는 조건에 대해서 모든 코드를 다 살펴야 했다.
이때 기지를 하나 발휘하였는데, 캐쉬키를 조회/생성/삭제하는 API를 테스트 용도로 사용하였다. 이로써 캐쉬가 생성되고 삭제되는 로직을 살펴보지 않아 이로 인한 비용을 많이 아낄 수 있었다.
부하테스트
부하 테스트는 많은 테스트 툴이 있다. 그 중에서 타 외국기업에서 일한 동료가 추천한 vegeta를 사용하였다. report가 되며, nGrinder처럼 과하지 않으며, 단순하게 사용하실 분들에게 추천드린다. 무엇보다 세팅을 파일기반으로 하기에 vegeta가 좋아 해당 작업으로 진행하였다.
부하테스트를 진행하였을 때, 모든 API를 테스트 하는 것은 사실상 불가능이였다. 그렇기에 다음과 같은 방식으로 테스트 타겟을 뽑았다.
- SLA가 존재하는가?
- 물건을 구매하는 것에 있어 치명적인 API인가?
- 캐쉬에 많이 의존하는 API인가?
이렇게 10개의 API를 기준으로 삼았으며, ASIS(Spring4, Jedis)와 비교하여 TOBE(Spring5, Lettuce)를 비교하였다. 부하는 해당 API가 한 인스턴스에 불리는 정도의 2배로 세팅하여 부하를 주어 테스트 해보았다.
결과 TP 95, TP 99값이 대략 8% 감소하는 것을 확인하여, 성능에는 큰 이상이 없는 것을 확인하였다.
API 케이스 별로 다 테스트 하기
사실 이 부분이 핵심이다. 너무나 테스트 할 API와 테스트 케이스가 많았다. 더불어 이 테스트 케이스는 최신화가 더욱 안되어서 정말 답이 없었다. 이에 오히려 반대로 생각했다.
모든 경우의 수는 포함될 수 없으며, 영속성은 확인하여 롤백이 자유로우니 많이 사용되며 치명적인 API 위주로 테스트 하자
이렇게 하여 해당 서비스에 꼭 필요한 20여가지의 테스트 케이스와 액션을 정의하였고, 이로서 치명적인 장애를 막을 수 있었다.
교차 테스트
그리고 가장 많이 놓치는 테스트가 교차 테스트일 것이다.
우리의 코드는 무중단 배포이기에, 항상 두개의 다른 버전이 서로 떠있을 수 밖에 없다. 즉 A버전에서 생성한 데이터가 B버전에서 제대로 읽을 수 있는 지 확인해야한다는 것이다.
이 교차 테스트를 통해 해당 케이스에 대해서 알게 되었다.
카나리 배포
그리고 마지막 검증 방법은 카나리 배포이다. 전사적으로 K8s를 쓰고 있으며, 현재는 RollingUpdate로 진행하고 있다. 사내에서 기본적으로 15분의 카나리 시간을 의무적으로 가진다. 시니어 개발자 분의 조언으로 카나리를 24시간 이상 두어 그만큼 커버되지 않은 케이스에 대해서 확인할 수 있었다.
마치며
그리고 결국 나는 3번의 작은 사고를 맞이한다. 이는 스프링 업그레이드 장애로 부터 살아남기 시리즈로 마저 기재하겠다!