서론개발자들이 흔히 저지르는 실수 중 하나는 요구사항을 듣고 이를 곧바로 비즈니스 로직이나 쿼리로 구현하는 것입니다. 이게 왜 문제가 될까요? 아래 이미지는 팀의 백엔드 개발자 채널 내용 중 일부입니다. 주목할 부분은 빨간색으로 표시된 요청사항입니다.요청사항:5년이 지난 결제 정보를 찾아, 개인정보 관련 특정 컬럼(id, 이름, 필명, 연락처)만 null로 업데이트하기.요청사항만 보고 그대로 Spring Data JPA로 구현한다면, 보존 기간이 지난 데이터를 findAll()로 조회하고, 데이터가 많다면 청크 단위로 나눠서 saveAll()로 저장하면 된다고 생각할 수 있습니다. 하지만 이렇게 접근할 경우 큰 문제가 발생합니다. Spring Data JPA의 saveAll은 개별 update 쿼리를 실..
서론 모든 Request는 WebGateway가 받아서 각 Reqeust에 맞는 Service들로 매핑시키도록 아래와 같이 구성도를 작성하였습니다. 해당 Request가 올바른 권한과 인증을 부여받은 Request인가를 판단하기 위해, 앞으로 인증과 인가는 WebGateway에서, 인증과 인가 없이 요청할 수 있는 예외의 Request(Login, SignUp 등)는 Filter를 구현받지 않고 바로 Auth Service로 통과시켜주는 Gateway를 구현해보도록 하겠습니다. (Playground라는 프로젝트 명칭은 학습 및 연구하며 실제로 적용해보는 놀이터용도로써 만든 프로젝트로서 큰 의미는 없습니다.)1. module-webGateway 역할 정의webGateway에서 모든 web 관련 Reques..
오늘은 Spring Batch를 사용하여 대량의 데이터를 삭제할 때 발생하는 성능 문제와 이를 개선한 과정을 공유하고자 합니다. 기존 코드와 문제점저는 일정 시간이 지난 UserCertLog 엔티티의 데이터를 삭제하는 작업을 진행하고 있었습니다. 초기에는 다음과 같이 코드를 작성했습니다./** * nice 인증 결과 로그인 UserCertLog 삭제 처리 * 매일 새벽 12시 30분에 도는 스케줄러 입니다. */@Scheduled(cron = "0 30 0 * * ?")public void certLogRemove() { log.info("---certLogRemove start!!---"); deleteService.deleteUserCertLog(); log.info("---certL..
1. 인증과 인가인증과 인가. 많이 들어 본 말이지만 들을 때 마다 햇갈리는 단어입니다. 때문에 쉽게 생각해야 할 필요성이 있었고 저는 이와 같이 정의를 내렸습니다. 인증은 사용자가 자신의 신원을 확인하는 모든 행위라고 생각합니다. 인가는 인증을 통해 신원이 확인된 사용자에게 특정 액세스 권한을 부여하는 모든 행위를 뜻 한다고 생각합니다. 더 쉽게 개발적인 이야기로 얘기하자면, 인증은 ID/PW, JWT Token 등과 같은 모든 자신의 신원을 확인하는 신분증이고 인가는 그런 인증에 대해 엑세스 권한을 체크 및 부여하는 행위라고 생각하면 됩니다. 저는 인증과 인가는 Gateway에서 처리하고, 해당 인증과 인가에 필요한 회원 확인 및 JWT Token 발급은 Auth Service(이하 Auth API)..
서론멀티 모듈 프로젝트는 쉽게 말해, 하나의 큰 프로젝트 아래에 여러 기능 혹은 프로젝트를 모듈화하여 관리하는 방식을 말합니다. 각 회사마다 다르겠지만, 대부분의 회사에서는 여러 서비스들을 개발 및 운영하고, 같은 기능(인증 및 인가 등)이나 같은 형식의 데이터베이스 엔티티를 사용하다 보니 회사 규모가 커지면 커질수록 더 많은 리포지토리가 생겨나고, 같은 코드와 같은 기능들이 중복되기 시작합니다. 저의 경우에는 동시다발적으로 진행되는 프로젝트 및 유지보수 운영 때문에 IDE에 열려있는 프로젝트는 점점 많아지고 개발자들 간의 소통 또한 어려워졌으며, 코드 컨벤션(Code Convention)들도 어긋나게 되는 상황이 발생하였습니다. 이를 해결하기 위해 같은 기능을 담당하는 코드들을 통합하는 기회를 만들 겸..
서론게시글을 제공하는 모든 서비스에서는 게시글의 조회수를 다양한 방법으로 제공하고 있습니다. 저희 회사에서도 게시글의 조회수를 집계하기 위해 여러 방식을 사용해 왔습니다. 기존에는 게시글 상세 조회 시마다 접속 정보(게시글, 접속 장치, 접속 시간)를 RDB에 로그 형태로 단순 삽입하고, 일정 시간마다 배치 작업을 통해 실제 조회수 RDB를 업데이트하는 방식이었습니다.하지만 이 방식은 시간이 지남에 따라 심각한 문제점을 드러냈습니다. 게시글의 수가 하루에도 몇십에서 몇백 개씩 증가하면서, 상세 조회마다 RDB에 Insert되는 횟수가 기하급수적으로 늘어났습니다. 이는 데이터베이스에 부하를 주고 성능 저하를 유발했습니다.이를 해결하기 위해 조회수 데이터를 Redis에 저장하고, 배치 작업을 통해 RDB를 ..