문제상황사용자 경로 제공에 있어 Kakao, Naver, Tmap Open API를 사용하였고 Open API에 장애가 발생한 경우 처리에 있어 유연한 처리가 필요함을 느낌장애가 발생하더라도 지속적으로 [OpenAPI 요청 -> 예외 발생] 이 반복되는 상황다음과 같은 부분이 가장 개선하고 싶었다.지속적으로 네트워크를 활용해 요청하는 부분어차피 데이터를 못 받아오는데, 매번 요청하여 에러를 반환할 때까지 기다리는 부분이러한 자잘한 문제도 있었다.DB를 같이 활용하는 API의 경우 OpenAPI 정보를 제외한 정보는 반환하고 싶은데, DB 정보까지 반환 못하는 부분(사실 이 부분은 모든 OpenAPI 로직에 try-catch 코드를 넣으면 해결은 가능하다.)접근Resilience4j를 통해 Open API..
Redis Cache 성능 비교문제상황사용자에게 지명 정보, 경로를 제공하기 위해 Kakao, Naver, Tmap Open API를 사용한다. 위 API 제공에 있어 호출까지의 시간이 소요되고 비용 낭비가 발생이미 반환된 정보를 사용자가 재사용하는 경우가 많기 때문에 경로를 임시 메모리에 저장하는 로직 필요데이터 특성 상 한번 참조된 값에 대해 변경이 자주 일어나지 않음접근Redis Cache를 이용하여 Open API의 반환값을 일부 저장하여 사용자에게 제공적용@CachePut과 @Cacheable Annotation을 사용하여 API에 레디스 캐시 적용캐시 적용시 동작 흐름 @CachePut과 @Cacheable을 사용하는 API 분리 (동일 로직 수행)위와 같이 API를 분리해 구현한 이유사용자가..
문제 상황 & 접근FCM 오류 처리그룹 초대 , 친구 요청 서비스를 수행하는데 있어 FCM을 사용했다. FCM 자체의 성능 개선을 위해 RabbitMQ을 사용함. FCM 요청에 있어 오류가 발생할 경우 처리를 위해 데드레터 처리비동기 적용FCM 자체는 동기방식이기 때문에 짧은 시간에 많은 요청이 수행되는 경우 성능상 개선 필요, 메시지 큐를 사용하여 비동기 방식으로 처리적용queue 설정알림을 위한 RabbitMQ queue에서 발생한 오류는 데드레터로 메시지가 전달되도록 연결하였다.producer알림관련 정보 즉, rabbitmq로 발행할 메시지 정보들을 db에 저장한 이후 rabbitmq로 알림 발송을 위한 메시지를 발행한다.consumerFCM을 통해 알림을 발송한다.db에 저장된 알림 관련 Ent..
문제 상황‘이길저길’ 서비스 내에서 친구 검색 시 Member의 닉네임(문자열)으로 검색을 수행하는 API가 있고 기존 Like 검색은 데이터의 개수가 많아질수록 성능에서 부족함이 있었다.Like 연산시Member 데이터를 500만 row 저장하고 특정 닉네임을 검색하는 쿼리를 Like 연산을 이용하여 수행하였다.준비 작업 (프로시저)sql로 프로시저 작성 (그대로 실행하면 500만개의 member를 insert한다)기존 자바 코드로 500만개를 넣으려 시도하니 heap 영역의 공간이 없어 error 발생DELIMITER $$DROP PROCEDURE IF EXISTS twtw.insertLoop$$CREATE PROCEDURE twtw.insertLoop()BEGIN DECLARE i INT DE..
문제 상황 & 접근매우 느린 Github API를 사용해야 했으며 바로 데이터를 response 해야 함Github Repository의 기여자들의 기여도(커밋, addition, deletion)와 기여자 정보를 가져오는 API Github Repository -> Insights -> Contributors 탭에 브라우저를 통해 들어가면 매번 분석을 위해 어느정도 Delay 이후 정보를 확인할 수 있다. 사용하고자 하는 Github API가 해당 정보들을 가져오기 때문에 느린 것으로 예상된다. 문제가 생긴 Github API 의 특징맨 처음 호출시 202 상태코드 response 및 계산 시작계산이 끝나면 그 다음 호출시 데이터 반환하며 비동기 호출 방법을 제공하지 않음평균 7초 이상 소요되며 최대 ..
문제 상황 & 접근하나의 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 기반으로 정렬하여 저장한다.순위를 매겨 조회해야하는 경우 효과적이다.페이징과 같이 부분만 ..