속닥속닥 기술블로그 속닥속닥 기술블로그

1. 들어가며✨ 속닥속닥은 Spring Data JPA를 사용했습니다. 그말인 즉슨, N+1 문제를 개선하고, 쿼리 개수를 모니터링할 필요가 있다는 뜻이었습니다. 이에 저와 이스트는 특정 커넥션에서 사용된 쿼리 개수를 세는 "쿼리 카운터"를 개발했습니다! sql의 count() 아닙니다 쿼리 카운터를 구현하는 방법으로 고려했던 것은 총 2가지였습니다. 하이버네이트의 StatementInspector 사용하기 직접 AOP 기반 쿼리카운터 만들기 저희는 2가지 방법 중 2번을 선택했습니다. 1번이 구현하기엔 더 편리합니다. 하지만 이후 하이버네이트 이외의 구현체를 사용하거나 사정상 직접 JdbcTemlate을 사용했을 경우에도 범용성있는 쿼리 카운터를 구현하고 싶어 AOP로 구현했습니다. 다음은 쿼리 카운터..

테스트 성능 개선하기 속닥속닥 팀 프로젝트는 400개 이상의 테스트 케이스들이 존재합니다. 따라서, 로컬에서 테스트들을 실행할 때 시간이 오래 걸렸습니다.(자세한 시간은 아래에서 알아보겠습니다). 또한, CI를 Github Action을 통해 진행하고 있는데, CI의 Test Stage에서도 오랜 시간이 시간이 소요되었습니다. 따라서, 팀원인 이스트와 함께 테스트 성능을 개선해보았습니다. 1. Context Caching 프로젝트 초반에 DB 초기화를 위해 사용했던 DirtiesContext를 제거하면서 Context를 Caching 할 수 있도록 했습니다. 하지만, 테스트 클래스마다 사용하는 Bean들이 달라서 Context Caching을 잘 활용하고 있지 못하는 상황이었습니다. 위와 같이 locat..

우아한테크코스 최종 데모데이의 요구사항으로 무중단 배포가 있다. 이를 학습하고 적용한 내용을 정리한다. 무중단 배포는 왜 필요할까? 스프린트4 때쯤, 기능을 개발하고 팀원들끼리 QA를 한 후에 운영서버에 배포를 하고 있었다. 그런데, 그 찰나의 순간에 우리 속닥속닥 서비스를 이용하고 있던 다른팀 크루가 속닥속닥 왜 안되냐는 말을 했다. 우리 서비스의 경우 사용자가 많지 않고, 잠깐 서비스가 중단된다 해서 금전적인 손해가 발생하지는 않기 때문에 큰 문제는 없다. 그런데, 서비스가 잠깐이라도 중단되면 안되는 서비스라면 어떨까? 특히, 금전적인 문제가 달려있다면? 새로운 기능을 배포하거나 버그 픽스는 위험을 감수해가며 배포 할 것이지만, 리팩터링에 대한 배포는 쉽지 않을 것이다. 무중단 배포 3가지 방법 Ro..

속닥속닥 프로젝트(https://github.com/woowacourse-teams/2022-sokdak)를 진행하면서 현재는 문제가 되지 않지만 시간이 갈수록 데이터가 쌓이면서 문제가 될 수도 있겠다라고 생각한 부분이 있습니다. 게시글에 대한 '좋아요' 기능인데요, 현재 구조에서는 게시글을 조회할 때, '좋아요' 테이블과 함께 조인을 해서 가져오고 있습니다. 단순히 좋아요 개수만 저장하지 않는 이유는, 한번 좋아요 버튼을 누른 사람은 두 번째 누를 때 취소할 수 있어야 하기 때문입니다. 하지만 이런 방식이라면 만약 게시글 하나에 좋아요가 100만개가 된다면 게시글을 조회 한번 할때마다 100만개를 조인하게되어 오버헤드가 커지게 됩니다. 실제로 유튜브, 인스타의 경우 좋아요 ..

테스트 환경 설정 환경을 어떻게 설정하고 테스트해야할지 감이 잘 오지 않아서 실험을 여러번 다시했다. 그리고 아직도 완전히 정답을 찾은 것 같지는 않지만 나름대로 이유를 세우면서 테스트를 해보려했다. 1. Nginx에 부하테스트 vs WAS에 부하테스트 처음에는 Nginx 인스턴스에 부하테스트를 했다. 하지만 이건 로드밸런싱 같은 설정이 되어있을 때 더 의미있는 테스트일 것 같다는 의견이 나왔다. 실제로 이번 부하테스트를 통해서 알고 싶은건 스레드 설정이므로 WAS에 직접적으로 테스트를 해도 좋을 것 같았다. 2. DB의 데이터 설정 DB에 데이터를 넣지 않고 테스트를 진행하니 TPS가 되게 잘나왔다. 하지만 데이터가 어느정도 들어있고 DB에서 Disk IO가 유의미하게 시간이 걸리는 상황이 우리가 테스..

프로젝트를 진행하면서 팀원들끼리 "우리 서버 터지는거 아냐?"라는 말을 많이 했다. 특히 데모데이 전날에 우리 서비스 서버가 어느정도 요청까지 처리할 수 있는지 감이 없어서 많아야 몇십명이 들어올 데모데이 전날에는 불안하기도 했다. 이번에 스레드 풀 설정 및 최적화에 관해 학습 및 테스트를 해보며 부하테스트도 같이 알아봤다. 부하테스트 툴 선정 부하테스트 툴을 선정하는데 JMeter, nGrinder, k6 중에서 고려를 했다. k6의 경우 결과 시각화를 하려면 유료로 서비스를 쓰거나 CLI로 쓰고 그라파나와 결합을 해야했다. 또 자바스크립트로 테스트를 작성해야해서 거부감을 갖는 팀원도 있었다. JMeter는 레퍼런스가 많았지만 인터페이스가 그렇게 쓰기 좋지 않은 것 같다는 생각을 했다. 또 nGrind..

우아한 테크코스 팀 프로젝트(속닥속닥)에서 Jenkins의 Multibranch Pipeline을 통해 CI/CD를 구축해두었습니다. https://velog.io/@byeongju/Jenkins의-Mulitbranch-Pipeline을-통한-CICD 현재 CI는 Github Action으로 분리가 된 상태입니다. 당시 CI/CD를 구축해두었을 때, 몇가지 문제가 있었습니다. 1. CI/CD 스크립트(Jenkinsfile)가 Git으로 관리가 된다. 2. dev와 main의 CI/CD를 한 파일로 관리하기가 어렵다. 3. FE와 BE에 대한 분기 처리가 어렵다. 순서대로 위의 문제들을 어떻게 해결한지 알아보겠습니다. 1. Git을 통한 스크립트 관리 해결 위와 같이 Git을 통해서 Jenkinsfile이..

0. intro 이번에 속닥속닥은 feature-dev 간 pr 병합 시 squash merge 방식을 채택했습니다. 이를 통해 dev 커밋기록을 깔끔하게 관리할 수 있었습니다!👍 1. 문제상황 1) main에 squash merge 다음은 저희가 main에 squash merge를 했던 과정입니다. 기존 main 커밋들이 날아간 관계로 간단히 도식화해 보여드리겠습니다. main에 hotfix 커밋을 추가 dev에서 기능(d1, d2) 구현 dev 커밋들(d1, d2)을 main으로 squash merge dev에서 이후 기능들(d3, d4) 구현 dev 커밋들(d3, d4)을 main으로 squash merge 불가! 문제는 4번, main-dev 간 병합 시 발생했습니다. (2번) 기존의 dev 변경..