[WIL] 카프카와 이벤트
·
WIL
🧠 이번 주에 새로 배운 것카프카란 무엇일까?분산 메세지 스트리밍 플랫폼디스크에 Log를 지속적으로 AppendConsumer는 각자의 Offset을 통해 메세지를 읽음카프카를 사용하는 이유?이벤트 물리적 저장 + 다른 사람과 주고받기 위함고가용성여러 브로커를 두어 브로커 장애 시에도 다른 브로커가 대체메세지가 들어올 때 분산 저장교체 시점의 부하가 줄어든다.파일 I/O 기반의 영속성확장성브로커, 파티션의 수평 확장으로 처리량 증가범용성메세징, 로그 수집, 이벤트 소싱 등 사용 가능토픽은 하나의 터널, 파티션은 터널 내 차선으로 비유할 수 있다.Broker카프카 서버 단위Producer의 메세지를 받아 Offset 지정 후 디스크에 저장Consumer의 파티션 Read에 응답해 디스크의 메세지 전송Pr..
[WIL] Decoupling with event
·
WIL
🧠 이번 주에 새로 배운 것이벤트를 통해, 하나의 작업에서 길어지는 동기 연산을 구분할 수 있다.불필요하게 긴 하나의 트랜잭션을 나누어 DB 리소스를 효율적으로 사용한다.도메인간의 결합도를 낮출 수 있다.핵심 로직과 부가 로직을 구분하여, 정합성을 맞춰야하는 것과 부가적인 비즈니스를 나누어 수행한다.‘정말 하나의 트랜잭션으로 관리해야 하는지’, ‘분리한다면, 어떻게 분리하는게 좋을지’ 좋을지 고민할 수 있게 되었다.스프링의 ApplicationEvent를 통해 어플리케이션 내부에서 이벤트 기반의 흐름을 제어할 수 있다.TransactionalEventListener: 트랜잭션 특정 시점에 이벤트 처리BEFORE_COMMIT, AFTER_COMMIT 등EventListener: 이벤트 발행 시 즉시 처리..
[WIL] Failure-Ready System
·
WIL
🧠 이번 주에 새로 배운 것서킷 브레이커를 단순히 써보기만 했었는데, 어떻게 어떠한 목적으로 쓰는지 고려할 수 있게 되었다.리트라이, 타임아웃을 설정하여 발생할 수 있는 지연, 실패에 대응할 수 있다.설정을 통해 어떤 Exception을 잡을지 관리할 수 있다.resilience4j.circuitbreaker: instances: myService: failureRateThreshold: 50 slidingWindowSize: 100 recordExceptions: - java.io.IOException ignoreExceptions: - ..우리 시스템의 장애와 외부 시스템의 장애를 분리하여, 외부 시스템 장애시 어떻게 처리할지 고민..
[WIL] 인덱스와 캐시
·
WIL
🧠 이번 주에 새로 배운 것캐시를 적용해보고, 부하 테스트를 통해 실제 얼만큼 성능이 향상되었는지 확인할 수 있었다.실행계획을 통해 확인하고, 이를 기반으로 쿼리를 고쳐나갈 수 있었다.K6를 통해 부하 테스트를 수행할 수 있었다.카디널리티에 따라 인덱스가 효과적으로 작용할 수 있는지 고려해야 함을 알 수 있었다.조회 요청의 단일 응답 시간이 느려야만 캐시를 거는 것이 아니다.빠른 조회 연산이라도 실제 요청이 너무 많으면, DB에 불필요하게 닿지 않고 커넥션을 점유하지 않도록 캐시를 도입할 수 있다.💭 이런 고민이 있었어요캐시 자체를 코드에 적용하는 것보다, 각각 어떠한 전략으로 가져갈지 고민하게 되었다.상품 상세 조회에서 캐시를 가져야하는 이유를 크게 느끼지 못했다.상품 상세 조회는 상품 ID를 알고..
[WIL] 동시성 이슈 제어
·
WIL
🧠 이번 주에 새로 배운 것동시성을 제어하고, 이를 테스트할 수 있는 방법에 대해서 알게 되었다.ForkJoinPool, CompletableFuture, Executor, CountDownLatch`@Transactional`의 필요성에 대해 생각해보게 되었다.JPA Transactional 잘 알고 쓰고 계신가요? | 카카오페이 기술 블로그상품 재고 차감에서 데드락이 발생할 수 있음을 알게 되었다.💭 이런 고민이 있었어요SELECT FOR UPDATE 가 거는 락의 범위가 예상과 달라서 어려웠다.한 트랜잭션에서 여러 상품의 재고 차감이 이루어지는 경우, 데드락이 발생한다.비관적/낙관적 락의 결정이 특정한 근거로 정해져야할 것 같다고 느꼈다.💡 앞으로 실무에 써먹을 수 있을 것 같은 포인트비관적 ..
[WIL] 설계 - Software Design
·
WIL
🤦 기존의 지식 & 생각 & 습관요구사항 문서로부터 도메인 개념을 뽑아낸다.설계에 대한 중요성을 직접 경험해보지 못했다.시퀀스 다이어그램, 클래스 다이어그램은 따로 작성하지 않고 개발을 진행했다.멱등성에 대해서 잘못된 개념을 가지고 있었다.🛠️ 이번 주 경험요구사항 문서 작성 (유저 시나리오 도출 -> 자연어 설명)행위 중심의 기능 목록을 정리유스케이스 흐름 작성요구사항 문서를 기반으로 시퀀스 다이어그램 작성하나의 기능에서 객체 간 메시지 흐름을 시각화클래스 다이어그램 작성도메인 개념 간 책임과 관계를 시각화엔티티/VO 분리ERD 작성🐥 경험으로부터 배운 것들문서를 작성하는 목적을 정확히 하자.내가 문서를 작성하는 목적을 정확히 해야, 문서가 전달하고자 하는 메시지가 명확해진다.요구사항과 시퀀스 다..
[WIL] TDD & 지속 테스트 가능한 구조
·
WIL
기존의 생각 & 지식 & 습관테스트의 중요성은 어느정도 알고 있었지만, 테스트를 생각하며 프로덕션 코드를 작성하진 않았다.Swagger를 적용하면, Controller에 Swagger 관련 코드가 많아져 코드를 읽기 어렵다.기능이 많아질수록 DTO 파일이 많아져, 파일 탐색이 어렵다.퍼사드는 서비스를 조립하는 역할이다.FK를 쓰지 않는 이유는 운영 편의성을 챙기기 위해서다.로그는 문제가 발생하는 경우에 남긴다.이번 주의 경험TDD 방식으로 과제를 구현단위 테스트, 통합 테스트, E2E 테스트API Spec을 인터페이스로 관리함으로써 버저닝public interface UserV1ApiSpec { @Operation( summary = "회원가입", description = "사용자 정..