분류 전체보기

문제우선 좀 더 명확한 요구사항이 나오게 되면서 깨닳게 된것이 WishList라는 것이 찜같은 것이 아니라 장바구니의 역할을 하게 된다는 것이였다. 이유는 WishList와 관련된 서비스가 User에 존재하지 않고 Order에 존재했기 때문이다. 사용자가 찜을 해서 사용자가 자신의 마이페이지에 갔을때 찜한 목록을 보는 것이다 라고 생각한다면 해당 서비스는 User에 생겨야 한다고 생각했지만 요구사항에서 Order에 존재한다는 것은 해당 내용이 주문으로 이어진다는 이야기이고 그것은 곧 장바구니이다. 라고 생각이 떠올랐다 Redis(Shopping Cart)이번에 Redis를 공부하게 되면서 장바구니 하면 떠오르는 것이 바로 redis이다. 왜냐하면 사용자의 입장에서 장바구니를 접근하는 횟수는 다른 요청에 ..

문제 발생기존의 이메일을 인지하고 인증 코드를 보낼때 서버에서는 세션에 저장하여 이후 해당 이메일 인증 코드가 들어오면 세션의 값과 비교해서 이메일을 인증했다. 그렇게 진행을 했지만 MSA로 변경하고나서 문제가 발생했다. 더이상 세션을 통해 코드를 확인할 수 없다. 그 이유는 세션이 휘발성의 성격으로 인해 다음 요청에 세션이 비어있는 것이다. 모놀리식과 MSA의 세션 정책모놀리식모놀리식에서는 일반적으로 세션 저장소를 사용해서 세션을 관리한다. 이는 세션이 서버의 메모리나 외부 DB에 지속된다는 것인데 이는 클라이언트가 세션을 만들고 서버와 상호작용을 지속하고 있는 한 세션이 유지되고 있다MSA 서비스 간에 상태를 공유하는것을 피하기 위해 상태를 분리한다. 모두 독립적으로 실행되고 있으며 일반적으로 세션과..

🎲 레디스란?Key-Value 구조를 가진 형태로 다양한 형태의 자료구조를 제공하고 데이터를 저장한다레디스 클러스터 모드를 가지고 있어 다중 노드에 데이터를 분산 저장하여 안정성 & 고가용성을 제공한다다양한 목적으로 사용된다 ( e.g. Pub/Sub패턴, 블랙리스트 등등)모든 데이터를 In-Memory인 RAM에 저장하기 때문에 굉장히 빠른 작업 처리 속도를 가지고 있다데이터 영속성을 위한 SSD나 HDD에 저장하는 방식도 사용하고 있다장점 정리메모리에 데이터를 저장하면서 매우 빠른 읽기와 쓰기 속도를 보장하고 다양한 데이터 타입을 저장할 수 있다 Redis의 persistenceRedis는 RAM에 데이터를 저장하기 때문에 휘발성 데이터라고 생각하면 된다. 그래서 Redis는 이를 보완하고자 데이터..

💡 기존의 암호화 방법우리가 프로젝트를 하다보면 사용자의 데이터를 암호화 해주어야 한다는 것을 한번쯤은 듣게 된다. 그래서 데이터를 암호화하기 위해 암호화하는 로직을 만들고 암호화를 했다면 복호화를 해야하는 로직도 만든다 문제점암호화를 하는 타이밍마다 해당 로직을 구성해주어야 하고 그 타이밍마저 다 다르다수정을 위한 코드에도 암호화가 들어가야한다또한 사용자에게 데이터를 전달하거나 비교를 할 때 일일히  복호화 로직을 또 구해야한다는 것이다.만약 코드를 누락할 경우 문제가 발생할 수 있다. 💡 JPA의 AttributeConverter이 문제들을 해결하기 위해 JPA의 AttributeConverter라는 것을 이용해보려 한다. 간단하게 설명해보자면 서버에서 DB로 데이터를 넣기전과 DB에서 데이터를 ..

고민세션을 사용하는 프로젝트의 경우 세션을 지우는 것으로 로그아웃을 진행한다. 그러면 세션을 더 이상 체크 할 수 없기 때문에 로그아웃이 된 것처럼 보이기 때문이다. 하지만 토큰을 사용하는 현재 프로젝트의 경우에는 사용할 수 없다. 때문에 로그아웃을 하기 위해서 세션처럼 확인을 할 수 있게 해주는 무언가가 필요했다. 1. RefreshToken세션처럼 사용 할 수 있는 무언가가 필요했고 그것을 RefreshToken으로 정했다. 해당 토큰으로 존재하면 로그아웃이 아니고 지워졌다면 로그아웃 상태로 판단을 했다. 모놀리식으로 진행한 프로젝트에서는 전체 서비스가 하나의 DB를 바라보고 있기 때문에 테이블을 하나 추가하면 접근하기 굉장히 쉬웠다.  로직간단히 말하자면 로그인이 성공하면 onAuthenticati..

🥽 내가 구현한 기능 항해는 프로젝트의 요구사항의 큰 줄기를 알려준다. 때문에 해당 요구사항을 기반으로 제작하게 된다. 우선 큰 줄기만 보자면 우리는 쇼핑몰을 구현한다. 많은 기능이 있겠지만 그중 필수요소인 로그인과 주문 그리고 사용자의 위시리스트로써 찜하는 기능 같은 것 같다 우선 그 기능을 기반으로 원하는 기능은 모두 구현이 완료된 상태이다. 테스트를 마친 상태로 따로 문제가 있던 기능이 없었다. 🥽 기술적 의사결정 로그아웃은 Redis를 많이 사용하지만 굳이 초반부터 후반 기능을 사용하고 싶지 않았다. 때문에 RefreshToken을 이용한 로그아웃을 구현했다. 데이터를 암호화하는 것은 가장 대중적으로 사용되는 AES를 사용했고 데이터의 암호화를 위해 만들어진 암호화 방식은 JPA의 Attribut..

해당 내용은 쉬운코드님의 영상을 기반으로 제작되었습니다😓 다양한 트랜잭션 문제 예시와 해당 문제의 이름♪ Dirty read트랜잭션 1 : x에 y의 값을 더한다트랜잭션 2 : y 의 값을 70으로 바꾼다 이전 데이터 ▶ x = 10, y = 20상황1번이 실행이 되면 처음에 x의 10을 읽었는데 2번이 실행되었다. 2번은 y를 70으로 바꾸었다. 그리고 1번이 쭈욱 실행이 되고 y가 70이 되었기 때문에 x에 80이라는 숫자로 commit 을 해주고 종료되었다. 하지만 2번이 문제가 발생하면서 y의 데이터가 rollback이 되었다. 이후 데이터 ▶ x = 80, y = 20 정의commit 되지 않은 변화를 읽은 것처럼 나타나는 것이 Dirty Read 이다  ♪ Dir..

해당 내용은 쉬운코드님의 영상을 기반으로 제작되었습니다 이전 블로그에서 트랜잭션의 4개 특성 중 Isolation 이 굉장히 중요하다는 것과 까다로운 것을 알 수 있었다. https://latewalk.tistory.com/230 💾 Transaction, 트랜잭션이란? 해당 내용은 쉬운코드님의 영상을 기반으로 제작되었습니다 🔌 트랜잭션이란? 단일한 논리적인 작업의 단위 여러개의 SQL문들을 단일 작업으로 묶어 나눠질 수 없게 만든 것 transaction의 SQL문들 latewalk.tistory.com 정말 간단히 알아본 Isolation에서 좀 더 깊게 알아보는 시간을 가져보자 🔌 예시 상세 설명 이전 시간에 간단하게 작성한 예시를 상세하게 설명해보자 상황1. J가 H에게 20만원을 이체하려고 한다..

해당 내용은 쉬운코드님의 영상을 기반으로 제작되었습니다 🔌 트랜잭션이란? 단일한 논리적인 작업의 단위 여러개의 SQL문들을 단일 작업으로 묶어 나눠질 수 없게 만든 것 transaction의 SQL문들은 일부만 성공될 수 없다. 🔌 Commit & Rollback Commit 현재까지 작업한 내용을 DB에 영구적으로 저장한다 그리고 transaction은 종료한다. rollback 지금까지 작업들은 모두 취소하고 transaction 이전 상태로 되돌린다 그리고 transaction은 종료한다. AutoCommit ● 각각의 SQL문을 자동으로 transaction 처리 해주는 개념이다 ● SQL문이 성공적으로 실행하면 자동으로 commit 한다 ● 실행 중 문제가 발생하면 자동으로 rollback 된다..

💬 사용해야 하는 이유 이번 개인 프로젝트의 구현 내용 중 배송 상태를 체크하여 상품을 취소하거나 상품의 반품을 진행하기 위해 주문한 내용의 배송 상태를 확인해보아야 한다. 이번 조건은 시간 단위가 아닌 일일단위로 결제를 한 당일부터 하루하루가 지나가며 조건이 생긴다 그렇다면 상태가 하루에 한 번씩 바뀌면서 체크를 해서 취소 혹은 반품을 할 수 있는가에 대한 상태를 반환받고 그 내용에 따라 진행이 되어야 하는데 이때 굉장히 번거로운 일이 발생한다 하루에 한번씩 배송 상태를 체크하는 요청을 보내야 하는가? 이는 굉장히 귀찮은 방법에 속한다. 그래서 이걸 자동으로 하는 방법이 없을까? 라는 생각이 들었고 바로 방법을 찾게 되었다. 💬 @Scheduling 그래서 Scheduling 을 사용하게 되었다. 이걸..