이거 10월된지 4일밖에 안지났는데 완전 수상함,,,,,,,,,,,,,,,,,,     다신 보지말자.........새로 생성한 Redis 인스턴스에 SSH로 접속하고 Redis를 설치한 다음 Spring이 실행 중인 인스턴스에 연결하자!  나머진 다 똑같은데주요 차이점은 SSL/TLS 지원 여부이다. ElastiCache는 보안 요구 사항에 맞추어 SSL/TLS 연결을 지원하며, 보안성을 높인다.반면, EC2 인스턴스에서 실행되는 Redis는 기본적으로 SSL/TLS를 사용하지 않는다.이를 사용하려면 추가 설정이 필요하다. 하지만 ElastiCache는 관리형 서비스이기 때문에 일반적으로 더 높은 비용이 발생하지만,EC2 Redis는 비용을 보다 유연하게 관리할 수 있다.

https://chaereemee.tistory.com/41 Redis를 활용한 인증번호 캐싱 시스템 구현아이디 찾기의  리팩토링 을 해보려고 한다.  기존 방식의 문제점 인증 번호를 데이터베이스 테이블에 저장하고, 최신 데이터를 조회하여 인증번호를 검증하는 방식은 테스트하며 구현하기chaereemee.tistory.com 이번엔 Redis를 사용한 인증번호 캐싱 시스템을 AWS ElastiCache를 통해 리팩토링한 과정을 기록하고자 한다.이전 포스팅에서는 Docker를 통해 로컬 환경에서 Redis를 사용했지만, 이제 실제 운영 환경에서는 AWS ElastiCache를 적용해 더 안정적이고 효율적인 시스템을 구축하게 되었다. 🫥  문제였던 것 1) redis-cli 버전 문제로 TLS 연결 실패 ➡..

아이디 찾기의  리팩토링 을 해보려고 한다.  기존 방식의 문제점 인증 번호를 데이터베이스 테이블에 저장하고, 최신 데이터를 조회하여 인증번호를 검증하는 방식은 테스트하며 구현하기 편리했지만, 일시적인 데이터를 저장하고 불러오는 데  비효율적 이다.  해결 방안➡️ Redis 로 전환 - Redis로 전환하여 인증번호와 같은 일시적인 데이터를 메모리 기반으로 처리하면 빠른 속도로 조회할 수 있다.- Redis는 TTL을 설정하여 일정 시간 후 자동으로 만료되므로, 복잡한 쿼리 작업 없이 최신 데이터를 유지할 수 있다.(기존 복잡한 쿼리 " findTopByPhoneOrderByCreateDateDesc(String phone) ")  Redis 명령어의 결과를 설명하자면두번째 KEYS * 명령어를 통해 ..

Redis  - 메모리 기반의 데이터 저장소- 매우 빠른 속도로 데이터 저장 및 조회- key-value 데이터 구조에 기반한 다양한 형태의 자료 구조 제공- 메모리에 데이터를 저장하기 때문에 저장 공간에 제약이 있음 ➡️ 클러스터로 확장 가능  캐시 - 메모리에 데이터를 미리 적재하고 이를 빠르게 읽어 응답하는 구조  메모리 특성상 데이터가 휘발될 수도 ❓이를  보완하고자 RDB(Redis Database)와 AOF(Append-Only-File)을 제공한다.RDB: 메모리에 있는 데이터 전체에서 스냅샷을 작성하고 이를 디스크로 저장하는 방식AOF: 레디스에 데이터가 변경되는 이벤트가 발생하면 이를 모두 로그에 저장하는 방식차이점RDB는 주기적으로 전체 데이터를 저장하지만, AOF는 모든 변경 명령어를..

데이터가 많아질수록 응답 시간이 길어진다는 것을 위에 이미지로 확인할 수 있다.데이터 양이 늘어날수록 응답 속도가 비례하여 느려진다.      서버 로그 를 확인해보면애플리케이션이 데이터베이스에 쿼리를 실행하거나 요청을 처리할 때,Hibernate와 같은 ORM 툴은 자동으로 SQL 쿼리 실행 정보를 기록해 준다. 쿼리 로그를 분석해 본 결과shelter_info 테이블과 관련된 쿼리가  반복 된다select (생략) from shelter_info si1_0 where si1_0.care_nm=? 특히, care_nm을 기준으로 shelter_info 테이블에서 여러 번 JOIN이 일어나고 있다. 기본적으로 @ManyToOne 관계에서 Lazy Loading이 기본으로 설정되어 있다.Lazy Loadi..

애플리케이션에서 많은 데이터를 처리하고 이를 랜덤하게 선택해야 하는 경우, 흔히 사용하는 방법이 Collections.shuffle()이다.이 방식은 데이터를 메모리로 불러와 Java 컬렉션에서 랜덤하게 섞는 방식이지만,데이터 양이 많아질수록 성능에 심각한 문제가 발생할 수 있다. 이번 포스트에서는 Collections.shuffle()을 사용해 발생했던 성능 문제를 살펴보고,이를 개선하기 위해 데이터베이스 수준에서 랜덤 샘플링을 적용한 것을 공유하고자 한다.   기존 방식의 문제점 Collections.shuffle() 의 성능 한계 다음과 같은 문제가 발생할 수 있다. ✔️ 메모리 사용 증가더보기모든 데이터를 메모리에 로드하여 처리하기 때문에, 데이터 양이 많아질수록 메모리 사용량이 급격히 증가한다...

개발을 하다 보면 기능 구현에 열중한 나머지 성능 최적화를 놓치는 경우가 많다.특히, API 요청의 처리 속도를 개선하기 위해 리팩토링을 진행하였고,그 결과를 바탕으로 성능 테스트 결과를 공유하고자 한다.  성능 테스트 방법- Postman 을 사용하여 리팩토링 전후 각각 10번씩 API 요청을 보낸다.- 각 요청에 대한 응답 시간을기록한다.- 모든 응답 시간을 더한 후, 평균을 계산한다.- 리팩토링 전후의 평균 응답 시간과 평균 처리량을 비교하여 개선율을 산출한다. 개선율 계산(리팩토링 전 - 리팩토링 후) / 리팩토링 전 * 100  리팩토링 전리팩토링 후 더보기로그인12345678910591 ms598 ms611 ms609 ms604 ms599 ms638 ms609 ms612 ms627 ms Acc..

전 포스팅https://chaereemee.tistory.com/25 Spring Security 기록 (최종 직전)먼저 JWT(JSON Web Token)에 대해 알아보자.Spring Security는 여러 가지 인증 방법을 지원하며, JWT는 그 중 하나일 뿐이다.- 그 외 인증 방식 : 세션 기반 인증(상태 저장 방식) 등 JWT의 구조Header (헤더)토chaereemee.tistory.com 본문은 구분선 아래에 있음 전 포스팅을 보면 알겠지만, 현재 코드에서 사용하는 구조는 Access Token 방식만을 사용하고 있으며, 별도 만료에 대한 처리가 없다.인증 토큰이 만료되면 사용자는 다시 로그인해야 하는 불편함이 있다. 이를 해결하기 위해 Refresh Token을 도입하고자 한다. Acce..

먼저 JWT(JSON Web Token)에 대해 알아보자.Spring Security는 여러 가지 인증 방법을 지원하며, JWT는 그 중 하나일 뿐이다.- 그 외 인증 방식 : 세션 기반 인증(상태 저장 방식) 등 JWT의 구조Header (헤더)토큰의 타입과 서명 알고리즘을 포함한다.Payload (페이로드)주로 사용자 정보나 기타 데이터를 담고 있다.Claims 포함된다.Signature (서명)JWT의 무결성을 검증하는 데 사용된다. 🧐 먼저 나는 왜 JWT를 선택했을까 ?JWT는 상태 비저장 방식의 인증을 지원하기 때문에 서버가 별도의 세션을 저장하지 않아도 되고, 토큰이 만료되지 않는 한 추가적인 인증 검증 절차가 필요없기 때문에 확장성 측면에서 유리하다.리액트와 같은 SPA는 클라이언트 측에..

https://chaereemee.tistory.com/22 ❓보호 경로 설정이 안된다 (해결 완료)먼저 아래 화면은 관리자가 신고 목록을 처리할 수 있는 페이지이다.이 페이지는 관리자로 로그인 했을 때 헤더에서 드롭 다운으로 들어갈 수 있다.하지만 URL을 통해 일반 사용자나 비로그인 상chaereemee.tistory.com 문제 식별관리자로 로그인했음에도 불구하고, 권한이 없는 페이지로 리다이렉트되는 문제가 발생했다.role과 requiredRole이 [ROLE_ADMIN]으로 동일하게 출력되고 있다면,일반적인 상황에서는 if 조건문이 통과되지 않고 children이 반환되어야만 한다.이를 통해 애플리케이션이 사용자의 역할을 제대로 인식하지 못하고 있다는 문제를 확인했다. 원인 분석src/App.j..