들어가면서 프로그래머스 마지막 프로젝트의 서비스인 찌릿을 개발하면서 주요 기능인 조회 기능의 성능을 개선해보려고 합니다. 현재 프로젝트에서 동적 쿼리를 사용하기 때문에 QueryDSL을 사용하여 쿼리를 작성하였습니다. 하지만 테이블을 설계하고 쿼리를 짤 당시에는 인덱스와 쿼리의 성능을 고려하지 않은 채 개발을 진행하였죠. 그리고 어떻게 튜닝해야 할지 감도 잡히지 않는 상태였기 때문에 먼저 성능 테스트를 진행하고 성능을 개선해 보기로 하였습니다. 성능 테스트 툴은 ngrinder를 사용하여 진행하였습니다. 쿼리 튜닝 과정의 이해를 돕기 위해 현재 사용 중인 ERD를 보여드리도록 하겠습니다. 성능 테스트 결과부하 테스트를 진행하기 전 먼저 데이터를 상품 테이블은 200만 건, 나머지 테이블들은 100만 건..

이번 프로젝트를 진행하면서 쿼리 튜닝을 할 예정인데 쿼리 튜닝을 하기 전 먼저 N + 1 문제를 해결하려고 했다. 하지만 발생하는 쿼리들을 확인하기 위해 로그를 하나씩 뜯어봐야 하는 번거로움이 발생했다. 그래서 효율적으로 N + 1 문제가 발생하는 부분을 찾을 수 있는 방법을 찾아보다가 쿼리 카운터라는 하나의 API에서 총 몇 번의 쿼리가 발생하는지 쉽게 볼 수 있는 게 있다고 해서 프로젝트에 도입해 보기로 했다. 또 쿼리 카운터는 쿼리 개수를 모니터링하기에도 효과적이다. 쿼리 카운터 구현 방식쿼리 카운터는 일반적으로 두 가지의 방식으로 구현할 수 있다.StatementInspector를 사용하는 방법Spring AOP를 사용하는 방법결론부터 말하자면 필자는 Spring AOP를 사용하여 개발하였다. S..

이번에는 Prometheus(프로메테우스)와 Grafana(그라파나)를 이용하여 모니터링 서버를 구축해 볼 것이다. 사람마다 모니터링하고자 하는 대상이 다 다르기 때문에 필자의 글을 모니터링 구축의 가이드라인이라 생각하면서 읽고 자신만의 모니터링 시스템을 구축하면 좋을 것 같다. 필자는 AWS의 EC2 인스턴스와 Spring 서버를 프로메테우스와 그라파나를 사용하여 모니터링하였다. Prometheus프로메테우스는 시스템 및 서비스의 상태를 모니터링하는 오픈소스 모니터링 도구이다.모니터링은 서버와 연결한다고 해서 바로 되는 것이 아니라 서버의 상태를 측정하고 그것을 기반으로 서버의 성능을 측정해 나가는 것이다.서버의 상태들을 나타내는 것을 메트릭(Metric)이라 한다. 메트릭은 아래 사진과 같이 되어 있..

많은 사람들이 API 문서 툴로 Spring Rest Docs와 Swagger를 주로 사용한다. 필자는 적용하기 편한 Swagger를 주로 사용하였다. 하지만 Swagger에는 단점들이 명확히 존재했고 Spring Rest Docs 또한 찾아보았지만, 단점은 존재했다. 그러던 도중 Rest Docs의 단점인 부족한 UI를 채워줄 방법이 없을까 하다가 Spring Rest Docs에 Swagger UI를 입힐 수 있다는 것을 알게 되어 적용해 보기로 하였다. Spring Rest Docs VS Swagger먼저 필자가 Swagger가 아닌 Spring Rest Docs를 사용하게 된 이유를 정리해 보았다. 장점Spring Rest Docs프로덕션 코드에 영향이 없다.테스트를 강제화할 수 있다.Swagger..

프로그래머스의 3차 프로젝트의 요구사항은 자바 프로젝트를 코틀린으로 마이그레이션 하는 것이었다. 실제 코틀린 사용량도 늘어나는 추세이고 새로운 프로젝트를 진행할 때 주로 코틀린을 사용한다고 한다. 그래서 필자도 이번 기회에 코틀린을 공부하기로 하였다. 마이그레이션을 진행하기 전 코틀린을 왜 사용하는지 Kotlin의 장점에 대해 알아보겠다. 코틀린이 좋은 이유Null-Safety가장 큰 이유는 아마 Null-Safety가 아닐까 생각한다. 개발자들이 개발하면서 가장 많이 겪는 예외 중 하나인 NullPointerException을 미리 방지할 수 있다. 아래처럼 변수 타입 뒤에 '?' 를 붙이게 되면 null을 허용할 수 있고 그렇지 않으면 null을 허용하지 않아 만약 null을 넣게 되면 컴파일 에러가..

프로그래머스 백엔드 데브코스 2, 3차 팀 프로젝트가 끝이 났다. 사실 2차와 3차 회고를 나누어서 쓸려고 했지만, 너무 바빠서 쓸 시간이 없었다. 그래서 2차와 3차 회고를 같이 쓴다는 점 양해 바란다. 이제 한번 얘기해 보겠다. 2차 프로젝트기획2차 프로젝트는 1차 프로젝트가 끝나자마자 바로 랜덤으로 팀이 정해져서 시작했다. 그래서 팀원 간의 어색한 분위기를 지울 수 없었고 그 상태에서 바로 프로젝트를 시작해서 소통의 부족함이 있었지만 그래도 지금은 많이 서로 편안해진 것 같다. 우리 팀은 먼저 어떤 걸 만들지 정했는데 수많은 후보 중에서 자신이 들은 노래를 날마다 기록하고 공유하는 서비스인 뮤직 캘린더를 만들기로 했다. 주요 기능들을 노션에다가 먼저 정리했는데 간단하게 작성한 것이고 프로젝트 기간이..

프로젝트를 진행하면서 코드 컨밴션을 맞추는 이유는 코드의 가독성과 이해도를 높인다고 생각한다. 또 유지보수성도 높아지기 때문에 코드 컨밴션을 맞추는 것은 중요하다. 그래서 나는 프로젝트에 코드 컨밴선을 맞추게 도와주는 린트(Lint)를 적용하기로 했다. 먼저 Java 코드의 코드 컨밴션을 맞춰주는 린트인 check-style과 sonarlint를 찾아보았다. CheckStyle VS SonarLintSonarLint IDE 플러그인으로만 사용 가능코드 스멜, 보안 취약점 검사 가능SonarQube와 연동하여 더 많은 기능 사용 가능CheckStyle코드 스타일, 코드 컨밴션 검사 가능빌드 시 컨밴션도 검사 가능컨밴션이 맞지 않을 시 PR의 머지를 강제로 막을 수 있다.xml의 파일로 설정하기 때문에 커스..

프로그래머스 데브코스 백엔드 엔지니어링 과정에 참여한 지 어느덧 2개월이 넘었고, 1차 프로젝트가 끝남과 동시에 1차 스프린트도 끝이 났다. 벌써 데브코스의 반이 지나갔지만 허무하게 소비한 시간도 있고 알뜰하게 사용한 시간도 있었다. 그럼 이제 하나하나씩 풀어보도록 하겠다. 시작처음 데브코스에 합격하고 쉰 시간만큼 열심히 해야겠다고 다짐했다. 하지만 수업은 9 to 6를 모두 온라인으로 진행하다 보니 집중력이 부족해지는 경우가 많았다. 또 초반에는 기초반과 숙련자 반으로 나누어서 기초반은 수업을 듣고 숙련자들은 따로 과제를 주는 방식으로 진행되었다. 나는 과제를 풀면서 평소에 깊게 공부하지 못한 자바의 GC나 Virture Thread의 정의뿐만 아니라 사용하는 이유 등 자바를 깊게 공부하는 시간을 가졌..