이슈 트래커

DB에 있는 데이터를 벌크 update를 할 때 어떤 방식을 써야 할까? 참고자료 BULK 처리 Write에 집중해서 개선해보기 많은 데이터를 insert,update하는 상황이면 db와 애플리케이션 간에 발생하는 I/O를 줄이는 방향으로 쿼리를 실행하는 게 좋다.

accommodation은 이번 프로젝트에서 제일 중요한 도메인이다.처음 db 모델링을 할 때는 요구사항을 모두 만족하려고 하지 말고 우선필요한 것들을 먼저 처리하자고 생각했다.지금 accommodation과 reservation을 고도화하면서 늘어난 칼럼이 isOnS

선착순 쿠폰 이벤트를 할 때는 여러 명이 동시에 쿠폰 발급을 누를 수 있다.이때 동시성 문제로 제한된 물량보다 더 많은 쿠폰이 사람들에게 뿌려질 수 있다.이러한 문제를 해결하기 위해서 redis와 kafka를 쓸 수 있다고 한다.redis는 하나의 스레드를 활용하기 때

트러블 슈팅1) 카프카와 레디스를 같이 쓰면서 계속 메시지가 안가서 확인해보니레디스에 저장된 값이 2801이었다. 애초에 로직이 레디스의 값이 100을 넘어가면 그냥 종료하는 것으로 돼 있어서, 로직이 실행이 안 되는건데... 카프카에 문제가 있는 건줄 알고 하루종일

JPA에서 ENUM을 쓸 떄는 위처럼 @Enumerated(EnumType.STRING) 이걸 지정해주는 게 좋다고 한다. 만약, 지정하지 않으면? 저기에 ENUM과 관련된 어노테이션을 붙여주지 않으면 디폴트 값이 설정된다. 그렇게 되면, DB에 값을 넣을

서비스를 운영할 때 '삭제'를 한다고 해서 바로 db에서 데이터를 지우지 않는 경우도 있다고 한다.이를 soft delete라고 하는데, 나중에 복구해달라는 요청이 오면데이터를 복구해주기 위해서다.테이블에 is_delete같은 칼럼을 놓고서, 삭제 요청이 오면 이 칼럼

이 코드는 인프런의 <재고시스템으로 알아보는 동시성이슈 해결방법>을 참고해서 작성했다.(참고로 이번 프로젝트를 하면서 재고를 관리하는 이슈는 없었지만, 숙소 동시 예약에 대해서 인사이트를 얻을 수 있을 것 같아서 공부 중이다.)여러 스레드가 하나의 공유변수에 접근

스프링 시큐리티 인 액션을 보고서비밀번호를 암호화하는 방식을 구현했다.책을 참고해서 암호화 방식을 구현했는데, 비밀번호는 복호화가 불가능한 해시를 사용하는 것이 더 좋다는 말을 들었다.해싱과 암호화는 데이터 보안에 사용되는 개념으로,Hash는 단방향 암호화 기법 Enc

서비스를 제공할 때 중요한 것은 누군가에게 어떤 권한을 제공할지를 확인하는 것이다.스프링 시큐리티에서는 filter를 통해서 이 과정을 커스터아미징할 수 있게 해준다.확인 과정에서 이용자에게 이메일 주소를 입력하게 하거나, 일회용 암호를 입력하게 하는 방식이 대표적인

이 두개 클래스가 순환참조가 발생했다.처음에는 생성자에 주입하는 방식이라서 필드로 주입하는 방식을 써도 여전히 순환참조가 일어났다.순환참조는 a클래스가 b클래스를 참조하고, b클래스가 a 클래스를 참조할 때 발생한다.이 문제는AuthenticationProvider를

이렇게 엔드포인트에 대해서 인증을 하지 않도록 설정을 했는데도포스트맨에서 api를 호출할 때 계속 401 에러가 떴다.구글링을 해보니 에러(예외)가 터졌을 때도 스프링 시큐리티의 인증요청 때문에 막혔던 거 같다.이렇게 해주니 포스트맨에서 이런 결과가 나왔다. 애초에 막

air-dnb 애플리케이션에서 권한은 크게 두가지다.user와 host 이렇게 설정을 해두고api에 대한 권한을 조정할 계획이다.authorizeHttpRequests() 이 메서드는 엔드포인트에 대해서 권한과 관련된 규칙을 설정하게 해준다. anyRequest()는

사용자가 의도하지 않은 악성 공격이 일어날 수 있다. 이를 막기 위해 필요한 기법이다.csrf 보호는 web applications의 프론트페이지만이 mutating opeartion을 하도록 보장한다. (데이터를 수정하는 작업, 예를 들어 POST, PUT, DELE

우리는 보통 특정 회사에 방문할 때 건물의 안내데스크에 방문 목적을 밝히고, 방문키를 받는다. 이러한 일련의 프로세스는 OAuth2의 작업과 유사하다.방문자는 user(로) 특정한 use case를 처리할 필요가 있다. 가령, 회의실에 방문하는 것처럼 말이다. 이를 위

우선, 여기서는 redis를 사용해서 jwt토큰을 담기로 했다.Redis를 활용한 JWT 토큰 관리 (feat.쿠키)이 글을 참고해서 그 이유를 정리한다.우선, jwt는 accesstoken과 refreshtoken을 만든다. accestoken은 사용자 인증에 사용되

1.값 직렬화레디스에 refresh token을 저장하는데 계속 값이 제대로 저장이 안돼서 모든 키를 조회해보니 직렬화가 잘못됐었다.이 문제를 해결하려면 String 타입에 맞는 직렬화 설정을 해주어야 한다고 한다.이렇게 RedisTemplate에 타입을 지정해주니 정

jwt는 로그아웃을 구현할 때 클라이언트가 갖고 있는Access Token과 Refresh Token을 만료시키는 방식으로 이루어진다.로그아웃을 할 때는 redis에 있는 refresh token을 지워버리면 된다. 이때 블랙리스트라는 개념을 도입할 수 있다.로그인 상

구글 로그인 페이지에서 정보 제공 동의를 눌렀는데그 다음 페이지로 가지 않고 계속 로그인 페이지로 리다이렉션이 됐다.알고보니, 스프링 시큐리티 config에서 /oauth2 관련 페이지들을 허용하지 않았기 때문이었다.이렇게 해주니 oauth2 에러가 떴는데 알고보니 시

(지금부터 작성할 시큐리티 코드는 스프링 인 액션 second edition을 보고 작성한 것이다. 국내에서는 아직 번역이 안돼서 원서를 참고했다. 1st 에디션을 이미 3년전 쯤에 나온 책이라서 업데이트가 안 된 내용이 많아서 2nd 에디션을 보기로 했다.)여기서 U

디비에는 보통 비밀번호를 암호화한 책로 넣는다고 한다. 그렇다면, 유저가 입력한 비밀번호가 db에 저장된 비밀번호와 일치하는지 확인하는 단계가 필요하다.PasswordEncoder를 구현하면 스프링 시큐리티에게 어떻게 비밀번호를 검증할지 알려줄 수 있다. 인터페이스는

처음에는 discountpolicy를 accommodation의 embeded 하는 방식을 썼다.discountpolicy가 accommodation에 종속되기도 하고, 테이블을 계속 따로 만드는 것을 좋지 않을 것이라고 생각했다.다만, 이렇게 했을 때 생기는 문제가