개발놀이터

이번 포스팅에선 스프링 시큐리티에 JWT 인증 레이어를 추가하는 방법에 대해서 소개해드릴까 합니다. 제가 이 프로젝트를 개발하면서 했던 고민들, 마냥 만사형통하지 않았던 험난한 과정들, 결국 내가 이 프로젝트를 통해 얻은 것들, 앞으로의 계획등은 아래의 링크에 자세히 기술되어있으니 참고해주시면 좋겠습니다. https://coding-review.tistory.com/381 온라인 쇼핑몰 ver.2 (3) : JWT 토큰으로 인증 레이어 추가하기 기존 프로젝트에선 스프링 시큐리티의 인증 + 세션 + Redis 이렇게 세 단계가 존재했습니다. 이번 개선으로는 JWT토큰을 도입해 인증에 새로운 레이어를 추가하는 것입니다. 하지만 따지고 보면 스 coding-review.tistory.com 아마 두개 내지 세..

기존 인증 방식 스프링 시큐리티에 100퍼센트 의존하는 방식이었습니다. 스프링 시큐리티는 웹 세션으로 동작합니다. 기존 인증 방식의 문제점 추후에 MSA로 변경하는 과정에서 필요한 stateless한 인증 방식이 필요했습니다. ver.2에서 개선한 인증 방식 스프링 시큐리티의 Authentication 객체를 이용해 JWT를 만들어 회원 인증에 사용했습니다. 인증 레이어를 기존 스프링 시큐리티 하나에서 JWT를 추가해 두개의 인증 레이어를 사용할 수 있었습니다. 스프링 시큐리티에 100퍼센트 의존했으면 구현할 수 없었던 OAuth 의 Remember-me 기능을 JWT를 이용해 구현할 수 있었습니다. JWT로 인증 추가 0. 고민 사실 이 프로젝트를 진행할까 말까 수많은 고민이 오갔습니다. 이미 인증으로..

이번에 JWT 토큰 인증 방식에 대해서 공부하고 있습니다. 제 프로젝트에 인증 부분이 세션 + Redis + Spring Security 이렇게 세가지 부분으로 돌아가는데 여기에 JWT라는 새로운 레이어가 들어가면 보안적으로 어떨지 궁금했습니다. 알아보던 중에 정말 괜찮은 블로그를 발견했습니다. https://wildeveloperetrain.tistory.com/57 spring security + JWT 로그인 기능 파헤치기 - 1 로그인 기능은 거의 대부분의 애플리케이션에서 기본적으로 사용됩니다. 추가로 요즘은 웹이 아닌 모바일에서도 사용 가능하다는 장점과 Stateless 한 서버 구현을 위해 JWT를 사용하는 경우를 많 wildeveloperetrain.tistory.com 이분 블로그에 있는 ..

기존 SMTP SMTP 는 stateful 프로토콜 + 동기 네트워킹입니다. 기존 방식의 문제점 이메일은 회원가입시 2FA로 이용됩니다. 회원 가입을 할 때 이메일을 보내면 이메일이 전송되는데 걸리는 시간인 3~4초 가량을 아무것도 할 수 없습니다. 이는 부정적인 유저 경험으로 이어질 우려가 있습니다. ver.2에서 개선한 SMTP SMTP를 @Async 어노테이션으로 비동기 처리를 하였습니다. 기존 방식대비 고객경험을 90배가량 개선할 수 있었습니다. 먼저 JavaMailSender를 빈으로 등록해줬습니다. package com.hello.capston.config; import org.springframework.context.annotation.Bean; import org.springframewo..

꽤 전에 동기 비동기 프로그래밍에 대해서 이론적으로 학습하고 최근에 실습할 기회가 생겼습니다. SMTP를 이용해 2차인증을 요구하는 서비스를 개발하는데 SMTP가 동기 네트워킹이라 사용자가 이메일이 날아가는 3~4초정도를 손놓고 가만히 기다려야 하는 상황이 발생했습니다. 이를 비동기 통신으로 바꾸면 좋겠다는 생각이 들어서 찾아보니 @Async를 적용하면 동기 통신을 비동기 통신으로 바꿔준다는 소리를 들었습니다. @Async @Async는 스프링 AOP에 의해 동작하는 프록시 패턴 중 하나입니다. 해당 포스팅에선 프록시 패턴이 어떤 것인지는 다루지 않겠습니다. @Async가 설정된 메서드에 접근하면 프록시가 중간에서 샥 하고 가로채서 메인 스레드가 아닌 서브 스레드에 할당합니다. 그렇기 때문에 @Async..

기존 프로젝트의 방식 "누가"에 대한 데이터가 굉장히 많이 필요합니다. "누가" 장바구니를 담았는지, "누가" 좋아요를 눌렀는지, "누가" 결제를 했는지, "누가" 로그인을 했는지 등등... 총 42개의 API 중 66%에 해당하는 28개의 API에서 "누가"에 해당하는 데이터를 요청했습니다. 총 DB 연산 143개 중 약 30%에 해당하는 43개의 DB 연산이 "누가"에 해당하는 데이터를 요청합니다. 기존 프로젝트의 문제점 정적 데이터를 항상 DB에서 조회하기 때문에 조금만 트래픽이 몰리면 DB의 심각한 부하가 우려됩니다. ver.2에서 개선한 문제점 정적 데이터이기 때문에 캐싱을 적용하면 좋겠다고 판단하였습니다. EHcache, Memcached, Redis 중 고민하였고 세션까지 분리할 수 있고 다..

https://coding-review.tistory.com/365 Redis를 이용해 캐싱 구현하기 (with Spring) 저번 포스팅에선 Redis의 기본적인 개념에 대해서 알아봤습니다. Redis가 어떻게 NoSQL중에서 가장 빠른 성능을 보여줄 수 있었는지, 자료구조는 어떤 것을 지원하는지, 사용처는 어떤게 있는지, 배 coding-review.tistory.com 우리는 저번 캐싱 구현에서 Spring Data Redis를 적극적으로 활용해 CrudRepository를 상속받아 사용했습니다. 하지만 이 방법은 high level 코딩이었기 때문에 문제가 몇가지 있습니다. 바로 Redis에서 제공해주는 다양한 자료구조 중 Hash 밖에 이용할 수 없다는 것이죠. Redis에선 String, Se..

유튜브를 보다가 시니어 개발자분들이 나와서 얘기하는 것 중에 Version 2 를 만들어봐라 시간이 된다면 3, 4 이렇게 점진적으로 고도화시켜봐라 그것이 반드시 도움이 될것이다 라는 얘기를 들었습니다. ver.2 를 만들기 위해서는 어느정도 큰 규모의 서비스여야 한다고 생각이 들어서 제가 만든 프로젝트 중에 가장 규모가 큰 온라인 홈쇼핑을 ver.2로 만들기로 했습니다. 기존 ver.1 에서의 문제점을 분석하고 해결할 수 있는 기술을 공부하고 테스트하고 적용하기까지의 블로그 포스팅이 될 것 같습니다. 우선 제가 분석한 제 온라인 홈쇼핑 ver.1의 문제점은 다음과 같습니다. 인증, 인가에 Spring Security를 사용하고 있는데 추가적인 레이어가 필요할 것 같다 현재는 세션을 쓰고있음 데이터베이스..

요즘 MicroService Architecture (이하 MSA) 에 관심이 생겨서 이것저것 알아보던 중에 Kafka라는 서비스를 알게되었습니다. 쉽게 얘기하면 각각 떨어져있는 서비스들 사이에서 메시지를 주고받을 수 있도록 하는 서비스입니다. 기존 카프카가 없을 때 메시지를 보내려면 위와 같이 모든 컴포넌트가 메시지를 쏴줘야 하는 문제가 있었습니다. (딱봐도 문제가 있게 생겼습니다) 이렇게 데이터를 보내게 되면 데이터 복잡성이 증가하겠죠. 하지만 카프카가 도입되면서 메시지를 보내는쪽 (Publisher) 과 메시지를 받는쪽 (Subscriber) 을 나누고 카프카를 통해 메시지를 주고받으면서 조금 더 편하게 데이터를 주고 받을 수 있게 되었습니다. 이번 포스팅에선 메시지 브로커 (메시지 큐잉 서비스) ..

https://coding-review.tistory.com/346 여태까지 공부한 네트워크 면접질문 / 답변 https://coding-review.tistory.com/345 여태까지 공부한 데이터베이스 면접질문 / 답변 https://coding-review.tistory.com/344 여태까지 공부한 Spring 면접질문 / 답변 https://coding-review.tistory.com/343 여태까지 공부한 Jav coding-review.tistory.com 앞선 포스팅과 이어집니다. 70. 프로스세와 스레드에 대해서 설명해주세요. 프로세스는 컴퓨터가 연속적으로 실행하는 프로그램이고 스레드는 프로세스 안에서 실행되는 흐름의 단위입니다. 프로세스는 고유한 주소와 데이터 공간을 할당받고 독립적..