Loop:Pak 마지막 주차인 10주차를 마무리하였다.Loop:Pak에 신청하게 된 이유는 기술적 성장이다. 다양한 기술 키워드는 알고 있지만, 관련한 질문에 대해서 답할 수 없었다.과거의 나는 어땠을까?과거의 나는 기술에 대해서는 알고 있었다. Redis, Kafka, Circuit Breaker를 개인 프로젝트에서 사용해본 경험이 있다. 그런데 합리적인 사용이 아니라, 기능보다 기술이 중점이었다. 그러다보니 어떠한 상황에 어떻게 녹여내야 하는지 모르고 있었다.물론 기술 학습을 위한 프로젝트인 것은 맞지만, 실무에서는 백엔드 개발자로서 주어진 리소스에 맞게 운용하는 것이 중요하다. 단순히 관련 코드를 짜봤다는 것만으로는 전혀 메리트가 되지 않았다.Loop:Pak을 하면서Loop:Pak을 약 10주간 하..

이번 과제에서 집계 정보를 토대로 랭킹을 구현하는 목표가 존재했다.요구사항은 다음과 같았다.“상품의 일별 랭킹을 보여주세요.”이러한 요구사항이 있을 때, 우리는 어떠한 생각을 가지고 나아가야 할까?무엇을 기준으로 랭킹을 보여줘야할까?우선 랭킹의 기준을 정의하는 것이 필요하다. 랭킹의 지표가 될 수 있는 것은 다양하다. 좋아요 수, 판매 수,조회 수가 존재했다. 그러면 이 지표들을 모두 합산하면 될까?해당 지표들을 단순 합산하여 나타낼 경우 문제가 생길 수 있다.만약 랭킹 지표가 **"좋아요 수 + 판매 수 + 조회 수”**라고 해보자. 그러면 판매와 조회가 같은 점수를 가지게 된다. 하지만 판매와 조회를 같은 선상에 두는 것은 실제 가치가 다르기 때문에 같이 봐선 안된다. 그래서 다음과 같이 가중치를 적..

🧠 이번 주에 새로 배운 것카프카란 무엇일까?분산 메세지 스트리밍 플랫폼디스크에 Log를 지속적으로 AppendConsumer는 각자의 Offset을 통해 메세지를 읽음카프카를 사용하는 이유?이벤트 물리적 저장 + 다른 사람과 주고받기 위함고가용성여러 브로커를 두어 브로커 장애 시에도 다른 브로커가 대체메세지가 들어올 때 분산 저장교체 시점의 부하가 줄어든다.파일 I/O 기반의 영속성확장성브로커, 파티션의 수평 확장으로 처리량 증가범용성메세징, 로그 수집, 이벤트 소싱 등 사용 가능토픽은 하나의 터널, 파티션은 터널 내 차선으로 비유할 수 있다.Broker카프카 서버 단위Producer의 메세지를 받아 Offset 지정 후 디스크에 저장Consumer의 파티션 Read에 응답해 디스크의 메세지 전송Pr..

카프카는 파티션 단위로 순서가 보장된다.그런데 만약 파티션 내에서 순서보장이 필요없는 작업이라면 어떻게 해야할까?예를 들어, 단순히 이벤트에 대해 감사 로그를 저장해야 하는 상황을 생각해보자. 그리고 순서를 보장할 필요가 없다고 가정하자.이 작업에서 순서대로 저장되는 것이 중요할까?순서 보장이 중요한 작업은 아닐 것이다. 또한 이벤트 생성시간을 함께 저장한다면, 충분할 수 있다.이때 감사 로그를 저장하는 것을 병렬 처리로 수행하고싶은 생각이 들 수 있다.이때 어떻게 병렬 처리를 수행할 수 있을까?Parallel Consumer이에 대한 대안으로 Confluent가 제공하는 카프카 오픈소스인 Parallel Consumer가 존재한다.물론 파티션을 늘리고 Consumer를 더 붙여서 병렬로 처리할 수도 있..

🧠 이번 주에 새로 배운 것이벤트를 통해, 하나의 작업에서 길어지는 동기 연산을 구분할 수 있다.불필요하게 긴 하나의 트랜잭션을 나누어 DB 리소스를 효율적으로 사용한다.도메인간의 결합도를 낮출 수 있다.핵심 로직과 부가 로직을 구분하여, 정합성을 맞춰야하는 것과 부가적인 비즈니스를 나누어 수행한다.‘정말 하나의 트랜잭션으로 관리해야 하는지’, ‘분리한다면, 어떻게 분리하는게 좋을지’ 좋을지 고민할 수 있게 되었다.스프링의 ApplicationEvent를 통해 어플리케이션 내부에서 이벤트 기반의 흐름을 제어할 수 있다.TransactionalEventListener: 트랜잭션 특정 시점에 이벤트 처리BEFORE_COMMIT, AFTER_COMMIT 등EventListener: 이벤트 발행 시 즉시 처리..

이번에 이벤트 테스트를 하면서 다음과 같은 상황이 있었다.@Test@DisplayName("UserActivityEvent 이벤트가 발행 됐을 때, 이를 처리한다.")void handle_userActivityEvent() { eventPublisher.publishEvent(new LikeEvent.Liked(1L, 1L)); await() .atMost(3, TimeUnit.SECONDS) .untilAsserted(() -> verify(userActivityEventListener, times(1)) .handle(any()));}class Listener { @Async @TransactionalEventListener(ph..

🧠 이번 주에 새로 배운 것서킷 브레이커를 단순히 써보기만 했었는데, 어떻게 어떠한 목적으로 쓰는지 고려할 수 있게 되었다.리트라이, 타임아웃을 설정하여 발생할 수 있는 지연, 실패에 대응할 수 있다.설정을 통해 어떤 Exception을 잡을지 관리할 수 있다.resilience4j.circuitbreaker: instances: myService: failureRateThreshold: 50 slidingWindowSize: 100 recordExceptions: - java.io.IOException ignoreExceptions: - ..우리 시스템의 장애와 외부 시스템의 장애를 분리하여, 외부 시스템 장애시 어떻게 처리할지 고민..

우리는 문제 상황에 대응하기 위하여 다양한 도구를 사용한다. 이때 Circuit Breaker, Retry 등이 사용될 수 있다.서킷 브레이커(circuit breaker)는 회로 차단기이다. 차단기는 문제 상황 시 회로를 차단하고, 어느정도 시간이 지난 뒤 기능이 동작하도록 복귀한다.리트라이 (Retry)는 일시적인 장애 상황에서 재시도를 통해 정상 응답을 받아내기 위해 사용한다.이때 위 두 개를 조합하여, 일시적인 장애 상황일 수 있으므로 재시도를 요청하고, 재시도 마저도 실패할 경우 해당 기능 실패로 분류할 수 있을 것이다.일시적인 장애 상황일 수 있으므로, 재시도를 수행한다.재시도마저도 실패한 경우, 진짜 실패가 된다.Circuit Breaker와 Retry를 함께 사용위와 같은 대처 상황을 만들..

🧠 이번 주에 새로 배운 것캐시를 적용해보고, 부하 테스트를 통해 실제 얼만큼 성능이 향상되었는지 확인할 수 있었다.실행계획을 통해 확인하고, 이를 기반으로 쿼리를 고쳐나갈 수 있었다.K6를 통해 부하 테스트를 수행할 수 있었다.카디널리티에 따라 인덱스가 효과적으로 작용할 수 있는지 고려해야 함을 알 수 있었다.조회 요청의 단일 응답 시간이 느려야만 캐시를 거는 것이 아니다.빠른 조회 연산이라도 실제 요청이 너무 많으면, DB에 불필요하게 닿지 않고 커넥션을 점유하지 않도록 캐시를 도입할 수 있다.💭 이런 고민이 있었어요캐시 자체를 코드에 적용하는 것보다, 각각 어떠한 전략으로 가져갈지 고민하게 되었다.상품 상세 조회에서 캐시를 가져야하는 이유를 크게 느끼지 못했다.상품 상세 조회는 상품 ID를 알고..

서비스의 상품 목록 조회를 개선해야한다는 미션이 주어졌다고 가정해보자.우리는 이때 무엇을 시도할 수 있을까?1️⃣ K6 성능 테스트우선 지금 현재 상황이 어느정도인지 체크할 필요가 있다고 느꼈다.현 서비스가 어느정도의 요청까지 버틸 수 있는지 알아야, 개선하더라도 얼만큼 개선된 것인지 파악할 수 있기 때문이다. 또한, 이 포인트를 알고 있어야 추후 서비스가 성장했을 때, 개선이 필요한 시점을 쉽게 잡을 수 있지 않을까 생각한다.현재 상품 목록 조회는 페이지 처리가 포함되어 있고, 상품 목록 조회 기능은 브랜드 ID 필터링과 정렬 조건(최신순, 가격 낮은 순, 좋아요 많은 순)만 있다고 가정해보자.테스트 환경은 다음과 같다.상품 약 50만 개브랜드 약 10만 개인덱스 및 캐시 적용이 거의 없는 상황상품 목..