일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 1차원 DP
- 2차원 dp
- 99클럽
- @Builder
- @GeneratedValue
- @GenericGenerator
- @NoargsConstructor
- @Transactional
- Actions
- Amazon EFS
- amazon fsx
- Android Studio
- ANSI SQL
- ApplicationEvent
- assertThat
- async/await
- AVG
- AWS
- Azure
- bind
- builder
- button
- c++
- c++ builder
- c03
- Callback
- case when
- CCW
- chat GPT
- CICD
- Today
- Total
목록Web (39)
기록
시작하면서스프링 프로젝트에서 QueryDSL을 사용해 데이터를 업데이트할 때, 테스트 코드가 예상과 다르게 동작해 당황한 경험이 있으신가요? 이번 글에서는 QueryDSL로 데이터베이스 업데이트 후 JPA 1차 캐시와 동기화되지 않는 문제를 해결한 과정을 공유합니다.문제 상황 개요QueryDSL을 사용하여 테이블의 데이터를 직접 업데이트하는 메서드를 작성한 후, 테스트 코드에서 기대한 대로 데이터가 조회되지 않는 문제가 발생했습니다.주요 동작 흐름단계 1: JPA로 엔티티를 저장할 때, 데이터베이스에 값을 저장하고 동시에 1차 캐시(영속성 컨텍스트)에 엔티티 상태를 유지합니다.단계 2: QueryDSL의 update() 메서드를 사용하여 데이터베이스의 값을 직접 수정합니다. 하지만 이 과정에서 JPA의 ..
시작하기로그인 시스템에서 중요한 과제 중 하나는 사용자 인증 토큰의 안전한 저장과 관리입니다. 이번 포스팅에서는 AWS Elasticache Redis를 활용하여 스프링 부트 프로젝트에 확장 가능한 인증 시스템을 구축하는 방법을 공유하려고 합니다. 이전 포스팅에서는 인메모리 Map을 사용해 로컬 환경에서 간단한 토큰 관리를 구현했습니다.([Web/Spring] - 테스트 환경에서의 In-Memory Map을 활용한 로그인/로그아웃 시스템 구현) 이번에는 이를 기반으로 Elasticache Redis로 확장하여 분산 환경에서도 안정적으로 인증 시스템을 운영하는 방법을 다룹니다.1. 소개Redis는 다음과 같은 이유로 인증 토큰 관리에 적합합니다:빠른 키-값 조회: 로그인 토큰의 저장과 조회 속도가 빠릅니다..
1. 소개JWT를 선택한 이유사용자를 인증하는 방법에는 여러 가지가 있습니다. 그중에서 JWT(JSON Web Token)를 사용하기로 한 이유는 간단합니다. JWT는 서버가 사용자의 인증 상태를 유지하기 위해 별도의 저장 공간을 필요로 하지 않습니다. 반면에, 세션 기반 인증은 서버가 상태를 저장해야 하므로 확장이 어렵고 유지보수가 복잡합니다. JWT는 이러한 문제를 해결해 줍니다. 또한, JWT는 클라이언트가 자체적으로 인증 정보를 유지하기 때문에 마이크로서비스 환경에서도 유용하게 사용할 수 있습니다.토큰 전달 방식 고민JWT를 사용하기로 한 뒤, 우리는 "어떻게 토큰을 전달할 것인가?"라는 질문에 직면했습니다. 토큰을 쿠키에 저장하면 클라이언트가 따로 신경 쓰지 않아도 된다는 장점이 있습니다. 하지..
시작하면서최근에 고민했던 것 중 하나는 "로그인 시 만들어둔 토큰을 어떻게 관리해야 할까?"라는 문제였습니다. 로그인 토큰은 인증과 권한 관리를 위해 반드시 필요한데, 이를 어디에 저장하고 어떻게 관리해야 하는지 명확히 정해야 했습니다. 처음에는 외부 저장소를 활용하는 방안을 떠올렸습니다. 예를 들어, Redis 기반의 Elastic Cache를 사용하면 분산 환경에서도 안정적으로 토큰을 관리할 수 있습니다. 하지만 여기서 예상치 못한 난관에 부딪혔습니다. Elastic Cache는 같은 VPC 내에서만 접근 가능하다는 제한이 있었습니다. 로컬에서 이를 테스트하려면 Bastion Host를 통해 접속하거나, VPN 같은 추가적인 네트워크 설정이 필요했습니다. 이 과정이 생각보다 복잡하고 번거로웠습니다. ..
스프링 이벤트 처리 예제 및 코드 구현시작하면서이 프로젝트는 오픈소스를 분석하다가 각 모듈들이 이벤트를 통해 통신하는 것을 발견한 것이 계기가 되었습니다. 처음에는 이벤트 기반 통신이 어떻게 이루어지는지 이해하기 어려웠지만, 이를 제대로 익히기 위해 직접 샘플 프로젝트를 만들어보기로 했습니다. 스프링의 이벤트(Event) 기능은 애플리케이션의 모듈화와 확장성을 높이는 데 큰 도움이 되며, 이번 글에서는 간단한 이벤트 처리 프로젝트를 통해 이벤트 구현, 발행(Publish), 리스너(Listener) 설정 방법을 단계별로 익혀보겠습니다. 또한 이러한 이벤트 기반 아키텍처의 장점과 활용 방법에 대해서도 함께 논의해 보겠습니다.1. 프로젝트 개요 및 목표이번 프로젝트에서는 두 가지 사용자 정의 이벤트(Firs..
시작하면서RabbitMQ는 오픈 소스 메시지 브로커로, 애플리케이션 간에 메시지를 안전하게 전달하는 역할을 합니다. RabbitMQ는 메시지 큐를 이용해 비동기 통신을 쉽게 처리할 수 있어, 애플리케이션이 서로 독립적으로 동작하면서도 필요한 데이터를 주고받을 수 있게 도와줍니다. 이번 포스팅에서는 RabbitMQ의 주요 개념을 이해하고, 스프링 부트를 이용해 간단한 메시징 시스템을 구현하는 과정을 소개하겠습니다.RabbitMQ의 주요 개념RabbitMQ를 제대로 이해하려면 몇 가지 핵심 구성 요소들을 알아야 합니다. RabbitMQ는 여러 애플리케이션 간에 안전하고 효율적으로 메시지를 교환하기 위해 사용하는 메시지 브로커입니다.Producer: 메시지를 보내는 역할을 하는 애플리케이션입니다. Produc..
시작하면서웹 개발을 하다 보면 자주 겪게 되는 오류 중 하나가 CORS (Cross-Origin Resource Sharing) 관련 오류입니다. 이는 브라우저에서 다른 출처의 리소스를 요청할 때 발생하는 보안 문제로, 주로 API 서버와 클라이언트가 서로 다른 도메인에 있을 때 나타납니다. 오늘은 Spring Boot와 Swagger를 사용한 프로젝트에서 발생한 CORS 오류를 해결한 경험을 공유하며, CORS의 개념과 문제 해결 방법을 다뤄보겠습니다.CORS란 무엇인가?CORS는 Cross-Origin Resource Sharing의 약자로, "교차 출처 리소스 공유"를 의미합니다. 쉽게 말해, 한 웹 애플리케이션에서 실행되는 JavaScript 코드가 다른 도메인에 존재하는 리소스를 요청할 때 발생..
1. 시작하면서Spring Boot를 사용하여 API 서버를 구축하는 과정에서, 사용자의 유형에 따라 권한을 제어하는 것이 필요했습니다. 이 프로젝트에서는 다음과 같은 사용자 유형을 정의했습니다:BOSS: 관리자 역할로, 시스템 전반에 대한 접근 권한을 가집니다. 이 사용자는 주요 관리 기능을 수행하는 데 필요한 모든 권한을 갖습니다.CUSTOMER: 일반 고객으로, 특정 서비스에만 접근할 수 있습니다. 고객은 자신의 계정 정보나 주문 상태 등을 조회할 수 있습니다.ADMIN: 시스템 관리자로, 사용자 관리 및 시스템 설정을 담당합니다. 이 사용자는 시스템의 운영과 관련된 여러 작업을 수행할 수 있는 권한을 가집니다.OPEN: 권한이 필요 없는 요청으로, 모든 사용자에게 허용됩니다. 이 카테고리는 일반적..