조급하면 모래성이 될뿐

결론 - 동시에 처리 가능한 스레드 풀 개수를 조절하여 리소스(CPU) 사용률을 관리하자 - 큰 파일 업로드 시 메인 메모리에 대한 걱정은 거의 없다. 임시 디스크에 대한 경로를 직접 설정해서 혹시 남아있는 경우가 있다면 직접 관리하자. - 네트워크 대역폭을 넓히거나 하드웨어성능을 높여보자. (가능하다면) 업로드 로직 application.yml spring.servlet.multipart.max-request-size: 3GB spring.servlet.multipart.max-filet-size: 3GB UploadService fun upload(multipartFile: MultipartFile) { val elapsedTime = measureTimeMillis { if (multipartFil..

1. 낙관적 락 방식을 통해 동시성 문제를 제어한다. 2. 버전 충돌로 인한 문제가 발생했을 때, 다시 로직을 시도한다. 낙관적 락(Optimistic Lock) 이란? - 코드 레벨에서 동시성 문제를 해결하는 방법이다. 간단하게 설명하면 버저닝을 통해서 문제를 해결한다. - 읽을 때 버전과, 변경할 때 버전이 다르면 예외가 발생한다. - DB 자체에 Lock을 걸게 되는 비관적 락(Pessimistic Lock) 방식보다 빠르다. - 그러나 Rollback 처리가 번거롭다. 스프링과 같이 트랜잭션 관리를 프레임워크가 처리한다면 비교적 신경 쓸 부분이 많이 줄어들지만, 그렇지 않은 경우에는 코드레벨에서 롤백에 대한 처리를 신경 써야 한다. 적용해 보기 - Jpa와 함께 낙관적 락을 사용해 보자 - 버저닝..

https://tech.kakaopay.com/post/overcome-spring-aop-with-kotlin/#overcome-with-kotlin--spring-context Kotlin으로 Spring AOP 극복하기! | 카카오페이 기술 블로그 Kotlin의 문법적 기능을 사용해서 Spring AOP 아쉬운 점을 극복한 경험을 공유합니다. tech.kakaopay.com 위 글을 읽고 프로젝트에 적용한 AOP 코드를 개선해보고 싶다는 생각이 들었다. 개선하고 싶은 코드는 동시성 처리를 위한 Redisson Lock 처리 코드이다. 정리 - 동시성 처리를 위해 적용한 AOP 코드를 KotlinAOP로 변경해 보았다. - 두 방식 모두 장, 단점이 있는 것 같다. - Spring AOP는 익숙하기 ..

결론 - accessToken, refreshToken 모두 httpOnly 쿠키로 응답했다. (XSS 공격 방지) - 하지만 refreshToken을 통한 재발급 로직을 구현하기 위해서 httpOnly옵션의 accessToken 쿠키는 서버에서 추가적으로 신경 써주어야 한다. (FE팀에서 조차 accessToken에 접근할 수 없기 때문에 토큰 만료시점을 알 수 없다..) 장점 - XSS 공격 방지할 수 있음. 단점 - 쿠키 관리신경 써야 함 - 서버 로직이 복잡해질 수 있음 (비교적..) 직면한 문제 1 accessToken 쿠키 만료시간. 처음에는 accessToken 쿠키 만료시간을 JWT와 동일하게 주었다. 프론트에서는 토큰 만료 여부를 서버응답에 의존하기 때문에 쿠키가 사라지게 되면 서버에서는..

현재 진행하는 프로젝트에서는 소셜로그인을 사용하지 않는다. 자체 인증시스템이 필요했고 JWT를 적용했다. 기존의 인증방식 기존의 쿠키나 세션방식은 서버 또는 클라이언트에 유저 정보를 저장하여 인증을 수행한다. 쿠키는 웹 브라우저에 저장하기 때문에 비교적 쉽게 탈취당할 수 있다. 세션은 다중서버구현 시 정합성을 보장할 수 없다. A클라이언트의 요청을 S1서버에서 인증했을 때, 두 번째 요청이 S2로 전송되면 S2세션에는 A유저의 정보를 모르기 때문에 인증이 되지 않는다. (스티키 세션, 세션 클러스터링, 메모리 디비를 사용해 해결할 순 있다.) JWT JWT는 RFC 7519 버전에 만들어진 약속이다. JWT의 핵심은 서명된 토큰이라는 것이다. 쉽게 서버에서 지정한 SecretKey로 JWT토큰을 만들어서..