🧐 서론 데이터베이스에는 트랜잭션이 존재합니다. 트랜잭션을 통해 하나의 작업 단위를 묶어서 ACID 원칙을 지키기 위해 노력합니다. 하지만, ACID 원칙이 언제나 완벽하게 지켜지진 않습니다. 너무 완벽하게 지키기 위해 어떤 상황에서라도 지키려고 한다면, 동시성이 떨어지는 문제가 발생하기 때문이죠! 그렇기 때문에 ACID 원칙을 적절하게, 상황에 맞게 유지시키면서 동시성을 높일 수 있게 DB에서 기능을 제공합니다. 바로 Isolation level을 통해서요! (트랜잭션에 대한 추가 설명은 이전 글을 참고해주세요!) 결국, Isolation level 별 적절한 Lock을 진행하고, 이는 DBMS마다 다릅니다. 저는 MySQL InnoDB 기준으로 어떤 Lock이 있는지 알아보도록 하겠습니다. 🫢 본론 ..
😏 서론 개발을 하면서, 유니크한 값을 사용할 일이 많습니다. 예를 들어 PK가 있을 수도 있고, 쿠폰번호가 있을 수도 있고, 결제번호가 될수도 있습니다. 유니크한 값을 만드는 방식들은 어떤 게 있고, 어떤 상황에 어떤 방식을 사용하는 게 좋을지 정리를 해보겠습니다. 😎 본론 먼저 3가지의 유니크 ID를 생성 종류에 대해서 알아보고 각각 어떨 때 적용하면 좋을지에 대해 개인적인 생각을 적어보겠습니다! 1. RDBMS 의 Auto Increment 디비에서 자동으로 만들어주는 자동증가 값으로 PK 용도로 사용된다. 장점 구현이 매우 간단하다. 숫자 증가기 때문에 재정렬이 필요 없다. 순서가 보장된다. 물리삭제가 되지 않는 특성의 테이블의 경우 마지막 row id 값만으로도 대략 테이블 데이터의 수를 파악할..
😢 서론 KakaoPay API 통신을 feign client를 통해 진행하는 중 POST로 form-urlencoded 타입으로 전송해야 하는데, @JsonNaming 애노테이션이 form-urlencoded 타입에서는 정상적으로 작동하지 않아 해결한 내용을 정리해봅니다.. ㅜ 이 글은, feign Client를 통해 요청을 보내는 방법을 정리합니다. 본인의 서버 컨트롤러로 받는 방법으로는 여기 에서 많은 해결책이 나와있습니다. 참고 바랍니다!! 🫢 본론 FeignClient @FeignClient(name = "kakaoPay", url = "https://kapi.kakao.com/v1", path = "/payment", configuration = CoreFeignConfiguration.cla..
😢 서론 처음에 설정했을땐 logging not working.. logging이 작동하지 않아 간단하게 정리해봅니다. 🙂 본론 public class CoreFeignConfiguration { @Bean Logger.Level feignLoggerLevel() { return Level.FULL; } } @FeignClient(configuration = CoreFeignConfiguration.class) public interface KakaoPayClient { ... } 코드를 추가해도 로깅이 찍히지 않아서 검색해본 결과 application.yml 에서도 logging을 설정해주어야 했었습니다. Fiegn Client가 포함된 패키지 혹은 클래스에 대해서 Spring Boot 로깅 수준을 D..
🫣 서론 스프링 클라우드 gradle 설정 시 만난 오류.. 🔥 본론 [main] ERROR org.springframework.boot.SpringApplication - Application run failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'configurationPropertiesBeans' defined in class path resource [org/springframework/cloud/autoconfigure/ConfigurationPropertiesRebinderAutoConfiguration.class]: Post-processing of merged bean ..
🥸 서론 현재 진행 중인 Ticketing 프로젝트는 시스템이 분리되어있다는 가정 하에 진행된 프로젝트입니다. 여기서 결제시스템에서는 어떤 유저가 결제했는지에 대한 정보가 있어야 합니다. 처음 설계 당시에는 유저 PK 값을 넣어서 사용하려 했지만, 몇 가지 문제가 있어서 대체 유니크키 생성을 결정하게 되었고, 그 내용을 정리해보려 합니다. 😎 본론 기존 ERD 구조입니다. 여기서 Payment 에서 User의 pk 값을 가지고 있죠. 고민의 시작인 API의 간단한 Sequence Diagram 입니다. 여기서 결제 목록 요청을 할 때 각 유저의 고유한 값을 Payment에서 가지고 있어야 유저의 결제 목록을 응답해줄 수 있습니다. 여기서 기존엔 User의 PK를 사용했는데, 왜 고민했는지 Email, U..
😏 서론 현재 제가 진행 중인 토이 프로젝트는 '영화예매' 주제로 진행 중에 있습니다. 테이블 설계 이후 구현 단계에서 다른 테이블에 중복 컬럼을 왜 추가하게 됐는지 정리해보려 합니다. (많이 History 느낌의 글입니다.) 🥹 본론 현재 프로젝트 상황 패키지 시스템 구조는 아래와 같습니다. 나중에 MSA 구조로 분리하기 위해 현재는 패키지만 분리해둔 상태입니다. ERD 영화 서비스에선 5개의 테이블 결제 서비스와 유저 서비스에선 각각 1개의 테이블이 있는 구조입니다. 요구사항 분석 회원 결제목록 조회 로그인된 사용자의 정보를 이용해서 결제 목록을 얻어온다. 결제목록은 영화제목, 금액, 결제상태가 존재한다. 요구사항을 위해서는? 결제목록을 가져오는 요구사항은, 현재 설계된 모든 서비스를 거치게 됩니다...
🧐 서론 테스트를 돌릴 때 통합테스트는 Spring을 올리기 때문에 생각보다 긴 시간을 잡아먹습니다. 현재 프로젝트에서 통합테스트가 별로 없음에도 통합테스트와 유닛테스트 구분 없이 한 번에 돌리다보니 시간이 비효율적이라고 느꼈고, 환경을 분리해야겠다고 생각이 들어 내용을 정리해보겠습니다. 참고 참고로 gradle은 Groovy 가 아닌 Kotlin 으로 진행된 점 참고하여 봐주시길 바랍니다! 😎 본론 build.gradle.kts 설정 sourceSets { create("intTest") { compileClasspath += sourceSets.main.get().output runtimeClasspath += sourceSets.main.get().output } } val intTestImplem..
