멋진 개발자/트러블슈팅

개요 한정된 수량을 준비된 재고보다 훨씬 많은 유저들이 동시에 구매를 시도할 때, 어떻게 하면 재고수량을 넘지 않게 구매가 완료될 수 있을까?? 200개의 재고를 총 10,000명의 유저가 요청했을 때 오버셀링이 일어나지 않아야 한다. Race Condition 여러 개의 프로세스가 공유 자원에 동시 접근할 때 실행 순서에 따라 결괏값이 달라질 수 있는 현상 A스레드가 구매를 요청하여 3개 남은 재고를 1 감소시키려 한다. 이때 B스레드도 3개 남은 재고를 확인하고 1 감소시키려 DB에 접근한다. 먼저 요청한 A스레드는 3에서 2로 잘 감소시키고 트랜잭션을 마쳤다. 하지만 B스레드는 3개의 재고를 확인하고 1 감소시켰기 때문에 마찬가지로 3에서 2로 감소시키고 재고를 2로 UPDATE 하였다. 3개의 재..

개요 모노리스 서비스에서 적용된 jwt 인증을 마이크로 서비스에서 jwt 인증을 할 수 있도록 구현하기 user와 관련된 내용이지만 게시글 작성, 댓글 작성 등 인가가 필요한 활동을 할 때마다 user-service를 거치지 않을 것 인증/인가가 필요하지 않은 서비스와 필요한 서비스를 구별 접근방법 모든 요청을 가장 먼저 받아서 처리하는 api-gateway에서 인증/인가를 구현 AbstractGatewayFilterFactory를 상속받는 filter를 사용 인증/인가가 필요한 서비스와 필요하지 않는 서비스를 나누어서 두 개의 filter를 각각 적용 해결과정 인증/인가가 필요하지 않는 서비스에는 NoTokenRequiredFilter를 적용 (회원가입, 로그인, 이메일 인증, feign-client..

개요 jwt 토큰방식의 인증/인가를 도입 토큰 하나로 모든 서비스를 처리하게 된다면 해당 토큰을 탈취당하는 보안 이슈 발생 우려 jwt 토큰방식의 보안성 강화 접근방법 토큰에 클라이언트의 ip주소를 담고 검증과정에서 ip주소가 다를 경우 에러를 반환 RefreshToken 사용 ip주소가 담긴 토큰이 탈취된다면 더 심각한 보안 이슈가 발생될 가능성이 있으므로 많이 쓰이는 RefreshToken을 사용 또한, 모바일의 경우 ip 주소의 변경이 자주 일어날 수 있으므로 그때마다 에러를 반환하게 된다면 유저가 불편함을 겪기 때문에 ip 주소를 담지 않기로 함 또한 RefreshToken도 유저에게 발급하고 관리하게 된다면 마찬가지로 탈취될 가능성이 있다고 우려되어, RefreshToken은 유저에게 제공하지 ..

개요 회원가입의 마지막 단계에는 이메일 인증을 완료해야 한다. 이메일 인증 도입 이유 이메일을 회원의 아이디로 사용하기 때문에 고유한 값이 필요(Unique Key) 이미 타 사이트에서 인증이 된 이메일을 사용함으로써 고유성을 확보 하지만 이메일 인증의 방식에는 두가지가 존재 일반적으로 내가 경험한 사이트들은 회원가입시 이메일로 인증 코드를 발송하고, 인증 코드를 사이트에 입력하여 일치여부를 확인한 뒤 가입을 완료시킨다. 위와 같은 인증 코드를 입력시키는 일반적인 방법 외에 인증 링크를 클릭해서 인증을 완료하는 방법도 존재하였기에 이 두가지 방식 중에 어떤 방식을 적용 시킬지 고민을 하였다. 링크 vs 입력 인증링크를 클릭하는 방식을 선택 가입 시 입력한 이메일에 쿼리 파라미터로 이메일과 인증코드가 담긴..