전에 프로젝트를 진행하며 for문을 돌며 query를 날려야했던 상황이 있었는데 그때 공부했던 내용을 정리해 보겠습니다. 우선 문제 상황은 하나의 course에는 여러개의 location과 hash-tag를 가지고 있고 사용자가 등록하고자 하는 course를 요청에서 받아 location과 hash-tag를 등록하는 상황이었습니다. 이때 저는 반복문을 돌며 쿼리를 수행하는게 매번 반복문을 돌때마다 db와 네트워크를 n번 만큼 타야하기 때문에 성능적으로 저하가 있을 것 같다고 생각을 하게 되었고 결과적으로 JPA의 save로 단건 저장하던 쿼리를 saveAll로 여러건 묶어서 보내는 것이 성능이 더 좋게 나온다는 테스트 결과를 가지고 코드를 작성했습니다. 이 과정에서 save를 사용하든 saveAll을 사..

오늘은 프로젝트를 진행하면서 Spring Session으로 Redis를 적용한 내용을 간단히 정리하겠습니다. 우선 현재 사용자의 서버 인증 방식이 Session Cookie를 사용하고 있는데 추후 배포는 로드밸런싱으로 서버 다중화를 구성할 계회이었습니다. 세션의 경우 별다른 설정을 하지 않으면 서버의 메모리를 차지하여 사용자의 정보를 저장하게되는데 이렇게되면 서버를 여러대를 사용하는 환경에서 한 대의 서버에서 인증 받은 사용자의 세션은 해당 서버에만 세션이 존재하기 때문에 추후 로드밸런서의 요청이 다른 서버를 가리키게되면 세션이 풀리는 상황이 발생합니다. 그래서 저는 Redis를 사용해서 여러대의 서버가 Redis를 가리키는 방식으로 구성을 해보겠습니다. 실제 프로젝트 배포는 AWS ElasticCach..

프로젝트를 진행하며 Spring Security를 사용하고 있어 Controller나 Service layer에서 별도로 사용자 인증, 인가 여부에 대해 하드 코딩하지 않아도 돼서 각각의 layer의 역할이 늘어나는 일을 막을 수 있다. 만약 별도로 login, logout을 구현해서 사용했더라면 추후 인증, 인가 방식에 변동이나 추가가 있을 경우 시스템을 확장 시키는게 아니라 변화 시켜야 하기 때문에 OCP에 반한다고 생각해서 추상화가 잘 되어 있는 Spring Security를 사용하게 되었는데 인증과 인가를 해결하더라도 컨트롤러에서 사용자 세션의 정보를 가져오는 부분에서는 Controller나 Service Layer에 녹아들 수 밖에 없었다. 물론 Spring Security는 어느 Layer에서..

안녕하세요. 오늘은 프로젝트 진행중 logging하며 공부했던 내용을 정리 해보겠습니다. logging의 목적은 프로그램 동작중 어떤 상황에 어떤 일이 발생했을 때 그 일을 logging level로 분류하여 나중에 그 정보를 바탕으로 추적을 하거나 오류 상황을 다시 보기 위함등등 많은 이유가 있습니다. 많은 사람들이 개발을 시작할때 System.out.println으로 데이터를 찍어보곤 하죠 하지만 이 메서드는 사용해선 안됩니다. 그 이유는 이런식으로 내부에 synchronized를 사용하고 있기 때문입니다. synchronized를 사용하면 락을 걸어 다른 스레드의 접근을 막고 한 개의 스레드만 동작하게됩니다. 멀티쓰레딩 환경에서 무분별한 동기화의 성능 저하의 원인이 될 수 있습니다. 그래서 Syst..