Intro 엑셀파일이나 zip 압축파일을 서버에서 생성해 다운로드를 제공할 때, 최초 응답시간에 대한 고려가 필요하다. 물론 미리 준비되어 있는 파일이라면 브라우저에 바로 응답을 보낼 수 있겠지만 DB에서 데이터를 조회하고, 이를 바탕으로 엑셀 파일을 생성하는 경우 사용자에게 여러 개의 파일을 압축된 형태로 제공하는 경우 이러한 상황에서는 파일을 준비하는 데 시간이 상당히 소요될 수 있다. 데이터의 크기에 따라 응답시간이 크게 달라지기 때문에 예상되는 응답 시간을 구체적으로 제공하기도 어려운 상황에서, 화면에 스피너만 딸랑 띄워놓는 것 만으로는 어지간한 사용자들의 인내심을 달래기 쉽지 않다. 서버에서 아무리 바쁘게 준비하고 있다고 뜨거운 열을 뿜어내며 소리쳐도 사용자는 서버가 멈춘 것으로 오해할 수 있다..

Intro 사이드 프로젝트에 actuator 를 적용해보았다. 그런데 /actuator 경로를 그냥 오픈하고 싶지는 않았는데, 마침 기존에 관리자 페이지 접근 권한 부여를 위해 사용하던 인터셉터가 하나 있어서, actuator 엔드포인트에 등록 해 두고 그대로 사용하면 되겠다 싶었다. 아래 코드는 기존의 인터셉터 등록에 관련된 코드. @SpringBootApplication(exclude = [UserDetailsServiceAutoConfiguration::class]) @EnableJpaAuditing @EnableScheduling class DutyparkApplication( private val authService: AuthService, private val jwtConfig: JwtCon..

Intro 여러개의 데이터베이스에 연결하는 스프링부트 프로젝트에서 커넥션풀 설정이 제대로 적용되지 않고 있다고 하여 확인을 해 보았습니다. 데이터베이스를 한개만 쓴다면, spring.datasource 에만 등록하면 충분합니다. 하지만 여러개를 등록하려고 하면 스프링부트의 autoconfigure 만으로는 부족합니다. 일단, 프로젝트를 열어 코드를 살펴보니 아래와같이 application.yml 에 각각의 데이터 소스를 설정 할 때, prefix를 주어서 각각의 데이터소스를 설정하고 있었습니다. ${code:application.yml} myapp.datasource: type: com.zaxxer.hikari.HikariDataSource driver-class-name: org.postgresql.D..

Intro 스프링기반 프로젝트를 만들다 보면 기계적으로 필요에 따라 각종 어노테이션을 붙이게 됩니다. 컨트롤러에는 @Controller를, 서비스 레이어에는 @Service를, 그리고 데이터베이스에 접근하는 퍼시스턴스 레이어에서는 @Repository를 붙였습니다. 그 외 어플리케이션 컨텍스트에 빈으로 등록 하고 싶은데 특별한 설정 절차가 필요 없어서 컴포넌트 스캔을 통한 자동 등록이면 충분 할 때에는 @Component를 붙여 왔습니다. 그런데, 사실 Bean 으로 등록되어 후에 Dependency Injection에 사용된다는 공통점을 생각 해 보았을 때는 "전부 @Component"로 해도 되는거 아니야?" 라는 생각이 들 수 있습니다. 각각의 차이도 모른채 습관적으로만 사용하고 있는게 사실입니다...

Intro 프로젝트에서 파일 업로드 부분에 대한 개선을 진행 했습니다. 기존의 파일 업로드를 처리하는 부분에 몇가지 문제가 있었는데, 특히 대용량 파일을 안정적으로 업로드 하기 위해서 해결해야 하는 포인트들이 여러가지가 있었고, 꽤나 난해했습니다. 사용자가 파일 업로드를 마쳤지만, 서버에서 일어나는 다양한 작업을 마칠때까지 오랜 시간동안 응답을 받지 못함 사용자 입장에서 업로드 100% 에서 오랜시간 화면이 멈추어 있어 UX가 좋지 않음 대용량의 파일을 업로드할 때 응답에 걸리는 시간이 너무 오래걸려 timeout 되는 문제 사용자는 파일을 성공적으로 업로드 했지만, 서버에서 해당 파일을 처리중 문제가 생겼을 때의 방안 대용량의 파일 업로드시 대량의 IO 작업으로 시스템 자원이 쏠리는 현상 간단히 추려보..