Haneul's Blog

deleteAll 삭제 시 문제 JPA를 사용하여 여러 개의 데이터를 삭제하려고 할 때 JPA의 deleteAll 기능을 사용하려고 해보니 제 생각과 다르게 쿼리가 생성되고 있었습니다. 제 프로젝트를 예시로 들면 아래와 같습니다. scheduleRepository.deleteAllByCalendar를 예시로 들면 저는 이 메서드를 통해서 매개변수에 들어갈 Calendar 엔티티와 연관된 Schedule 엔티티들의 모든 데이터를 DB에서 삭제시키려고 했었고, 다행히도 deleteAllByCalendar라는 코드를 통해서 쉽게 해결할 수 있었습니다. 하지만 제가 생각한 결과는 맞지만, 내부적으로 동작하는 과정이 제가 생각한 방법과 다르게 진행되고 있었습니다. 저는 deleteAllByCalendar라는 메..

Jacoco란? Jacoco는 프로젝트의 커버리지를 체크하는 라이브러리입니다. 이를 사용자의 편의를 위해서 커버리지 결과를 html, csv, xml 등과 같은 리포트를 생성해줍니다. 커버리지가 높을 수록 테스트 코드가 프로젝트의 코드를 잘 테스트 하고 있다는 지표로 활용할 수 있고, 커버리지가 일정 수준에 도달하지 않으면 배포를 할 수 없도록 제한을 걸 수도 있습니다. Jacoco Gradle 설정 - https://techblog.woowahan.com/2661/ Gradle 프로젝트에 JaCoCo 설정하기 | 우아한형제들 기술블로그 {{item.name}} 안녕하세요. 상품시스템팀에서 서버 개발(..새발)을 하고 있는 연철입니다. 프로젝트 세팅 중에 찾아보고 삽질했던 내용들이 도움이 될까 하여 남깁..

N+1 문제 JPA를 사용하게 되면 자연스럽게 마주하는 문제가 바로 N+1이라고 할 수 있는데, 이는 연관 관계에서 발생하는 이슈로 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수만큼 연관관계의 조회 쿼리가 추가적으로 발생하여 데이터를 읽어오게 되는 것입니다. 제 프로젝트에서도 JPA를 사용하고 있었기에 자연스럽게 N+1 문제가 발생하였는데 아래의 사례와 같습니다. 1. memberRepository.findById(memberId) subscriptions를 찾기 위해서는 아래의 findSubscriptions 메서드를 호출해야 하는데, 그렇게 되면 위 이미지의 (1)을 보면 알 수 있다시피 memberRepository.findById(memberId)를 통해 아래와 같은 쿼리를 DB에..

무중단 배포란? 말 그대로 배포 중에 서비스 기능은 멈추지 않고, 실제 사용자들이 정상적으로 서비스를 사용할 수 있는 편의를 제공하는 배포 방법입니다. 2개 이상의 서버 그렇다면 이를 위해서는 어떻게 해야 할지를 생각해볼 때 서비스를 다시 배포하기 위해서는 서비스를 중단했다가 다시 실행할 필요성이 있습니다. 이걸 다르게 생각해보면 하나의 서버로는 무중단 배포가 불가능 하다는 것을 알 수 있고, 최소 2개 이상의 서버가 필요합니다. 로드 밸런서의 필요성 만약 로드 밸런서가 없이 무중단 배포를 한다고 생각하면 프론트 측에서는 백엔드의 서버 주소를 모두 알고 있어야 되고, 새로 빌드된 파일을 배포하려고 할 때면 유동적으로 연결된 백엔드 주소를 변경해줘야 하는데 이는 상당히 번거로울 수 있는 작업입니다. 또한 ..

Jenkins를 활용한 CI/CD 환경 구축 1. 플러그인 다운로드 Github와 Jenkins의 연결을 위한 Github Integeration Plugin와 SSH 접속을 위한 Publish Over SSH 플러그인을 Jenkins관리 -> 플러그인 관리 순서대로 클릭 후 들어가서 설치해줍니다. 2. CI/CD Item 생성 (1) Build 메뉴창의 새로운 Item을 누릅니다. Item 이름을 정하고 Freestyle project를 클릭해줍니다. General에서 깃허브 프로젝트의 주소를 입력해줍니다. GIt의 주소를 입력해주고, master 브랜치로 되어 있던걸 main으로 변경해줍니다. 빌드 유발에서 Github hook trigger for GITScm polling을 선택해줍니다. spri..

CI/CD란? 서비스를 배포하기 위해서는 개발, 테스트, 빌드 등의 여러 과정이 필요합니다. 서비스를 처음 단 한 번만 배포하면 좋겠지만, 실제 개발에서는 여러 오류가 발생하고 이를 fix해서 다시 배포하거나 기능을 추가해서 배포 또는 성능을 개선해서 배포한다던지 등의 여러 문제가 있기 때문에 배포는 여러 번 이루어지게 됩니다. 이런 배포를 하는 과정은 단순 반복이기 때문에 약간 귀찮은 감이 없지 않아 있습니다. 이러한 작업에 들어가는 시간을 단축시켜 개발에 투자할 수 있게 해주는 것이 CI/CD라고 할 수 있습니다. CI(Continuous Integration) CI는 지속적인 통합이라는 의미로, 간단하게 설명하면 빌드, 테스트의 자동화라고 할 수 있습니다. CD(Continuous Delivery ..

성능테스트가 필요한 이유 서비스를 사용하려는 이용자들은 서비스의 응답 속도가 느리다면 다른 대체할만한 서비스가 많다고 판단하고 빠르게 현재 서비스를 이탈하는 경향이 있습니다. 그렇다면 이 문제는 서비스 이용자에게 있는 걸까요? 그렇지 않습니다. 서비스를 만든 개발측에서 응답 속도를 느리게 한 잘못이라고 생각을 하고 개선을 하려는 노력을 보여야 합니다. 그것을 위해서는 현재 성능이 어떻게 되고 동접자 몇명까지 수용이 가능한지를 측정할 수 있는 방법이 필요한데 그 방법을 위해서 여러 성능 테스트 도구들이 존재합니다. 그 테스트 도구들은 Jmeter, NGrinder, Locust 등의 성능 테스트 도구들이 있지만 저는 여러 자료들을 찾기 쉽고, 초기 학습 비용이 적은 JMeter를 공부하여 적용해보기로 결정..

통합 테스트 Spring에서는 @SpringBootTest 애노테이션을 통해 간단하게 통합 테스트를 진행할 수 있습니다. 통합 테스트는 모듈을 통합하는 과정에서 모듈 간의 호환성을 확인하기 위해 수행되는 테스트로, 간단하게 테스트를 작성할 수 있는 이점이 있지만 고생을 덜 하고 번거롭지 않은 만큼 치명적인 단점들이 있는데, 당장 테스트 하고 싶은 부분이 있는데 모든 빈을 등록하고 테스트 하기 때문에 비교적 시간이 오래 걸린다는 점입니다. 예를 들어 어떤 한 도메인이나 어떤 한 서비스단 등의 테스트를 해보고 싶은데 통합 테스트를 하게 되면 테스트를 진행하는데 시간이 오래 걸리게 됩니다. 또 다른 단점으로는, 어디서 문제가 생겼는지 찾는데 시간이 걸릴 수 있다는 점입니다. 통합 테스트를 진행하여 테스트를 했..

프론트 캐싱에 관한 고민 일정 관리 스케줄에서 스케줄들을 호출할 떄 아래와 같이 달을 이동할 때 api를 호출하는 방법을 사용하다보니 프론트쪽에서 캐싱을 하지 않으면 만약에 3월에서 4월로 이동하고 다시 4월에서 3월로 이동할 때 한 번 더 api 호출하게 되어 불필요하게 3월을 두 번 호출하게 되는 문제가 있었습니다. 위의 사진을 보면 3월달 화면을 로딩시에 api를 최초 1회 요청하는 것을 보실 수 있습니다. 그리고 4월달로 이동하면 다시 4월달의 일정 api를 최초 호출하는 것을 보실 수 있습니다. 그런데 위의 마지막 사진을 보시면 3월달로 다시 돌아갔을 때 api 호출이 불필요하게 한 번 더 되는 것을 볼 수 있습니다. 이 문제를 해결하기 위해서는 한 번 호출했던 데이터를 일정 시간동안 캐싱하는 ..

계층별 vs 기능별 프로젝트 구조 프로젝트를 시작하기 전에 계층별로 패키지를 구조를 짤 것인지 기능별로 패키지 구조를 짤 것인지에 대한 고민을 하고 시작하였습니다. 그렇다면 둘 중 하나의 구조를 선택하기에 앞서 두 구조에 대한 이해를 하는 게 우선이라고 생각하여 찾아보았고 이를 뒤늦게 정리해보려고 합니다. 계층별 구조 위의 이미지는 이전의 프로젝트(면접 준비 프로젝트)에서 진행한 패키지 구조인데, 이 구조를 계층별 구조라고 할 수 있습니다. 계층별 구조는 한 눈에 패키지의 전체적인 구조를 쉽게 파악할 수 있다는 큰 장점이 있습니다. 예를 들면 presentation 패키지를 확인하여 어떤 controller가 있고, 어떤 api들이 있는지를 쉽게 파악할 수 있다는 것입니다. 하지만 프로젝트의 규모가 커질..

활동 알고리즘 스터디 1일 1 커밋 트래픽 공부 우아한테크코스 프리코스 완료 회고 알고리즘 스터디 사실 알고리즘 스터디 이외에 CS 스터디도 진행했었지만 스터디를 이끌어주시던 분이 번아웃이 온 관계로 CS 스터디가 끝나게 되어 CS 공부는 혼자 하고 있습니다. 먼저 알고리즘 스터디의 멤버에 관련된 얘기를 해보자면 기존에 알고리즘 스터디를 3명으로 진행하고 있었는데 한 분은 회사일이 너무 바빠서 더 이상 같이 하지 못하게 되었습니다. 그래서 현재는 2명으로 스터디를 진행 중이며 다행히도 남은 한 분이 잘하시고 열정적이신 분이라서 2명이서 진행해도 크게 지장 없이 스터디가 굴러가고 있습니다. 스터디 진행 방식은 일주일에 6문제씩 풀면서 두 번은 구글밋으로 만나서 서로 푼 문제를 어떤 식으로 풀었고, 서로에게..

회고를 시작하기 전에 4주차 미션에 대한 간단한 설명과 해당 미션에 대한 목표에 대해서 간단하게 설명하고 넘어가겠습니다. 4주차 미션 - 다리 건너기 게임 간단한 설명 위아래 둘 중 하나의 칸만 건널 수 있는 다리를 끝까지 건너가는 게임입니다. 이 미션은 설명을 하기보단 실행 예시를 보는 것이 이해하기 쉬울 것 같아서 아래를 보면 좋을 것 같습니다. 다리 건너기 게임을 시작합니다. 다리의 길이를 입력해주세요. 3 이동할 칸을 선택해주세요. (위: U, 아래: D) U [ O ] [ ] 이동할 칸을 선택해주세요. (위: U, 아래: D) U [ O | X ] [ | ] 게임을 다시 시도할지 여부를 입력해주세요. (재시도: R, 종료: Q) R 이동할 칸을 선택해주세요. (위: U, 아래: D) U [ O ..