문제 상황 & 접근하나의 API에서 Github API 4개와 블록체인을 접근하며 API Latency 대략 5s바로 데이터를 응답하지 않아도 되는 API 이므로 비동기 처리 적용 적용producer - consumer 를 통해 비동기 처리 적용에러 발생시 일정 횟수 재시도 이후 DeadLetter 처리주요 에러는 OpenAPI Timeout, RateLimit 에러여러 단계에 걸친 로직은 없었으며 실패한 Topic명, Payload, 시각 등을 DB에 저장관리자 이메일로 관련 정보를 보내 확인할 수 있도록 구현결론부하테스트를 통해 평균 Latency를 확인하였다.API Latency 21.27배 개선데드레터를 바로 확인할 수 있으며 DB에 저장된 데드레터 정보 확인으로 장애 상황에 대응 가능동기 처리 ..
문제 상황 & 접근DB 페이징 쿼리 기반으로 랭킹을 조회하는데 있어 성능이 좋지 못함오프셋 기반 페이징이라 데이터가 많아질 수록 느려지기에 Redis를 통해 랭킹 시스템을 구축하고자 결정 적용기존 쿼리Pageable 를 통해 데이터베이스의 데이터를 정렬하여 오프셋 기반 페이징을 수행한다.where 절의 조건은 랭킹에 포함할 멤버인지 확인하는 정도의 조건이다.DB에서 순위를 매겨야 하기에 정렬은 불가피 했고, 서비스 요구사항에 의해 페이징도 필요했다. (요구사항이 아니더라도 많은 데이터가 있는 경우 페이징이 없다면 전체조회는 위험하다.) Redis의 자료구조 중 하나인 Sorted Set은 member를 score 기반으로 정렬하여 저장한다.순위를 매겨 조회해야하는 경우 효과적이다.페이징과 같이 부분만 ..
요구사항유저는 지인들과 그룹을 만들 수 있으며, 그룹 내에서 서로 어느 위치에 있는지 휴대폰 화면으로 확인할 수 있어야 한다.특히나, 두 명 이상의 유저가 가까운 거리에 있는 경우 느리게 업데이트되면 빠르게 위치를 파악하지 못해 만나는데 서비스가 크게 도움이 되지 않을 것이기에 3초에 한 번 자신의 위치를 클라이언트에서 공유하여 그룹 전체 인원에게 알린다.문제 상황 - 실시간 공유 기술 선택양방향 실시간 위치 공유 구현을 위한 기술 선택 필요요구 사항[실시간성] 실시간으로 확인할 수 있도록 낮은 지연 시간 요구됨변화 시점마다 그룹원의 위치 파악 필요[양방향 지원] 양방향으로 데이터를 공유각 그룹원이 데이터를 서버에 보내면 나머지 그룹원이 데이터 받아야 함[높은 업데이트 빈도] 각 유저는 3초 주기로 데이..
문제 상황동시에 여러 번 호출할 경우 DB 데이터가 중복 저장되는 현상 빈번히 발생한 번의 요청에 종류가 다른 4가지 멤버의 기여도를 가져와 하나의 같은 테이블을 업데이트, 다른 한 테이블에는 insertDB Lock 적용DB Lock을 통해 데이터의 중복 저장을 막을 수 있을 것이라 기대시도 1 : @Version 기반 낙관적 락성능을 생각해 낙관적 락을 먼저 걸어보기로 했다.Jpa 엔티티에 @Version 필드를 추가해 락을 적용한다.다중 요청시 version 필드의 충돌로 인해 롤백이 자주 발생했다.쓰기 작업에 더 높은 수준의 락이 필요하다고 느꼈다.시도 2: 공유락읽기 작업에는 락이 걸리지 않아도 되었기에 공유락을 선택했다. (이전의 데이터를 읽어도 큰 상관은 없었다.)사용할 JpaReposito..
Latency 3.52s -> 454ms 로 쿼리를 7.7배 개선한 작업을 공유하고자 합니다. 문제 상황 & 고민 서비스의 핵심 API의 Latency가 데이터가 몇십만 건이 쌓이는 경우 성능적 개선이 필요했습니다. 해당 API에서 사용하는 DB 조회 쿼리 개선이 필요하다고 판단했습니다. 개선 작업 약 41만 건의 랜덤한 데이터 삽입 이후 K6를 통해 부하테스트를 통한 평균 Latency를 확인하며 진행했습니다. 부하테스트의 경우 같은 조건으로 5번 이상씩 수행하며 평균에 가까운 값을 확인했습니다. 1. 초기 상태 [3.52s] 어떤 작업도 하지 않은 상태에선 조회 API Latency가 3.52초가 걸렸으며, 이로 인해 개선 작업을 시작했습니다. 서비스의 가장 중요한 결과 조회 API 이었기에 더더욱 ..
재검토중 이 글에서 설명하는 방법으로 이슈가 해결되지 않음을 확인했습니다. 하나의 탐구과정으로 봐주시면 감사하겠습니다.문제의 발생ObjectMapper의 NamingStrategies를 여러개 쓰이게 되는 상황이 발생했다.여러 종류의 외부 API를 반영하는 서비스였기에 외부 API 마다의 json 네이밍 컨벤션이 달랐다.특히, 하나의 NamingStrategies가 늘어날 때 마다 ObjectMapper에 대한 빈을 하나 더 등록하면서 주입 받을 때도 빈이 여러개라서 신경을 써야 하는 등의 불편함이 발생했다.이 문제를 해결하는 방법을 찾던 중, 디자인 패턴인 Composite 패턴을 통해 해결하기로 했다.Composite 패턴이란?Component 라 불리는 최상위 클래스와 Leaf, Composite ..