제리 devlog

무신사 왓쳐의 데이터의 업데이트는 하루마다 이뤄지므로 캐시의 의존성이 크다. 그런데 spring에서 제공하는 @Cacheable을 사용했을 때 발생가능한 key중복 문제에 대해서 정리하고 무신사 왓쳐에서 cache key중복을 해결한 방법에 대해 소개한다. @Cacheable @Cacheable은 스프링에서 제공하는 캐시관련 어노테이션으로 aop방식으로 동작한다. 별도의 설정없이도 어노테이션을 선언하면 캐시적용이 가능하기 때문에 간편하지만 여차하면 잘못된 캐시 결과를 가져올 수 있다. 예시를 보자 @EnableCaching @Service public class CacheService { @Cacheable(value = "productCache") public long findProductCount()..

테스트 코드에 대해 작성하고 리팩토링해가면서 깨달은 점과 적용한 부분에 대해서 개인적인 생각을 정리해보려고한다. 얼마전까지는 테스트 코드를 커버리지 위주로 생각하려는 경향이 강했었다. 라인 커버리지와 브랜치 커버리지를 높여서 단순히 이 수치로 얼마만큼 로직이 검증되었는지 표현하려고했다. 하지만 이 수치가 완벽하게 시스템의 안정성을 보장해주지는 않는다는 것을 느꼈다. 1. 무엇이 테스트의 대상인가? 아마도 테스트를 하면서 가장 중요한 대목이 아닌가싶다. 달리 표현하면 어떤걸 테스트해야하는가?라는 표현도 맞겠다. 하나의 예시를 들어보자. 무신사 왓쳐에서는 오늘 역대 최저가인 상품을 제공한다. 그렇다면 이 기능을 검증하기 위해서는 무엇을 테스트 해야할까? 생각하기에 앞서 오늘 역대 최저가인 상품은 어떤 과정으..

서비스를 운영하면서 고려해야 할 중요한 문제는 장애 처리라고 생각한다. 이번 프로젝트로 장애 처리에 대한 지식을 조금이나마 얻어 갈 수 있었다. MSA구조에도 자주 사용된다는 서킷 브레이커를 적용해봤다. Redis서버에 장애가 생기면? redis서버에 장애가 생기면 위와 같이 서버에서 500 error가 발생하고 컨텐츠가 보이지 않는다. 별도의 설정을 하지 않았을 때 캐시 서버에 문제가 생겼을 때 서비스가 다운됐다. 기존 캐시 구조는 다음과 같다. 1. 클라이언트로부터 api요청이 들어온다. 2. redis에 캐시가 저장되어 있는지 확인한다. 2-1. 캐시가 있다면 캐시 값을 반환한다. 2-2. 캐시가 없다면 3으로 이동한다. 3. 캐시가 없는 경우 DB에서 조회한다. 위와 같은 구조에서 global c..

이 프로젝트를 진행하면서 사용자의 트래픽에 대해 어떻게 처리해야할지 고민했다. 그런 이유로 서버를 쉽게 확장할 수 있는 CI/CD구조도 고민하게 되었고 자연스럽게 서버 성능에 대해서도 고민하게 되었다. 프로젝트를 진행하며 부하테스트라는 것도 알게 되었는데 부하 테스트를 통해 트래픽을 어느 정도 처리할 수 있는지 정량적인 수치를 알 수 있었다. 부하 테스트 랭킹 카테고리의 아이템을 페이징하여 조회하는 API를 호출한 결과이다. 40명의 가상 유저를 만들어 테스트 해봤을 때 TPS(초당 트랜잭션 수)가 13에 불과했다. select id, brand, brand_url, category, img, modified_date, product_id, product_name, product_url, rank fro..

이번 프로젝트에 CI/CD를 도입하면서 많은 고민과 시행착오를 겪었다. 왜 처음 결정한 구조에서 변경을 했는지, 어떻게 변경을 했는지 정리해보았다. CI/CD를 도입한 이유 CI는 사전적인 의미로 지속적인 통합이다. 바꿔말하면 개발자가 코드를 작성하고 합치고 빌드하고 테스트하는 과정을 일컫는다. 이 과정이 수동으로 진행되면 코드를 작성하고 합칠 때마다 빌드와 테스트를 수동으로 진행해야 한다. 이런 귀찮은 과정을 github에 push 하기만 해도 전부 이뤄지게 자동화할 수 있다. CD는 사전적 의미로 지속적인 배포이다. CI 과정 뒤에는 CD 과정이 필요하다. 배포 프로세스도 수동으로 작업할 필요 없이 CI와 연동하여 자동화시키면 서버를 배포하는 과정을 수동으로 하지 않아도 된다. 내가 CI/CD를 도입..