Choi Eun Kang 👋

Q. 인상깊었던 주제는 무엇이었나요? 분산락과 캐시 전략중 어떤 주제가 더 인상깊었나요? 항해를 하기전 레디스를 사용해왔을때는 JWT 토큰정도로만 해왔습니다. Key value 기반 NoSQL 데이터베이스인 레디스가 단순히 캐싱의 역할을 하지 않고 Lock으로서의 역할을 할 수 있다는걸 이번과제를 통해 새로알게됐습니다. 또한 읽기와 쓰기에서의 캐싱전략이 여러가지가 있다는걸 처음알게됐습니다. 해당 개념을 통해 어떤 구조적/성능적 문제 해결을 가능성을 느꼈나요? 아직까지는 과제를 수행해보면서 어느점이 문제인지, 그에 대한 해결은 무엇인지에 대한 답변이 명확하지 않았습니다. 그래도 떠오르는 한가지는 캐싱쪽에서는 트랜잭션을 접근하기전에 캐시저장소(redis)에서 캐시히트가되면 빠른 응답을 해줄 수 있다는 점입니다....

동시성 문제 (RaceCondition) 여러개의 스레드가 같은 공유자원에 대해서 동시에 읽기/쓰기 접근 요청할 때 공유자원의 데이터의 정합성이 깨지는 현상. 데드락 (DeadLock) 1 2 3 4 화장품가게 에는 립밤 1개, 스킨로션 1개 를 판매하고 있다. - 손님 A가 립밤 1개를 집었다. - 손님 B가 스킨로션 1개를 집었다. 손님 A 는 (B가 집은) 스킨로션을 원하고, 손님 B 는 (A가 집은) 립밤을 원한다. 손님 A의 입장에서는 손님B가 스킨로션을 내려놓을 때까지 기다려야하고 손님 B의 입장에서는 손님A가 립밤을 내려놓을 때까지 기다려야한다....

만능은 없다. TradeOff는 있다. 읽기 성능이 좋으면 쓰기성능이 구리고, 쓰기성능이 좋으면 읽기성능에 구려진다. 정규화 쓰기성능을 높임으로써 데이터 중복을 줄이고 일관성을 높인다. 반정규화 읽기성능을 높임으로써 일부 중복을 허용한다. 트랜잭션 격리 수준 Uncommitted Read - 커밋되지 않은 읽기 다른 트랜잭션에서 커밋되지 않은 데이터에도 접근하게 할 수 있는 격리수준 DirtyRead: 커밋되지 않은 트랜잭션에 접근해서 아직 정상반영되지 않은 데이터를 읽는 현상 (해당 데이터는 롤백되어 없어질 수도 있다) Committed Read - 커밋된 읽기 다른 트랜잭션에서 커밋된 데이터에만 접근할 수 있게 하는 격리수준 Non-Repeatable Read: 하나의 트랜잭션에서 동일한 SELECT 쿼리문을 실행했을 때 커밋전의 데이터와 커밋후의 데이터가 읽히면서 다른결과가 생기는 현상 Repeatable Read - 반복가능한 읽기 커밋된 데이터만 읽을 수 있으며, 자신보다 빨리 수행된 트랜잭션에서 커밋한 데이터만 읽을 수 있는 격리 수준...

서론 단위테스트의 목데이터를 만들때 생성자를 호출하게되어 연관관계를 갖는 도메인을 setter로 설정시켜서 목데이터를 생성하는데 점점 무거워지는 불편함을 겪었습니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 @Test void 신규_임시예약상태의_예약도메인_생성에_성공된다() { // given long userId = 1L; long concertSeatId = 1L; User user = new User(userId, "은강"); Concert concert = new Concert(1L, "항해와 함께하는 TDD 단위테스트 콘서트", "항해플러스"); // 👈 도메인 엔티티 생성자를 직접호출!...

ERD 개선하기 보완피드백1: 유저와 토큰 테이블 분리하기 보완피드백2: 테이블의 역할을 고민해서 만들기 payments 라는 엔티티에 금액정보가 없어서 책임을 다하지 못할 수 있음. As-Is (1차 설계) To-Be (2차 설계) 테이블개수를 6개 -> 8개 로 확장했습니다. 토큰(tokens) 테이블 추가 포인트 내역(point_histories) 테이블 추가 payments 테이블에 결제금액(price) 를 추가하여 결제에 대한 책임을 부여했습니다. 2차 설계안 고민포인트 1번을 참고하여, 날짜에서 예약가능여부(is_available)을 추가했습니다. ERD 2차 설계안 고민포인트 대기열토큰의 대기순서를 나타내려면, 토큰테이블에 대기순서를 기재하는게 좋을까요 아니면 대기열큐를 하나의 테이블로 나타내어 대기순서를 기재하는게 좋을까요?...

멘토링하면서 깨달은 점 객체에게 책임을 부여시켜서 분리를 한다면 TDD 도 가능합니다. 우리는 그동안 코딩을하면서 API를 설계하고 개발했다. 코딩으로 설계를 할 수 있다 하지만 견고하거나 명확하지 않을 수 있습니다. 명확한 설계가 뒷받침된다면 코딩은 단순히 명확한 설계를 구체화하는 수단이 될 수 있습니다. 과제 발제시간에 발제 코치인 허재님이 말씀하신 부분이 기억이 남습니다. 설계가 명확하면, “코드를 치는 행위” 는 목표를 달성하는 “수단” 이 된다. 설계가 명확하지 않으면, “코드를 치는 행위” 는 불필요한 “노동” 이 된다....

서론 API명세서는 프론트엔드와 백엔드간의 협업을 위해서 가장 필요한 도구입니다. 백엔드 개발자는 API를 설계하고 공유할때 API명세서를 만듭니다. API 명세서를 다루는 대표적인 툴로는 Swagger가 있습니다. 이번에는 Swagger 을 도입하는 과정과 중간에 겪은 트러블슈팅 해결과정 그리고 더나아가서 직접 github-action으로 배포하는 과정을 공유해보도록하겠습니다. 스프링부트에 스웨거 도입하기 Java: 17 SpringBoot: 3.4.4 build.gradle 에 추가하기 1 2 3 4 5 6 7 dependencies { // Swagger UI implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2' ...생략... } application.yaml 에 추가하기 1 2 3 4 5 6 7 8 9 10 11 spring: application: name: hhplus-concert ....

멘토링하면서 깨달은 점 통합테스트/유닛테스트 의 범위는 정해져있지 않다. 통합테스트에 대한 최소 기준은 내가 호출할 친구가 통합테스트로 검증되어있는지 확인을 합니다. 단위함수가 아닌 2개이상의 함수나 외부의존성이 있는지 e2e 관점으로도 통합테스트를 할 수 있다. 비개발자 를 대상으로 내부동작보다는 호출했을때 실질적은 결과를 보여주는 테스트도 괜찮은 편. 가까운 대상을 테스트하는게 좋다 DTO입장에서는 서비스 메서드함수 한개가 통합테스트가 될 수도 있다. 단위테스트는 테스트 대상외의것들을 (서비스의 의존성을 비롯한 테스트 대상에는 해당되지않지만 서비스에 연결되어있는 대상들을) Mocking 을 해야한다. 객체에게 책임을 부여하면 불필요한 코드를 제외할 수 있다....

동시성제어를 테스트하는 것은 단위테스트에 적합할까? 통합테스트에 적합할까? JVM 내에서 동시성테스트를 하려고한다면, synchornized, ReentrantLock, JVM 내 큐(queue)를 사용하는 방법이 존재합니다. 그러나 동시성제어를 테스트할때 통합테스트에서 실행해야되는건지 아니면 유닛테스트에서 테스트를 해야될지 애매할겁니다. 단위테스트는 가장 작은 테스트인만큼 1개 메서드/함수 단위로 독립적인 기능을 빠르게 검증하기 위한 테스트입니다. 동시요청이 발생할 때 큐를 이용해서 순서를 제공해주거나 잠금(locking)연산을 수행하여 다른요청이 접근하지 못하도록 막거나, 큐를 이용해서 순서를 보장해줘야하는 역할까지 검증을 해야되기 때문에 단위테스트만으로는 어려울거같습니다. 즉, 동시성은 여러개의 스레드가 동시에 접근하거나 실행될 때 발생하는 문제를 검증해야하므로, 단일 스레드 환경에서 실행되는 단위테스트만으로는 동시적인 상황을 재현하기가 어렵습니다....

목적 UserPointService 의 충전/사용 메서드를 리팩터링한다 절차지향적인 코드를 객체지향적으로 변경해보자 냄새나는 코드? 포인트 충전 로직 개선시키기 수정 이전 (절차지향적) 포인트 충전 내부로직 플로우 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 // PointServiceImpl.java @Service @RequiredArgsConstructor public class PointServiceImpl implements PointService { @Override public ChargeResponse charge(ChargeRequest request) { long id = request.id(); long amount = request.amount(); UserPoint userPoint = this....