프로젝트를 진행하는 과정에서 MySQL DB를 replication을 진행했는데 이는 추후 서버 증설을 가정했을 때 가용성이나 다수의 서버가 한 대의 데이터베이스를 바라보는 구조에서 트래픽이 한 개의 DB에 몰릴 때 해당 DB가 죽어버리면 앞단의 모든 서버까지 다 죽을 위험이 있기 때문이다. 요청당 스레드가 서버의 cpu,메모리, db connection 등을 가지고 요청을 보내는데 뒷단에 DB가 죽었으니 time out으로 에러가 발생할때까지 대기하게 되고 이 과정에서 서버에 동시 접속자 수가 늘어나고 요청의 수가 많아지면 서버의 자원을 계속해서 잡아먹으며 무조건 실패하게될 요청을 죽은 DB로 보내게 되므로 서킷 브레이커를 붙여주거나 replication으로 다중화를 해주는게 좋다고 생각했다. 밑에 구..

현재 진행하고 있는 프로젝의 API문서화를 Swagger로 진행하고 있습니다. API 문서화는 저는 혼자 프로젝트를 진행하면서 필요성을 느끼지는 못하지만 그래도 추후 프론트엔드 개발자나 아니면 제가 프론트엔드 개발을 진행하게되면 그때 사용할 목적, 포트폴리오 제출시 API 테스트 목적 등등 다양한 목적으로 문서화를 하고 있습니다. Spring의 Swagger적용은 springfox-swagger 의존성을 추가해서 구성하고 작성이 가능한데요 이런식으로 추가 후 Swagger관련 설정파일을 만들고 설정을 진행해 주심 됩니다. 문서에 관한 설명이나 특정 파라미터에 대한 무시 처리, paging을 위해 입력받을 PageRequest객체에 대한 resolver 설정 등등 많은데 이런 설정에 관한 설명은 이미 관련..

전에 프로젝트를 진행하며 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..