👨‍👩‍👧‍👦 Project

1. 성능 최적화 계기 현재 관리자 페이지에서 예약 내역을 페이징 처리하여 조회할 수 있는 기능이 있다. limit는 20으로 한 페이지당 20개의 예약 컨텐츠를 보여주고 있다. 전체 예약 데이터는 354,200개인 상황이고 해당 API의 성능이 평균적으로 1.74초의 시간이 걸렸고 최대 1.99초까지 걸림으로써 성능이 좋지 못했다. 해당 성능을 최적화할 수 있는 방법을 모색하기 시작했다. 미리 말하자면, 평균 56.2%의 성능향상을 맛보게 되었다! 2. 반복되는 Count Query를 개선해보자! 해당 부분에서 성능을 최적화할 수 있는 부분으로 가장 눈에 띈것은 매번 반복되는 전체 데이터의 수를 측정하는 Count Query였다. "굳이 Count Query가 페이지마다 매번 반복될 필요가 있을까?" ..

1. 토큰 재발급에 저장공간이 필요한 이유 현재 JWT 인증방식을 적용하고 있다. 해당 방식의 플로우는 대략 아래와 같다. 로그인시 Access Token과 Refresh Token이 발급된다. 권한이 필요한 API의 경우 header에 Access Token을 추가하여 요청한다. Access Token이 만료된 경우에는 Refresh Token을 통해 Access Token과 Refresh Token 모두 재발급 받는다. 이러한 절차 과정에서 토큰을 저장할 공간이 필요하다. 현재 사용하고 있는 RDBMS인 MariaDB를 사용한 경우와 Redis를 사용한 경우 기능, 성능적 차이를 비교해보았다. 아래는 최종 비교 결과이다. Redis에 대해 자세히 알고 싶으면 이전에 작성한 포스팅을 참고하자! 2023..

1. 성능 최적화 계기 현재 프로젝트는 예약과 관련하여 시간을 많이 다루고 있다. 따라서, DATETIME 타입의 컬럼을 범위 비교 또는 동등 비교하여 조회하는 쿼리가 많이 존재하였다. 해당 컬럼에 대해 인덱스를 지정하여 성능 최적화를 할 수 있을것 같아 Real MySQL 8.0의 도움을 받아 시도해보았고 기간별 예약 내역 조회 쿼리에 대해 1374% 향상을 보게 되었다. 2. 문제의 쿼리 문제의 아래 쿼리는 기간별로 예약 내역을 조회하는 쿼리이다. where절에서 DATETIME 타입의 예약 시작날짜시간에 해당하는 start_at 컬럼에 대해 BETWEEN 연산을 진행한다. 나는 start_at 컬럼에 대해 Index를 적용해보고자 했다. select reservatio0_.project_table_..

1. 배포 자동화를 구축하게 된 계기 현재 교내 서버실에 운영서버가 구축되어 있고, 교내망 정책에 따라 외부 액세스 포트는 80, 443 2개만 사용할 수 있었다. 이미 80, 443은 애플리케이션 배포를 위해 사용하고 있다. 따라서 교내망에 접속해 있을 때만 22번 포트로 ssh 접속을 통해 변경사항을 운영서버에 배포할 수 있었다. 이렇듯 교내망에 접속해야만 한다는 문제도 있었지만, 결국에는 수동으로 배포하다 보니 명령어를 잘못 입력하는 경우도 있었고 배포할 때마다 반복되는 작업을 진행하다 보니 배포 자동화가 정말 절실했다. 2. 배포 자동화 플로우 우선 Jenkins를 이용하여 배포 자동화를 구축하고자 한다. PR이 Master 브랜치로 Merge되면 Github WebHook이 Trigger 된다...

1. 클라우드 서비스로 이전하게 된 계기 현재 교내 서버실에 KIOSEK 서비스가 On-Premise 환경으로 배포되었있고, 이전에는 프론트 개발자와의 지속적인 협업을 위한 개발 서버는 필요할 때마다 내 노트북에서 틀어서 포트포워딩 해주는 방식으로 하였다. 해당 방식은 너무나도 비효율적이었지만, 가용할 물리 서버가 없었고 사실 환경을 하나 더 구축한다는게 귀찮은 점도 있었다. 하지만 한계를 느꼈고, 이번 기회에 개발 서버를 AWS 클라우드 환경에 구축해서 프론트엔드 개발자에게 IAM 계정을 할당하고 필요할 때마다 서버를 껐다 켤 수 있게 할 생각으로 구축하게 되었다. 2. 사용할 AWS 자원 정하기 1. 키오스크 백엔드 어플리케이션과 NGINX 웹서버를 운영 할 EC2 인스턴스가 먼저 필요했다. 해당 시..

1. 문제상황 Repository단에서 Command와 Query를 분리하여 책임을 분리함으로써 코드 응집도와 유지보수성을 높이고자 하였다. 이에 처음 시도했던 방법은 아래와 같다. Create, Update, Delete를 담당할 CommandableRepo Interface와 Read를 담당할 QueryableRepo Interface로 나누었다. 구현체는 CommandRepo, QueryRepo로 구현한다. 하지만, 문제가 생겼다. 어떠한 엔티티를 save해야 하는 상황을 가정할 때, 중복조회나 다른 조회 메서드를 이용해야 하는 상황이 주로 발생했다. 이럴때, Repository를 사용해야 하는 Service 계층에서 의존성이 너무나 많아지는 문제가 발생했다. 2. 문제해결 과정 1 - interf..