개발놀이터

1. 기존 검색 방식 LIKE 연산자를 이용한 검색을 했습니다. 2. 기존 검색의 문제점 인덱스 설정을 할 수 없습니다. 인덱스를 설정하면 시간 복잡도가 O(log n)이지만 인덱스를 설정하지 못하기 때문에 시간 복잡도가 O(n)에 바인딩 즉, 풀스캔으로 조회합니다. 3. ver.2에서 개선한 점 Elasticsearch의 역색인을 이용해 검색 성능을 20배 (100만행 기준) 끌어올렸습니다. Elasticsearch 고난 항상 느끼는 것이지만 NoSQL은 진입장벽이 어마어마한 것 같습니다. RDBMS에 너무 익숙해진 것도 있겠지만 하나부터 열까지 새롭지 아니한게 없었습니다. RESTful API로 테이블 (인덱스)를 만들고 모든 CRUD 또한 RESTful API를 따르고 있었습니다. 또한, GUI도 ..

기존 동시성 문제 기존에도 동시성 문제가 발생한다는 것을 느낌적으로 알아차렸습니다. 이에 Synchronized 키워드를 이용해 동시성 문제를 해결했습니다. 기존 동시성 문제의 문제점 Synchronized 키워드는 다른 동시성 문제를 해결하는 방법보다 성능상 좋지못합니다. ver.2에서 개선한 동시성 문제 JPA의 특징 때문에 Synchronized 키워드는 어울리지 않는다고 판단하여 JPA와 어울리는 낙관적 락 / 비관적 락 중 하나를 선택하였습니다. 우선 테스트 코드를 통해 "동시성 문제가 발생합니다" 라고 증명하는 것부터가 문제였습니다. 그 때 마침 "단위 테스트" 라는 것에 꽂혀서 어디선가 DB를 불러오는 단위 테스트는 안티 패턴이다 라는 말이 생각났습니다. 그래서 Mock 객체를 이용한 단위 ..

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

기존 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..

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

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