Redis가 단일 스레드(single-threaded)로 설계된 이유는 주로 성능 최적화, 복잡성 감소, 그리고 데이터 일관성을 유지에 있습니다.단일 스레드 모델은 멀티스레드 모델에 비해 설계와 구현이 상대적으로 간단합니다. 멀티스레드 환경에서는 동시성 문제(레이스 컨디션, 데드락 등)를 처리하기 위해 복잡한 동기화 메커니즘이 필요하지만, 단일 스레드 환경에서는 이런 문제를 자연스럽게 회피할 수 있습니다. 동시에 여러 스레드가 동일한 데이터를 수정하려고 할 때 발생할 수 있는 데이터 불일치 문제를 방지합니다. 모든 명령어가 순차적으로 처리되기 때문에, 복잡한 락(lock) 메커니즘 없이도 데이터의 일관성을 자연스럽게 유지할 수 있습니다.Redis는 주로 메모리 내에서 빠르게 수행되는 I/O 작업을 처리하..

JWT(Json Web Token) 은 통신 정보를 JSON 형식을 사용하여 안전하게 전송하기 위해 사용됩니다. JWT는 토큰 자체에 정보가 포함되어 있는 클레임 기반 토큰입니다. 일반적인 애플리케이션에서 JWT는 주로 인증과 인가를 구현하기 위해 사용됩니다.  JWT는 헤더, 페이로드, 시그니처로 구분됩니다. 헤더에는 토큰의 암호화 알고리즘이나 타입을 가지며, 페이로드에는 데이터(만료일, 사용자 정보 등)을 가집니다. 시그니처는 헤더와 페이로드가 변조되지 않았는지 판단하기 위해 사용되는데요. 헤더와 페이로드를 비밀 키를 사용하여 헤더에 명시된 암호화 알고리즘으로 암호화하여 시그니처가 만들어집니다. JWT를 사용하여 인가를 구현하는 경우, 클레임 기반 토큰의 특성 덕분에 세션 기반 인증에 비해서 사용자 ..

프로젝트 진행 중 불필요한 연관관계를 끊고, 조회 성능을 향상시키기 위해 Post 테이블에 member 정보에 대한 컬럼을 추가했었다. 컬럼을 추가할 생각을 가졌을 때에는 당장 연관관계보다의 장점만을 생각하면서 진행하였지만 막상 적용하고 나서 보니 단점도 보이기에 이 글을 적게되었다. 단점으로는 데이터 일관성이 있겠다.닉네임이 member_A 인 회원이 글을 작성하면 해당 post의 작성자 닉네임은 당연하게도 member_A 이다.하지만 이후 member_A가 닉네임을 member_B로 수정을 한 후에도 이전 post의 작성자 닉네임은 member_A 이다.여기까지는 예상을 했던 상황이고 그저 post 수정 시 새로 업데이트 해주면 되겠다 생각을 했다.하지만 또 다른 회원이 member_A로 닉네임을 수..

첫 번째 문제 발생flyway로 DB 스키마 변경하는 테스트를 로컬에서 마치고, 개발 서버에 적용을 했을 때 발생한 오류이다.org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]:Failed to initialize dependency 'flyway' of LoadTimeWeaverAware bean 'entityManagerFactory': Error creatin..

Flyway로 생성된 flyway_schema_history 테이블에는 스키마 변경 내역이 저장되는데 만약 V2 스크립트 파일을 마이그레이션하다가 오류가 발생하게 된다면, flyway_schema_history 테이블에는 V2에 대한 실패 내역이 저장되게 된다. 이후에 실패한 원인을 찾아 V2 스크립트 파일의 명령어를 수정하고 다시 실행한다 해도 이미 V2에 대한 실패 내역이 남아있기 때문에 해당 버전은 flyway가 실행하지 않는다. 그렇다면 수정한 코드로 V3를 새로 만들어서 실행해야하느냐? 물론 이 방식도 존재하지만 간단한 오류를 고치기 위해 항상 새로운 버전을 생성해야하는 것은 번거로운 방법이라 볼 수 있다. 그러면 기존에 에러나 스크립트 파일을 수정한 뒤에 어떻게 다시 적용할 수 있을까?해결방법..

이전 글에서도 말했듯이 이번 포스팅에서는 로컬 데이터베이스에 스키마 구조를 변경해보고 flyway를 통해 제대로 적용이 되는지 확인해보겠다.Entity 구조 변경ddl-auto: validate 로 설정해뒀기 때문에 Entity와 DB 테이블의 구조가 같은지 비교하고 유효성 검사를 위해 앞으로 변경할 DB 스키마 구조에 맞게 entity도 변경해줘야 한다. Member Entity와 연관관계 매핑 되있던 것을 끊고 회원 아이디, 이메일, 닉네임 컬럼을 추가한다. 현재 CodePost, TILPost 테이블 두 개가 존재하기 때문에 각 Entity 구조를 아래와 같이 변경하면 되겠다.연관관계와 관련된 로직들의 수정 코드는 따로 작성하지는 않겠다.// member 컬럼 삭제// @ManyToOne(fetch..

프로젝트 리팩토링을 진행 중에 code post와 member 테이블 간의 연관관계를 끊어야 할 상황이 생겼기 때문에 고민하게된 내용이다. 대부분의 개발자들은 업데이트를 진행하면서 데이터베이스의 구조를 변경할 상황이 무조건적으로 생길 것이라 생각한다.이때 이미 배포된 데이터베이스의 정보를 수정하고 다시 배포해 버리면 이전 데이터와 새로운 데이터 간의 차이가 발생하고 만다.이를 해결하기 위해서는 손수 개발 DB와 운영 DB에 DDL, DML 명령어를 사용하여야 한다. 하지만 그럴 경우 개발자의 실수 즉, 휴먼 에러로 인해 두 DB 간의 구조가 불일치할 수 있는 경우가 생길 수 있다.이러한 상황을 방지하고자 DB 형상 관리 도구인 Flyway를 도입하고자 한다.Flyway 란?Flyway는 데이터베이스의 형..

응집도(Cohesion) 는 모듈에 포함된 내부 요소들이 연관되어 있는 정도를 나타냅니다. 결합도(Coupling) 는 의존성의 정도를 나타내며, 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타냅니다. 응집도와 결합도는 변경과 관련이 깊으며, 일반적으로 좋은 설계란 높은 응집도와 낮은 결합도를 가진 모듈로 구성된 설계를 의미합니다. 객체의 행동에서 객체가 알고 있는 모든 정보를 사용하거나, 변경이 존재하는 경우 특정 모듈만 수정되면 응집도가 높다고 판단할 수 있습니다. 또한, 특정 모듈을 변경하는 경우에 다른 모듈도 변경해야 하는 상황에서는 결합도가 높다고 판단할 수 있습니다.캡슐화의 정도가 응집도와 결합도에 영향을 미치는데요. 캡슐화를 지키면, 모듈 안의 응집도는 높아지고 모듈 사이의 결합도는..